Week 2: Key lessons learnt about SKAdNetwork (SKAN) and App Tracking Transparency (ATT) so far
We’re now a fortnight after the enforcement of Apple’s App Tracking Transparency (ATT) framework and increased usage of their SKAdNetwork (SKAN) attribution solution. We’re obviously all learning more as we go and like with last week’s post we wanted to round up all the interesting things we’ve seen and the lessons we’ve learnt from live SKAN implementations so far.
We’ll also be running a “SKAN & ATT: Lessons learnt & early best practices” webinar with industry experts in the coming weeks once more lessons have been learnt to evaluate new best practices and how we should adapt as mobile user acquisition experts. You can get notified when we go live with this webinar by signing-up here.
Realities of SKAdNetwork (SKAN) data
Updates on last week’s lessons
- MMPs integrating conversion data from SANs: We mentioned last week that MMPs were reporting zero SKAN installs and conversions from SANs like Facebook due to ongoing efforts from MMPs to ingest SKAN data from SAN’s APIs. There has been some progress this week as some MMPs added support. However, there’s not full coverage across all SANs for all MMPs yet, so make sure you understand the status of your MMP’s SAN support for conversion and installs when analysing SKAN data.
- Apple’s privacy threshold: When talking about Apple’s privacy threshold last week we suggested that reducing the number of unique ConversionValue’s might help overcome it. However, it actually appears that the privacy threshold might be set at the Campaign ID level rather than the ConversionValue level. This means you would need a certain level of installs from a given campaign to receive the ConversionValue data. As such, reducing the number of unique ConversionValue’s would have no impact on the privacy threshold. Also, when the privacy threshold isn’t met ConversionValue’s are returned as 0’s, as are installs that have fallen foul of the privacy threshold where no conversion event happened. This makes it hard to tell whether your ConversionValue 0 installs are because of the privacy threshold or because the user didn’t execute any conversion events. Different ad networks are treating this differently, some are merging some are not. It’s worth trying to understand what the treatment is for all your ad networks to get a view on what the impact of the privacy threshold is and how many installs from a channel actually didn’t convert.
Re-installs on Facebook
One other interesting thing to look out for is in the SKAN data passed back from Facebook to MMPs. In particular around installs vs re-installs, or the lack of re-installs. Whilst SKAN does provide the ability to anyone with the raw postback to differentiate new installs from re-installs, the data coming from Facebook does not separate new installs from re-installs. All installs are considered equal.
Whilst Facebook hasn’t traditionally separated new and re-installs, MMPs were able to distinguish between new and returning users, largely thanks to the IDFA. Obviously that’s not possible with SKAN data now as the identifier isn’t present. The traditional MMP approach would have meant that the same user downloading the app on a different device would largely count as a new install because the device ID would be different. However, the new approach with SKAN is almost better as we’d assume that it measures a re-install as an iTunes account that has previously downloaded the app no matter what device.
As such, it’s a bit frustrating that Facebook isn’t passing this data back to MMPs and MMPs are having to report all Facebook installs equally unlike other channels. It’s obviously useful to understand when the ratio of re-installs is high as it suggests that you’re saturating an audience or channel. However, most importantly it’s key to consider in your analysis that all Facebook installs are not necessarily new installs when comparing channels.
- Continue to understand which SANs your MMP has integrated SKAN conversions and installs for to ensure you’re evaluating iOS 14.5 campaigns correctly as it’s not necessarily 100% coverage.
- Understand from your ad networks whether they’re separating ConversionValue 0 installs by those due to the privacy threshold and those that are genuinely installs without conversions or whether they’re merged.
- Remember when looking at Facebook installs in your MMP you’re looking at new installs and re-installs all in one bucket when comparing channels. It’s possibly worth looking at historical data to create a new vs existing ratio you can apply to Facebook installs.
ATT opt-in rates
There’s been a few folks revealing data on what ATT opt-in rates are looking like. We highlighted a Flurry report last week with daily opt-ins at around 11%, which has now risen to 12-13%. As more opt-in rates have been shared, this number appears an outlier, despite mainstream media pick-up with scary headlines. Other anecdotal and aggregate reports seem to be showing opt-in rates anywhere between 30%-45%!
So why the much lower number from Flurry? It’s appears mostly methodology and sample related:
- Methodology: Most other reports are looking at opt-in rate as:
- Opt-in rate on apps where ATT is enabled: MMPs Appsflyer (37%) and Kochava (45%) are both reporting opt-in rates by looking only at apps where ATT has been enabled. We’ll explain the difference between these two numbers in more detail in a moment.
- Bid requests: Programmatic advertising tools such as Bigabid (33%) and Blis (30%) are reporting what percentage of iOS 14.5 bids are coming with the IDFA authorised.
- Flurry: They’re looking at 5.3m devices with iOS 14.5 enabled. This doesn’t necessarily mean that the apps have enabled ATT (currently only 13% according to Appsflyer). It’s also very unclear how that opt-in rate is calculated at the user-level. Is it the percentage of app launches where the IDFA is present? Is it the percentage of users who have been shown a prompt and allowed tracking?
- Sample: The apps and users in the sample are also important to consider. As Eric Seufert highlighted on Twitter the sample of apps using Flurry are likely smaller. This means that they’re less likely to have enabled ATT and may not have the user trust of larger more established apps. As such, you’d expect the opt-in rate to be lower vs others.
These numbers are not apples-to-apples comparisons when you dig into methodology and sample. With all the sample and methodology question marks around Flurry’s report and it being such an outlier it’s probably best to take it with a pinch of salt until there’s more info on the methodology.
The most significant data is likely from Appsflyer, in a detailed report released last week which reported 37% opt-in and Kochava who reported a 45% opt-in.
Whilst both reports are only looking at apps where ATT is enabled, Kochava are ignoring a subset of users. Appsflyer’s percentage considers users who don’t see a prompt because they are “LAT on” or “Allow Apps to Request to Track off”. Meanwhile, Kochava are only looking at users who actually interact with a prompt. Flurry’s report suggests users who won’t see an ATT prompt accounts for about 4-5% of users, which just about adds up here.
In essence, each dataset gives you a sense of what opt-in rate you can expect at differing later stages of the opt-in funnel. They are not apples-to-apples comparisons. Also, neither are telling us of the total universe of IDFAs on iOS 14.5, what percentage are available? This is because:
- Neither include the 87% (according to Appsflyer’s report) of apps that haven’t yet enabled ATT. We shouldn’t assume that all apps will enable ATT in the future and those that do may have higher or lower opt-in rates relative to early adopters. The bias towards early adopting apps and users should be considered when analysing this early data.
- Neither include ‘Restricted’ status users (end-users who are underage and cannot opt-in, or restricted devices).
- Kochava’s report doesn’t include “LAT on” or “Allow Apps to Request to Track off” users who won’t even be shown an ATT prompt regardless of the app’s ATT status.
Basically, if we look at iOS 14.5 as a whole the picture looks something like this according to these latest numbers:
The other important thing to note with all these opt-in rates is the importance of dual opt-in. For things like attribution and user-level ad targeting to work there will need to be an opt-in on the advertiser side and the publisher side. The overlap is likely quite a bit lower than what’s reported here. In particular, at the moment where it seems a lot of apps on the advertiser side haven’t even implemented ATT and are taking a wait and see approach. The numbers on dual opt-in when ATT and iOS 14.5 are widely adopted will be the real test.
There’s also further segmentation in AppsFlyer’s report by geo and app category. The key things they found by geo were:
- The consent rate in developing markets is 35% higher than in developed markets.
- In Gaming, Brazil’s consent rate is 47%, Saudi Arabia 43% and India at 36%, meanwhile the US is only 18%, Germany 20%, and the UK 20%.
I have seen data which suggests the US is significantly higher than 18% across all app categories, but the sample is smaller. That does suggest we should take these geo breakdowns with a pinch of salt for now given likely sample sizes. However, it does appear that the bigger European markets are lower than less developed markets.
It also appears that apps in more established categories with known and trusted brands do seem to have higher opt-in rates.
|Food & Drink||40%|
|Source: Appsflyer – https://www.appsflyer.com/ios-14-att-dashboard/|
However, these numbers could change pretty rapidly as more apps enforce ATT and sample sizes increase in each category. For example, 18% of Shopping apps have already implemented ATT compared to only 8% in Photography.
There was also an interesting piece of data in Kochava’s analysis on how long it takes users to accept or reject tracking.
The findings are not really surprising as they found that it takes users significantly less time to accept than reject tracking permissions. Those who reject are clearly taking more time to read the text. Clearly the text that’s being used so far is not persuasive enough to drive the opt-in.
- Aggregate data suggests that when you show someone an ATT prompt, the opt-in rate appears to be just over 40%. However, if you include users who have opted-out of even being asked it’s closer to 35%.
- These are nice numbers, but don’t really tell us what access is likely to be to the entire universe of IDFAs on iOS 14.5 due to so many apps not implementing ATT yet and data likely having an early adopter bias on the app and user side.
- For attribution and user-level targeting you will also need dual opt-in on the advertiser and publisher side, so the reality of IDFA access overlap for these purposes is probably still lower currently.
- It appears that in more established categories like shopping, finance and food & drink with recognisable and trusted brands you can expect a higher opt-in rate.
- Also, you might expect a higher opt-in rate in developing countries compared to developed countries. In particular, big European markets appear to have lower opt-ins.
- Those rejecting tracking are taking longer to read the text. It’s clearly important to use more positive and benefit-led language in the prompt subtext as the current default is not driving opt-ins.
ATT and iOS 14.5 adoption
When trying to understand what access to the entire universe of IDFAs looks like for advertisers it’s worth considering it in the context of iOS14.5 adoption on the device side and ATT adoption on the advertiser side.
On the iOS14.5 user adoption side, both Kochava and Appsflyer have released adoption stats and projections.
|Source||Latest iOS 14.5 adoption||Future projections|
|Appsflyer||8% (May 2nd 2021)||30% adoption 4-6 weeks after launch (24th May – 7th June 2021)|
|Kochava||10.6% (May 3rd 2021)||60% adoption within 30 days after release (26th May 2021)|
Current stats line up between the two and is still low at around 1 in 10 devices, whilst projections don’t concur. However, it’s likely to reach a tipping point by the end of this month, where most apps will need to be ready and make a decision on whether to implement ATT or not.
With that in mind, Appsflyer also shared that ATT adoption was currently still very low at 13% amongst apps. It also varied quite a bit by app category:
|Food & Drink||10%|
|Source: Appsflyer – https://www.appsflyer.com/ios-14-att-dashboard/|
So ATT adoption still has a long way to go and will likely grow with iOS 14.5 adoption on the device side making it more essential. However, that’s not to say all apps will eventually adopt ATT.
It’s also worth noting that there is already an iOS14.5.1 which:
“Fixes an issue with App Tracking Transparency where some users who previously disabled Allow Apps to Request to Track in Settings may not receive prompts from apps after re-enabling it.”
This might also mean there are a small number of additional ATT prompts to be shown than are in the existing data.
Shifts in media spend
Some early data on media spend trends post ATT have also started to be released this week. A couple of hypotheses pre ATT were that it would:
- Force advertisers to shift budgets from iOS to Android in the short to medium-term.
- CPMs would fall on iOS devices because of the budget shift and the inability to target high-value users
Based on early data, it would appear these trends are possibly playing out. Appsflyer’s report highlights that there has been a small switch to an increase in Android spend after ATT enforcement.
Although it also appears that iOS spend is flat, so it’s unclear where that spend is coming from. It also appears that this is iOS spend across all versions not just iOS 14.5. So we may see more extreme trends once iOS14.5 adoption increases.
So the original hypotheses around high-level media spend appear to be playing out with early data suggesting that more budget is shifting to Android and CPMs are deflating with the loss of IDFAs. We’ll be releasing some more granular data on shifts in share of wallet and iOS vs Android spend in the coming weeks, so make sure to sign-up to our newsletter to be notified when it’s released.
- Expect costs to increase on Android in the coming weeks as iOS 14.5 adoption increases and more advertisers shift budget there.
- In tandem expect costs to reduce on iOS as advertisers shift budgets aways and CPMs deflate.
There’s been a lot of confusion around SKAN and ATT in its early stages, hopefully we’ve managed to reveal some of the details behind that here. To summarise further lessons this week:
- Continue to monitor your MMPs support for SKAN install and conversion data from SANs as there’s still not 100% coverage.
- When ConversionValues are returned with zeros from ad networks make sure you can differentiate what is due to the privacy threshold and what is genuinely installs without a conversion.
- Remember when analysing Facebook SKAN data that installs and re-installs are lumped together.
- When a user is shown an ATT prompt early assumptions suggest an opt-in rate around 40%. Remember this doesn’t mean you’ll have access to 40% of IDFAs due to LAT On users. It will also vary by app category (highest in shopping, finance, food & drink), user base (currently early adopters) and geo (likely higher in developing markets).
- Continue to optimise ATT prompt sub-text with more positive benefit-led language and look to use the pre-prompt. Also test this later in onboarding than on app launch.
- With broader adoption of iOS14.5 expected towards the end of May, you need to be fully ready by then with an optimised ATT strategy and SKAdNetwork implementation.
- Anticipate more significant increases in Android costs and reductions in iOS costs over the coming weeks as more advertisers shift their media strategy.
We’ll be back with more lessons next week and don’t forget to sign-up to get notified for our webinar where we’ll explore early best practices for SKAdNetwork and ATT alongside industry experts here.