SKAdNetwork and iOS 14 Privacy Changes

Through changes announced at WWDC, Apple has — by fiat — completely reshaped the mobile advertising landscape. While the full implications are still unclear, and Apple may make adjustments before iOS 14 ships, it’s a good time to dig into what we currently know and start preparing for what’s to come.

TLDR: Apple has effectively killed the Identifier for Advertisers (IDFA) by forcing developers to request permission for tracking before accessing it. This will undoubtedly impact Facebook, Google, and other players in the mobile ad ecosystem that have built their businesses around targeted ads, but is also likely to affect the apps that rely on those services. Apple seems to have created SKAdNetwork to soften the blow. While the prospect of Apple providing a better source of truth for attribution is enticing, the current implementation of SKAdNetwork leaves a lot to be desired. 

‍

Why Do We Care?

RevenueCat isn’t an ad-tech company, but we do care about paid user acquisition, as it helps developers reach their true fans and grow their app businesses. In that, we’re actually quite aligned with Apple and our customers. The trust Apple is building with consumers will benefit developers in the long term, even if it causes temporary upheaval on the App Store.

‍

The Importance of App Install Ads

For better and for worse, paid user acquisition powers the economic engine of the App Store. It’s not the only way people find apps — there’s also search, App Store/Play Store editorial, press, word of mouth, and more — but all of those channels are, to varying degrees, driven by the feedback loop of attention. And the most reliable way to feed that loop is to buy attention.

The rise of TikTok is a perfect example. It’s one of the most viral apps in recent years, but Bytedance (TikTok’s parent company) backed that up with a mountain of cash. According to a Bytedance insider, the company has been spending over $1 billion dollars a year on paid user acquisition and other marketing.

Much of the tooling that currently powers paid user acquisition on mobile relies heavily on the IDFA, which allows developers (and the SDKs they install) to uniquely identify individual users. Since Apple introduced the IDFA with iOS 6 in 2012, a slew of tools have been built using it to target, measure, and optimize ad spend at the user level. Because of that, paid user acquisition became more reliable, easier to scale, and easier to measure than other forms of marketing. Not easy, but easier. That’s why it’s the primary user acquisition channel for many apps.

Love or hate it, targeted advertising has almost certainly increased the GDP of the App Store. Any disruption to that paradigm risks a contraction in App Store revenue.

‍

The Dark Side of the IDFA

While Apple intended the IDFA to be used solely for marketing purposes, a shadow industry quickly grew, collecting as much personal information as possible and linking it back to individuals using a combination of the IDFA, fingerprinting, and other techniques. IDFA abuse is nearly impossible for Apple to detect and punish, so Apple was left little choice other than to make system-level changes to prevent abuse.

‍

Exit IDFA

At WWDC last month Apple announced that access to the IDFA now requires explicit permission from users. And because the permission request is controlled by iOS directly — only allowing developers to customize one small section of text — developers won’t be able to use dark patterns the way they have in “complying” with GDPR. A recent survey from TapResearch suggests that the opt-in rate will be well below 30%, which would make the IDFA essentially useless for tracking users at scale.

Even if 50% of users opt in when prompted, users with Limit Ad Tracking (LAT) turned on in iOS 13 (roughly 30% of users) won’t even see the prompt in iOS 14. Which means that a very optimistic 50% opt-in rate amounts to just 35% of all users. Plus, for tracking to be effective, the user would have to opt in both in the app that displayed the ad and in the app that was installed from the ad.

To make matters even worse, LAT users on iOS are some of the biggest spenders on the platform. On iOS 14, the additional hurdle of having to prompt for tracking means that the small audience that can be tracked is a biased subset of an already biased subset. Therefore, any data from users who opt in to tracking can’t be used to make even general assumptions about other users on the platform.

Despite the optimistic reassurances of many people in the ad-tech space, using the IDFA for tracking on iOS 14 is unlikely to provide much meaningful data.

Without being able to target (and retarget) specific users and track them all the way through to purchase, measuring and optimizing the effectiveness of ad spend will change dramatically.

‍

Fingerprinting Is Out Too

When the IDFA isn’t available, such as on the web or when LAT is turned on, ad networks and other companies turn to fingerprinting. The user’s IP address is combined with their device type, local network data, clipboard contents, and any other accessible data to generate a “fingerprint” that attempts to uniquely identify that user.

While many ad-tech companies have proposed fingerprinting as a way to soften the iOS 14 blow, Apple has announced that fingerprinting will also require user permission. Developers will undoubtedly try to skirt those rules, but Apple anticipated this and made fingerprinting much more challenging on iOS 14. While some companies have claimed to achieve 70% or higher fingerprinting accuracy on iOS, the actual number is probably much lower — and will likely drop even more after the changes Apple is making to prevent fingerprinting on iOS 14.

Like IDFA abuse, Apple will have a hard time detecting fingerprinting abuse, but fingerprinting really only works at scale anyway. So expect Apple to closely monitor ad networks, MMPs, and other players in the ad-tech space.

‍

Enter SKAdNetwork

Knowing that they would eventually torpedo the IDFA, in May 2018 Apple quietly released the beginnings of a solution: SKAdNetwork. In exchange for not being able to granularly measure the effectiveness of ~70% (the current IDFA opt-in rate) of advertising, SKAdNetwork allows aggregate attribution without having to ask for permission. Which means near-100% coverage for campaign-level install data. But of course, there are caveats.

First let’s go over how SKAdNetwork works. Here’s a slide from Apple’s “What’s New with In-App Purchase” session at WWDC:

Simple, right? Let’s try that again:

While the gist of SKAdNetwork is relatively easy to understand — Apple tracks clicks at the system level and reports installs directly to ad networks — the implementation details are convoluted. Providing attribution data, even aggregated attribution data, without compromising user privacy is quite difficult, so a certain level of complexity is to be expected.

For all the problems industry players see in SKAdNetwork, Apple seems intent on giving developers and ad networks better attribution data, and that is commendable. While attribution seemed like a solved problem prior to iOS 14, it’s never been as reliable as the mobile ad ecosystem would have developers believe. Between LAT, fraud, first/last click assumptions when a user sees multiple ads, unreliable fingerprinting, and many other issues, developers have been in desperate need of a single source of truth for attribution. And with some additional work, SKAdNetwork could become that, albeit without user-level tracking.

‍

Caveat #1: Campaign Limits

Tracking data will only be allowed at the campaign level, and Apple limits each ad network to 100 campaigns per app.

While 100 campaigns may seem like a lot in the current marketing paradigm, keep in mind that ad networks will now be forced to do all targeting and optimization within these 100 buckets. There are no ad groups, no creative sets — nothing.

So why not allow more campaigns? If Apple allowed unlimited campaign IDs, they would become de facto tracking tools, allowing ad networks to create a unique campaign ID for each ad that is displayed. Even if Apple allowed, say, 1000 campaigns, ad networks would be able to more easily identify individual users.

‍

Caveat #2: Minimal Developer Control

Tracking data will be exchanged between Apple and ad networks directly — neither the app nor any other third party will be able to collect, verify, or act on the data.

From a privacy perspective, this makes sense. The fewer people who receive this data, the less likely it is that users can be triangulated and individually identified. But this puts ad networks in charge, leaving developers with no way to verify or control most of the process. And historically, ad networks have not exactly been saints.

‍

Caveat #3: No Retargeting

Even if a user quickly abandons an app, the act of downloading and engaging with that app demonstrates some level of interest in using the app. Retargeting those users can be one of the most effective forms of advertising. However, tracking limitations will make retargeting much more difficult, even though postbacks contain a “redownload” field for indicating that the app had previously been installed.

‍

Caveat #4: No “View-Through” Attribution

Imagine a user watches a YouTube video with an ad for an app, then a few minutes later searches for that app on the App Store. Apple assumes that install is organic. SKAdNetwork has no way of measuring when an ad impression leads to an install if the ad doesn’t directly lead to the install via a trackable click.

While not perfect, user-level tracking does allow MMPs and ad networks to better tie ad impressions to “organic” installs. On some networks, view-through attribution can account for up to 50% of traffic. On iOS 14 it will be tough to even make educated guesses about view-through attribution.

‍

Caveat #5: Limited Measurement

Measuring return on ad spend is severely limited by Apple’s implementation of updateConversionValue and its timer-based postbacks.

This is the big one.

After an ad is displayed, there’s no way to reliably track revenue generated from that ad, even at the campaign level. To prevent developers from using updateConversionValue to track individual users, Apple has severely limited the timing of those postbacks and the data they contain. While the postback will theoretically make it through 100% of the time when updateConversionValue is called, two fields in the postback, Conversion Value and Source App ID, will be left off if Apple determines that they could violate an individual user’s privacy. This means that developers could get a relatively clear picture of app installs from SKAdNetwork but will get a much fuzzier sense of ROAS.

‍

The Fallout

Because of the limitations and caveats of SKAdNetwork, the mobile advertising industry will have to build new tooling and completely re-think currently successful strategies. But that’s for them to sort out — what matters to RevenueCat and our customers, as well as to Apple, is what happens to apps.

It’s tough to even guess how things will go for apps this fall. Apps that rely heavily on highly targeted user acquisition for installs are likely to be the most seriously impacted, but as discussed above, the accuracy of attribution has been overstated for years. Shifting spend from deterministic to probabilistic measurement might not be as disruptive as it sounds, and big networks with lots of data (like Google and Facebook) might still be able to target somewhat efficiently even with the limitations of SKAdNetwork and Apple’s new privacy rules. But Facebook itself warned this week that “at the very least, [iOS 14 is] going to make it harder for app developers and others to grow using ads on Facebook and elsewhere”.

Another possible outcome is that CPMs drop along with the drop in efficiency as targeting and measurement degrade. That seems a bit less likely, since app advertisers are unlikely to dramatically reduce their spending, and other advertisers will be affected less. Facebook and Google are already working on solutions to get around measurement limitations on the web in iOS 14 — and a significant number of Facebook and Google ads are displayed within their own apps — so targeting and measurement of DTC campaigns and other non-app advertising won’t be impacted as much as app install ads. Google and Facebook don’t share enough granular data to get a handle on how that might play out, but it will be interesting to watch.

Despite the uncertainty, what is clear is that the fundamentals of building a great app business haven’t changed. Apps that deliver true value will continue to convert and retain customers well, even if they are forced to shift their marketing strategies. Just ask the developers of kids’ apps — they got a head start on a post-IDFA world last year after Apple announced stricter tracking limitations for kids’ apps at WWDC 2019.

‍

Negative Incentives

Unfortunately to mitigate those potential impacts, developers will be incentivized to track users in ways that are more difficult for Apple to police. For example: more apps are likely to force logins via email and/or phone numbers. If those identifiers are used for tracking, developers are supposed to ask users for tracking permission, but it’s nearly impossible for Apple to know if a developer shares that data with Facebook for lookalike targeting (or later sells that data to a data broker).

That being the case, expect Apple to force developers to use Sign In With Apple as a login option at some point in the future. Currently, it’s only required when a developer uses a third-party login such as Facebook Login or Google Sign-In. Apple’s cat-and-mouse game to protect user privacy is going to continue for many years. Sabotaging the IDFA might seem like the end of the war, but in reality it’s just another battle that Apple was able to end by fiat.

Given the current implementation of SKAdNetwork, developers will also be incentivized to collect data and push users to subscribe as quickly as possible. Calling updateConversionValue is most reliable in the first session with a new user. If a developer waits for a subscription conversion event to call updateConversionValue, there’s no guarantee the user will re-open the app in a timely manner after completing a free trial. And there will be fewer events, which makes it less likely the postback will pass Apple’s privacy threshold.

‍

The Future of SKAdNetwork 

There are many ways Apple could improve SKAdNetwork, and tackling some of the low-hanging fruit before iOS 14 ships could go a long way toward mitigating the potential disruption.

Here are a few ideas:

1. App open postbacks could be decoupled from Conversion Value postbacks so that at the very least, developers get a clearer picture of installs generated from specific campaigns and don’t have to rush users through the funnel to have a chance at sending the Conversion Value. updateConversionValue could then be called at a later time (or even multiple times) when more meaningful conversion events take place.
2. For subscription apps specifically, it would be fantastic if developers could register specific IAPs so that postbacks could be sent automatically in the background once a free trial has converted (or is cancelled). Most IAPs can only be purchased when a user is live in an app, but free trial conversions often happen on days when the user doesn’t open the app and might not open the app again for many days (daily use is less of a value driver for subscription apps that monetize based on value created for the user instead of the number of hours a user spends looking at ads in the app).
3. Adding additional fields, such as “Ad Group”, to the postback could give developers more control and flexibility. Apple’s privacy threshold would still apply, so high-volume apps could get more granular data without compromising privacy, while smaller apps could avoid using additional fields since fewer postbacks would make it through.
4. One additional field that would be incredibly helpful is “Ad Displayed Date”. I’m not holding my breath on this one, since it will likely be hard to implement while respecting user privacy, but currently there’s no way to tie a postback to a specific day that the ad was displayed. As with everything SKAdNetwork, that’s great for privacy but makes it much more difficult to do any sort of ROAS estimation.
5. Apple Search Ads should implement SKAdNetwork. Whatever tools are built based on this new paradigm, it would be nice for all attribution data to be standardized around SKAdNetwork.
6. SKAdNetwork should implement some rules or features that hold ad networks accountable. Over the past few years, MMPs and other ad-tech companies have helped push ad networks toward greater transparency. SKAdNetwork appears to put all the power right back in the hands of the ad networks. Replicating postbacks so that MMPs and other ad-tech companies could help measure ad performance would be nice. Similarly, an SKAdNetwork developer API for ingesting aggregate data could help. At the very least, Apple should force ad networks to share SKAdNetwork data with developers.

‍

Preparing for iOS 14

While we don’t know exactly how things are going to play out, the writing is on the wall: the methods and tools currently used for paid user acquisition on iOS will change dramatically this fall. That being the case, spending the summer ramping up with tools that are destined to change seems like a waste of time. Likewise, trying to build new tooling now while so much is still up in the air seems like a recipe for having to rework everything again as best practices emerge.

For now, developers should continue to focus on the things that matter regardless of what happens with Apple’s privacy rules: customer satisfaction, product improvements, conversion optimization, ASO, retention, word of mouth, PR, etc.

For apps that have already built tooling for efficiently acquiring users in the current paradigm, now might be a great time to pull forward some of your 2020 marketing budget and ramp up spending as long as it remains cost-effective.

Either way, developers should plan on having the flexibility to quickly react later this summer and early this fall as ad networks, MMPs, and other companies begin rolling out SKAdNetwork support and SDK updates to comply with Apple’s new policies.

The first few months of iOS 14 will likely feel a bit chaotic as everyone, including Apple, scrambles to determine the impact of iOS 14 as adoption climbs. By early next year the dust should start to settle. New strategies will emerge, along with new tools and even new companies built to help developers thrive in this new reality.

RevenueCat will continue to keep a close eye on the situation. We’re currently talking to industry players, listening to developers, and looking for ways to help our customers navigate this paradigm shift. Expect another post or two on SKAdNetwork in the coming months.

Further Reading:

This post is a summary of the most important information about the changes to iOS 14, but hundreds of thousands of words have been written about the situation since the WWDC announcement. Much of it is market-speak from companies trying to put their customers at ease, but there are a few informative pieces worth checking out if you want more detail or a different perspective. (Disclaimer: these links aren’t endorsements of the writers or companies that published them, nor the ideas they present.)

First off, take a minute to hear it straight from the horse’s mouth. Here are the two WWDC sessions that explain Apple’s changes in detail:

• What’s New with In-App Purchase (SKAdNetwork discussion starts at 37:40 and lasts about 7 minutes)
• Build Trust Through Better Privacy (SKAdNetwork discussion starts at 30:45 and lasts about 5 minutes, but the whole video is worth watching to understand Apple’s approach to privacy and other changes they are making around tracking permissions)

This post by Headlight founder Grant Harbin approaches the IDFA and privacy changes through the lens of “jobs to be done”.

On his excellent Mobile Dev Memo blog, Eric Seufert takes a deep dive on SKAdNetwork and how iOS 14 will reshape the future of mobile marketing.

In this podcast with Eric Seufert, Maor Sadra discusses the potential of incrementality testing to fill the gap and even provide benefits over the current deterministic approach to mobile ads. (Note: As the founder of a company that provides incrementality testing, Maor is a bit biased, but the concepts are worth consideration.)

While many assume Apple’s privacy stance is inherently moral and in the best interest of consumers, it‘s important to acknowledge that there are tradeoffs. Ben Thompson addresses those tradeoffs well in this post on privacy fundamentalism.