In April 2021, Apple introduced a privacy policy called App Tracking Transparency (ATT) that moderates a data collection and aggregation practice known as “tracking.” Under ATT, an app must receive explicit consent from a user before that app can collect the user’s unique device identifier, known on iOS devices as the IDFA. Prior to ATT, the IDFA was widely used by advertising platforms for ads personalization and targeting through a process that I detail in this article.
ATT’s impact on the mobile advertising ecosystem is consequential: both Facebook and Snap, in recent quarterly earnings reports, described the frictions caused by ATT as having meaningfully impaired their advertising businesses. Apple’s own ad network, Apple Search Ads (ASA), has experienced considerable growth since the introduction of ATT. Both Facebook and Snap cited deficiencies with SKAdNetwork, the advertising measurement framework that Apple has made available as a replacement for the IDFA, as contributing to ATT’s impairment of their advertising businesses.
In this article, I’ll make the case that ATT advantages Apple’s own ad network, and I’ll propose remedies that would bring the applicability of ATT to parity across Apple’s ad network and the broader advertising ecosystem. Note that Apple’s documentation for its ads platform and privacy controls is vague in places, and the logic it uses to power certain protocols is non-public. I attempt in this article to document all claims with authoritative resources, but in some cases that is not possible and I rely on direct experience and anecdotes.
SKAdNetwork
SKAdNetwork is an advertising measurement framework that Apple introduced in 2018: I opined on the impact that this solution might have on the mobile advertising landscape at the time in Will Apple redefine mobile advertising with SKAdNetwork?. SKAdNetwork was mostly irrelevant until WWDC 2020, when Apple unveiled its App Tracking Transparency (ATT) privacy policy.
SKAdNetwork allows advertising platforms to attribute app installs, along with a limited amount of in-app context, to the ad campaigns that generate them. The data payload, or postback, that SKAdNetwork delivers to ad platforms is indexed at the level of an ad campaign and not an individual user, essentially anonymizing the postback and preventing behavioral data from being aggregated into profiles. But the scope of the SKAdNetwork postback is limited through a number of design choices that render it insufficient as a measurement tool.
I have previously made the point that SKAdNetwork is inadequate as an advertising measurement solution: it lacks critical granularity, and its timer system is unnecessarily convoluted. In Dear Apple: These changes will improve SKAdNetwork for advertisers, I enumerated a number of changes that Apple could make to SKAdNetwork that would improve its usefullness as a measurement framework. But Apple has done very little to change SKAdNetwork since version 2 was introduced at WWDC 2020, the most of which being the addition of view-through install attribution and PCM attribution for app-to-web campaigns. Additionally, Apple introduced the ability for developers to receive SKAdNetwork postbacks directly in iOS 15, although this was not a change to SKAdNetwork, per se.
But despite these improvements — and they are improvements — SKAdNetwork remains a deficient measurement framework, to which both Snap and Facebook’s earnings attest. There are five primary problems with SKAdNetwork that render it insufficient for advertising measurement:
- SKAdNetwork postbacks are deployed according to a convoluted and partially random timer logic that makes analyzing SKAdNetwork postback data on a daily basis — that is, attempting to compare daily ad spend against daily advertising results like installs and conversions — impossible. This type of daily cohort analysis is core to advertising measurement and it is not possible with SKAdNetwork postbacks. I describe the SKAdNetwork timer logic in this QuantMar thread, but in brief: it includes a random component that camouflages the date of an app install;
- Apple limits the inclusion of certain data in SKAdNetwork postbacks according to a privacy threshold that the company does not make public and may actually change over time. The conversion data that is limited according to this threshold pertains to in-app actions that users take after installing an app — it is this data on which app advertisers and ad platforms alike rely for calculating campaign performance. Apple has revealed very little information about how its privacy threshold works outside of this documentation, although I discuss the topic in detail in this podcast episode;
- Apple limits the number of campaign identifiers that can be utilized in advertising a specific app on a given network to 100. This limitation imposes significant restraints on testing, since each unique combination of targeting parameters requires its own campaign identifier;
- Apple does not include a parameter in the SKAdNetwork postback to account for creative information, such as the specific ad that was clicked by a user to produce an install. This is critical detail that advertisers require in optimizing campaigns. Without creative context in attribution data, the advertiser can’t directly gauge the effectiveness of its ads;
- The SKAdNetwork postback does not include a parameter to account for device country, and in an undocumented change, Apple began routing SKAdNetwork postbacks through a VPN system in iOS 14.6, meaning that postbacks cannot be geo-located. This prevents advertisers and ad platforms from understanding in which country an install is generated. This presents an acute opportunity for abuse and fraud by ad platforms, since geography is a critical campaign targeting parameter (an ad platform could claim to be targeting users in one geography and actually be targeting users in another).
These limitations are explicit design choices, and in some cases (specifically, lack of creative context), it’s difficult to understand how they contribute to strengthened user privacy.
Apple Search Ads
Recent reporting from the Financial Times argues that Apple’s own ad network, Apple Search Ads, or ASA, has captured a meaningful share of the market for app install advertising since ATT reached majority scale (there’s some nuance to why that wasn’t immediately after the launch of iOS 14.5 in April, which I explain here). The Financial Times estimates that Apple’s 2022 fiscal year revenue from ASA might reach $5BN, and an Evercore ISI analyst estimates that ASA might reach $20BN in revenue by 2025. Both of these estimates presuppose roughly $2BN in ASA revenue for 2021.
This is stunning growth in percentage terms, although as has been argued, relative to the size of the mobile advertising market as well as Apple’s overall revenue, even $20BN is somewhat immaterial. But the quality of the revenue matters: ASA is a high-margin business that contributes to Apple’s Services segment, so the growth from ASA is potentially more strategically valuable than if it were delivered through some other initiative.
What’s jarring about the divergent outcomes for ASA and other ad platforms as a result of ATT is that Apple’s own ad network is not subjected to the limitations of ATT, and it isn’t forced to use SKAdNetwork for ad attribution.
Apple justifies this disparity through its definition of “tracking,” which it spells out here:
“Tracking” refers to linking data collected from your app about a particular end-user or device, such as a user ID, device ID, or profile, with Third-Party Data for targeted advertising or advertising measurement purposes, or sharing data collected from your app about a particular end-user or device with a data broker.
On its Advertising Privacy & Policy documentation, Apple states authoritatively that its own ad network does not track users, using its own definition of that term:
Apple’s advertising platform does not track you, meaning that it does not link user or device data collected from our apps with user or device data collected from third parties for targeted advertising or advertising measurement purposes, and does not share user or device data with data brokers.
Apple does use behavioral data to target ads with its ads platform, but it does so in a way that doesn’t confront its definition of tracking. From the same documentation:
Apple uses the behavioral data gleaned from users within apps published to the App Store to target the ads served by its ad platform. The vast majority of the apps published to the App Store are not developed by Apple. But the in-app purchase and subscription events that are emitted from those apps are considered first-party to Apple, ostensibly, because Apple operates iTunes, which processes payments for apps (a user makes a purchase in an app but must finalize the purchase using iTunes). Apple is able to exempt itself from ATT because Apple controls the payments processor that emits the data used to target its ads, and therefore none of that data is considered third-party to Apple.
It is presumably for this reason that Apple’s ad network is not forced to use SKAdNetwork for attribution, but rather it can utilize Apple’s Ads Attribution API, which exists within Apple’s AdServices program. Attribution through the Apple Ads Attribution API is wholly separate and distinct from SKAdNetwork. In this attribution scheme, the AdServices framework places a token on the user’s device after an install, and that token is passed to the Apple Ads Attribution API for attribution, with a postback being returned from the API that provides context around the install. Because this token is placed on the device, it can be tied to a specific user identifier in the app, meaning that users can theoretically be attributed to specific ASA campaigns in a way that isn’t possible using SKAdNetwork.
The Apple Ads Attribution API payload contains different data than does the SKAdNetwork postback (see below for a comparison). Critically, the Apple Ads Attribution API payload includes context around the ad creative that delivered the install (creativeSetId, keywordId) and the geography of the device on which the install occurred (countryOrRegion).
Note that the Apple Ads Attribution API payload does not utilize a timer system: installs that occur through ASA are attributed as they happen, unlike with SKAdNetwork, which is subject to a minimum turnaround time of between 24-48 hours from ad click to install postback. This install timing capability with the Apple Ads Attribution API presents a considerable difference between the reporting API that Apple makes available for its own ad network and the reporting API it forces other ad networks to use, SKAdNetwork. With Apple’s own reporting API, install reporting can be cohorted and compared against daily ad spend for measurement and optimization purposes. With SKAdNetwork, because of its timer system, that is not possible.
Additionally, because Apple operates the attribution apparatus for its own ad network, it is able to set terms for attribution that other ad networks can’t and that advertisers might find unusual or non-standard. Mobile attribution platform Appsflyer points out that installs generated from ASA when an IDFA is not available are recorded as organic, or not having derived from an ad click, prior to iOS 14. But because Apple controls the operating system of the device and manages attribution for its own ad network, it is able to attribute ASA installs regardless of ATT status (ie. whether or not a user opted into making their IDFA available), and it is also able to dictate the “lookback window” over which those installs are attributed to clicks. Notably, for opted out users, Apple sets a 30-day lookback window on click attribution, meaning that any ad click from an ASA campaign that takes place in the 30 days before an install is observed is credited for that install.
Appsflyer’s documentation indicates that its platform defaults to a 7-day attribution window for clicks when a different value has not been set by the advertiser for networks other than ASA. From my own experience, 7 days is a common install attribution window for an ad click. 30 days is an unnecessarily protracted lookback timeline for attributing installs to clicks: it could result in ASA taking credit for installs for which other ads from other ad networks were more immediately responsible. Other ad networks and ad platforms allow for attribution windows to be set by the advertiser; as an example, this documentation explains how advertisers are able to set an attribution window for TikTok advertising campaigns.
Advantages and remedies
The exemptions and separate standards that Apple applies to its own ad network provide it with inequitable advantages over other ads platforms and ad networks. These advantages manifest in a number of ways:
- The language that Apple uses to collect consent from users for ads targeting is vastly different from the language that is mandatory in the ATT consent prompt (as contrasted at the top of the article). Developers are only able to customize the supporting text under the ATT prompt headline, but the headline itself cannot be modified: App Name would like permission to track you across apps and websites owned by other companies. Apple’s own opt-in prompt describes its collection of data from apps that it does not own, through its App Store payments processor, for the purposes of ads targeting as “personalization.” As I describe in this article, the personalization framing is, subjectively, less intimidating than the tracking framing, and it also implies consumer benefits (relevant advertising) whereas tracking does not;
- Apple is able to collect behavioral data from apps developed by third parties for the purposes of ads targeting through its exclusive provision of payments infrastructure in the App Store. App developers have no choice but to give Apple transparency into the payments events that take place in their apps since Apple doesn’t allow for alternative payments systems to be used within apps on iOS. Apple’s restriction of third-party payments processors within apps on iOS provides it with exclusive access to the payments data that is used for targeting ads with ASA. Other ads platforms cannot use payments data for ads targeting for users that have opted out of ATT;
- The Apple Ads Attribution API provides more granular and complete install attribution payload data than does SKAdNetwork. Apple’s own ad network, ASA, is able to attribute installs using the Apple Ads Attribution API, whereas all other ad networks must use SKAdNetwork for install attribution when a user has opted out of ATT. SKAdNetwork is missing critical creative parameters, and its timer system severely limits its usefulness. The Apple Ads Attribution API provides creative context with its install attribution payload, and it is not subject to a timer system for install accounting;
- Apple dictates a 30-day lookback window for install attribution when the user has opted out of ATT. This is a non-standard lookback window that essentially bestows Apple with better access to claiming attributions than other ad platforms and likely results in installs being attributed to ASA for which other ad platforms could more credibly claim credit. Apple does not allow advertisers to change this lookback window whereas other ad platforms and networks do.
Below I propose remedies for each of these inequitable advantages, but they are all conceptually unified by equivalent treatment and applicability. Apple has created a parallel set of standards for the treatment of its own ad network relative to the treatment of all other ad platforms and networks. If Apple were simply to apply universal standards to data access, consumer choice, and reporting fidelity with respect to mobile advertising, then these advantages wouldn’t exist.
- EQUIVALENT CONSENT TEXT. Apple should allow app developers to use the same prompt text for ATT opt-in that Apple uses for collecting consent for ads personalization. The prompt for collecting ads personalization opt-in that Apple uses is more evocative of how ads targeting systems use behavioral data, and it does a better job of exposing the benefits of opting into participating in that system than does the unalterable ATT prompt text. Apple should standardize the ATT prompt and its own ads personalization prompt to the same language.
- EQUIVALENT ACCESS TO PAYMENTS DATA IN A FIRST-PARTY ENVIRONMENT. Apple is able to collect in-app payments data with first-party privileges for use in ads personalization because app developers are forced to use iTunes connect for payments processing on iOS. Apple should allow developers to use alternative payments processors in their apps, which would remove Apple’s exclusive access to payments data for the purposes of ads targeting.
- EQUIVALENT REPORTING. Apple should standardize reporting robustness across SKAdNetwork and the Apple Ads Attribution API. The SKAdNetwork postback payload should contain the same level of granularity as does the Apple Ads Attribution API, and the delivery of SKAdNetwork postbacks should be conducted with the same timeliness as are those from the Apple Ads Attribution API.
- EQUIVALENT ATTRIBUTION CONFIGURATION. Apple should make the attribution window for ASA campaigns configurable for advertisers. A 30-day attribution window is non-standard, and advertisers should have the option of setting the attribution window for ASA campaigns to a value of their choosing, as is done with many other large ad platforms and ad networks.
As I wrote more than a year ago in The IDFA is the hydrocarbon of the mobile advertising ecosystem, I believe that the IDFA had reached the end of its useful life and was facilitating a system of data collection that was ultimately corrosive to user trust and harmful to the mobile advertising ecosystem. I applaud Apple for taking the initiative to protect user privacy by effectively deprecating the IDFA.
But ATT is a clumsy solution that doesn’t foster genuine consumer choice and inflicts unnecessary pain on advertisers that is causing very real value destruction. ATT threatens the viability of the freemium business model, which I think is the most profound commercial innovation of the past 30 years, and the harm it engenders will ultimately be felt by consumers. The inequitable advantages that Apple has conferred on its own ad network, especially through the inadequacy of SKAdNetwork, are generally destructive to the advertising efficiency that allowed the App Store to blossom into, as Tim Cook calls it, an “economic miracle.” Apple can restore some of that efficiency while still providing for consumer privacy by implementing the remedies to those inequitable advantages that I articulate here.