SKAdNetwork 4.0: what problems does it solve?

Apple unveiled SKAdNetwork 4.0 at WWDC in June: the next iteration of Apple’s privacy-safe advertising measurement framework is scheduled to be released “later this year” and introduces noteworthy improvements over the current version. Apple made the first version of SKAdNetwork available in 2018, but, as I observed at the time in a piece titled Will Apple redefine mobile advertising with SKAdNetwork?, it was launched with very little fanfare. The framework didn’t achieve any appreciable relevance until Apple announced the App Tracking Transparency (ATT) privacy policy at WWDC 2020; accompanying that announcement was the introduction of an upgraded SKAdNetwork 2.0, which offered an expanded data payload, known as a postback, to be transmitted to ad platforms following an install (more information can be found here).

In April 2021, Apple upgraded SKAdNetwork to version 2.2, which allowed advertisers to receive install postbacks directly (whereas previous versions only transmitted postbacks to ad platforms) and included the new fidelity postback parameter to indicate whether an install attribution occured after an ad click or an ad view. And in September, SKAdNetwork 3.0 was released with iOS 14.6, which routes all postbacks through Apple’s servers, obscuring the IP address of the device on which the install occurred. The new version also introduced the did-win parameter, which indicates whether the ad platform “won” (was responsible for) the install or not. Alongside the did-win parameter, Apple began sending postbacks to up to five networks that did not generate a given install. This article presents the development chronology of SKAdNetwork from version 1.0 in helpful detail.

SKAdNetwork 4.0 represents a dramatic enhancement to the tool’s current state: it’s not an iterative change but a foundational re-imagination of the measurement framework. I’ve called SKAdNetwork dysfunctional: its limitations are so severe and its obfuscating effects so onerous that it is effectively useless for anything other than install accounting. I observe SKAdNetwork’s functional shortcomings at length in this piece, but at a high level:

  1. SKAdNetwork’s opaque privacy threshold, when combined with the existence of just one possible conversion value tied to one possible postback per install, limits the transmission of in-app context so sharply that advertisers cannot adequately attribute post-install value to campaigns;
  2. The limit of 100 campaign identifiers per app, per ad network acutely restricts the ability of advertisers to experiment with combinations of ad targeting and ad creative, and it especially limits the ability of ad platforms to automate that experimentation;
  3. The gratuitous and, frankly, bizarre random timer system that regulates when postbacks are transmitted prevents advertisers from being able to even reliably cohort install counts, and it further restricts the number of campaign identifiers available to use in experimentation (because the timer system delays the transmission of postbacks, campaign identifiers from paused campaigns must be held “in reserve” until the SKAdNetwork timers have credibly expired).

SKAdNetwork 4.0 addresses each of these limitations and restrictions. But in considering the impact that SKAdNetwork 4.0 could potentially have on mobile app advertising — and it’s worth noting that SKAdNetwork is only useful for app install advertising campaigns, not campaigns that lead to web destinations — it’s more helpful to identify the specific problems that the update solves. Below is a survey of what are, to my mind, the three most pernicious of those problems, and how they might be solved with SKAdNetwork 4.0.

The chicken-and-egg problem with conversion values

In the current implementation of SKAdNetwork, conversion values are only transmitted with install postbacks when a nebulous privacy threshold is met: this threshold is applied to each campaign identifier, meaning that any given campaign must generate enough installs to surpass the privacy threshold in order for conversion values (and source app identifiers) to be included with its postbacks. The privacy threshold is assessed at the point of install.

The result of this is that new campaigns must generate some number of installs before conversion values are included in postbacks. And since conversion values are used to assess the performance of campaigns — by both advertisers and ad platforms alike — for the purpose of allocating budget, the critical information needed to determine whether a new campaign should be scaled or not is unavailable. This creates a chicken-and-egg dynamic: an advertiser can’t scale a campaign absent performance data, but the campaign doesn’t generate performance data absent scale.

SKAdNetwork 4.0 addresses this by introducing a coarse conversion value: a three-option categorical variable that is included in the postback when a minimal level of crowd anonymity is met (with SKAdNetwork 4.0, Apple replaces privacy threshold with the more common terminology of crowd anonymity). Note per the above diagram that the lowest of the three tiers of crownd anonymity produces a postback that contains no conversion value data: it’s unclear what these new thresholds will be, and if the threshold to enter the “intermediate tier” that includes the coarse-grained conversion value will be lower than the current threshold.

Presuming that the intermediate level of crowd anonymity is less restrictive than the current privacy threshold, this new approach should result in advertisers getting more performance signal from new campaigns — potentially enough to determine whether additional spend is justified to enter the “highest tier” of crowd anonymity. This intermediate, directional signal might be invaluable from a campaign optimization standpoint: it allows the advertiser to understand if the users being acquired are generating value to some rough standard. If this directional signal can obviate the chicken-and-egg problem, it might unlock additional ad spend, allowing campaigns to be scaled where before they might have been abandoned.

The lack of transparency into down-funnel user behavior

SKAdNetwork’s existing, convoluted timer system, which I unpack in this QuantMar thread and in the diagram below from this piece, incentivizes advertisers to collect conversion values from early in the customer journey such that the timer expires as quickly as possible after the install, reducing the round-trip feedback loop for advertising platforms. To that end, some advertising platforms explicitly instructed advertisers to only observe conversion values for the first 24 hours after an install to facilitate that speedy turnaround on campaign signal.

This resulted in advertisers attempting to proxy an estimate of user lifetime value from very early in the product journey. This is difficult to do; as a result, some developers inserted heavy-handed monetization mechanics into the early customer experience so as to collect monetization signal from players as quickly as possible, and others simply relented and reverted back to very broad optimization against install prices. Neither of this is optimal from a commercial standpoint. It’s understandable that Apple would want to disrupt the free-flow of data between apps and ad platforms — I’ve called this the events stream — but it makes no sense to limit the ability to capture context to such a degree that developers are forced to implement heavy-handed monetization in early moments of the customer journey to get any signal at all.

This lack of transparency results from both the timer system and the fact that SKAdNetwork only allows for one postback to be produced per install, and both of those issues are addressed with SKAdNetwork 4.0. The timer system is being replaced with three attribution windows of 0-2 days, 3-7 days, and 8-35 days, each of which will produce a separate postback. The postback from the 0-2 day window can potentially contain a fine-grained conversion value, given enough install volume to reach that level of crowd anonymity, but the other two postbacks can only contain coarse-grained conversion values. Nonetheless, these windows will allow advertisers to harvest in-app context from later stages of the customer journey, providing a window into late-stage monetization and engagement that will deliver more information to use in estimating user value (and bid prices) than is currently available. Worth pointing out is the fact that the postbacks from these separate attribution windows will be independent of each other: ad platforms and advertisers won’t be able to connect them for individual users.

The inability to scale creative testing

Prior to ATT, as digital advertising generally embraced the extensive use of campaign automation, the prevailing strategy for campaign optimization at high levels of spend was broad, expansive creative testing. As I detail in this article, the largest ad platforms were capable of targeting distinct groups of people on the basis of the behavioral data they collected, and so the provision of very many creative variants allowed those platforms to pair ad creative with audience segments with a high level of specificity. This was done in an automated way by the ad platforms: the creative that was uploaded by advertisers was procedurally bundled into different permutations of ads, consisting of ad creative, bid, and audience targeting parameters. These automated systems could assess these combinations for performance quickly because the IDFA allowed for campaign conversions to be observed immediately.

This changed with ATT because, as mentioned previously, SKAdNetwork only allows for up to 100 campaign identifiers to be used per app, per ad platform. This limits the number of permutations that an ad platform can test at a time, as explained here. SKAdNetwork 4.0 addresses this by creating a hierarchical source identifier field that can hold up to four digits, for 10,000 possible values (0-9999). Apple has advised advertisers to think of the four digits as representing three different values that can be assigned to any property of a campaign (as below: digit one is a value, digit two is a different value, and the last two digits represent the existing campaign identifier schema).

The addition of these new digits to the source identifier field could allow advertisers to more thoroughly conduct experiments with campaign parameters (or to capture more distinct campaign characteristics, such as the ad creative used). This additional capacity for experimentation could have a direct impact on performance: with more ability to test new audience targets and creative resonance, an advertiser can find successful variations on campaign settings more quickly. Note that the availbility of the additional two digits is contingent on crowd anonymity: at the lowest level, only two digits are available for use, and the two higher tiers harvest one additional digit each.

SKAdNetwork 4.0 invites optimism. If implemented in earnest by Apple in service of advertiser interests, version 4.0 could potentially solve the thorniest problems with SKAdNetwork.