Apple’s AppTrackingTransparency (ATT) Framework and You

January 28th is Data Privacy Day at Apple, and with it comes Apple’s announcement that the AppTrackingTransparency (ATT) framework will go into effect with its next beta update with broad roll out in early Spring.

“And starting soon, with Apple’s next beta update, App Tracking Transparency will require apps to get the user’s permission before tracking their data across apps or websites owned by other companies. Under Settings, users will be able to see which apps have requested permission to track, and make changes as they see fit. This requirement will roll out broadly in early spring with an upcoming release of iOS 14, iPadOS 14, and tvOS 14…”

That the market’s reaction to Apple’s AppTrackingTransparency (ATT) framework has been varied is no surprise. Since it was first announced at Apple’s 2020 Worldwide Developer Conference (WWDC) in June, different mobile measurement partners (MMPs) have come forward with various approaches to continue providing meaningful advertising measurement in the new reality created by Apple. The true extent of the ATT framework’s impact on digital advertising measurement requires a careful review of how it intersects with Apple’s User Privacy and Data Use Policy. 

In this post, the following key points will be addressed:

• What does the ATT framework mean for your advertising measurement? 
• How is Kochava approaching ATT?
• How are other MMPs approaching ATT and why does it matter?

The ATT framework and your advertising measurement

Apple’s privacy policy states: 

“With iOS 14, iPadOS 14, and tvOS 14, you will need to receive the user’s permission through the AppTrackingTransparency framework to track them or access their device’s advertising identifier.”

This means that if a user chooses not to opt-in through the ATT framework, not only will you not get access to their IDFA, but you’re also restricted from passing their user or device data off their device for the purpose of combining that with another company’s data to perform advertising measurement (a.k.a. attribution). “Another company’s” data is essentially interchangeable with paid media. This means that without opt-in, paid media attribution insights will be isolated to Apple’s SKAdNetwork. Owned/non-paid media would be an exception—allowing you to perform attribution between two apps within your own publisher account based on the identifier for vendor (IDFV). This would be sharing your own first-party data among your own apps, not those of another company. Thus, cross-promo opportunities should be a key factor in your future growth strategy if you have a portfolio of apps. 

Is there an exception for probabilistic or fingerprint forms of attribution that don’t require an IDFA and aren’t deterministic in nature?

While probabilistic attribution for opt-out users seemed like a viable option in the early weeks and months that followed WWDC, Apple subsequently provided additional clarity within a Q&A section of their privacy policy. The following is an excerpt on a specific question and answer. 

This clearly leaves no ambiguity. Probabilistic and fingerprint methods of attribution that leverage IP address, device user agent, and other contextual device attributes in lieu of the IDFA are also prohibited in the absence of ATT opt-in. This means that paid media run on mobile web channels cannot be attributed by probabilistic or fingerprint methodologies if the user DOES NOT opt-in through your app’s ATT prompt. If a user DOES opt-in to ATT, then probabilistic or fingerprint methodologies can still be leveraged to attribute to media outside of an iOS app when IDFA wouldn’t be available from the source. 

Once again, owned media is an exception. Probabilistic and fingerprint methods of attribution are permitted when attributing user conversions to owned media run on mobile web channels since this would still be matching first-party data to other first-party data, and not that of another company. 

So, what will your attribution look like post-ATT enforcement? The answer depends on who your MMP is. 

How Kochava is approaching ATT

Collecting ATT status

To begin, Kochava is working with all media partners to pass ATT status on clicks and impressions coming from your marketing campaigns. 

For advertisers, Kochava has published an iOS SDK that supports seamlessly passing ATT status. Download our Native iOS SDK, or supported wrappers (Unity, Xamarin, Cordova, etc.) here. Documentation has also been published to support advertiser clients using our server-to-server (S2S) integration. View S2S support documentation here. 

Attribution eligibility based on ATT status

Once Apple begins enforcement of ATT, Kochava will start identifying advertiser and media partner traffic sent to Kochava iOS apps as consented (opt-in), non-consented (opt-out), or not subject to ATT (eg, mobile web). Traffic identified as non-consented will not be eligible for MMP attribution or any form of linking to another company’s data. SKAdNetwork will be the only form of attribution available for non-consented users. As discussed earlier in this document, owned media is the exception, since it’s comparing first-party data to other first-party data. 

The table below outlines attribution methods available based on a variety of ATT scenarios. Attribution eligibility will be dependent on the ATT status of the user in both the advertised app and the source where the ad interaction occurred (paid vs. owned media and in-app vs. mobile web). For Kochava to perform deterministic attribution on ATT opt-in users, please refer to our support documentation on configuring our SDK to handle your app’s ATT prompt timing.

Attribution hash

The Attribution hash was one of the first solutions proposed to mitigate the impact of ATT. The idea was to create a hash from the IDFA/IDFV on the demand side for both opt-in and opt-out users. The hash could then be used to attribute to ad signals of opt-in users. Unfortunately, this technique was not viable as it relied on the SDK accessing the IDFA without first obtaining the user’s ATT permission. In addition, hashed or not, the IDFA would still be sent off of the device, regardless of ATT permission status, and linked with another companies’ data, which Apple has clearly said is prohibited in instances where ATT opt-in is not present. In cases where ATT is applicable, consent must be obtained on both sides for attribution to occur. 

Aggregated attribution

Aggregated attribution seeks to take the IDFA and/or other user/device data, regardless of ATT permission status, and process attribution matching at the row-level, but then ONLY surface aggregated reporting to advertisers and their partners, not exposing the row-level/user-level data. It relies on the continued use of probabilistic attribution of users who have opted out of tracking. While the final output of data is aggregated and anonymous, the solution at its core still relies on sending user/device data off the device for linking with other companies’ data. This is out of alignment with Apple’s User Privacy and Data Use Policy, which is applicable not only to the app owner (advertisers, publishers) but any SDK activity within their app. MMPs are no exception from Apple’s point of view. 

Cross-customer identity graph

Cross-customer identity graphs work by linking device IDs, IP addresses, user agents, and browser cookies when they are available on an attributed click and install. By logging these connections, the MMP can reference it for attribution on another customer’s app where one or more of these attributes are missing, resulting in attribution that would otherwise not be possible. This can be thought of as a co-op among an MMP’s customers, where the benefit is an increased number of attributions and resulting insights. However, if this method is used for opt-out users, it is out of alignment with Apple’s User Privacy and Data Use policy due to the reliance on combining one app’s data with the data of not just one but many other companies.  

Why it matters which approach you choose

The following is an excerpt from Apple’s privacy policy Q&A: 

Q: “I have integrated an SDK from another company. Am I responsible for the data collection and tracking of users of my app by that company?”

A: “Yes. Developers are responsible for all code included in their apps. If you are unsure about the data collection and tracking practices of code used in your app that you didn’t write, we suggest contacting the developer of the SDK.”

This means you’re responsible for all data collection in your app, even the data collected by a third-party SDK, like that of Kochava and other mobile measurement providers (MMPs). You’re also responsible for how that data is used after it leaves the device. This is why Kochava is strictly adhering to both the letter and the spirit of Apple’s User Privacy and Data Use Policy. This ensures that our clients have absolute peace of mind that the data collected by our SDK and how it’s used (with ATT opt-in) or NOT used (with ATT opt-out) for advertising measurement purposes is 100% in alignment with Apple’s guidelines. 

As we look toward ATT enforcement in early spring, be sure you understand the approach your MMP is taking with ATT and how they intend to use the data collected from your apps. In the event that your MMP’s data use practices are considered to be in violation of Apple’s user privacy and data use policy, Apple reserves the right to remove your app from the App Store because of it. That’s why it’s vital to understand right now whether your MMP’s approach follows Apple’s policy.  

If you want to discuss the Kochava approach to Apple’s AppTrackingTransparency (ATT) framework, or other approaches in the space, we’re here to help. Contact us for a consultation on your ATT strategy. 

Vivian Watt – Product Manager
Kochava