AppTrackingTransparency FAQ

The Branch SDK does not trigger the ATT modal. If you want to implement it, we have provided an example code snippet for how to invoke the ATTrackingManager class here.

You may also refer to Apple's documentation here.

No, it is not necessary to implement the AppTrackingTransparency prompt in order to use Branch: there are many valid Branch use cases that do not fall within the scope of Apple's policies on 'tracking', including deep linking and measurement of owned/organic channels.

For more information, please see these FAQ items:

• What counts as an 'ad' and 'tracking' under Apple's policy language?

• Are owned channels under the scope of Apple's new policy?  

• Are organic/earned channels under the scope of Apple's new policy?

• Does Apple's new tracking policy block deep linking?

If you choose to show the ATT modal, you will simply continue receive device-level data from Branch for ad conversions when the user opts in on both ends.

We published a blog post on this recently, but here are a few high-level thoughts:

Showing the ATT prompt clearly interrupts your app's user experience. That's why most companies we spoke to originally expected to forgo access to IDFA with iOS 14 in order to avoid that interruption. The revised January 2021 language from Apple likely means that the ATT prompt will become the “GDPR cookie banner” of 2021 for companies that want any degree of access to device-level ads attribution.

If Apple's latest guidance means you're newly re-considering that approach, the good news is that we have initial best practices data from a few sources:

• Data on efficacy from companies that did originally plan to use the prompt and have tested mock scenarios since September (with opt-in rates as high as 40%).

• Long-term learning from other permission prompts (think geolocation, push notifications, etc.).

• Visible testing approaches from companies with tremendous scale, like Facebook.

First and foremost, go soft-prompt first. This means providing context about what the user is about to be asked right before you trigger the Apple-mandated modal. The “official” language can be a little scary from a user perspective, so providing a voiceover about why you’re about to ask for this permission is critical.

Our recommendation for the soft-prompt itself comes down to three core tenets:

• Show value to the user. Any company worth their salt wants the best experience for their users. How will approving this ask help your users? Could it include increased personalization, access to rewards, special benefits, or fewer ad interruptions? When a user can see how this will benefit them personally, you’re more likely to get their informed consent.

• Consider the timing. Onboarding is always a delicate process, so while getting approval for ATT is critical, consider when to best make the ask from a user perspective. Consider floating your modal after an early “success” that ties into the user value you plan to highlight.

• A/B test with rigour. Your paid media team has testing built into their DNA. Apply that mentality to the copy, creative, timing, and highlighted value prop that accompany your soft prompt. Work as a cross-functional marketing, product, and data team to guide your process.

So when should you start testing?

• Start testing your soft-prompt prior to iOS 14.5 with scoped audience segments. That way you can get a sense of what resonates best with new users from different install sources while IDFA is still available, and you can easily assess impact on down-funnel behavior

• Integrate the Apple modal whenever your dev team has time in the next month, but keep the actual modal behind a flipper until iOS 14.5 release. No need to reduce data availability before it’s necessary and if you trigger the modal today, IDFA will be zero’d out unless your user accepts ATT.

We have provided an example code snippet for how to invoke the ATTrackingManager class here.

You may also refer to Apple's documentation here.

Deciding if/when to prompt a user for tracking permission is completely up to the developer. The Branch SDK will not trigger the modal.

• If you do not implement the modal, IDFAs will not be collected and device-level ad data will not be available.

• If you implement the modal, any events that occur before permission is granted will not have IDFA values attached and will be attributed as organic. When the user opts in, Branch will trigger a second install event with the correct ad attribution data, and subsequent events will be correctly attributed to the ad (however, events prior to the opt-in will not be updated).

We have published a blog post with ATT opt-in best practices here.

Apple has taken a very strong position with the default language in the AppTrackingTransparency prompt. We understand that some companies may simply not feel comfortable showing this modal to users, even though it is for a completely legitimate and appropriate purpose.

If you choose not to show the ATT prompt, you'll see the following:

• Device-level ad attribution will no longer be possible for any users on iOS 14.5. Instead, you'll receive aggregate data via SKAdNetwork for app-to-app install campaigns (assuming your ad network has implemented SKAdNetwork) Attribution will not be possible for web-to-app ads, or for re-engagement ads.

• Attribution for owned/organic channels will continue to work as before.

• Deep linking will continue to function, including deferred deep linking and deep links in paid ads when supported by ad networks (device-level matching for the purpose of UX is not considered 'tracking' under Apple's policy)

When you show the ATT prompt and users decline it, the following will happen:

• Device-level ad attribution will not occur. You'll still receive aggregate data via SKAdNetwork for app-to-app install campaigns (assuming your ad network has implemented SKAdNetwork) Attribution will not be possible for web-to-app ads, or for re-engagement ads.

• Attribution for owned/organic channels will continue to work as before.

• Deep linking will continue to function, including deferred deep linking and deep links in paid ads when supported by ad networks (device-level matching for the purpose of UX is not considered 'tracking' under Apple's policy).

No, unfortunately this isn't possible. In order to know IF a user is coming from a paid ad, by definition you need to have done some form of 'tracking them' (as defined by Apple's policy) first.

Yes, it is possible to link the user into the Settings page to change this the ATT setting, if the user hasn't disabled tracking requests at the device level. Apple even mentions this here: https://developer.apple.com/app-store/user-privacy-and-data-use/.

It won't reset the prompt to show a second time, but the user can go there and manually change the toggle setting.

The Apple Human Interface Guidelines contain specific instructions on what is allowed in 'pre-permission prompts', including visual examples of what is allowed/not allowed.

The short version is that the official ATT modal can only be displayed once, shouldn't contain anything resembling a mockup of the system prompt, and must not function as a custom prompt that could be shown multiple times to 'protect' against the user opting out.

Also, once you implement the ATTrackingManager class in your app, Apple's reviewers expect to see the prompt and they appear to be rejecting any subsequent app updates that do not include the framework.

AppTrackingTransparency is like any other permission on iOS: it gets reset when the app is uninstalled. This means the user will be asked again after they reinstall.