SKAdNetwork (SKAN) 3.0 and iOS 15: Everything you need to know to prepare your user acquisition

A big move just happened in mobile advertising measurement. Apple is potentially about to turn measurement for Self Attributing Networks (SANs) like Facebook, Google and Snap upside down with the release of iOS 15.

For a long time these major ad networks have been able to mark their own homework in terms of claiming credit for conversions. However, Apple is about to make moves to try and put some power back in the hands of advertisers.

In this post we’ll explore what it means for you as a mobile advertiser, covering:

  • Considerations for SKAN 3.0
  • What’s the impact of iOS 15?
  • Considerations and best practices for handling raw SKAN postbacks

Considerations for SKAN 3.0

To put in context what’s happening, it’s worth reviewing what’s come before by looking back at how SKAN has evolved through the different versions:

SKAdNetwork (SKAN) version history

As we look back through the SKAN versions, the minor releases are v1.0 (largely setting the foundations before ATT was a thing) and v2.1 (adding an attribution signature to combat fraud). The first major release was v2.0, which was launched alongside iOS 14 when ATT was originally meant to be released. This provided more important parameters for basic attribution like conversion value, redownload and source app ID. The next major release was v2.2 alongside the actual enforcement of ATT in iOS 14.5. This set the foundations for measuring view-through impressions (not just StoreKit enabled ads, which opens an app store modal upon a click) and was well covered by the fine folks at StoreMaven and Branch. When ATT adoption reached mass adoption in iOS 14.6 SKAN 3.0 was released into the wild. Tightly linked to v2.2 this version takes a very basic first stab at privacy compliant multi-touch attribution.

Having looked through the functionality in different SKAN versions, a question immediately arises for SKAN 3.0. That question is: “How are the networks getting a did-win = false postback given credit for influencing the related conversion?”

To answer this question, it’s best to look at the logic Apple sets out on this page. The key things to understand are:

  • SKAN only remembers the last 15 impressions for each user and advertised app. So any credit will only go to an impression amongst the 15 most recent.
  • To qualify as an impression the ad must be shown for a minimum of 3 seconds.
  • The fidelity type – whether the ad was a StoreKit rendered ad or view-through ad – has an impact on credit given. 
    • Firstly, in terms of attribution window or time elapsed between the impression and the install. For StoreKit rendered ads 30 days can elapse between the impression and the install and for view-through ads 24 hours can elapse. 
    • Secondly, it appears that StoreKit rendered ads take priority (assuming they’re within the 30 day window to install) then view-through ads (assuming they’re in the 24 hour window). So, the most recent StoreKit rendered ad will get credit with the “win”, whilst other StoreKit rendered ads within the 30 day window get returned as “losers” followed by any view-through ads within the 24 hour install window.
  • If a winning ad network also has an earlier ad interaction, they will only receive the winning postback, not the losing one.
  • “Losing” postbacks don’t receive the conversion value or source app ID.

If we use this structure then an imaginary conversion path (assuming all channels offer StoreKit rendered ads) would look something like this:

SKAdNetwork (SKAN) view-through attribution

So, Twitter gets the win. However, their previous view-through impression doesn’t register. Facebook gets a “losing postback” for their view-through impression. Aarki, despite only having an impression just over an hour earlier than Facebook, doesn’t get any credit. Meanwhile, Google who had a StoreKit rendered ad nearly a month before install also got a “losing” postback.

Whilst it’s good to see this feature development form Apple with SKAN, there’s a big gap in this model still for advertisers. With losing impressions, there’s no sense of what the influence of a “losing” postback is as there’s no indication of how long ago the impression was. For example, if you look at the scenario above Google gets a “losing” postback, but there are three other far more recent ad interactions that don’t get a postback. As an advertiser you wouldn’t know that.

The other question is “how will ad networks report losing attributions in their own native aggregate reporting?” Will they claim credit for losing attributions? Or will they ignore them? It’s unlikely they’ll be able to claim them as the postback won’t include conversion value or source app ID. However, you never know when it comes to SANs marking their own aggregate homework. This brings us onto new things in iOS 15.

What’s the impact of iOS 15?

Whilst custom product pages and the iCloud VPN (which will limit fingerprinting for some iOS users on Safari) are new considerations for advertisers in iOS 15, we want to focus here on the availability of raw SKAN postbacks.

This was something we started calling for back in May and Apple quietly gave this gift as part of their WWDC announcements. Originally SKAN postbacks were sent back to ad networks and then they would either send the raw postback or aggregate SKAN data onto an MMP. As we discussed before, this caused issues as different ad networks and MMPs were handling this differently, creating a maze of confusion for advertisers. 

Again, the fact that Apple will now send raw winning postbacks directly to advertisers does increase transparency for advertisers. It also removes some power from Self Attributing Networks (SANs) who have been able to mark their own homework for a long time, including in the post-ATT world. However, as with all things in these early versions of SKAN, there are limitations.

Considerations for handling raw SKAN postbacks

So what are the considerations for you when handling raw SKAN postbacks?:

  1. The postback will only be for devices running iOS 15+, not anything earlier than that. So it will only be a partial SKAN view whilst iOS 15 reaches mass adoption.
  2. It will only be the winning postbacks you receive, not those for the five “losing” ad networks. Unless every ad network sends its raw losing postbacks to the MMP, you have no visibility on this beyond self-reporting in ad network interfaces.
  3. The other challenge is that the campaign ID needs to be translated by the ad networks. There are 100 campaign IDs, however, the likes of Facebook and Google are using most of these campaign IDs for testing, which makes it hard for you as an advertiser to translate that back to a specific campaign. This means that if you’re hoping to validate performance at a more granular campaign level then you’re going to struggle with just raw data. 

This really does leave you wondering: what value does this raw postback provide to you as an advertiser? Well there’s a few areas of use for it:

  • Firstly, it can be used to validate the data you’re receiving back from ad networks and MMPs about network level performance. If ad networks provide translated raw campaign IDs, then it could be more useful. However, unless Google and Facebook do this it’s unlikely that others will follow suit. Unfortunately, it seems unlikely Facebook and Google would provide this in a raw format, given their status as SANs. So it seems you will mostly be using these raw postbacks to validate network level reporting.
  • The other area that they’ll be useful for is getting a better idea of the impact of Apple’s privacy threshold. With this data it will be easier to understand which networks have the biggest gaps due to the privacy threshold. This gives you insight on where you need to try and reduce the granularity of campaigns to get more data returned.

So, whilst it’s a step towards Apple turning the power back to advertisers from SANs and there is some use in the data, there’s still a way to go for advertisers to get full value from raw postbacks.

Concluding thoughts

Whilst there was some hope for SKAN 3.0 and iOS 15 to deliver multi-touch attribution and more transparency on SANs, it’s simply a step towards that. We’re not yet at a stage where SKAN is delivering everything that advertisers need. However, it’s good to see the development.

In general, as you approach SKAN 3.0 and iOS 15 there’s a few areas to focus on:

  • Understand how your ad networks are treating losing SKAN postbacks. Are they claiming credit in their own aggregate reporting? Or are they ignoring them?
  • When it comes to the raw postbacks, it’s important to understand if your ad networks will translate campaign IDs in a raw format that you can unify with the raw postbacks. If they are, you can actually start to use this data for reporting at a more granular campaign level. If not, your main use of this data will be validating channel performance at a network level vs other data sources.
  • This raw postback will also be valuable for understanding the impact of Apple’s privacy threshold at a network level. This enables you to understand where campaigns are too granular and need broadening.

Overall, whilst there’s progress, these updates actually create more data sources and complexity for SKAN reporting. If you’re still struggling to get a complete view of SKAN performance data, check out our SKAN reporting and modelling solution, which is freshly upgraded.