How to work with SKAD traffic in mobile games: lessons and lifehacks

Alexey Gavrilov, Marketing Producer at mobile games publisher, AppQuantum, offers insights on working with SKAD traffic 12 months of living in the ATT era.

Last year’s release of iOS 14.5 turned the mobile world upside down. On top of that, Google too has announced its own version of ATT. Thus, we continue to adapt to our new reality: keep exchanging knowledge, testing hypotheses and learning to work without user data in hand. Now it’s time to take stock and share our lifehacks. Over the past year we at mobile publisher AppQuantum have developed a system for working with iOS traffic for mobile games. In this article we want to share our methods of buying, attributing and scaling SKAD-traffic in an effective way.

Main points
First to get you up to speed on the terms we’ll be discussing. The three main ones, circulating close to each other are ATT, IDFA and SKAdNEtwork.

App Tracking Transparency (ATT) is a framework, with which app developers ask users to allow them to use an advertising identifier. Now, users can forbid apps from sharing their personal data: gender, age, device the app was installed onto, time and date of the install.

Users that opt in are a small share of the overall population, with the latest information from Flurry showing the worldwide percentage being only 25 per cent.

Identifier for Advertisers (IDFA) is a device marketing identifier, which advertisers use for ads attribution, retargeting, working with look-alike audiences, analytics and other tasks.

SKAdNetwork (SKAN/SKAD) is Apple’s attribution technology, on iOS 14.5+ devices. SK stands for StoreKit Apple’s framework, through which developers interact with the App Store and in-app purchases. Ad advertisement and Network are self-explanatory.

Before ATT and SKAD, mobile advertisers could track user data and hand all of it over to the MMP (Mobile Measurement Partner) throughout its life within the app. Now the amount of available data is catastrophically not enough to make marketing decisions. Because of this problem, others spread out like a web. We’ll explain in more detail exactly what those problems are and how you can recognise and solve them.

Challenges of working with SKAD
First, there were problems with testing the creatives, building buy predictions and traffic attribution. Every area required a workaround. Let’s look at specific challenges and solutions AppQuantum found for them.

Traffic attribution
Pretty much all marketing specialists working with iOS traffic ran into attribution issues. Now, to attribute traffic with accuracy, you first need to determine the purchasing models. We’ll point out the two main ones:

  • When traffic purchase for one GEO is divided by sources For example, the USA on Facebook, Germany on Google, France on Snapchat, etc. When you buy one country’s traffic through one separate source, it’s easier to track its dynamic. The downside of this option is a huge amount of analytics implied.

  • When the purchase is tested on all sources and GEOs Turning each source off and on you can measure the campaigns effectiveness. It’s not a cheap method and should only be used when you’re ready to spend over $50,000 (but the amount greatly depends on the amount of organic traffic and CPI). You should be ready for the prospect of first purchases not bringing in tangible results, but will instead bring a lot of knowledge for UA and analytics teams.

These options are not perfect and it’s possible they wouldn’t be a good fit for you. But they work for us and you can use these methods, customize and modify them, finding the best models for your specific projects.

Limited number of ad campaigns
According to Apple’s rules, you can now only track 100 active campaigns for each advertising network. Most self-reporting networks (SRNs) limited the number of campaigns for advertisers to nine, 10 or 11. Campaigns above that use the source for teaching their machine learning algorithms.

If you previously targeted for worldwide, now you have to group the GEO segments into Tiers – 1, 2, 3. The traffic, in turn, will have to be evaluated at the campaign level. GEO level is not relayed in SKAD postbacks but you can see spread by country in the traffic source itself.

Forecasting the next buy
The most significant changes in user acquisition post-SKAD happened in ad campaigns forecasting. For example, previously we planned the purchase with user-level and cohort data, but those are no longer available. There’s now only campaign and source-level data, and thus the purchase has to be planned on those levels.

SKAD attribution allows us to track the first 24 hours after install, so we can forecast the traffic, using day zero data (d0).

Let’s assume you’re tracking revenue by conversion value (CV). The metric itself is a number from 0 to 63. It shows the value, or quality of conversion. Within the CV you can track in-game events, in-app purchase revenue and, in some cases, ad revenue. The latter can be used to forecast subsequent purchases using this formula:

LTV = SKADRevenue_d0 * predict coef_d0

The downside of this option is that the revenue amount in d0 could be insufficient for quality forecasting, but overall it works well.

In addition, you shouldn’t write off the data from users that opted into the tracking (ATT). Despite the fact that those users are few, they still exist, so this data will be useful for forecasting.

The opt-in user share can vary by source: for example, according to our data, the percentage is high in TikTok. According to research, TikTok users are more susceptible to brand messages, calls to action and ads overall. It’s possible that a wider number of users understand what the data tracking is needed for. Thus you can evaluate TikTok traffic and extrapolate results onto your other sources. 

What the future holds
By introducing such a harsh personal data protection policy, Apple set a trend which will only grow stronger. Granular targeting, aimed at every particular user, along with user-level analysis and probability attribution, will become a thing of the past. Developers will have to explain more thoroughly why they need users to agree to data tracking. For now, we work with what we have and look for new ways to work “in a vacuum”, without user data, keeping our finger on the pulse and sharing our latest findings with you.