Dear Apple: These changes will improve SKAdNetwork for advertisers

Dear Apple,

The privacy protections you are implementing in iOS 14 are indisputably good for consumers: these changes will give iOS users a level of granular control over their data that amplifies trust. In the short term, these changes present challenges to mobile advertisers, most of which have built infrastructure for which the IDFA is integral to advertising measurement and analytics. Advertisers will feel some pain as they transition away from this infrastructure, but I believe that the long-term consequences to advertising performance of user-level attribution being abolished are exaggerated.

As an analyst of the mobile ecosystem, I find it more beneficial to think about the durable solutions to changes that will persist three to five years from now than devoting energy to thinking about short-term workarounds or loopholes that will only be viable for some number of months. It is for this reason that I believe all advertisers would benefit from planning their infrastructure around SKAdNetwork, which is the long-term solution to advertising measurement on iOS. You have made it clear that fingerprinting will not be allowed if a user has opted out of ad tracking, and other similar, awkward shortcuts are unlikely to be workable for enough time to be interesting.

It is also for this reason that I believe it worthwhile to propose changes to SKAdNetwork that will benefit advertisers while still preserving Apple’s core commitment to user privacy. SKAdNetwork can be an incredible tool for mobile advertising measurement, but in the incarnation described in its technical documentation, it lacks some critical functionality.

A spirited discussion is taking place on the Mobile Dev Memo Slack around how SKAdNetwork will be implemented and how advertisers will be able to transition to this new paradigm. Allowing advertisers’ voices to be heard now will likely alleviate the need to police loopholes and workarounds later. Most advertisers with whom I’ve spoken in the weeks since WWDC20 want SKAdNetwork to succeed as the permanent solution for mobile measurement on iOS; allowing advertisers to become invested in its development is a win for the entire ecosystem. This ecosystem, including Apple, should be aligned around a privacy-centric measurement solution that facilitates advertising growth, and the concomitant increases in developer and platform revenues that result.

That said, I believe there are improvements that can be brought to three functional components of the SKAdNetwork workflow: conversion measurement, campaign tracking, and data retrieval.

SKAdNetwork Conversion Measurement

The current SKAdNetwork conversion measurement logic is overwrought and complex, and the way that conversion identifiers are implemented doesn’t provide enough value to the advertiser. A conversion event should be useful to an ad network in optimizing its targeting within the context of some optimization objective. The current implementation of the conversion identifier only allows for one event — the highest value recorded via the 6-bit field within some cycle of a resettable timer — to be associated with an install attribution, meaning the source network receives no insight into the number or magnitude of the events fired by the user.

A more helpful approach would be to create a second postback type specifically for conversion events. Ad networks use conversion events to target the most engaged users: the magnitude and frequency of events are important considerations of campaign success. Further, the construction of the current conversion event timer logic incentivizes app developers to concentrate their monetization mechanics very early in the user lifecycle so as to produce meaningful monetization signals as quickly as possible. This will result in a degraded user experience: users will feel like their pockets are being picked with aggressive sales tactics, especially with subscription apps, which will need to find ways to incentivize immediate subscriptions so as to feed their ad networks with conversion events in order to capture any monetization data.

Sending conversion events as separate postbacks will allow ad networks to track the magnitude and frequency of these events at the campaign level without incentivizing app developers to front-load the user experience with monetization hooks. And privacy would still be preserved: the ad networks that receive these events back wouldn’t be able to tie them to individual users since they have no insight into the cohort to which the installs belong, and thus they would be prevented from using this information to build device graphs.

SKAdNetwork Campaign Tracking

There are a number of issues with the existing incarnation of SKAdNetwork that prevent campaigns from being optimized effectively. The first and most obvious of these is the arbitrary limit of 100 tracked campaigns. I understand that advertisers can micro-target campaigns in such a way that could lead to near-deterministic attribution, but 100 campaigns is simply too few to allow for adequate segmentation, especially in this new paradigm that reverts campaign management strategy back to circa 2014-2015 best practices. A limit of 1,000 campaign identifiers would achieve the same privacy objective while also giving advertisers enough agency to segment traffic competently.

Second, a campaign identifier isn’t sufficient for optimizing and iterating on ad creative. Advertisers really need an advertisement identifier to be able to build creative production processes that allow them to hone messaging.

SKAdNetwork Data Retrieval and Aggregation

The current workflow, in which a postback is sent to the ad network that generates an install, allows ad networks to optimize campaigns, but it creates some complications by granting first party ownership of attribution data to the ad networks. Users don’t have relationships with ad networks, they have relationships with apps: is it not more seamless and sensible to give advertisers first-party access to install data and let them decide with whom they share it?

Consider making attribution data available to advertisers directly via API. Advertisers could connect directly to the API and ingest all of their attribution data, across all ad networks, in one place, as opposed to the current solution which requires advertisers to ingest data from each of the advertising network that they work with. The current flow of data — from the SKAdNetwork SDK in the app to the ad network — gives ad networks an incredible level of power in determining how that data is subsequently transmitted. Advertisers should have a means of accessing their attribution data without depending on the ad network sending it to them (or any other party).

The current flow of data also burdens app advertisers with a daunting amount of overhead, requiring them to build connections to every one of their ad partners’ APIs in order to ingest siloed advertising data. As anyone who has ever built a cost aggregation system for advertising spend knows, these APIs change and break frequently, causing data availability issues that occur with frustrating regularity.

Conclusion

SKAdNetwork is the future of mobile attribution on iOS, and it will play a critical, focal role in mobile advertising measurement. But an ounce of prevention is worth a pound of cure with SKAdNetwork: by engaging with advertisers and app developers around what they need in an attribution system, Apple can avoid the cat-and-mouse game that will inevitably emerge as ad tech companies create workarounds for user-level attribution that violate the spirit of the changes introduced in iOS 14.

The next few months present a valuable opportunity to re-cast mobile advertising with consumer privacy as a fundamental precept. I think SKAdNetwork can both allow advertisers to perform the measurement necessary to grow their revenue through performance advertising and protect consumer privacy, but it’s currently missing core functionality if it is to replace install attribution on iOS completely.

Photo by Nizzah Khusnunnisa on Unsplash