Sam joins Branch as a Product Marketing Manager after 3+ years at Amplitude Analytics. She brings extensive domain and industry knowledge from her time previously as a Customer Success Manager, Solutions Engineer, and Technology Partner Manager. She specializes in helping businesses reach their revenue goals, scale for growth, and building the best product for their users.
Oct 25, 2022
To the mobile industry’s collective surprise, Apple released SKAdNetwork (SKAN) 4.0 with iOS 16.1 on Monday, October 24th, 2022. This release introduces a few new features and improvements since the initial announcement at WWDC in June.
Now that SKAN 4.0 is here, we’ve pored over Apple’s release notes and have compiled everything that changed this week — as well as what hasn’t changed — so that you can stay informed and prepared.
The good news is that the previously published descriptions of SKAN 4.0 only slightly varied from the latest specifications. Consequently, your technology partners — namely ad networks — will need to make a few minor adjustments.
From a high level, the elementary concepts of improvement in SKAN 4.0 still exist, specifically:
To start with the very basics: the newest version of SKAN is now SKAN 4.0. Apple has announced that marketers will only receive SKAdNetwork v4 postbacks if the following conditions are met:
Because SKAN 4.0 will only be supported if all conditions above are met, this means that — while the fast-movers may start to see 4.0 results soon — the market will take some time to make the transition. Multiple versions of SKAN will exist (and be supported) for a while.
SKAdNetwork was introduced to limit the amount of data sent in postbacks in order to maintain users’ privacy and ensure crowd anonymity. Previous versions of SKAN introduced the concept of “privacy thresholds”. And now, SKAN 4.0 ventures further, adding additional “tiers” to allow more granularity, while still obscuring individuals within a group by way of crowd anonymity.
In June, Apple defined the three tiers of crowd anonymity, which are based on attribution volume: low, medium, and high. Crowd anonymity controls granularity for both the conversion value and source identifier field — compared to SKAN 3.0 the source identifier is expanding to allow more data at higher tiers, and conversion value granularity is going down at lower tiers.
With each tier, more granular data becomes available within the postback:
Apple hasn’t — and likely won’t — provide clear thresholds of users for each tier — only stating that more attributed volume enables access to a higher tier.
With the public release of SKAN 4.0, Apple has formally announced four tiers to make explicit the levels of crowd anonymity — which includes the addition of an even lower tier, Tier 0.
As the size of a campaign increases, the tier will increase — allowing for more measurement granularity. It’s important to note that Apple assigns the crowd anonymity tier level after app download.
Per Apple, the postback data tier determines the data marketers receive in the postbacks, as follows:
This tier system will enable marketers to see lower granularity (coarse-grained) campaign results on smaller groups of users.
Apple’s release notes for iOS 16.1 stipulate that web-to-app SKAN postback functionality only works for apps running iOS 16.1 or later — with Safari; not Chrome or any other browsers. With any other browsers, the framework just won’t function.
With SKAN 3.0 and before, Apple added a randomized 24-hour timer on the single postback. Every time the postback was updated, a randomized delay was added, leading to a “rolling” delay. With SKAN 4.0’s concept of multiple postbacks with predefined measurement windows, there is no need for a rolling delay — instead Apple has chosen to lengthen the random timer for the first postback from between zero and 24 hours to between 24 and 48 hours. The second and third postback will receive a randomized delay of one to six days (24 to 144 hours) after the measurement window closes.
This means that in some cases marketers may now need to wait longer to ensure all postbacks are collected on a campaign before making decisions. With delays of up to six days after postbacks, marketers will need to plan accordingly when selecting postbacks and measuring campaign results.
To facilitate differentiating postbacks, Apple has introduced the postback-sequence-index parameter to explicitly distinguish between postbacks 1, 2, and 3. It’s worth mentioning that there’s no way to connect all three postbacks for a specific user together as the data will remain aggregate level.
For apps that want to receive postbacks sooner, Apple has introduced the concept of “locking” conversion values. While this won’t decrease the randomized timer for postback windows, it will allow app developers to receive the postback for each window early — before the end of the measurement window.
With these changes being introduced, two scenarios exist:
Scenario 1: Unlocked conversion values will wait until the end of the time period, then — after a random delay — the postback will be relayed through SKAdNetwork.
Scenario 2: A locked conversion value will allow the app to fire the postback prior to the end of the postback window.
At first, it might seem like the increase in postback windows could force marketers to wait longer to receive maximum signal on installs. However, SKAN 4.0 is a notable improvement than its predecessors – with the removal of the rolling timer from earlier SKAN versions, the addition of two more postbacks, and the option to close the measurement windows early (by leveraging locking conversion values) – marketers have more flexibility within the SKAN framework.
It remains to be seen, but we suspect that ad networks will provide guidance on when to use locking conversion values once they refine and test their models on the newly available data signal.
If you’d like to learn more about how Branch can support you during the transition to SKAN 4.0, contact your customer success manager or request a demo.
To help you fuel cross-channel and cross-platform mobile growth, our team works hard to deliver the most current, relevant resources.