The information you need to prepare for an IDFA-less world.
This morning, Apple confirmed that they will postpone required adoption of the IDFA opt-in module until early next year. As a voice of many of the largest advertisers in mobile, we’re pleased that Apple listened to Branch, alongside many others in the space, and made the responsible decision to delay the most disruptive change in iOS 14 until 2021.
However, this is no time to get comfortable.
To learn more about our plans and recommendations for what you should do next, please click below to read our new blog post about this delay.
As of iOS 14, the IDFA will not be available to advertisers or ad networks unless users grant permission to both the advertiser app and ad network to read it for every new app the user downloads. The IDFA isn’t technically gone, but because very low opt-in rates are expected, it’s safe to assume the IDFA is essentially useless.
When users opt out of IDFA tracking, this diminishes advertisers’ ability to serve personalized and retargeting ads, as well as the ability to accurately attribute their marketing campaigns and understand campaign ROI.
Branch’s linking platform and attribution technology is designed specifically for a world where universal identifiers such as IDFA and GAID don’t exist. By using an industry-unique, anonymous, predictive algorithm that incorporates historical attributions to deliver high accuracy data where there is no universal ID, Branch can deliver superior, more accurate attributions for the majority of your mobile user base. Importantly, we can use this insight to improve accuracy both when making an attribution, and when deciding not to attribute.
IDFAs will largely disappear from exports and other data integrations.
Branch is working to rebuild data integrations that depend on IDFAs. IDFVs will 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.
The major SAN networks (Google, Facebook, Twitter, Snap) have announced they will initially support only SKAdNetwork for the release iOS 14.
Branch is building support for SKAdNetwork, including updates to our iOS SDKs and a new reporting dashboard. We are also working with the SAN networks to enable support for Branch predictive modeling.
IDFAs will only be available after users opt in
In order to give you full control over the user experience, the Branch SDK will not trigger the IDFA permission modal. However, we will still collect and use IDFAs when available if you do choose to trigger the modal.
If you want to collect IDFAs, you can implement the 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.
With the industry falling back on probabilistic modeling techniques in the absence of IDFAs, we anticipate that the mix of tactics employed by fraudsters will change. Certain data points Branch currently uses for fraud detection (like Persona age) will become less useful. Most others will be unaffected, however.
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.
The non-SAN integrations that Branch maintains use Branch tracking links to measure performance. These tracking links will no longer be populated with the IDFA macro.
We’re working with these networks to update tracking links to support predictive modeling in place of IDFAs.
Nothing is required if you integrated via the Branch SDK.
Note: if you use a S2S integration with Branch (rare), you will likely need to make updates to pass additional install metadata.
Apple’s attribution solution for if and when users opt out of IDFA 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.
Apple believes there is a “dirty data” industry that collects and combines user data based on IDFAs. They want to crack down on this.
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. Responsible use of the IDFA (including for mobile campaign measurement) is simply collateral damage.
We expect IDFA opt-in rates to be extremely low for several reasons:
1. Users have to opt-in everywhere for IDFA attribution to work (both the app where the ad is served and the destination app being advertised). While it's conceivable that users may opt-into certain apps accessing their IDFA (ex: apps with enormous market sway like Facebook, Twitter, etc.) it is unlikely that smaller apps advertising on these platforms will attain the same level of user opt-ins.
2. Some MMPs have proposed that advertisers will be able to push higher rates of user opt-in by requiring users to either give access to their IDFA or use a paid version of their services. However, companies relying on this method will be at a competitive disadvantage against similar apps who do not pursue this path. For that reason, we do not think it will be widely adopted for apps prioritizing growth.
3. Even incredibly informed users are likely to be influenced by the required language from Apple and reject tracking by apps that they are unfamiliar with. The problem is that they will then need to dig deeply into settings to reverse their choice, which will further lower aggregate opt-in rates.
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.
Branch offers a unique predictive modeling engine that provides accurate device-level data for supported ad networks, even in a world where universal IDs like the IDFA don't exist. By using an industry-unique, anonymous, predictive algorithm that incorporates historical attributions to deliver high accuracy data where there is no universal ID, Branch can deliver superior, more accurate attributions for the majority of your mobile user base.
If SKAdNetwork limitations make it unworkable for you, you can update your campaign strategy to leverage predictive modeling by switching your SAN campaigns to objectives that accept a tracking link, or moving your spend to networks that support tracking links.
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.
The IDFA is the most convenient form of cross-company, persistent identifier on iOS. However, it is not the only one. At WWDC, Apple also discussed limitations on “fingerprint IDs.”
Historically, MMPs used the term “fingerprinting” as a name for what is more accurately described as “point-in-time probabilistic modeling.” Probabilistic modeling does not form a persistent ID, and MMPs do not use this technique to share or combine personal user information across companies.