Week 3: Key lessons learnt about SKAdNetwork (SKAN) and App Tracking Transparency (ATT) so far

Here we are three weeks after the enforcement of Apple’s App Tracking Transparency (ATT) framework. We’ll continue to round-up weekly lessons for the next couple of weeks and we’ll be looking back after a month with a webinar on 2nd June “Under the hood of ATT: Lessons so far and best practices for the future”. You can book your place here and we’ll also be revealing results from our proprietary analysis of media spend shifts in the first few weeks of ATT. We look forward to hopefully seeing you there!

On with the lessons for this week …

Realities of SKAdNetwork (SKAN) data

This week we’ve seen a lot more data from Self Attributing Networks (SANs) like Facebook, Google and Snapchat. What’s most interesting is how SANs are abstracting away information from the raw SKAN postback when sharing it with advertisers and MMPs. As Thomas Petit  questioned, why don’t Apple just send the raw postback directly to the advertiser?

Here’s some of the discrepancies we’ve seen in SKAN data this week.

Facebook SKAN data

• Re-install and IP data: We mentioned last week that Facebook is not sharing re-install data back to MMPs or in their own reporting interface, which is annoying given we see some apps with a 50:50 ratio of new vs re-installs. We also now believe that they’re not sharing IP address information since MMPs are not providing country splits for Facebook data.  
• Modelling: Once you go below the campaign level in Facebook’s own reporting you’re going to be letting Facebook mark their own homework as they model data at more granular levels. Importantly, MMPs don’t appear to be displaying any SKAN data from Facebook below the campaign level. Either because they don’t want to let Facebook mark their own homework or because Facebook isn’t passing this data back to the MMP.
• ConversionValue mapping: One step you need to go through for Facebook is mapping your ConversionValue logic to Facebook via your MMP. This enables Facebook to provide more useful reports natively on their UI and via reporting APIs as your ConversionValue events are mapped to Facebook’s own event schema. However, it does also mean that your MMP needs to re-translate these Facebook events back to their own events in your app. All this translating can create inconsistencies, so it’s worth exploring the details of this within your MMP and Facebook mapping.
• Aggregated data: What’s probably becoming clear now is that Facebook is sending very much aggregated SKAN data back to MMPs. Unlike other ad networks who are sharing the raw postback and letting MMPs do the work and send information back to them. So it’s hard to get an apples-to-apples comparison across channels in your MMP.

Google UAC SKAN data

• Currently no MMP integrations: It appears that Google are dragging their heels somewhat when integrating SKAN data with MMPs. They only recently announced that they would support MMPs. It appears that MMPs are targeting support by the end of this month. Unsurprisingly, you can already see SKAN installs in Google Analytics from Firebase, Google’s own attribution tool.
• Google Ads reporting: This leaves you currently relying on a very raw SKAN ConversionValue report in the Google Ads interface that’s about as useful as a chocolate teapot. All in all, it’s going to be quite hard to understand the impact of Google UAC spend on iOS 14.5 beyond installs over the next week or so, it’s somewhat spray and pray right now.
• Upcoming features: Google shared some interesting SKAN FAQs recently. The key highlights:
  • MMPs: Or App Attribution Partners (AAPs) as they call them, will receive what looks like raw postbacks from Google. This appears to be a divergence from Facebook’s approach where it’s aggregating data before sending it back.
  • Modelling: Google will model conversions, however, they won’t share modelled data back to MMPs. Within the Google ads interface there will also be a delay of upto 5 days for modelled data to appear. There’s also some information on how they will model using Google’s first-party data signals like how similar users converted, device type, conversion type, time of day, country, and browser.
  • Future “privacy-safe” measurement: Within the FAQ they push some benefits of using the Google Analytics for Firebase SDK, including this one: “Ensures your campaigns will be compatible with upcoming privacy-safe measurement innovations from Google.” First of all, a hint at further “privacy-safe” tracking announcements from Google in the wake of their recent Federated Learning of Cohorts (FLoC) posts. Second of all, a hint that it could require Google Analytics for Firebase to be “compatible”. All eyes on Google I/O today.

SNAP SKAN data

• IP data: Much like Facebook, Snap isn’t reporting back IP address data to MMPs so understanding installs and conversion by geo is going to be quite difficult there. However, they are sharing a split of new vs re-installs with MMPs, despite not surfacing this in their own interface.
• Mapping: Similar to Facebook, you will need to map ConversionValue events between your MMP and Snap so that Snap can decode ConversionValues in their own reporting interface. However, unlike Facebook it also appears that Snap is sharing raw postbacks with the MMP, not aggregated so you may have less of an issue with inconsistencies relative to Facebook.. 

MMP SKAN data

An important inconsistency between ad networks and MMPs, which makes it hard to reconcile data between the two reporting interfaces, is the date that installs are attributed to. Whilst SANs and ad networks are reporting install date as the date the postback is received, some MMPs are introducing their own logic to determine the install date. As such, they’re attributing installs to a certain time period before the postback was received. This means the data doesn’t match between your MMP and native SAN or ad network reporting interfaces and makes it hard to reconcile.

Key lessons:

• It’s important to understand when you’re looking at SAN reporting interfaces what’s modelled and what’s raw SKAN data for accuracy.
• In Facebook and Snap you’ll also lose geo breakdowns with a lack of IP address information, including in your MMP. Equally, in both of their reporting interfaces you won’t have visibility of new vs re-installs, whilst for Facebook you won’t get this in your MMP either.
• Due to different methodologies across MMPs on calculating when an install occurred by factoring in delays, you’re not going to be able to reconcile the SKAN data you see in native SAN reporting interfaces with those that you see in some MMPs.
• You’re basically going to be flying blind to post-install behaviour with Google Ads on iOS 14.5 for a few weeks given their delayed MMP support. However, when supported it does appear that they’ll be sharing raw SKAN postbacks with MMPs.
• Make sure that you set up mapping of ConversionValue events between your MMP and Facebook and Snap to make sure reporting and optimisation work. It also appears that you’ll likely need to do something similar for Google.

ATT opt-in rates

I think we’d all given up on understanding anything meaningful from aggregated ATT opt-in rate reports given the methodology and sampling discrepancies. However, we couldn’t let this excellent work from Alex Bauer at Branch pass without a mention. This is probably the most transparent and detailed breakdown of ATT opt-in rates benchmarks we’ve seen, which gives you trust in the numbers. In it he shares the numbers Branch are seeing relative to other reports methodologies, so we start to get more of a range of apples-to-apples comparisons:

• Opt-in for only ATT enabled apps excluding restricted users: Branch is seeing a 21% opt-in rate, which is quite a bit lower than the 37% reported by Appsflyer last week.
• Opt-in for all apps: Branch is seeing a 6% opt-in compared to Flurry who are seeing it float around 13%. However, Alex notes that “This difference is likely due to a number of very high-traffic apps on the Branch platform that have chosen not to implement ATT.” Side note: Flurry added more detail on their methodology, which makes it clearer what they’re actually calculating.
• The ATT restricted rate: Or users who aren’t allowed to see the ATT prompt at all, due to account-level policies enforced by Apple was 10% according to Branch.
• The opt-in rate for all users on ATT enabled apps: All of this means that Branch are reporting this number at 11.9%.

This gives us probably the clearest view on what to expect in terms of IDFA access, with the usual sampling bias caveats around it being early adopters on the app and user sides as well as specific apps and geos in the Branch sample skewing the data.

With about 12% IDFA access when using the ATT prompt and dual opt-in needed on the advertiser and publisher side for attribution and user-level targeting, it does beg the question, is ATT even worth the effort?

However, geo, app category and prompt execution will all play a role. Appsflyer’s data suggests that:

• Shopping and finance apps have higher opt-in rates, whilst social apps are much lower. Interestingly, the social category doing so badly might mean that publisher opt-in on SANs like Facebook, Snap etc might not be great for attribution and user-level targeting.
• Developing countries also continue to perform better from an opt-in perspective.

All-in-all aggregate data isn’t necessarily telling the full truth with sampling and methodology biases and it’s important to consider app category, geos targeted and user relationship / trust before ruling out ATT completely.

Key lessons:

• When ATT is enabled it appears that apps can expect around 10-20% IDFA access on average. For dual opt-in to power attribution and user-level targeting the number will be lower.
• You can expect it to be higher in developing countries and lower in a lot of big European markets.
• You can also expect it to be higher in app categories like shopping and finance, but lower in categories like social.
• If your IDFA access is closer to 10% it seems like effort could be better spent elsewhere as 10% access won’t be particularly effective for modelling.

ATT and iOS 14.5 adoption

Alex at Branch also shared some useful visuals on expected iOS14.5 adoption. The most illustrative being this:

It shows iOS 14.5 adoption is still so insignificant. Outside the adtech bubble and early-adopters and despite Apple’s PR campaign, adoption only sat at 14% as of May 15th according to Branch and 12% as of May 11th according to Appsflyer. However, recent historical trends would suggest that the adoption curve will be steep in the coming weeks. It does, however, feel like iOS 14.5 adoption is moving at a slower rate than iOS 14.4 versions.

Low user adoption so far probably hints at why ATT adoption still only sits at 15% on May 11 up from 13% the week before according to Appsflyer. However, low ATT adoption could also be down to the low opt-in rates that are being seen because ATT adoption appears to be growing at a slightly slower rate than iOS 14.5 adoption. 

The majority of developers still seem to be taking a wait and see approach. Most don’t seem to like what they’re seeing so far but that could all change as iOS 14.5 adoption grows faster in the coming weeks. Well developed app categories like ecommerce, gaming and social are also adopting slightly quicker than other categories.

Key lesson:

• Whilst iOS 14.5 adoption is still low a major inflection point will likely hit in the coming weeks, so you need to be ready. The most important task feels like a well implemented SKAdNetwork setup.

Wrapping up

There’s a lot of discrepancies still to clean up in the coming weeks around ATT and SKAN, however, it does feel like some norms are starting to be established. It feels like the key things we confirmed this week are:

• It’s important to understand when you’re looking at SKAN data in SAN interfaces what’s modelled and what’s raw SKAN data. Mostly anything below campaign level will be modelled.
• In Facebook and Snap you’ll also lose geo breakdowns with a lack of IP address information, including in your MMP. Equally, in both of their reporting interfaces you won’t have visibility of new vs re-installs, whilst for Facebook you won’t get this in your MMP either. We suspect other SANs will have similar limitations too.
• Due to different methodologies across MMPs on calculating when an install occurred by factoring in delays, you’re not going to be able to reconcile the SKAN data you see in native SAN reporting interfaces with those that you see in an MMP.
• When ATT is enabled it appears that apps can expect around 10-20% IDFA access on average with the higher end in shopping and finance as well as developing countries and on the lower end for categories like social and in major European markets.
• If your opt-in numbers are around 10% it seems like effort could be better spent elsewhere as the dual opt-in requirement for attribution and user-level targeting and the sample data required for effective modelling essentially make it meaningless.
• It’s important to anticipate and be ready for major iOS 14.5 adoption over the next couple of weeks with a fully functioning SKAN implementation.

We’ll be back with more lessons next week and don’t forget you can reserve your place at our 2nd June webinar “Under the hood of ATT: Lessons so far and best practices for the future” by filling out the form below.