The information you need to prepare for a world without device-level ad attribution on iOS.
Apple has not yet confirmed a release date for iOS 14.5, beyond sharing it will be "early spring."
To avoid disruption, Branch recommends being prepared for these changes by March 1.
Looking for a comprehensive readiness checkup? Take a look at our iOS 14 Readiness Checklist.
Go to the checklistAs of iOS 14.5, device-level ad attribution will not be possible unless users grant permission to both the advertiser app and publisher app.
Without this opt-in, advertisers will lose the ability to serve personalized and retargeting ads, as well as the ability to accurately attribute their marketing campaigns and understand campaign ROI.
IDFAs will largely disappear from exports and other data integrations.
Branch has rebuilt data integrations that depended on IDFAs. IDFVs continue to be available as an alternate identifier.
You’ll need to find a new primary key (such as the IDFV) for your internal business intelligence and analytics.
Depending on the specific data integration you use, you may also need to make in-app code updates to pass an alternative identifier.
You won’t have IDFA values available to submit for GDPR/CCPA data deletion requests.
Our Data Subject Request API already supports alternative identifiers, including IDFV and developer_id.
You will need to send Branch alternative identifiers (such as IDFV or developer_id) instead of IDFA for all data deletion requests.
Ad networks (including the major SAN networks: Google, Facebook, Twitter, Snap) will primarily use SKAdNetwork for ad attribution on iOS 14. Some networks will continue to support device-level attribution when users opt in.
Branch has built robust support for SKAdNetwork, including updates to our iOS SDKs and a new reporting dashboard. In parallel to SKAdNetwork, we will continue supporting device-level attribution for opted-in users.
You will need to set up SKAdNetwork in your app. If you want to continue receiving device-level ad attribution data, you will need implement the new ATT permissions prompt.
Under Apple’s new policy, information may only be used used for ad “tracking” after users opt in via the AppTrackingTransparency framework. This includes IDFAs, and also “fingerprints IDs, properties of a user’s web browser and its configuration, the user’s device and its configuration, the user’s location, the user’s network connection, session ID, device graph identifiers.”
To comply with Apple’s policy, Branch will not perform device-level ad attribution until you get ATT opt-in from the user. In order to give you full control over the user experience, the Branch SDK will not trigger the ATT modal on your behalf, but you may choose to do so on your own.
If you want to access device-level attribution data for your ad campaigns, you will need implement the AppTrackingTransparency permission modal yourself.
Deterministic deferred deep link matches (+match_guaranteed = true) will no longer be available for the first app session post-install on iOS 14.
Deferred deep linking will still be possible via probabilistic modeling techniques (as it always has been in situations where a deterministic match could not be made). However, these probabilistic links should not be relied upon for user authentication or other critical failure use cases.
If you leveraged +match_guaranteed data for use cases such as auto-login from a link, this functionality will stop working on iOS 14 in most cases.
Assuming best practices were used in development, your app should already be set up to gracefully failover in this situation.
SKAdNetwork will protect against some fraud techniques, but fraudsters will certainly find new ways to exploit the system.
Because Branch has broad knowledge of legitimate user behavior across both web and app, our fraud detection engine will have a significant advantage in determining which conversions are valid.
Nothing is required from you.
Apple’s attribution solution for if and when users opt out of ad tracking of any kind is SKAdNetwork. SKAdNetwork allows marketers to track their campaigns to determine which ones led to installs or purchases, but without disclosing granular, user-level data. Advertisers will have to rely on aggregate level data, which shows limited information about a campaign without revealing specific details that could potentially reveal a user’s device ID. Marketing activities like impression tracking, frequency capping, and personalization will be more difficult.
Learn more about how SKAdNetwork affects the mobile industry
We’ve updated the Branch SDK to support sending install and conversion notifications to Apple for SKAdNetwork; specifically registerAppForAdNetworkAttribution() and updateConversionValue(0-63).
Learn more about the steps you need to take to set up SKAdNetwork in your app.
To protect against fraud and add a level of trust to SKAdNetwork data, we will use an Apple-provided cryptographic signature to validate postbacks forwarded to us by ad networks. We will then aggregate the data sent by ad networks and display it on the dashboard in our own analytics section for a convenient one-stop shop for all your data.
Our dashboard will serve as one centralized place to view SKAdNetwork attribution data instead of having to log in to separate ad network dashboards. This update will include a new Ads Analytics dashboard dedicated to just SKAdNetwork data, separate from existing user-level data from Branch. You’ll be able to view the total number of installs and conversion events reported by SKAdNetwork, and filter installs/conversions by parameters like ad network and source app.
The public justification is to improve user privacy. Apple has indicated that they want to crack down on an entire 'dirty data industry' that looks to track and target users for paid advertising purposes without OS-level consent.
Specifically, since the IDFA was a common ID that all apps could read and recognize, it was perfectly-suited for vacuuming up PII data from across the ecosystem to compile user profiles. By blocking access to this ID, and enforcing policy guidelines to prevent any technically-equivalent alternatives (such as fingerprint IDs), Apple can wipe its hands clean and move on. Responsible use of device-level matching (including for mobile campaign measurement) is simply collateral damage.
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.
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. This revised 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.
We recommend testing a modal shown before the ATT modal to give the user context on why you are asking for their data. The “official” language can be a little scary from a user perspective, so explaining why you’re about to ask for this permission is critical. Note that Apple is cracking down on pre-permission prompts, so refrain from requiring users to opt in via your own framework.
Our recommendation for showing the contex-providing modal itself is based on 3 core tenets:
1. Show value to the user. 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.
2. Consider the timing. 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.
3. 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.
We recommend starting to test your context-providing modal with scoped audience segments prior to iOS 14.5. 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 ATT modal when your dev team has the bandwidth within the next month. However, 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.
SKAdNetwork is Apple's alternative attribution system, facilitating ad measurement without device-level data.
SKAdNetwork has significant limitations, including only aggregate campaign data, no impression or view-through data, very limited down-funnel reporting, and no control over attribution windows. However, for some ad networks (including the major SAN networks like Facebook, Google, Twitter, and Snap), it will be the only attribution method available when iOS 14 is first released.
SKAdNetwork does not replace MMPs. Like with all other attribution methodologies, Branch will help our customers with the process of setting up SKAdNetwork in their apps, optimizing and maintaining configuration, and generating actionable campaign performance reports from raw data.
While some of the mechanisms have changed, the role of the MMP stays exactly the same: provide unbiased measurement that allows you to make actionable decisions. Branch's proposed solution supports SKAdNetwork while also preserving the data needed for device-level attribution on organic channels and a cohesive view of all results across iOS/Android/web/OTT.
In addition to providing neutral, third-party verification on SKAN-reported results from your active ad networks, Branch also offers the following value as an MMP partner:
1. Deep linking / deferred deep linking capabilities.
It’s clear that Apple is only looking to crack down on advertising measurement, tracking, and audience use cases. Navigation and user-experience use cases are still supported and valid. In a world with more limitations on growth hacking strategies to optimize for app installs, there will be a core use case for (1) deferred deep linking to reduce friction in new user experiences and (2) direct deep linking from walled gardens that consistently routes acquired users back to the app for higher conversion rates and enhanced LTV.
2. Support for Android device-level (until GAID goes away).
We must not forget that Apple only owns a single platform, and Android still represents the vast majority of mobile devices. Things will continue as they were until Google indicates otherwise with GAID.
3. Aggregate data ingestion, combination, calculation and access.
As an MMP, Branch plugs into your media networks to ingset information on cost and performance, allowing easy manipulation and visualization of all campaigns in a single dashboard. The value of a service like this increases as spend becomes more fragmented and lets your UA team act independently, so you can quickly evaluate impact and iterate accordingly.
4. Access to MMP-only data from Facebook
Where users do approve the ATT from both Facebook and your app, Branch will continue to provide device-level data insights available only through Facebook MMPs that can help guide your targeting criteria, creative/copy optimization and bid structure, even where they do not reflect the full set of user data.
5. Reporting and benchmarking multiple non-exclusive datasets
Branch will provide analytics on the multiple non-mutually exclusive datasets (aggregate SKAN for paid media only, ATT-tracked device-level for advertising tracking only, device-level owned-channel without advertising tracking) that, when analyzed together, can provide unique insight around paid media efficacy, advertising incrementality, and paid + owned channel tandem strategies that increase the rate of SKAN-trackable conversion value achievement in the paradigm of SKAN’s 24-hour looping timer.
We think this is likely to happen at some point. This means that the mobile industry should prepare for a future in which there are no persistent, platform-wide identifiers. For now, Branch will continue using GAIDs because this provides the most accurate measurement.
Apple’s policy is specific to paid ads tracking, attribution, and targeting. Core app UX functionality like deep linking is not in scope.
Said another way, deep linking is possible whether the user opts in via ATT or not.
This will depend on support from each ad network. If supported by the ad network, similar to the functionality we offer for GDPR compliance, Branch will be able to reference link data for deferred deep link behavior without performing ad 'tracking'. We believe this is fully compliant with Apple's ATT policy, since this policy deals specifically with tracking, attribution, and audience creation (core app UX functionality like deep linking is not in scope).
To put it another way, deep linking and deferred deep linking from ads is allowed regardless of ATT opt-in, so long as no tracking is performed.
That being said, certain networks like Facebook have stated that they will not support deferred deep linking for SKAN campaigns. This is likely for technical reasons, as they've decided to rely exclusively on SKAdNetwork for attribution and have no mechanism in place to pass through the deep link data for any purpose.
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.
Predictive Modeling very much still exists, and will continue to power a number of critical use cases for our clients. These can be thought of as use cases that fall into two different buckets: paid ads and organic/owned links.
1. Paid Ads. When users have agreed to tracking via ATT in both the publisher and advertiser apps, the vast majority of device-level attribution will be done via IDFA. However, there will still be edge cases where this is not possible (such as the IDFA not populating in the tracking link). In these cases, Branch will be able to use Predictive Modeling to accurately attribute that user to the proper ad.
Additionally, since the IDFA is never accessible on mobile web, Predictive modeling will power all web-to-app ad attribution (so long as the user opts in via ATT in the destination app).
2. Organic Channels. Since Apple’s new guidelines apply to paid advertising, organic channels can still continue to function as they do today. Whether it be app-to-app links, links on a client’s site, links in an email, or non-paid links on another site, Predictive Modeling will power best-in-class attribution.