Skip to main content

I'm navigating the tricky waters of mobile attribution in 2023 for our iOS app and could use some community insights.

 

We're looking to collaborate with affiliates and influencers and are hoping to attribute post-install purchase events to individual affiliates/campaigns etc.

 

Ideally, we’d like to avoid having to display the AppTrackingTransparency (ATT) prompt and be able to honestly answer that we do not fall under Apple's definition of “Tracking” in AppStore Connect. As you will know, the mobile attribution market is adapting to many changes in privacy standards, so this isn’t straightforward.

 

Option 1: Deep Links

We're considering using deep links tied to individual affiliates/campaigns. Is this viable when users haven't consented to the ATT prompt? Without the ATT agreement, how would this affect the capabilities of attribution partners like Branch.io or AppsFlyer?

Perhaps relying on SKAdNetwork integration and other techniques? I haven't gotten a straight answer on what impact this would have from the Attribution Partners themselves (Branch/AppsFlyer). It would be good to know how their ability to attribute purchases to individual affiliates and marketing channels would be affected without ATT, how many attributions are lost? Or how many false positives are generated?

 

Option 2: Unique Affiliate Codes

Alternatively, we're thinking of the more old-school approach of using unique codes (e.g., BOB10) that affiliates can share. This would give users a discount and credit affiliates based on code conversions. Has anyone gone this route? If so, how did you manage the affiliates, payments, codes etc?

We've looked at Track Desk and Post Affiliate Pro for managing the unique codes but haven't landed on a solution yet.

 

If anyone has any insights or experiences to share, especially about the ATT prompt and its implications, that would be fantastic.

 

Thanks in advance for your help!

 

Hi @Roycroft,

 

For Option 1 - any integration that requires collecting the IDFA paramater on iOS requires importing the AdSupport Framework and so requires ATT consent. So the answer here depends on if you are hoping to collect IDFA and also if the attribution provider you’re using requires at all. Not all of them do, but many at least recommend it. If you don’t want to collect IDFA and the attribution provider doesn’t require it, then you can avoid importing AdSupport and wouldn’t need ATT consent. 

As far as longterm effects of not collecting this information, it’s tough to say. Attribution does work better if able to collect all advertising identifiers, and if they reject ATT consent then we simply have less information on them. 

 

For Option 2, hopefully another developer who has implemented this can chime in, since this is outside the scope of RevenueCat.

did you end up solving this? 

Im considering testing branch’s links without ATT. Difficult to get a clear answer on if they will work or not, but I’ll probably try. 

 

Also considering option 2. My plan was just to generate codes myself in App Store connect and track when a user triggers one in firebase. Calculate payouts at end of each month. Seems relatively simple to set up.

Hey ​@alex-simpson-407c60, this fell down our todo list. The last I looked into it I was leaning toward using a service like trackdesk to help with managing the affiliates. It would work something like this using the RC Webhook:

  1. A user enters a discount code in our app
  2. We attached this discount code to their RC identity
  3. When the purchase converts ( when the trial period is over) the revenueCat webhook fires.
  4. A cloud function receives this event and passes to the trackdesk endpoint, including the purchase amount, currency, and discount code.

!-->

Reply


Terms & ConditionsCookie settings