SKAN 4.0 strategy: how to transition from SKAN 3
SKAN 4.0 is here and it is starting to get the first glimmers of actual adoption. That means we’re starting to see a few SKAN 4.0 postbacks pop up. And that means it’s time to build your SKAN 4.0 strategy to take advantage of Apple’s updated mobile attribution framework.
Spoiler alert: it’s not easy.
Plus, the transition from SKAN 3 to SKAN 4.0 has some serious minefields to be aware of and prepared for.
What you’ll find here, however, is a concise summary of the changes in SKAN 4.0 and an overview of how to approach each of the major ones. In addition, I’ll add some details on what you can expect in your SKAN reporting from Singular, including during those awkward weeks — or months (!!) — while you’re transitioning from SKAN 3 to SKAN 4.
Want to read this content in a more friendly format?
We’ve recently taken this content, enhanced it, and added significantly more explanatory images. The result is available in a downloadable report, the SKAN 4 transition guide.
Jump over to that version to get something a little friendlier to read. It’s also more shareable … and has received high praise on LinkedIn from user acquisition experts.
“… the most complete, easy-to-understand and organized guide about SKAD 4.0 that I’ve read until now.”
Get the guide right here if you choose.
Or keep reading!
SKAN 4.0 quick summary: changes from SKAN 3
SKAN expert? Didn’t take time off at Christmas so no need to refresh your brain? Still totally up on everything SKAN 4.0?
Great: skip this section and move on to the next. Otherwise, skim or read as needed for a refresher.
SKAN 4.0 major update 1: Crowd anonymity and source identifier
Goodbye SKAN 3’s privacy thresholds. Hello crowd anonymity. At the same time, goodbye campaign ID, hello Source Identifier.
Crowd anonymity determines how much data you get from SKAdNetwork. This is simple in concept but complicated in detail.
The simple part: more installs per campaign equals higher crowd anonymity which will return more data. If you get only a few installs per campaign, you’ll only get minimal data. A large number of installs per campaign — only Apple knows how many, and the parameters could change over time — gets you the most data.
Briefly …
- Many installs per campaign?
- You’ll get 4.0 digits of Source Identifier information in your first SKAN 4.0 postback
- Use them to gather data on campaign ID, ad set, geotargeting, ad placement, or other info
- This helps you optimize campaigns and understand the value of results
- You’ll also get 64 potential values of post-install conversion data in your first SKAN 4.0 postback, which you can use to understand engagement, activity, and revenue from your new app users
- You’ll get 4.0 digits of Source Identifier information in your first SKAN 4.0 postback
- Few installs per campaign?
- You’ll get less data in your Source Identifier
- Perhaps only 2 digits, similar but not identical to SKAN 3
- You’ll get less data in your conversion values
- Coarse conversion value postbacks only have 3 potential values (whichever 3 you choose)
- You’ll get less data in your Source Identifier
More details on this in the next section, which details each of the 3 different postbacks you can get from SKAN 4.0, when you get them, and what data payload they can carry.
SKAN 4.0 major update 2: Multiple postbacks
SKAN 3 only had 1 single lonely little postback, making mobile marketers struggle to understand the value of their ad campaigns.
SKAN 4.0 offers 3 postbacks spread out over time, providing more insight and more value … at a pretty significant cost in complexity.
- Postback 1
Postback 1 is the most data-rich postback, as you can see above, and it can be sent the quickest: within 2 days - Postbacks 2 and 3
Postbacks 2 and 3 are very simple: each only has 1 of 3 possible values, and they will be set over longer periods of time- Postback 2: 3-7 days
- Postback 3: 8-35 days
- Random delivery delays
Note: actual delivery of postbacks will be impacted by a random timer. More on this later …
Postback 1 is the most critical postback for 2 simple reasons: it returns the quickest, and it carries the most data. There’s a lot of complexity in the range of values that you can potentially get from postback 1 depending on the level of crowd anonymity that you have achieved.
Tier 3 is where you want to be on postback 1. Getting there requires that you achieve high levels of crowd anonymity in a campaign through a large number of installs. If you do so, you’ll get:
- Maximum data in your Source Identifier
- 4 digits of data
- Plus a source app notification: essentially, a publisher ID telling you where the ad was shown
- Maximum data in your conversion values
- 64 possible values, which Apple calls “fine” data
If you only achieve lower levels of crowd anonymity, you will receive less source identifier data and less conversion data:
- Tier 0 returns no data
- Tier 1 returns minimal data
- Source Identifier: 2 digits only, not 4
- Conversion values: 3 possible conversion values only, not the full 64
- Tier 2 returns a good amount of data:
- Source identifier: 4 digits (but omits the source app)
- Conversion values: 64 values of fine conversion data
For postbacks 2 and 3, it’s a much simpler world, but that simplicity comes at a cost: less data. Postbacks 2 and 3 are always only one of 3 values each.
Think along these lines for your second and third postbacks:
- 0, 1, 2
- Bad, OK, Good
- Window-shopper, Buyer, Subscriber
- Or basically any values you might want to encode to your P2 and P3 values, as long as there are only 3
Swimming in complexity already? Freaking out?
Take a deep breath. Don’t worry.
The key learning is simple: fund larger, fewer campaigns to maximize data return and you will (almost) always get all available SKAN 4.0 data. Also, be aware: Singular will both enrich your data with first-party insights from your own app — after all, your own analytics know when you get an install, engagement, and purchases — and will present your data in a simple, user-friendly, understandable way.
But keep in mind, there’s more.
Because we haven’t talked about delivery times yet.
SKAN 4.0 major update 3: Postback delays and locking conversion values
If every postback arrived precisely at the end of its postback period, Apple’s efforts at ensuring marketing measurement privacy would fail.
The first postback, for example, can be updated until 2 days after app install. If marketing analytics platforms got the postback immediately, they could simply tie it back to new app user arrivals, and bingo: associate a specific SKAdNetwork postback with a specific app user.
So Apple adds random timers, which have changed in SKAN 4.0:
- Postback 1 random timer
- 24-48 hours, or 1-2 days
- Postback 2 random timer
- 24-144 hours, or 1-6 days
- Postback 3 random timer
- 24-144 hours, or 1-6 days
That means that if marketers use the full postback update window in each case:
- Postback 1 could arrive 3 to 4 days after an install
- Postback 2 could be 10 to 15 days after an install
- Postback 3 could be a staggering 36 to 41 days after an install
But yes, because this is SKAN 4.0, we’re not done with the complexity yet. Because Apple has introduced a feature that could return SKAdNetwork postbacks sooner. It’s called locking conversion values.
If marketers and developers choose, they can lock conversion values as soon as their in-app analytics detect an acceptable level of data.
In other words, if someone installs your retail app and buys an item immediately, you could lock the conversion and prepare a postback to be sent right away. In a game, if they play 5 levels on day 0, you could do the same. Don’t forget, however, each postback still has to wait for the random delay to expire: between 1-2 days on postback 1, and between 1-6 days for postbacks 2 and 3.
(If Apple didn’t require this, advertisers could lock all postbacks regardless of value at some point and then, as above, tease out which postbacks relate to which new app users.)
This means that in a scenario where you get great engagement and activity basically immediately and you lock the postback, you could achieve the following postback arrival periods:
- Postback 1 could arrive 25 to 49 hours after install
- Postback 2 could arrive 4 to 5 days after install
- Postback 3 could arrive 8 to 14 days after an install
Have you spotted the core challenge here?
There’s a huge diversity between earliest possible and latest possible postback delivery times … which is poison for being able to measure and evaluate cohorts of new users. Essentially, marketers could see a potential diversity between earliest and latest possible postback delivery of:
- Postback 1: up to 4 days
- Postback 2: from 3 to 13 days
- Postback 3: from 8 to 41 days
Remember this delta.
That potential diversity in postback delivery dates will become significant for how you approach your SKAN 4 strategy, as you’ll see later in the section on making the transition from SKAN 3 to SKAN 4.0. Quick hint: it makes cohort measurement MUCH harder.
SKAN 4.0 major update 4: Web to app support
It’s not universal across all browsers — only works in mobile Safari — and it’s not terribly comprehensive yet, but SKAN 4.0 does enable web to app measurement via the SKAdNetwork for Web Ads API.
The benefit for marketers is clear: web ads can be cheaper than in-app ads, and web onboarding experiences can be richer, more immersive, and more engaging than a standard app listing page in the App Store.
There are a bunch of steps to make it happen: the entity serving the SKAdNetwork-attributable link needs to be registered as an ad network with Apple, the link needs to be configured properly, and there must be an endpoint to provide a signed web ad impression, but there are some strong possibilities here in both web-to-app user acquisition.
(Note: for owned platforms such as your own website or landing page, you can simply use Singular deep links for full measurement and analytics capability.)
SKAN 4.0 major update 5: conversion value decreases
Finally: bear in mind that in SKAN 4.0, unlike SKAN 3.0, conversion values can go up AND down.
In SKAN 3, if you were updating a conversion value before the postback timer period clock ran up, it could only go up. Now in SKAN 4.0, you can also decrement conversion values.
This seems minor, but it’s a big deal for 2 reasons:
- It’s a complete mind-shift from SKAN 3
- It enables much more flexibility around the value of newly acquired users
Every app has flows that successful (ROI-returning) app users follow. And every app has flows that unprofitable users follow. The challenge in SKAN 3 is that sometimes the first few stages of user engagement and activity can look very similar for both groups. If that’s the case for you, in SKAN 4.0 you can decrease conversion values during the postback timer periods and supply yourself with valuable data for decision-making.
Example:
- You run a subscription app
- Some users sign up and provide long-term revenue
- Some users sign up but cancel their subscriptions after the trial period
- If you can find differences between those groups (and you might have multiple subgroups within each) you can include that data in your SKAN 4.0 postbacks
- That data can help you value cohorts, estimate LTV, and optimize ad budget allocation
Stay tuned as Singular adds capability for this.
Preparation: getting ready for the SKAN 3.0 to SKAN 4.0 transition
OK. You’ve either read or skimmed through 1,800 words of how SKAN 4.0 works, or you skipped down here right away.
What do you need to do to prepare for the transition from SKAN 3.0 to SKAN 4.0?
We’ve put together a detailed SKAN 4.0 readiness checklist which you can check out. But in short, here’s what you need to do:
Transition prep 1: update the Singular SDK in your app
Sure, it’s obvious, but it also requires communication, preparation, and action on the part of your product team: schedule an update to the Singular SDK in your app.
As of November 2022, the Singular SDK has been SKAN 4 ready.
It’s SKAN 3 compatible, so there’s no worry or risk of damage to existing SKAdNetwork implementations or attributions on legacy campaigns.
Transition prep 2: talk to your acquisition and monetization partners
Find out where they are in their SKAN 4.0 transition plans. If they’re already moving forward now, you need to catch up.
Early in the SKAN 4.0 release process, we assumed the following was necessary to get SKAN 4.0 postbacks:
- iOS 16.1 device (and up)
- Ad network encodes SKAN 4.0 click
- MMP updates SKAN 4.0 conversion values
However, we now know that’s NOT the case. All that is actually needed is 2 factors:
- iOS 16.1 device (and up)
- Ad network encodes SKAN 4.0 click
Those are very rare at the moment, but will start becoming more common in Q2 of 2023. At that point, if you haven’t set up a SKAN 4.0 model in your Singular dashboard, you’re going to be missing some data. In particular, you wouldn’t get any data for coarse conversion values: there’s no model prepared to receive that data.
So have the conversation.
Another reason to chat: if you’re ready to go, willing to make the transition, and eagerly anticipating new data from SKAN 4.0 but only half of your ad partners are ready, that’s a problem. In that scenario, you’ll need to make some decisions about either budget allocation — spend only with SKAN 4 ready partners — or timing of your SKAN 3 to SKAN 4.0 transition.
Transition prep 3: talk to your web partners
If you currently run ads on the web or are now considering it thanks to SKAN 4.0, chat with those ad partners as well.
Get details on their timetables and anything you might need to do to integrate or work together.
Transition prep 4: share your source identifier hierarchies
Part of the reason you want data from SKAdNetwork is to know what’s working.
Part of the reason ad networks need data from SKAdNetwork is essentially for the same reason: so that they can optimize campaign targeting, delivery, and volume in near real-time to deliver the best results for marketers.
Share what you’ve encoded into the SKAN 4.0 source identifier digits, so they know when they’ve succeeded, know when they’ve failed, and can act appropriately in each circumstance.
Transition prep 5: plan your coarse conversion value strategy
In some cases, due to low install volume, all you’ll get for postback 1 is a coarse conversion value. And for postbacks 2 and 3, that’s all it’s possible to get. Decide how to use coarse conversion values and what events or revenue amounts to encode to each of the 3 coarse values: low, medium, high:
Suggestion: align your coarse conversion value strategy with your fine conversion value strategy, so that whatever data you get back — whether it was from fine or coarse — is coherent and actionable. A coherent strategy between the two possible conversion payloads will ensure that while coarse results will of course be less specific than fine results, they are at least comparable and speaking the same language.
Here’s an example with a mixed event/revenue model:
With a simpler revenue-only model, decide which revenue ranges in your fine conversion values should count as “low” in your coarse conversion values, and do the same for both “medium” and “high.”
Transition prep 6: build a framework to evaluate users at each of the 3 postback stages
The good news is that Singular will enhance reporting at each stage with SKAN Advanced Analytics, modeling for missing data due to insufficient crowd anonymity, and enriching cohort reporting for revenue and ROI at each stage.
Even better: you’ll get confidence intervals so you know how much you can trust the modeled data: critical if you’re making significant budgeting decisions.
See more in the “What to expect in your Singular SKAN dashboard” section below.
Implementation: building your SKAN 4.0 transition strategy
Finally. You’ve learned, you’re prepared, and you’re ready to begin making the transition.
Wait just a moment. You may have all the technical details down pat, but there are a few strategic questions to answer before you flip the switch.
Strategic decision 1: building your conversion value models
Decide what data you need from each of the 4 possible postbacks you’ll be getting:
- Postback 1
- Either fine
- Or coarse
- Postback 2
- Postback 3
As I stated above, postback 1 fine and coarse conversion values should be aligned so that your post-install conversion data is compatible and makes sense. Postbacks 2 and 3 should be deeper-funnel events that take place between D2-D35 or higher-value conversions that will provide the most critical possible insight about the value of each cohort.
Possible models include:
- Revenue
- Conversion events
- Engagement
- Funnel
- Mixed models
- Conversion Events and Revenue
- Engagement and Revenue
- Funnel and Revenue
- Custom events/revenue model
Bear in mind that most mobile experts don’t get this right immediately, so don’t let the desire for perfection shackle you. Do what seems right, and you’ll be able to update it later. (See model migration below.)
One other note: Singular already offers optimized SKAN conversion model recommendations in many situations.
This feature literally ranks SKAN conversion models for effectiveness, analyzing your app, your postbacks, and your goals, and suggests the optimal conversion strategy. With always-on SKAN conversion model optimization checking in the background, you’ll get notified if there are potentially more accurate models to try. This is available for revenue conversion models now, and will support additional models soon.
Strategic decision 2: be willing to adapt, because Singular gives you free model flexibility
Model migration has historically been extremely challenging in SKAdNetwork. The problem is that when you migrate to a new model, you suffer from data gaps as the old model ages out and the new one phases in.
In SKAN 4.0, that’s a significantly more extreme challenge due to the very long possible postback time periods, plus random delays. You could literally be waiting for a month and a half to have entirely present and clean data for the new model.
The good news is that with Singular’s SKAN Advanced Analytics, you can migrate seamlessly and quickly, getting accurately modeled data on the same day you transition.
Schedule time to chat for more details.
Strategic decision 3: to use conversion locking or not
Remember what we said way back in the SKAN 4.0 major update 3 section about postback timing and conversion locking?
There is a massive range between the earliest to latest delivery times in SKAN 4.0. And that massive diversity is poison to your ability to generate accurate modeled cohorts. After all, accuracy is key.
As we calculated in that section, SKAN 4 postbacks from the same campaign and from the same day could be separated by as much as:
- Postback 1: up to 4 days
- Postback 2: from 3 to 13 days
- Postback 3: from 8 to 41 days
That’s why Singular’s recommendation right now is NOT to use conversion locking at all. Your app is unique, your needs are unique, so your mileage may vary, of course, but in general, the cost of getting early conversions is extremely high.
The challenge is that you have no idea on what day the conversion was locked, which creates a lot of uncertainty around the estimated install date. The result of that is cohorts are much harder to accurately model and your understanding of campaign value suffers. Sticking with the standard conversion windows for each of the postback periods buys you the certainty that each conversion was locked at the same time. Yes, there are still random timer delays, but 1 unknown is better than 2.
What might cause this advice to change:
At this point (January 2023) most of the major ad networks and platforms are not certain exactly how they want to handle SKAN 4.0 and achieve campaign optimization. As their thinking develops, this advice may change as well.
Strategic decision 4: choosing when to set up your SKAN 4.0 models in Singular
As I mentioned earlier, you can be getting SKAN 4.0 postbacks even before setting up your SKAN 4.0 models in your Singular MMP dashboard. Doing so will result in missing data, so you start developing your new conversion model strategies now to make sure you’ll be ready to go in mid Q1 2023.
The good news: a SKAN 3 click from an ad network that hasn’t yet encoded SKAN 4.0 clicks or a pre-iOS 16.1 device will be handled properly by Singular.
The challenge:
If you start getting SKAN 4.0 postbacks before you configure a SKAN 4.0 model, you’ll start seeing SKAN 4.0 data. However, you won’t yet get anything reported for coarse conversion values, because they haven’t yet been created and encoded into a model. You will see 4-digital source identifiers, if your campaigns achieve high levels of crowd anonymity.
Another challenge: transitioning.
Singular has created “transition mode” for the inevitable period in which you’ll be getting both SKAN 3 and SKAN 4.0 postbacks. In transition mode 1, you can start getting SKAN 4.0 postbacks, but because you don’t have a SKAN 4.0 model set up, you won’t get coarse values or postback 2 or 3. In transition mode 2, you will have set up a SKAN 4.0 model, and both SKAN 3 and SKAN 4.0 will work. However, while in transition mode 2, SKAN 4.0 conversions for the first postback period will be limited to 24 hours using conversion locking, so that all your data (SKAN 3.0 and SKAN 4.0) is equivalent and makes sense.
This is operable via a toggle mode, so you can turn transition mode — and which version of transition mode — on or off as you choose.
The key decision you’ll have to make upon chatting with your ad partners is deciding when you’ll only accept SKAN 4.0 data and therefore will not invest in any subsequent SKAN 3-only campaigns. For example, if you use 10 user acquisition ad networks but only 5 are fully updated for SKAN 4.0, you might choose to run in transition mode. If, on the other hand, 8 are fully updated for SKAN 4.0 and only 2 are not, you might decide to go full steam ahead on SKAN 4.0 and pause campaigns with the laggard ad networks until they complete their SKAdNetwork 4.0 build-out and configuration.
Talk to your Singular representative about the right time to make all of this live.
Operation: what to expect in your Singular SKAN dashboard
Assuming you’ve worked through all of the above, prepared, strategized, and transitioned, you should end up in a happier place than you were with SKAdNetwork 3.0. Even if you used SKAN Advanced Analytics to achieve close to 90% accurate D7 revenue.
For SKAN 4.0, Singular will display a coherent view of the data from all the postbacks that you are getting, providing a single number for revenue, installs, and events for each campaign.
That’s thanks to a modeling layer which takes in all postbacks, including those with null conversion values, coarse conversion values (low, medium, high, or whatever you’ve chosen), and detailed fine conversion values. Singular’s technology also takes into account activity, engagement, and purchases in your own first-party data from your app, and then provides a modeled view of the data.
This campaign view will be aligned to the conversion models that you’ve set up for your SKAN 4.0 reporting, and will show what each campaign ID has achieved. That will include D1, D7, and D35 revenue, which is now more accurate than under SKAN 3.0 thanks to the additional data from SKAN 4.0.
With more data, you’ll also be able to set up SKAN 4.0 to provide deeper granularity for geo-based reporting:
With modeled data from each potential postback and your own in-app data, you’ll also be able to see cohort revenue:
All of which is possible because Singular’s SKAdNetwork solution enriches campaign names, decodes conversion values, models missing data, and provides extremely accurate data estimates. All of which appears alongside your cost and percentage of installs that you’ve received conversion values for.
Get help?
We know this is complicated and new to most mobile marketers. Some haven’t had the chance to become SKAN 3 experts yet, and we’re already moving to SKAN 4, with the prospect of similar challenges on the Android side next year as Privacy Sandbox kicks into gear there.
We’re more than happy to help.
Get in touch today, and we’ll help you every step of the way.
And don’t forget: you can get this content, significantly enhanced, in the SKAN 4 transition guide.