Analyzing Facebook’s iOS14 advertising changes

After announcing last week that the company would completely abandon the IDFA for iOS14 advertising campaigns, Facebook released a FAQ document to advertisers that provides guidance around how they should prepare for updates to the platform.

The FAQ is rife with insight — and it reveals just how dramatically different the iOS14 marketing environment will be from that of today. Any illusions that Facebook will find workarounds to the IDFA restrictions, or that the company has enough data about each user to maintain the device-centric advertising status quo on mobile, are dispelled in reading the FAQ document. Advertising to iOS users on Facebook will fundamentally change with the release of iOS14; in this article, I will surface and analyze the most noteworthy revelations from the document.

Preparing for iOS14

The document opens with a list of staggering recommendations for advertisers in preparing for iOS14:

Going through each of these on its own:

Update to the latest version of the SDK to support iOS 14. Facebook is publishing an entirely new SDK to facilitate iOS14 advertising; presumably, this SDK will effectively terminate any data transmission if the user has not opted into ad tracking except for what is permissible through SKAdNetwork.

Use non-IDFA match methods such as adopting Facebook Login or using Advanced Matching to share (with applicable permissions) hashed customer contact information (e.g., email address). I’ve seen this recommendation be misinterpreted: what Facebook is telling advertisers in this statement is that Facebook Login (SSO) or hashed email addresses will be the identifiers that are sent when the user has opted into ad tracking because Facebook is abandoning use of the IDFA.

One common misconception around iOS14 is that SSO (eg. Facebook Login) can be used to evade ad tracking opt in: if the user opts out of ad tracking, direct them into an SSO login that associates their state in the advertiser’s app with their Facebook ID, preserving the event stream between the app and Facebook and enabling advertising measurement. But Apple has been very clear about SSO requiring opt in, per the App Tracking Transparency documentation:

Likewise, Apple was very clear at WWDC around in-app profile data being bound by opt-in if it is shared with an ad platform:

What Facebook is declaring in this line from the FAQ is that instituting SSO or the collection of emails should be done in the app for when a user has opted into ad tracking so that any data transmitted back to Facebook can be anchored with a useful identifier (again, which can’t be the IDFA, because Facebook is abandoning the IDFA on its platform).

To help preserve the fidelity of app install campaign measurement, we will require the creation and usage of a dedicated iOS 14 ad account. This line reveals just how seriously Facebook is taking its commitment to iOS14 privacy constraints: not only will advertisers need to use an entirely new SDK to prevent data leakage when the user has opted out, they will need to create wholly new ad accounts to avoid previously-collected data from being used to target campaigns to users that opt out of tracking after upgrading to iOS14.

There are a few details worth unpacking in this idea. The first is that there are essentially two broad buckets of data that are useful in targeting advertising campaigns. The first bucket is the user-specific data that Facebook uses to build profiles of its users: who monetizes, who engages, who clicks on ads, etc. This data doesn’t go away with the introduction of iOS14; user profiles are indexed to users’ Facebook IDs and remain valuable after the release of iOS14, although they degrade quickly. One of the primary indicators that a user is a high-potential monetizer is that they have monetized recently. Facebook loses the timeliness component of its knowledge of its users’ monetization histories after iOS14 (because it will no longer receive user-specific events streams from all iOS apps), and so while it might know that a user has monetized heavily in the past, it won’t know whether they have done so recently.

The second bucket of data that is useful for targeting purposes is campaign-specific data: when Campaign X has been targeted to users with some set of specific profiles, it has generated an optimal density of conversions for the advertiser (which is how Facebook gets paid: by generating conversions). Facebook loses this campaign performance data completely when it forces advertisers to create new ad accounts.

My best guess as to why Facebook is doing this: iOS14 campaigns will use SKAdNetwork conversion events as success signals for optimization and not the full stream of events that Facebook currently uses for iOS13 campaigns, and the optimization models required in each of these cases are so different that transitioning the campaigns from one model to the next would simply break ad targeting. Facebook currently targets at the user level using event histories; in iOS14, Facebook will have to target much broader segments of users using demographic and interest data. The loss of granularity at the targeting layer, in addition to the sparseness of event signals in iOS14 (only one conversion value is possibly sent per acquired user in the campaign), means that the two campaign types (iOS13 and iOS14) require totally different parameter sets.

Facebook provides a modest amount of context around the above topic in the FAQ portion of the document:

Campaign Limits and Reporting

In a later section, Facebook provides some interesting guidance around changes to reporting on the platform:

The SKAN API will report back data aggregated at the campaign level…reporting at the ad level will be modeled based on aggregated data received from the SKAN API, unless there is only one ad for a given campaign. This is important. In the new iOS14 campaign environment, Facebook only allows nine campaigns per ad account, with each campaign containing just one ad set (more on that later; the structure of the document is a little disjointed). Since the SKAdNetwork postback only includes a campaign ID parameter, then the relationship between campaign and ad set on Facebook needs to be one-to-one.

But it wouldn’t be practical to only include one ad per ad set, and given that SKAdNetwork reporting is aggregated at the campaign level, Facebook needs to “model” (estimate) the performance of each ad in the ad set based on campaign performance. I’ll offer more analysis on this point in a later section, but the broader point here is that ad-level performance won’t be directly measured for iOS14 campaigns but rather estimated.

This disclosure answers a question about how MMPs might take ownership of SKAdNetwork data, given that it is transmitted directly from Apple to ad networks: the ad networks will give it to them. Advertisers can enable a setting that instructs Facebook to transmit their SKAdNetwork receipts to their MMP.

But this insight also reveals that advertisers will need the Facebook SDK integrated into their apps in order to run AEO campaigns, and the MMP SDK will only allow for MAI campaigns to be run. This further calls into question the role that MMPs will play in the new ad tech landscape being excavated by Apple with iOS14: increasingly at the periphery of the primary, three-party relationship that exists between advertiser, ad network, and Apple.

This segment of the FAQ provides more context around reporting:

Facebook is mostly acknowledging here that campaign data will not be available in real time (as a result of the conversion value timer logic implemented into the SKAdNetwork postback flow), that performance data will be modeled (estimated) at the ad level unless each ad set only contains one ad, and that performance data will not be segmented by demographic features (because Facebook will only have demographic targeting features available at the campaign level, but it won’t actually know anything about the individual users that install apps or complete conversion events).

The next section in the FAQ is seismic: it is where Facebook states that only nine campaigns will be supported per iOS14 ad account, even though the SKAdNetwork provides 100 campaign IDs per advertised app, per network:

This is important, not only because it signifies a very real limitation on advertisers with respect to campaign breadth, but because it provides some helpful guidance around how Facebook is utilizing the SKAdNetwork framework for optimizing campaigns.

What I interpret from the nine campaign limit is that Facebook will utilize 10 campaign IDs per live, advertiser-designated campaign for experimentation (9 + 9*10 = 99). The idea here is that the advertiser will establish nine campaigns, each of which contains no more than one ad set but potentially many ads, and Facebook will use 10 reserved campaign IDs per live campaign to dynamically experiment with ad performance and adjacent demographic targeting in order to optimize those campaigns fully.

I actually proposed something similar to this for ad creative testing in my recent workshop series, How to Build and Scale successful apps without the IDFA, except that I suggested flipping the ratio: using just 10 campaign IDs for testing, with the remaining 90 being used for scaling live campaigns.

The performance principal in Facebook’s campaign limit approach is that an advertiser establishes a campaign with some sort of demographic targeting constraints, uploads a number of ads to the ad set for that campaign, and then Facebook uses the 10 “phantom campaigns” to test the various permutations of targeting parameters and ads that exist in order to find the one that produces the most cost effective conversions (as measured through conversion values from SKAdNetwork postbacks). Facebook will dynamically cycle these combinations of ads and targeting subsets through the available Campaign IDs, optimizing performance by allocating disproportionate budget to the combinations that drive the most efficiency.

Some approach like this will represent the new “learning phase” for Facebook campaigns, with the combinations of targeting parameters and ads settling into stable state as combinations are tested and performance is discovered.

Marketing API

Later in the document, Facebook summarizes the new limitations that are imposed on advertisers in the iOS14 environment (again, the ordering of these disclosures feels disjointed, but I wanted to maintain the structure of the document in the analysis):

This is mostly summary, with one important piece of new information:

Ads Manager only (no support for Marketing API to create and edit campaigns targeting iOS 14). Facebook is announcing here that it is not offering Marketing API support to iOS 14 campaigns; the Marketing API is what allows advertisers to create and edit Facebook campaigns programmatically. This blocks the SaaS tools that have emerged to automate Facebook campaign management (as well as the proprietary initiatives that many advertisers have launched in the past few years as marketing automation received significant investment across the mobile ecosystem).

Conversion Value management

The document then proceeds to relay some information (and subtext) about SKAdNetwork conversion value management:

There are two important revelations in this block of text:

  1. Facebook will only capture conversion values from within a 24-hour period after initial app launch. This means that the Facebook SDK won’t allow for the conversion value timer to be reset endlessly: Facebook will observe named conversion value events only within a 24-hour window after initial app open and stop firing the updateConversionValue() method once that period has lapsed;
  2. Facebook will provide advertisers with a standardized list of in-app events that should be mapped to 6-bit conversion values and instrumented within the app.

While both of these developments are significant, they were both predictable. The 24-hour window for capturing conversion values is a logical approach to optimizing performance within the tradeoff between SKAdNetwork postback turnaround time and in-app value signal. And a standardized library of defined events already exists within Facebook’s optimization schematic: it is the set of AEO events that Facebook suggests advertisers optimizes toward.

Why is a standardized event catalogue important? Because Facebook uses the accumulated performance of all apps, aggregated around the specific events in the AEO events library, in optimizing campaigns. To not use the standardized catalogue of events is to ask Facebook to build a performance history for some new event for some targeting segment for a single app, which would be slow, expensive, and not very performant. Keep in mind that most revenue and deep engagement events are very rare: by aggregating event history for all apps and all users within the confines of a standardized library, Facebook can leverage the entirety of its audience to optimize any given app’s advertising campaign.

The same logic applies to the conversion value mappings that Facebook will propose advertisers map to defined in-app events (eg. Tutorial Complete, Account Registration, etc.). By aggregating this data across its entire userbase in a standardized format, Facebook can scale campaigns on the basis of those events quickly and efficiently. Some campaigns, on their own, might never accumulate enough events in the requisite period of convergence time to optimize their own campaigns — leveraging an aggregated, audience-wide event history is critical for Facebook in driving efficient ad spend. The equivalent of not mapping Facebook’s prescribed 6-bit conversion values to specific in-app events would be to run AEO campaigns against “custom events,” which, while possible now, is extremely uncommon, for the reasons cited above.

Note that Facebook hasn’t actually revealed what this event list is yet — nor has it released the iOS14 SDK. Presumably both of these things will be made available in the next weeks.

Lookalike audiences

Finally, Facebook’s advertiser FAQ ends with a fittingly weighty revelation about lookalike audiences for iOS14 ad accounts:

What the above says is that lookalike audiences won’t be built from custom audiences, which are essentially user lists, for iOS14 accounts, but rather from existing campaigns or conversion values. Lookalike audiences are a core component of digital marketing, and they’re often built on Facebook from lists of high-value users uploaded as custom audiences. If marketers can no longer build lookalike audiences from custom audiences but rather have to use existing campaigns or in-app events (conversion events), then they lose the magnitude of monetization of high-value users in establishing targeting: conversion values will be captured within 24 hours of initial app open (as per above) and will only contain limited scope of monetization (because even very high-LTV users can only monetize so much within their first 24 hours of app usage).

This is a fairly devastating development, especially for advertisers whose apps feature long-tail monetization distributions. Custom audiences allow advertisers to build lookalike targeting on the basis of their most valuable users; with iOS14 campaigns, the ability to quantify that value is attenuated dramatically, with lookalikes being established on the basis of early-stage conversion value completion.

Of course, it bears repeating that user-level profiles won’t be possible in iOS14 anyway, and so targeting on the basis of any specific user’s propensity to spend is not possible in the first place. In iOS14, lookalike targeting will be done on the basis of the demographic and interest targets that deliver conversion events for already live campaigns. This is another reason why it will be critical for advertisers to instrument Facebook’s standardized conversion value catalogue.

In closing

Facebook is making substantive changes to its ad platform to accommodate iOS14. This wasn’t necessarily the expected course that Facebook would take; at least, it certainly wasn’t the prevailing expectation. In speaking to institutional investors, journalists, and other marketers since WWDC, my sense was that most people believed that Facebook could find a way — using its sophisticated infrastructure and massive data set — to maintain the device-centric status quo on mobile.

What Facebook’s announcement last week reveals is that it can’t: it is fully embracing the SKAdNetwork measurement framework and is excising the IDFA completely from its advertising machinery. Many things will likely change in the coming months about how Facebook accommodates SKAdNetwork (Facebook admits as much in its advertiser FAQ), but advertisers should be aware of how Facebook plans to update its platform to become SKAdNetwork and iOS14 compliant, as these changes don’t all take place below the surface.