Update as of Tuesday, October 25th 2022:
Apple released iOS 16.1 (and SKAN 4.0) this week – check out our SKAN 4.0 blog post that recaps everything you need to know (so you don’t have to pore through the release notes yourself).
Apple’s annual Worldwide Developers Conference (WWDC) concluded on June 10, 2022. Now it’s time to cover the latest about everything Apple announced, including improvements to SKAdNetwork and the latest on AppTrackingTransparency compliance.
Why is WWDC such an important event?
We can’t really talk about WWDC without reminding ourselves of its recent historical context.
In 2020, we got iOS 14, AppTrackingTransparency, SKAdNetwork, and the beginning of the IDFA Apocalypse. That was followed the next year by iOS 15 with Private Relay and Hide My Email. Not as big, but also not insignificant. Both were disruptive.
The stakes for changes like these are not small. When Apple makes announcements like these, it’s disruptive to all of us here in the world of mobile marketing… but it also literally moves markets and impacts the industry in very unpredictable ways.
For example, Apple’s own ad network, Apple Search Ads, has been thriving ever since the launch of iOS 14.5. Meanwhile, rival ad networks have been capped by this privacy push. After two years in a row of this, it makes sense that we all start twitching a bit every time Apple has a product announcement.
Going into this year’s WWDC, many of us in mobile expected something disruptive, but it seems like Apple decided to take the year off for privacy-related announcements.
WWDC 2022 scorecard
This isn’t to say there was a lack of interesting developments. To summarize the updates of note:
✖ No major privacy announcements
✔️SKAdNetwork 4.0 is here!
✔️Clarification on AppTrackingTransparency policy
✔️Changes to pasteboard access
No major privacy announcements
A good indication of what Apple considers important each year is whatever makes it into the main WWDC Keynote at the beginning of the first day. Nothing related to advertising or privacy made that keynote this year, unlike the last two years.
You may be wondering: What could something big have looked like? One leading theory was that Apple might extend iCloud+ Private Relay to cover app traffic, possibly combined with a solution similar to SDK Runtime (which was introduced as part of Privacy Sandbox on Android earlier this year). This would have further masked IP addresses, technically blocking AppTrackingTransparency workarounds like fingerprinting. (For a deeper explanation of how a system like this could have worked, read this blog post.)
However, Apple didn’t do that this year. Maybe in iOS 17…
If you get your annual kicks out of WWDC chaos, this might be mildly disappointing so far. But there is an unambiguously positive development: We’re getting a new version of SKAdNetwork!
We’ll go into all the details next, but SKAdNetwork 4.0 is a major improvement and should make SKAN a lot more usable for most apps.
The most important message is that more data signal is now accessible in more situations, according to the latest study. It can be said that previous versions of SKAN were somewhat over-engineered (such as the rolling timer), and the new version reduces the system’s complexity.
With V4, SKAN is finally becoming a system that feels like it might be implemented and used – essentially what we all desired from V1. It’s not yet perfect, but it’s an improvement from the past. It’s encouraging to see Apple continuing to invest here.
What are the SKAdNetwork improvements coming in version 4.0?
- Multiple conversions – You can now get up to three postbacks sent at predetermined intervals — no need to deal with complicated extensible timer logic!
- SKAdNetwork attributions for web – Attribution is now supported for web-based ads that direct to the app’s App Store product page.
- Hierarchical source identifiers – Apple is replacing the campaign ID with a new parameter named the source identifier, which is 100x larger and intended to be more flexible than campaign ID. Up to 4 digits are now supported, depending on privacy thresholds.
- Hierarchical conversion values – Addition of ‘coarse’ and ‘fine’ grained conversion value variants.
History of SKAdNetwork
- SKAN 1.0 (iOS 11) | Previous version of the Matrix: Version 1 came way back in 2017, with iOS 11. We can think of this as the previous version of the Matrix — it might be called SKAdNetwork, but it really didn’t function much like the current system. For all practical purposes, we can ignore it.
- SKAN 2.0 (iOS 14) | Beginning of the Modern Era: The first ‘modern’ version of SKAdNetwork was 2.0, introduced along with ATT in 2020. Since then, Apple has made a few incremental improvements to the system. For example, in SKAN 2.2, they added support for view-through attribution.
- SKAN 3.0 (iOS 14.6 – 15): In version 3.0, Apple added support for postbacks to ad networks that didn’t win last-touch attribution credit. Also in 3.0 (a bit later), Apple made it possible for advertisers (and mobile measurement parters (MMPs), on advertisers’ behalf) to get a copy of the SKAN data directly, instead of relying exclusively on ad networks to collect and forward everything.
All these improvements were welcome, but mostly incremental and not addressing some of the systemic issues that caused the most pain for advertisers with SKAN.
With SKAN 4.0 (iOS 16), that is finally starting to change.
Introducing: Crowd Anonymity
Before we jump into the details of what’s new in SKAdNetwork 4.0, we need to define a key concept: Crowd Anonymity. This is Apple’s term, and it’s important because of how it compares with earlier versions of SKAN.
In the past, SKAdNetwork 4.0 had the concept of a ‘Privacy Threshold’. There was only one, and passing this threshold involved getting enough activity on your campaign that Apple felt confident you wouldn’t be able to reverse-engineer anything about an individual user from the data. If you passed the threshold, you would get more data about the install and conversion process. If you didn’t, SKAN would withhold some data parameters. The criteria and minimums of this threshold were always secret.
In SKAN 4.0, the criteria and minimums are still secret, but now they’re also more sophisticated. Instead of one threshold to pass, now there are three different groups. Apple describes these as either less/more/most, or low/medium/high. The basic idea is they progressively reveal more granular data as the number of users in the cohort increases. Keep these three levels in mind because they are important for several of the new improvements.
In previous versions of SKAdNetwork, you got a single conversion postback. That was it. Just a single signal, ever. A complex system of timers made it possible to delay the postback until the user had time to make a conversion, but that came at the cost of waiting longer to get any information about the install.
In SKAdNetwork 4, you can now get up to three postbacks — and they are sent at predetermined intervals, which means no need to deal with complicated extensible timer logic.
Here’s how it works:
- Once the user opens the app for the first time, you register with SKAN for attribution. That’s the same as it has always been.
- Two days after this registration, the first postback is sent.
- Then, the second postback is sent after seven days.
- The third postback is sent after 35 days.
This allows for more time to collect signals about what the user is doing after the install, which solves one of the biggest painpoints with SKAN so far. It’s important to note that each postback is only sent if you make an update conversion value call during the given window. This means if your user installs the app and then doesn’t open it again for three weeks, you’d get postbacks one and three, but NOT two.
It’s also important to note that each postback will have a parameter specifying which position it’s in, but there won’t be any way to tie together the successive postbacks from each user. In other words, it’s all still aggregated data — just more of it.
Also, just in case it wasn’t already clear, this improvement means no more looping timers! This is a welcome development as the looping timers were confusing and difficult to work with.
SKAdNetwork attributions for web
Another improvement is SKAdNetwork support for web ads. Older versions of SKAN didn’t support this, and it was a significant hole. With 4.0, SKAdNetwork will support attribution for web-based ads that directs users to the advertised app’s App Store product page.
Together with PCM (Private Click Measurement), this means Apple is slowly covering more of the various conversion flows in a typical app marketing strategy. There are still plenty of gaps, but at least they’re gradually making progress.
Side note: SKAdNetwork for non-ads?
This new web functionality might mean that clicks for non-ad channels could be considered by SKAdNetwork. This is all still theoretical, but if it is possible, this may finally unlock some possibilities for SKAN support of non-ad marketing activities like web smart banners and email marketing. If so, this would be a huge opportunity because it would solve a major blind spot with SKAN that currently makes it impossible to know if an ad is falsely getting credit for conversions that were actually driven by other channels.
Hierarchical source identifiers
Next, let’s discuss the new hierarchical data parameters in SKAN 4.0, starting with the source identifier.
In previous versions of SKAN, we had the campaign ID. This was a two-digit parameter, which meant there were 100 possibilities. The entire parameter was always sent back in the SKAN postback. Now, Apple is replacing the campaign ID with a new parameter called the source identifier. They’ve renamed it because this new parameter is 100x larger and intended to be more flexible than just campaign IDs.
The digits can be used however the advertiser/ad network determines. This campaign/location/placement scheme is just one example.
It now supports up to four digits, and the number returned in the postback will depend on the Crowd Anonymity level:
- If the Crowd Anonymity level is ‘low’, then the first two digits are returned. This is the way things worked previously.
- At the ‘medium’ level, three digits are returned.
- At the ‘high’ level, all four digits are available.
Hierarchical conversion values
Let’s now cover the hierarchical conversion values. In previous SKAN versions, the conversion value was a six-bit number, meaning 64 total options. It was only possible for this number to be increased — if you set it to 10 (for example), there was no way you could reset it back to 9 again.
In SKAN 4.0, there are actually two different values:
- Fine-grained, which is the same as the six-bit value that already existed.
- Coarse-grained, which is a basic low/medium/high range.
Only one of these values is returned, and which one you will receive is controlled by postback position and Crowd Anonymity level. There is also no technical correlation between these two values, whichmeans both can be set at any time to any value the developer desires (e.g., both ‘high, 2’, and ‘low, 61’ are valid combinations).
And yes, in SKAN 4.0 the values can both increase AND decrease.
Let’s look at an example where the two conversion values might be set inside the app to ‘high’ and 42, respectively:
- If the Crowd Anonymity level is ‘low’, then neither version of the conversion value is returned. This is equivalent to prior versions of SKAN where the single privacy threshold was not met.
- At the ‘medium’ level, the coarse value is returned.
- At the ‘high’ level, the fine level is returned.
It’s important to note that only the first postback is eligible for the fine-grained postback. This means that the conversion value in postback one could be null, coarse, or fine, depending on the Crowd Anonymity level. Postbacks two and three can only be coarse or null, never fine-grained.
What happens next with SKAdNetwork?
While SKAN 4.0 is an improvement — with support for multiple postbacks, web ads, and simpler timer settings — gaps still exist. Here are a few of the top items we would still very much like to see, perhaps in SKAdNetwork 5.0:
- True support for non-paid channels (owned and earned).
- Deep linking.
- Re-engagement ads (app is already installed).
The full documentation for SKAdNetwork 4 has not yet been published, so some details remain unclear. For example, we don’t know what the introduction timeline looks like. It may not be released at the same time as iOS 16.0 this fall. Whatever happens, in reality, earlier SKAdNetwork versions will be with us for a while.
Additionally, there’s no indication that SKAN 4.0 will be retroactive to earlier versions of iOS, so prepare for more fragmentation. We’ll be dealing with fragmented data — coming from various versions of SKAN and other attribution methodologies — for a long time. That’s why it’s more important than ever to rely on trusted advisors (like your MMP) to make sense of all this chaos.
What about ATT enforcement?
Apple’s Explore App Tracking Transparency tech session contained some interesting details. While there’s nothing quite as clear as a ‘declaration of war’ on any particular behavior or activity, several things are still specifically addressed (at least, specific when it comes to Apple).
Here’s what we learned this year at WWDC about AppTrackingTransparency policy interpretation, compliance, and enforcement:
- ‘Tracking’ is not just about IDFA. ATT applies to all forms of advertising tracking, and it’s not just IDFA gating (IDFA is only mentioned once in the whole session). This was always clear in the policy, but the way Apple described it this year shifted subtly.
- No separate-but-equal systems to SKAN. Apple specifically rules out workarounds based on processing user-level data but only outputting aggregated reports. In other words, you can’t create ‘separate-but-equal’ systems to SKAN that work without user opt-in.
- Fingerprinting is never okay. Fingerprinting is addressed head-on: Apple says it’s never allowed. While there are no explicit statements about upcoming enforcement plans, it’s not hard to see this as a final warning.
Want to ensure compliance and value within ever-changing privacy policies (like AppTrackingTransparency)? If yes, you’ll be well-equipped with Branch’s SafeTrack™ — the best tracking compliance functionality to have in your armory. With this solution, you can rest assured that your ad links are designed to behave in full compliance with all applicable platform policies for ad tracking, including ATT.
Pasteboard access changes
Finally, Apple also announced some improvements to Pasteboard access for apps in iOS 16. Apple introduced a small paste notification banner in iOS 14, to give users more transparency into when apps accessed the pasteboard, but there was still no permissions requirement.
Now, more control for cross-app copy/pasting is here! In iOS 16, the system provides a new, customizable OS-level paste button that confirms the user’s cross-app intent by requiring the user to tap in order to paste. Other paste methods can still be used, but will now trigger a confirmation modal.. As before, developers can use the methods described in Detecting Patterns of Content in Pasteboard Items to determine if pasteboard items match various patterns — like web search terms, URLs, or numbers — without notifying the user.
Note: Branch’s on-device deferred deep linking solution, NativeLink ™, uses the pasteboard to remember the user’s destination through the App Store install process. NativeLink already asks for an opt-in from users in order to start the copy/paste flow, and these iOS 16 improvements support our emphasis on customer opt-in, flexibility and transparency. Our teams are testing the new iOS 16 pasteboard functionality, and we are confident these changes will fit well with the NativeLink ™ experience.
What does this mean for the future?
The overall trends are very clear, and nothing announced (or not announced) during WWDC 2022 changes that.
Apple is taking a break from new privacy-related high drama this year, but that doesn’t mean they’re walking away. Just see their new ad campaign for proof. Even if Apple doesn’t move more aggressively into ATT enforcement after these WWDC announcements, we believe the best strategy for the future of measurement is to embrace the new world. It’s advised to not waste time and energy trying to squeeze out just a little bit more device-level data through workarounds. Apple will inevitably crack down on them, whether this year or next. Device-level data is going out of fashion, in favor of aggregated reporting.
Your MMP is your ally. Don’t try to go it alone — it’s more important than ever to have a mobile measurement partner to handle all the complexity baked into measuring your ads. But at the same time, with new measurement frameworks like SKAdNetwork and Privacy Sandbox for Android, everyone is going to be using the same set of tools. Be sure to evaluate your MMP on their knowledge and experience pertaining to your brand’s industry.
Look for other low-hanging fruit. Ads have been the cheap, accessible option for a long time. They aren’t going anywhere, but now is the time to 1) look at other marketing channels and 2) focus on plugging the leaks in your funnel instead of just pouring more cheap traffic in the top. Now, we’re seeing a general trend toward interest in other owned and organic channels. Those have always been a good bet, and now they’re getting the attention they always deserved. This requires a different toolset from your typical, traditional MMP – so if you haven’t considered investing in a mobile linking platform (MLP) for your owned and earned channels, this is a great time to start.
Stay positive! Big shifts like this are why mobile is such a dynamic space to work. It’s incredibly exciting.
That wraps up our coverage of everything Apple revealed at WWDC this year, which includes changes to SKAdNetwork and AppTrackingTransparency compliance. To stay updated on the latest changes and developments in the ever-changing attribution industry, make sure you’re subscribed to our content (just add your email below). If you’d like to have a further conversation with a member of the Branch team, contact us anytime here!