SKAdNetwork and Private Relay quasi-VPN

During Apple's Worldwide Developers Conference (WWDC) 2020 and 2021, Apple came out with major updates to privacy that impacted mobile marketers for years to come in the iOS space. It’s no surprise everyone was waiting with bated breath to see where Apple would take us with WWDC 2022 announcements around iOS 16. While there were certainly going to be some updates for iOS 16, the big worry by many, and hope by others, was the anticipated expansion of Private Relay.

Private Relay is somewhat of a quasi-VPN, obscuring consumers identifying IP address information and assigning those individuals with a more general IP address based on regional location. The feature already existed for iCloud users but was not turned on by default and had remained in beta. While many Kochava customers do not rely on any probabilistic signal for attribution and therefore this change would not impact them, there are those in the industry that do leverage it. Kochava provides industry-leading support for SKAdNetwork, focused on delivering attribution capabilities in-line with Apple guidance.

SKAdNetwork and Private Relay quasi-VPN

While Apple has not yet enforced its guidance against using identifiable information (like IP address) for the purpose of targeting or attribution, many (including us) thought the expansion of Private Relay would be the selected strategy for enforcement and would be announced at WWDC 2022. The absence of expanded roll-out is telling, but we remain convinced that Apple will enforce their guidance eventually and we suspect that they have been waiting for forthcoming innovations with SKAdNetwork 4.0 (described further later) before they engage in enforcement.

WWDC 2022 gave us a great breakdown of additional functionality for Apple’s SKAN and all of its new features. SKAN received a massive increase in attribution after June of last year when Apple released iOS 14.5+ but it was always seen as limited. Thankfully, Apple addressed many of these issues and is planning on making some needed improvements, but the number of changes could overwhelm even the most well-versed iOS marketers. Luckily, we have the analysis you need.

SKAN 4.0 includes four major updates:

• Hierarchical IDs 
• Multiple conversions
• Web-to-app attribution
• SKAN testing improvements

Hierarchical IDs: 

Crowd Anonymity Tiers

Historically, Apple has not provided much information about the privacy threshold which determines the minimum amount of attributed volume which must be met before conversion values will be included in postbacks. With SKAN 4.0, Apple has finally defined three tiers of "crowd anonymity" based on attribution volume: low, medium, and high. With each tier, more granular data becomes available within the postback. Note that Apple still does not provide precisely what the thresholds are for each tier, only that with more attributed volume each tier is reached.

Source Identifier

SKAN 4.0 replaces the 2-digit campaign identifier field from the ad impression with a new 4-digit 'source identifier' field. This field should be thought of as a 'conversion value' equivalent for the ad impression, but should not be thought of in terms of bits, as each of the 4 digits becomes available as higher tiers of crowd anonymity are reached.

Similar to conversion values, these 4 digits could be used to represent different data. However, unlike conversion values, Apple obfuscates certain digits based on the level of crowd anonymity, which means each digit (not each bit) should represent something meaningful. Apple used the following model as an example:

Digit #4 = Ad placement bucket
Digit #3 = Date bucket
Digit #1,2 = Campaign ID

As you can see, like conversion values, models could be defined to interpret each digit differently per customer based on needs.

Coarse Value

SKAN 4.0 introduces a new value which is sent along with the conversion value in the advertiser app named the 'coarse value'. This coarse value can be set to one of three possible values (we'll use "a", "b", and "c" in this blog) and is included in postbacks in place of the conversion value when the crowd anonymity tier restricts the conversion value. In other words, when the attribution volume is too low to allow the conversion value to be shared, the coarse value will be included in its place. Note that the coarse value and conversion value are mutually exclusive; the coarse value cannot be used in tandem with the conversion value in terms of the conversion model.

Example

How the tier of crowd anonymity impacts each hierarchical value in the postback:

Multiple Conversions

As of SKAN 4.0, up to 3 postbacks are delivered and bucketed by the time of conversion with a maximum window of 35 days since installation. This is a great innovation! The time buckets are 0-2 days, 3-7 days, and 8-35 days. In short, the last conversion to take place within a given time bucket is sent at the end of the window. This is a departure from the concept of the 24-hour timer, and it means:

• The SDK does not have to attempt to "keep the 24-hour window open" using valuable bits.  
   
• It may no longer be necessary to allocate bits to time windows as the postback will reflect the time window, and the conversion value itself will only be available during the 0-2 day window

In the current implementation support for SKAdNetwork within Kochava, the Conversion Bit Modeler has been built to make up for current SKAdNetwork limitations and as a result - used valuable conversion bits. Using these new capabilities in 4.0 means that more bits can be used moving forward for optimization.

Install vs Re-engagement

Additionally, Apple stated the conversion value itself will only be available within the initial 0-2 day postback. The 3-7 and 8-35 day postbacks do not include the conversion value and instead include only the coarse value. Apple's intent is that the 3+ day postbacks are used primarily for re-engagement. Interestingly, this suggests that the more granular conversion value is lost after the first 2 days with the trade-off being that a coarse value is available up to 35 days later. It also may impact the landscape of conversion models if a conversion model is only good for days 0-2.

Note: It was mentioned that the conversion value may increase or decrease with SKAN 4.0, which suggests that the conversion value will not have to increase with each call. However, Apple did not elaborate on this.

Example

How the days since the installation will determine whether the coarse value or conversion value is included in the postback:

Web-to-App Attribution

In short, this is URL link-based attribution. It's certainly not as robust as something like the Google install referrer, but it should be thought of in a similar manner as it allows for an install to be attributed (albeit anonymously) to a URL-based link. The ad network is responsible for generating this URL-based link, which is specific to an ad impression, in a SKAdNetwork-compliant manner and then providing it to the publisher app. From there, the rest of the flow works as it does today.

There are plenty of steps required for the ad network to generate the link, but they won’t be covered here. The burden in implementing web-to-app attribution is placed almost solely on the shoulders of the advertising network. The publisher app needs only to embed the resulting link provided by the ad network, and the SDK (advertiser app) continues to implement standard SKAdNetwork API calls.

SKAN Testing

Apple added a variety of new testing tooling to help facilitate SKAdNetwork testing, which is going to be a big help for developers. Historically, this has been a significant pain point as the developer was forced to largely re-create the entire publisher-to-advertiser app flow in order to test anything.

While this year's WWDC announcements didn’t change the game as much as some had predicted, it’s clear that Apple and much of the industries are moving toward expanding privacy-first features. Kochava will support these new features to ensure that our customers don’t miss any opportunity to leverage and can maximize focus on growth.

It’s important for developers and UA managers to stay informed about these changes, so be sure to sign up for our newsletter, where we will discuss these developments and more from last year, this year, and many years to come.