IDFA Changes Flashcards
(10 cards)
Why is Apple blocking device-level attribution on iOS 14?
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.
Will Apple further tighten their policy language to prohibit measurement of earned/owned channels?
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.
What is Branch’s recommendation on implementing the AppTrackingTransparency prompt?
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:
- 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.
- 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.
- 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.
What is SKAdNetwork, and does it replace MMPs?
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.
Why do we still need an MMP at all?
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:
- 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. - 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. - 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. - 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. - 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.
Will Google do the same thing on Android by removing the GAID?
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.
Does this new policy block deep linking?
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.
Can we still use deferred deep linking in ads?
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.
What about web-to-app ad conversions, such as affiliate networks? Are those still allowed?
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.
What happened to Predictive Modeling? In which situations is it still an advantage?
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.
- 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).
- 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.
