Complying with Apple's Policy FAQ

App Tracking Transparency policy does not apply to tracking of owned channels.

This is a broad industry consensus, supported by the language of the ATT prompt.

Examples of Owned Channels:

• Web-to-app flows (smart banners, etc.).

• Email marketing.

• Most offline-to-online (QR codes, etc.).

No, we believe organic and earned channels are not in scope for Apple's policies against 'tracking'. Apple repeatedly calls out 'ads' (29 different places on the ATT policy page). Non-ad measurement is not mentioned, despite multiple updates since WWDC.

Examples of Organic/Earned Channels:

• Organic search.

• Non-paid social media.

• User-generated content sharing.

Also, it's relevant to note that SKAdNetwork (Apple's alternative attribution framework) only supports paid ads.

It's obviously possible that Apple might make additional policy changes, or update their guidance in future. If so, Branch will adjust as necessary to ensure compliance.

Based on both the spirit and direct language of Apple’s new guidance, it seems clear that organic/owned channels are not in scope. Apple’s iOS 14 guidance has been consistent since release in that it is explicit in addressing the focus on “advertising”, calling out the term in 29 different places in the “User Privacy and Data Use” developer guide.

This is also reflected in the presentation of the ATT modal itself, via the extremely specific language about tracking across apps and website owned by other companies:

Had Apple intended to restrict owned or organic-channel tracking, Apple easily could have used different language or taken the technical blocking route, as they did with IDFA approach, and restricted access to IDFV, making even multi-session context preservation impossible to the individual company without ATT consent.

As the sole arbiter of the Apple Developer Program License Agreement, Apple has the right to change guidance as they see fit. Given the granular nature of their latest update, we feel secure that if organic/owned channels were in scope of the iOS 14.5 release, Apple would have highlighted this change. We'll be watching carefully for any further clarifications from Apple, and will adjust our guidance if they provide additional information.

In addition to industry standard acceptance of clear distinctions in the intent, use and meaning of the terms “advertising” and “marketing” as separate terms of art (where advertising is a type of marketing but not all marketing is advertising), Apple has taken care to be specific in their consistent use of “advertising” while taking the necessary steps to provide granularity around the more ambiguous “tracking” in their updated guidance around iOS 14.5

Apple repeatedly refers to advertising in the context of advertising networks in their “User Privacy and Data Use” documentation, which indicates a common sense understanding of an “ad” as a third-party placement that seeks to drive user interaction with the advertiser on their separate platform.

Supplemental information in the FAQ section of the documentation, including the answer to “Can I use multiple advertising networks for the purposes of SKAdNetwork?” that states, “Contact your advertising networks of choice to understand whether they are integrated with SKAdNetwork” further indicate that a traditional understanding of “ads” as paid placements on “other companies’ apps, websites, or offline properties” as apple states in the opening paragraph of “Asking Permission to Track”.

The “Asking Permission to Track” provides a specific definition of tracking, specifically that, “Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.”

Based on Apple's language on their User Privacy and Data Use page, our understanding of the ATT policy is that it is specific to tracking, attribution, and targeting for paid ads and data brokers. This means that core app UX functionality (like deep linking) is not within the scope of the App Tracking Transparency policy, except in situations where an app attempts to abuse this functionality to work around other limitations of the ATT policy.

On April 19, 2021, Apple further reinforced this distinction around ad-related use cases via a new FAQ item on the User Privacy and Data Use page:

The wording of the question references 'deep linking' and 'deferred deep linking', and the answer makes it clear that the behavior Apple considers objectionable is using such functionality to '…pass unique identifiers or create a shared identity of the user between applications from different companies for ad targeting, ad measurement or sharing with a data broker'.

In other words, ATT prohibits utilizing deep linking technology for the purposes of working around the policy's restrictions on tracking paid ads and sharing data with data brokers. This is perfectly in line with the policy's other prohibitions (for example, on fingerprinting), and reflects Apple's goals of a) limiting the IDFA on iOS, and b) placing policy limitations on any method that could be used to bypass these IDFA limits.

Branch agrees with Apple's stance on this, and we're glad to see them make this move to keep deep linking focused on its original purpose: creating great product experiences for users.

In summary, Branch's understanding is that deep linking (including deferred deep linking) properly implemented for its intended purpose of user experience enhancement is still permitted on iOS 14.5+, whether the user opts in via ATT or not. We believe this is the case both when you build your deep linking implementation in-house, and when you legally establish a processor relationship with a vendor such as Branch.

Apple has made it very clear that in order to transmit the necessary data (IDFAs or other metadata for probabilistic matching) from your app necessary for attribution of a specific user to an ad, you must gain consent via ATT.

This policy also applies to a publisher app sending that same data (IDFAs, or other metadata for probabilistic matching), but Apple considers publisher websites out of the scope of ATT.

That means that for app-to-app ads, the user has to consent via ATT in both apps. While there is no ATT equivalent on the web, the user still needs to opt in via ATT in the advertiser’s app in order to attribute a web-to-app ad conversion.

Unfortunately, since SKAdNetwork is not compatible with mobile web inventory, there is not currently an Apple-approved way to attribute a web-to-app conversion if a user does not opt in via ATT in the advertiser’s app. We're aware this is a major problem, and we're hoping Apple will clarify their intentions.

In order to get device-level ad data in an app, you need to get consent via the AppTrackingTransparency framework. For app-to-app campaigns, if there’s no consent, Apple has provided SKAdNetwork as the alternative attribution method.

However, for web-to-app campaigns, there is no alternative that is equivalent to SKAN. This means if the user does not consent in-app, then there’s currently no way of attributing that ad (either in aggregate, at a device-level).

In accordance with Apple’s updated guidance on iOS 14.5, Branch has taken the position that we will not provide device-level attribution for paid advertising on iOS until a user has approved ATT. Hacking the Branch platform to circumvent our technical safeguards is a misuse of our technology that could put your app in violation of your Apple Developer Program License Agreement.

This is a question about the nuances of Apple's policy and how it applies to individual, app-specific implementation choices.

We'd advise that you consult with your team (and your legal/privacy counsel as needed) to determine whether you consider a boosted organic link to be an 'ad' as Apple defines it, and therefore subject to ATT restrictions.

At this point, no one outside of Apple is familiar with Apple's backend compliance systems and enforcement plans. This means it's impossible to say whether Apple plans to implement automated technical verification to support this new policy (and if so, how they plan to distinguish between organic and paid traffic as a technical matter).

Our position (that paid ads are the scope of Apple's policy, and owned/organic sources are not) is based on our best reading of Apple policy, but we would always advise checking with your own team/counsel as needed.

It does not. IDFVs are still considered owned identifiers, and can't be used to track activity across apps because each vendor receives a unique value. This makes IDFVs an excellent choice for internal analytics systems.

However, if an app attempted to map IDFVs to other cross-company data, it would be considered 'tracking'.

This will have a significant impact on retargeting providers. Web-based retargeting will still be possible (within the parameters of existing restrictions like ITP and user opt-in after install), but without IDFAs, we expect that in-app retargeting can no longer exist as it does today.

Additionally, SKAdNetwork does not support re-engagement conversions, so no attribution of any kind is possible if the user does not opt in via the ATT framework. We’re aware that this is a major gap: it’s clearly prohibited by the language of Apple’s ATT policy, and unfortunately not supported by any of Apple’s new functionality. We hope Apple will clarify their intentions here.

While this may be technically possible, our understanding is that it would fall under the definition of 'ad tracking' from Apple's policy, and is therefore subject to ATT opt-in.

In other words, there is no restriction on sending a user to mobile web and capturing conversion data there, but attempting to pass that ad campaign conversion data through to the app without securing user opt in via ATT could put your app in violation of your Apple Developer Program License Agreement.

Unfortunately not. Apple's policy makes it clear that the only acceptable opt-in method for device-level ad measurement on iOS is the AppTrackingTransparency prompt.

Technically, nothing is stopping browser apps like Chrome from implementing the ATT prompt. It's not clear yet what Apple's position is on this (if they have one), but it is a valid question because one could certainly make the case that Apple might feel Safari itself is liable for any 'information leakage' that might take place as a user is browsing the web. Apple's Intelligent Tracking Prevention (ITP) is likely a nod in that direction.

No, it is not necessary for users to opt in under AppTrackingTransparency for SKAdNetwork. This is addressed in Apple's FAQ:

iOS 14.5 actually blocks access to the IDFA at a technical level, which means IDFAs won't be available until/unless the user opts in via the App Tracking Transparency popup. Simultaneously, Branch will make a server-side update to disable other device-level ad attribution methods for iOS 14.5, including for older versions of the Branch SDK.

In other words, you don't need to worry about any compliance issues under Apple's policy, even if your users do not update to the newest version of your app until long after they upgrade to iOS 14.5.

No, it is not necessary to get user opt-in via the ATT policy in order to use Branch or load the Branch SDK.

There are numerous uses for UX and analytics tools (such as Branch) that do not fall within the scope of Apple's policies against tracking. Until/unless you receive ATT opt-in from a user, Branch helps you stay in compliance with the policy by not activating the functionality in our platform that provides device-level ad measurement.

For more details, please see:

• 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?

When selecting answers from the options presented in App Store Connect please keep in mind:

• Branch’s SDKs are fully configurable by you, both in the data we collect on your behalf and how you use that data. Accordingly, you should identify all possible data collections and uses, even if not outlined here or even if certain data will be collected and used only in limited situations.

• Your answers should follow the Apple App Store Review Guidelines and any applicable laws.

• You are solely responsible for keeping your responses accurate and up to date. If your practices change, update your responses in App Store Connect.

You can find a full list of data collected, used, and linked by Branch, here.