How To Prepare Your Mobile App and Attribution Stack for Apple’s iOS 14 Privacy and IDFA Changes

Note: As of January 28th, 2021, Apple has changed its policies regarding attribution on iOS 14. Read about that update and Branch’s latest stance here

At WWDC 2020, Apple announced that iOS 14 will make some significant changes to mobile tracking. The gist is that users will need to opt into tracking, meaning the IDFA will no longer be accessible to any mobile measurement partners — including Branch — for the vast majority of impressions, clicks, or app events that a user takes. (Update: as of January 28th, 2021, users must give explicit consent to share any sort of device-level data, including fingerprint IDs, session IDs, device graph IDs, and more. Read Apple’s latest policy here.) Note that for now, Android is unaffected, but it’s quite possible that GAID will see the same treatment in the near future.

As Alex mentions in his earlier post on the iOS14 and IDFA Changes, Branch has been building the linking platform and matching technology designed specifically for the world where universal identifiers such as IDFA and GAID don’t exist. The Branch system uses an industry-unique, anonymous, probabilistic algorithm that incorporates historical attributions to deliver high accuracy matching where there is no universal ID. This means where the rest of the industry is reliant on fingerprinting technology with accuracy rates of 60-70%, Branch can deliver superior, more accurate attributions in the high 90s% of your mobile user base, providing you reliable and correct numbers where others fail. All this is accomplished while no user data from your app is linked to other companies’ apps’ data (more on our privacy principles page). This method is available to you when users opt in, and works in parallel with SKAdNetwork.

We’re confident that Branch will continue to deliver its services, and users will gain huge amounts of control over their data, so we see this as a massive win for the mobile ecosystem. That said, there will certainly be changes to the advertising measurement functionality within Branch, specifically when it comes to app-based measurement from install-focused paid campaigns. We know these are likely to be significant, but we expect the impact to Branch customers will be far lower than the rest of the attribution industry, which relies primarily on device-level data for measurement and attribution.

 
A Summary of Services Affected by iOS14 Changes to Device-Level data

With device-level data effectively disappearing, there are a variety of services that will be affected. Below, we’ve listed a few preliminary areas where you’ll likely need to plan for some work to support this change. We’ll confirm details as we learn more from Apple and our industry partners.

 
1. iOS14 impact on log level data exports (bulk exports, custom exports, webhooks/postbacks, etc)

If you are processing or ingesting log-level data via the above mechanisms, the IDFA (user_data_idfa) will cease to be populated for the majority of impressions, clicks, and all other app-specific events (installs, opens, etc) where it was in iOS 13 or below.

Your degree of impact will depend on the percentage of your users who are on iOS (if you’re a Branch customer, you can easily generate a report like this one showing the breakdown of iOS/Android traffic), and how you may have been using IDFAs in your current business systems.

If you used IDFA for data stitching, identity resolution, or other analytics, you will need to change to an alternative identifier:

  • If you don’t care about stitching impressions/clicks to app events and only care about stitching app events, you can use the IDFV (user_data_idfv) which will annotate all app events.
  • If you are stitching impressions and clicks to app events, you will need to consider a solution like Branch’s link graph data that is using web and app activity.

If you did not depend on IDFAs for any data processing, then you likely do not need to change anything here.

 
2. iOS deterministic matching for deferred deep linking and attribution (+match_guaranteed = true for +is_first_session = true)

Branch leveraged IDFAs to deliver deterministic matching on iOS for the first app session, and therefore this will no longer be possible. If you were depending on this functionality for features such as auto-login from a link, you will need to update your code.

Branch instead will be falling back to predictive modeling using our link graph data. These matches are a significant improvement over fingerprint matching, and extremely reliable for most use cases, but should not be relied upon for authentication or other critical failure use cases.

Please note that +match_guaranteed can still be true for direct deep links, where a URI scheme or Universal Link opens the app and passes the data through. The functionality remains and is quite useful depending on your product needs, but will no longer function when it’s the first app session for a deferred deep link.

 
3. iOS14 impact on self-attributing ad network (Google, Facebook, Snap, Twitter, etc.) attribution and deep linking

We’re not yet sure exactly what is going to change here, but we know that something will. All current MMP integrations (both from Branch and from other attribution providers) use the IDFA to confirm device-level attribution on iOS. This allows us to make the attribution decision at the device level. When the IDFA goes away, all of these integrations will break. We’re in active discussions with all of the self-attributing networks to determine which direction they will go to support attribution, and we summarized the three main options that they are considering in the previously linked post.

Our goal will be to handle these technical changes on your behalf, minimizing any updates you would need to make. We also hope that these ad networks go in a direction where you can continue to receive device-level attribution data.

 
4. iOS14 impact on non-self-attributing ad network attribution

The hundreds of non-SAN integrations that Branch maintains are much simpler, in that they use Branch tracking links to measure performance. These tracking links will no longer be populated with the IDFA macro and therefore will rely on Branch’s probabilistic matching to make the connection to the app session. We’re confident that the accuracy of this matching will be trustworthy and reliable, and the best in the industry by far.

There is a possibility that some of these non-SAN integrations will change, but we’ll hopefully be able to handle all of the updates on our side without requiring action from you.

 

5. iOS14 impact on data integrations or custom partner postbacks dependent on device-level data

There are a few data integrations (DIs) that we maintain that are dependent on the IDFA for data sharing/annotation. To name a few popular ones, these include Amplitude, Braze, Mixpanel, Segment, and mParticle. If you are interested in a particular other DI, we’d be happy to confirm whether it is affected for you. If it is a custom partner, likely you would know whether it would be dependent on device-level data.

We don’t yet exactly know how these will translate to a world without device-level data, and we’re working with the various companies to rebuild the integrations. One approach may involve you modifying your SDK integration to do an SDK-to-SDK data transfer (we don’t have docs for every integration yet but you can see an example for how this works with our Firebase integration), rather than have it be done server-to-server. We’ll share more DI-specific migration guides once we confirm them.

 
6. iOS SDK update/code changes

If you use Universal Ads and ad network integrations or other data integrations, it’s quite possible that there will be a required Branch SDK update for iOS 14. We’ll confirm the specifics as we get more insight from our ad network and data partners on the integration requirements.

If you are not using Universal Ads or Data Integrations, we don’t believe there will be any requirement for an SDK update prior to the iOS 14 changes. That said, iOS betas can change dramatically leading up the actual release date. We’ll most certainly keep you updated as we learn more.

 
7. GDPR API

If you are using the GDPR API to send deletion requests associated with an IDFA, it will have lower efficacy since fewer users will allow tracking of the IDFA, which is the primary identifier for these requests. Instead, you’ll want to rely on IDFV where available, and consider shifting to using the SDK controls for disabling Branch functionality when a user requests an opt-out.

 
8. iOS14 impact on audience builder (in beta and releasing soon)

With no device-level data coming into Branch after the new iOS 14 change, there will be no device-level data to export via the Audience Builder product. This means that you’ll no longer be able to generate a list of IDs that can be sent to a third party ad network (and even if you could, the network wouldn’t be able to do anything with it). 

We understand that this largely eliminates the utility of an Audience Builder feature on iOS for most customers. We do plan on updating to support exporting your own user IDs, as well as CPID for internal targeting purposes. More details about these capabilities will be announced soon.

 
Overall, we are excited about iOS14 and the changes it brings

If you don’t see a service or change listed above, then we expect the impact to be minor. That means we expect that all deferred deep linking capabilities, Journeys smart banners, and deep linked email functionality, as well as aggregate analytics, will not see much change.

Beyond the impact of IDFA, we’re already investing in some of the new iOS capabilities announced and have a variety of product and engineering teams exploring the capabilities of App Search, App Clips, and more. We believe that iOS 14 will be a net positive for the industry as a whole, and are incredibly excited about the future.