Apple privileges its own ad network with ATT. What’s its privacy endgame?

Last week, I highlighted on Twitter the fact that Apple published documentation for a new API called the Apple Ads Attribution API for its Search Ads platform on January 6th. This new API provides more actionable granularity to advertisers than the SKAdNetwork framework. Mobile advertisers will be forced to adopt SKAdNetwork for users that opt out of App Tracking Transparency (ATT), but only for campaigns that aren’t run through Apple Search Ads (hat tip to Thomas Petit and Alex Bauer for surfacing this API in the Mobile Dev Memo Slack).

Taking a step back to furnish context:

  • The ATT prompt allows a user to dictate whether or not an app can use data about their device and their in-app behavior to optimize ad targeting. Apple revealed last week that developers will be required to expose the ATT prompt starting in “early spring.” Apple has made it clear that any app that collects sufficient data from a user will be required to show the prompt;
  • Advertisers cannot use existing ad attribution and event-stream methods for collecting behavioral and device data for users that opt out of the ATT prompt — they must instead use SKAdNetwork to attribute installs to ad campaigns. SKAdNetwork is an attribution framework that Apple launched in 2018 and updated to coincide with ATT. SKAdNetwork acts as an intermediary between ad campaigns that forward traffic to apps via ads and the apps that receive that traffic, and delivers install notifications (with some in-app context) to ad networks via postbacks;
  • Advertisers running ads through Apple’s Search Ads advertising platform, which currently traffics ad inventory across Apple’s App Store, News, and Stocks apps, will not use SKAdNetwork for attributing installs, but will instead use this new Apple Ads Attribution API;
  • The Apple Ads Attribution API payload (which delivers campaign data from an API endpoint) contains parameters that are missing in SKAdNetwork. Notably, the Apple Ads Attribution API contains fields for creativeSet (the set of ad creatives that was used for a given ad) and keywordId (the id of the keyword that generated the impression). The SKAdNetwork postback does not contain parameters related to ad creative.

The distinction between the Apple Ads Attribution API payload and the SKAdNetwork postback means, in practical terms, that advertisers get more granular data about the campaigns they operate on Apple’s own ad network than they do for those run on any other network (eg. Facebook). This potentially makes it easier to optimize — and spend more money on — Apple ad network campaigns than campaigns run on other platforms.

For reference, these are the parameters currently available in SKAdNetwork postbacks:

In Why is Apple rebuilding the App Economy?, I posited that Apple is activated by four primary motivations in implementing ATT: (1) user privacy, (2) advancing the fortunes of its own ad network, (3) harming Facebook, and (4) regaining control over app distribution. The discrepancy between the data available from campaigns run on Apple’s ad network and those run on other ad networks certainly supports the second of these four ambitions.

And while Apple recently announced improvements to SKAdNetwork — namely, adding support for view-through attribution — an obvious shortcoming exists for it relative to the reporting available from Apple’s own ad network. It is easy to say: “Apple is using the notion of privacy as a cudgel to advantage itself relative to other advertising networks, and that explains why they are implementing ATT.”

But that explanation seems insufficient. It’s important to understand the totality of ATT. ATT is not simply the restriction of access to the IDFA for users that have opted out: Facebook made clear in its most recent ATT guidance that ATT applies to app-to-web campaigns in addition to app-to-app campaigns. Somewhat quietly, Apple announced last week that it would soon introduce Private Click Management (PCM) for mobile. Private Click Management was proposed as a component of Apple’s WebKit privacy framework back in 2019: it attributes clicks and conversions privately in the user’s browser, with minimal data being revealed to third parties.

It seemed likely that the Aggregated Event Measurement (AEM) structure that Facebook discussed in its ATT guidance for app-to-web campaigns was modeled on PCM (and this is the case, as was pointed out to me on Twitter). That Apple’s ATT framework governs, directly or not, all forms of mobile advertising is substantially more impactful to the mobile ecosystem than if ATT merely applied to app campaigns.

And all of this is happening against the backdrop of the slow trudge toward total third-party cookie deprecation in the browser. Apple has dictated these developments all along. In Apocalypse Soon: What happens when the iOS advertising ID is deprecated?, where I predicted in February 2020 what might happen if Apple announced the deprecation of the IDFA at WWDC, I made the case that Apple was obligated to deprecate the IDFA simply to reach parity in the App Store ecosystem with its privacy policy for Safari.

All of this calls Apple’s endgame into question. It’s clear that ATT doesn’t stand alone: it’s part of a broader push by Apple — through ITP, through PCM, through SKAdNetwork and Apple Ads Attribution API — to position itself as the clearinghouse of advertising and behavioral data. In some cases, Apple gives its own services preferential access to that data, but in all cases, it keeps it and determines how much of it to pass onto developers and advertisers.

As I discussed in a recent episode of the MDM podcast, privacy isn’t a concrete concept: Apple has defined privacy in a way that privileges itself, and from that perspective, privacy is more of a commercial credo than a moral or social tenet. “Privacy is the aperture of data transmission that most benefits my commercial interests” is not the definition of privacy that consumers should accept from platform companies.

Edit: an earlier version of this post included the clickDate parameter as an example of extra data delivered in the Apple Ads Attribution API, but this is only passed when the user has opted into tracking.