As you're likely aware by now, a yet-to-be-released update for iOS14 will force significant changes to the ad industry ecosystem. What is less likely to be widely understood is the actual impact these changes will have on your business and how you can adequately prepare to avoid disruption.

First and foremost, this will not be a short read. Apple's changes are broad and sweeping and create a cascade of ripple effects as ecosystem vendors have chosen to react in separate but unique ways, often with incomplete disclosures that we must piece together ourselves. Secondly, the intent of this article is not to detail specific action steps. For that, we will circulate additional and more direct guidance for both Advertisers and Affiliates. Instead, this article aims to inform and educate you on the pending near-term changes and further speculate on what is likely to become the new normal.

Setting The Stage - iOS and Android

Initially slated for a release in the Summer of 2020, iOS14 aims to correct past mistakes of exposing a unique user identifier known as Identifier for Advertisers or IDFA. Its launch date was postponed quickly due to industry outcry - most notably from Facebook - until an undisclosed but now assumed imminent time in 2021. On the surface, IDFA is nothing more than a string of random characters, and while it may seem innocuous, its purpose was clear: to give advertisers an open and direct way to identify users across Apps in iOS. However, this concept is not unique to Apple. Google has implemented the same thing in Android, although they refer to it as an Android Advertiser Identifier or AAID to save the embarrassment of copying one of Apple's ideas.

More recently, Apple has gone through a bit of a cultural rebirth, centred around user privacy and data protection. And while it may make us feel warm and fuzzy to believe that Apple has elevated itself to become altruistic, it's hard to overlook how increased advertising friction would help close the few remaining ways around the 30% Apple tax. Either way, with this new-found will to fix past misgivings, Apple has decided that the simple removal of IDFA would be insufficient to protect user privacy. Instead, their future strategy consists of 3 core parts:

  1. Dubbed "The Prompt," but more formally known as AppTrackingTransparency (ATT), Apple will prohibit ad tracking of any kind unless users provide explicit consent.
  2. SKAdNetwork, an opinionated and rigid API for measuring advertising effectiveness for iOS Apps. It will serve as the only measurement option available when a user opts out of AppTrackingTransparency (i.e. most people).
  3. Private Click Measurement, or PCM, a browser-based framework designed to enable anonymous measurement for ad attribution. Essentially a variant of SKAdNetwork built for the web.

If there's one thing that does shine through all of Apple's proposed changes, it's their brutalist approach and brazen disregard for alternate models. Their self-appointed role as Judge, Jury and Executioner allows them to shutter businesses without a second thought and with nothing at stake.

As for Google, we can definitively say that they have more to protect here, and so far, their response has been non-existent. They are perhaps borrowing the strategy from a toddler's game of hide-and-seek and sticking firm to the belief that if they close their eyes and stand real still, they'll go unnoticed - even if they're standing in the middle of an empty room. It seems to be working, for now, but one has to wonder if fighting data regulators alongside antitrust investigators will spread them a bit thin. In any case, the benefit today is that parties relying on Google Advertising do not need to make any changes, even if targeting iOS users.

The Prompt

In its first iteration, "The Prompt" aims to make users aware of how pervasive background tracking is within apps and give them a choice to opt-out. This option is only presented to users when using applications installed through the App Store and does not directly affect the mobile web. Partly because IDFA's are not typically available in web contexts on iOS and partly because a superior technology for consent already exists in that ecosystem. You know - those cookie banners you come across on each site you visit, that you totally read in full and use to make informed decisions about your privacy.

A users' decision to opt-in to AppTrackingTransparency is a decision to maintain the status quo, and these individuals will earn the right to continue their blissful ignorance. Should a user decide data collection is not acceptable and opt-out, well, they will be enrolled in part two of Apple's outlined changes. Any 3rd parties that an App wants to share data with will have to collect it through SKAdNetwork - the implications of which I'll discuss in a minute.

Any App that collects user data (IDFA or not) outside SKAdNetwork after a user has opted-out shall be met with a swift removal from the App Store - likely permanently. What Apple stresses further is that it does not matter if this data collection was done knowingly in 1st party code or accidentally through an included 3rd party SDK. An App Publisher takes full responsibility for the application that they release. (We do not use a native SDK, your work with us is not a point of concern here.)

The actual opt-in rates will vary from App to App, and gurus and consultants alike will surely sell companies one weird trick to further influence user behaviour to opt-in. Still, we can probably safely conclude that opt-out will be the majority decision. None of this should be a direct concern, though, as you are likely a Buy-Side market participant and have no influence over the Apps that run your ads. It's the App makers and Mobile Ad Networks that need to make changes here. As a mere participant, any desires you have to hold the line and cling on to data and practices from yesteryear are irrelevant. Publishers have no choice but to make the necessary changes, and you will have no choice but to adapt or die.

SKAdNetwork

As the name might imply, Apple's new framework, known as SKAdNetwork, mostly applies to Ad Networks (Facebook, Twitter); however, Mobile Measurement Partners and Analytics Providers (Appsflyer, Adjust) might also need to adopt it if they help facilitate ad optimization or personalization.

Pre iOS 14, it was commonplace for Networks and Measurement Providers to ship native SDKs to App makers. These libraries greatly simplify the implementation process for developers to monetize and were more or less free to consume as much user data as necessary in the background to achieve that.

To combat this practice, SkAdNetwork aims to build a secure measurement channel, removing direct access to user data, instead only allowing it to flow through Apple as an impartial 3rd party. Conceptually, it acts as a filter between publishers and users by clamping down on the information that can be shared between them - commonly referred to as "entropy." In simplest terms, entropy is a measure of how many forms a piece of data can have, measured in the fundamental building block of computers - bits. A bit may take on two states, 0 or 1, so a variable with an entropy of one bit may have two discrete values. In existing advertising, there is almost an unlimited amount of entropy available. Ad ids, campaign ids, click ids, UTM values, and more allow advertisers to associate nearly anything to a user. Apple would like to change that, requiring advertisers to use no more than six bits of entropy or exactly 64 distinct values. Whatever you want to associate with a user, you must accomplish inside those six bits. Most publishers have chosen to use this entropy to disambiguate ad campaigns and ad sets, removing the ability to measure things like creatives and ad placements.

You can still do a lot with six bits if you're crafty, like stitch together multiple events to encode a larger message in morse code. To prevent this hooliganism, Apple further bans 3rd parties from communicating with the users directly. Instead, all user data must first flow through Apple, who will filter and randomize the captured data before passing it along with a delay to ensure that it remains anonymous. The use of redirect domains would bypass this system, as they would be able to "see" the user in real-time, so those too shall go.

While the above changes apply only to the App ecosystem, Apple has made clear their desire to do the same for the web and in-app browsers.

Private Click Measurement

In May of 2019, Apple's Webkit team released a new web tracking proposal known as Private Click Measurement or PCM. It aptly received little fanfare at launch due to a deliberate but perplexing flaw: it's a comically anti-advertiser feature that advertisers are encouraged to adopt. In that way, it's very much the same as SKAdNetwork, but fortunately for us, the web is both a more traditionally open platform than mobile and remains mostly outside the reach of Apple's iron grasp. By-and-large it wages the same war as SKAdNetwork - significantly reduced user entropy through an impartial intermediary - while adding even more onerous restrictions:

  1. Unlike SKAdNetwork, PCM explicitly prevents brands from sharing even anonymous attribution data with partners. Under PCM, only the brand owner is capable of receiving user-generated events. Somehow lost on Apple is the awareness that most brands are not multinational conglomerates. End-to-end vertical integration is an unrealistic expectation for small and even midsize companies. Supporting PCM requires robust, and boutique infrastructure and Apple expects that you have the expertise to manage this in-house.
  2. Whereas the previous Apple policies allow sharing data under a shared company umbrella, PCM defines ownership at the domain level (specifically TLD+1, meaning root domain plus extension. i.e. google.com) and purposefully excludes sharing data across these arbitrary domain boundaries. For example, if your marketing domain differs from that of your store, or your checkout funnel runs on a domain owned by your payment processor, you will be unable to receive user events altogether.
  3. Each TLD+1 has a small, fixed amount of entropy available for tracking unique events. Every event you use counts against this global cap, without exception. If you previously used campaign, agency, or regionally-specific events, you will quickly run out of allowed entropy, leaving the remaining events untracked. Under PCM, events fired on semantically distinct domains such as blog.mystore.com, ca.mystore.com, or mystore.com/us/ would still roll up to mystore.com as PCM is otherwise unable to shield user entropy from side-channel abuse.

In Apple's proposal, all of these restrictions are to be handled securely by the browser itself, where it would live as a new web standard. This distinction is an important one, for it means that companies that do not own browsers, such as Facebook, would have no mechanism to extend or modify the implementation to make it more functional. If it were a more amenable proposal - even slightly - this would be less of a point of contention. Instead, Apple has staunchly defended their work, frequently citing the protection of user expectations as the motivating factor, all the while discounting the fact that Privacy Policies are the proper legally defensible standard already in play. And it's in the protection of this arbitrary definition of user expectations that Apple believes earns them the right to play regulator and lockout otherwise legally acceptable business cases without due process.

Luckily for our collective sanity, Apple has yet to garner any broad industry agreement on this initiative in its current form, and existing technological ambiguity on the web prevents them from moving substantially forward by themselves. Facebook and Google take issue primarily with the domain-related limitations outlined above and further believe that Apple's entropy limit is too restrictive. Still, Apple refuses to compromise. While this impasse has frozen PCM in its place, Facebook and Google have perhaps seen the writing on the wall and decided to concede in ethos, though grounded in reality. Google's solution, Sandbox, is characteristically anticompetitive but not slated for release until 2022, so I'll sweep it under the rug for now. Contrarily, Facebook has mobilized in short order with plans to release its competing yet private framework, Aggregated Event Measurement or AEM, on the same day that Apple's iOS changes go live.

SKAdNetwork, combined with Aggregated Event Measurement, will create a fundamental shift in how attribution works on all Facebook campaigns - Mobile and Web alike. It's with this understanding that we can begin to dissect Facebook's significant and multi-faceted response. Expect breaking changes at an unprecedented scale, without a pre-launch beta or feature opt-in window. Strap in.

Facebook Relents

Despite their on-going public spat with Apple, Facebook has decided to press forwards with a staggering number of changes that surpass all other vendors' combined responses. In Facebook's fight for self-preservation, they have relented to the design ideals set forth by SkAdNetwork and implemented parallel changes for the web under the umbrella of Aggregated Event Measurement. On the surface, this may appear to be an over-reaction, as Apple does not yet have the teeth to impose changes on the web ecosystem. But if the proposal did gain steam, Facebook's lack of a browser would leave them with little recourse. Their resulting angle seems to be: comply in spirit and standardize around anonymous privacy primitives, hoping that this will position them well enough to avoid future disruption. It's a bold strategy indeed, especially when considering that because Facebook cannot implement AEM at the browser level, what they deliver will not truly be private or anonymous in the way that Apple desires. The lack of a secure intermediary means that any privacy protections are only feigned.

Facebook still has no choice but to use SkAdNetwork for in-app iOS traffic. Therefore, all of the previously outlined limitations apply equally to Facebook as they do to anyone else. App Campaigns will receive the following restrictions: single ad account, 9 campaign limit, 8 event limit, anonymous & delayed reporting. Agencies driving App installs are in for some trouble, but that's not us - phew!

What remains is a laundry list of restrictions derived from SkAdNetwork and Private Click Measurement but implemented via Aggregated Event Measurement. These changes will apply to all campaigns outside of those targeting iOS Apps. Summarized, these are:

  1. The reinforcement of Domain Verification and its new role in pixel events.
  2. A limit of 8 conversion events per domain for ad optimization, regardless of how many pixels you use.
  3. Event measurement to be restricted, aggregated and delayed, and removal of several previously supported attribution windows.

Domain Verification

This long withstanding Facebook feature is not new but is now of increased importance. To claim a domain, you go through a relatively standard procedure of uploading a secret value to a publicly accessible place on your website or DNS provider. Once claimed, Facebook will unlock additional tools for controlling who can run ads on your behalf or link to your content. (However, please do not  make changes without first coordinating with our team, as you may accidentally disrupt on-going campaigns.)

The newer and much more significant change regarding verification applies to pixels. We'll jump right into the implications of this, but take note that the next set of changes assumes that you've completed this process first for any domain that incorporates Facebook pixels.

Facebook Events

Previously, pixels effectively served as stand-alone optimization engines. Independent from domains and ad-sets, they were free to spread through the web like dandelion seeds. Equipped with nothing more than a Facebook Business Manager account, you were able to create as many as you wanted. In many ways, they were the lifeblood of advertising on Facebook, turning traffic and user behaviour into discounted ad-cost futures. Not only did these little containers enable media buyers and agencies to act independently of the brands that they serviced, but their near-endless customization options allowed for isolating key trends and market segments, turning loss-makers into out-of-the-park grand-slams.

Like all good things, the pixel golden age must come to an end. Apple's war on entropy has dealt a paralyzing blow to our dear pixel. It's not dead - merely relegated to the small confines of a hospital room where it clings on to life support. In the new normal, a pixel belongs to a single verified domain, from which it is not allowed to stray. It is no longer able to associate interesting metadata, such as what products users view or the actual value of their transactions, as that would open up too many bits of entropy for misuse. In place of all this, you'll now be limited to a maximum of 8 events per verified domain - 5, if you want to do something novel, like kinda-sorta differentiate between a purchase worth $5 and one worth $200. This event limitation further restricts the common practice of allowing 3rd parties to place their Facebook pixels on your domain, as going forward, the events omitted by these pixels will now count towards the per-domain limit: a breaking change. What Facebook has done a lousy job of communicating is that an events' uniqueness does not come from just its name - Purchase, AddToCart, etc. - but rather from the paired combination of <Pixel Id, Event>. You cannot avoid the new limits by using multiple pixels. Every domain has just 8 "signals" that it is permitted to broadcast, recipient included.

What is not abundantly clear is whether or not Facebook will allow the domain used in an ad to defer from that of its associated pixel. If not, it will become imperative to use the brand's pixel solely. SkAdNetwork and PCM both eliminate the use of additional domains as an acceptable practice, permitting only the 1st party brand domain (and pixel) to be involved in attribution. And while Facebook does echo this advice for their Dynamic Ads product, they make no specific call outs for any others. Buried deeper in the Facebook API docs is just a hint: "[conversion_domain] will be auto-populated for existing ads by inferring from destination URLs." This reveals that while there can only be a single conversion domain per ad, defaulting to the one used in the destination URL should imply that further changes are allowed. We further know that disagreement on single domain restrictions led in part to the creation of AEM, so there's a reasonable chance that Facebook such, although I wouldn't come to depend on it indefinitely. On the bright side, the added pixel limitations remove most of that Disney "magic," making them less worthy of secrecy and more tenable to share.

If you're a media buyer, a pause for concern here is warranted; after all, the use of 3rd party domains is a Performance Marketing mainstay. Platforms like ourselves depend on the use of 3rd party domains to provide features such as A/B split testing, CAP redirects, and most importantly, securely firing your pixels. A lot of engineering effort goes into maintaining, securing and scaling this infrastructure while safeguarding it against ever-present threats, including ad-block and domain reputation scoring. What's more, is we provide this industry-leading attribution stack for free to all our customers regardless of their size! We go to great lengths to ensure a minimal number of customers per domain, but reducing that number to 1 is intractable. As a result, verifying our tracking domains would be of little use. We will be unable to carve out a usable number of the 8 allowed conversion events per customer - assuming that we also found a way to manage the resulting event mappings. This means that it will be impossible for us (and other networks) to provide a direct mechanism for firing Facebook pixels on our platform. Consequently, your existing Facebook pixels will cease to function when AEM goes live. Instead, you will need to move your pixel configuration to a domain that you own and set this new URL as an iFrame in place of it.

Restricted, Aggregated, and Delayed Measurement

Aggregated Event Measurement must introduce new restrictions designed to protect individuals' privacy to mirror the safeguards put forth by SkAdNetwork and PCM. Facebook commonly refers to these in unison as "restrict, aggregate, and delay:"

  1. The 8 event limit serves to restrict the amount of data that you are allowed to collect. Any event that falls outside of these will not be available for ad optimization, although you may still use it to create custom audiences. Optional custom data that could previously be supplied alongside events will be ignored.
  2. Pixel owners must prioritize the events it may collect, and data will be aggregated according to this specification. Only the most significant event for each user will become visible in reporting. For example, if a user triggers events Lead, InitiateCheckout and Purchase, Facebook will only disclose the Purchase event's existence.
  3. Website conversion events will be delayed to track under conversion time and not the time of ad impression. Additionally, there may be an artificial delay of up to 48 hours added for offsite conversions from iOS users.

Facebook will also remove support for 28-day click-through, 28-day view-through, and 7-day view-through attribution windows and demographic breakdowns for offsite conversion events. If you rely on these features, you should take snapshots today to serve as historical benchmarks for comparison after their removal.

The most significant repercussions here will be the inability to optimize granularly. Due to the newly introduced artificial delays, hourly reporting will become inaccurate. It may also take days' wait to get an accurate picture of campaign performance inside Facebook's provided reports. These limitations are artificial (for now), so we'll step up to plug any holes for the time being. To that end, we'll be unveiling a new reporting suite that we call Jumbleberry Insights in the coming weeks.

Summary

Hopefully you're feeling a little less anxious and a lot more informed about the coming changes. It's a lot to take in, even for industry veterans like ourselves. For as many concepts as we covered, there's an equal number that we had to axe in the interest of time. You likely still have unanswered questions, as do we. We'll have additional resources, articles, and discussions available as we lead up to the launch of iOS14 changes, but it will still be impossible to cover every use case. We encourage you to continue discussions with our team members and other industry partners. Our teams are standing by to make this transition as easy as possible, but we can't do it alone, so thank you!