WWDC Day 3: SKAdNetwork v4.0 details are here!

By Jonathan Chen June 9, 2022

Apple has released their WWDC session on new SKAdNetwork updates. We’ve taken a first look and wanted to share the breakdown of the updates, and our initial thoughts on what it actually means for marketers.

Disclaimer: As of the publication date of this blog post, the actual developer documentation for the SKAN 4.0 specifications has not been released yet, so this first look is based only on the WWDC session, supporting WWDC content, and Apple’s Q&A lounges. Things may change!

Hierarchical Campaign (Source) IDs

Campaign ID now supports up to 4 digits (up from 2). This means up to 10,000 values can be supported for campaigns/creative or other breakdowns. In keeping with this expanded functionality, Apple has also decided to rename campaign ID to source ID to reflect the new intended use. We’ll refer to this as the “source ID” moving forward.

rename campaign ID to source ID

Apple also says that the new digits are subject to 3 tiers of “crowd anonymity” (AKA privacy thresholds). Apple updating privacy threshold behavior in response to the added digits is not a surprise. For now, it looks like high-volume campaigns will get significant amounts of data, as in Apple’s example below: campaign, location, and ad placement.

crowd anonymity

Our takeaways:

  • For ad networks and publishers, this is a huge and welcome change. With 100x more available granularity, we’re excited to see ad networks and publishers use the new granularity to provide more visibility and value to marketers.
  • Privacy thresholds on source IDs are new. We can assume that the “low” privacy threshold tier is the same privacy threshold tier that exists today, since source IDs (ie. campaign IDs) are always available today.
  • Source IDs directly impact privacy thresholds today (see our past analysis of SKAdNetwork privacy thresholds). We definitely will test these new privacy thresholds thoroughly and understand what the new behavior is, and if thresholds are still gated by the number of installs per ID. If thresholds are still dependent on unique values per ID, it could be unrealistic to use all 10000 source IDs.

Hierarchical Conversion Values

As an MMP, we’re personally excited whenever we see updates to SKAdNetwork conversion values. After all, extracting as much information from conversion values (we call these conversion models) is the bread and butter of what MMPs do.

Apple focused on 2 major changes to conversion values:

  • New “coarse grained” conversion values
  • 2 more SKAdNetwork postbacks for supporting multiple conversions

Separately, although only mentioned briefly in the session, we spotted a third major change as well:

  • Conversion values can now both increase and decrease

Coarse-Grained Conversion Values

Let’s take a look at “coarse-grained” values.

Conversion Value
Updating the Conversion Value

Apple is introducing a set of “coarse” conversion values that can be 3 potential values, enumerated as “low,” “medium”, and “high”. Both “coarse”and “fine” (the 6 bits we are familiar with today) values are assigned through the same “updatePostbackConversionValue”.

Crowd anonymity and conversion value

Although “coarse” and “fine” values can both be set, they won’t be available for reporting/postbacks together. Depending on the crowd anonymity (privacy thresholds), you may get no conversion values (low anonymity) at all, “coarse” values (medium anonymity) , or “fine” values (high anonymity).

In Apple’s example, a “coarse” value of “high” and a “fine” value of “42” has been set as the conversion value.  In a similar fashion to source IDs, depending on the privacy threshold met, either no conversion value, the value “high” (out of 3 possible values), or the value “42” (out of 64 possible values) would be sent in the SKAdNetwork postback.

Multiple Conversions (Postbacks)

Alongside “coarse” conversion values, Apple introduced more conversion insights in the form of “multiple conversions.” Simply put, Apple will now support sending three SKAdNetwork postbacks, a significant improvement from the single one that is sent today.

Postback 1 will arrive in 0-2 days, postback 2 will be 3-7 days, and the third SKAN postback can arrive as much as 35 days after an app install.

skadnetwork postbacks

This is also another big change to postback timer mechanisms. While initially vague on details in the session, it was verified in the Apple Q&A lounges that all 3 postbacks will follow strict postback sending windows (0-2, 3-7, and 8-35 days). This is a change from the behavior today, where calling updateConversionValue would effectively delay the SKAN postbacks past 24 hours, to try and encode more information. With the new postback timer logic, you can only delay until the upper bound of the window for the respective postback number.

Multiple conversions

There is one important detail of the additional postbacks — postbacks 2 and 3 get only coarse conversion values!

Support for Decreasing Conversion Values

Decreasing conversion values

We also saw a very briefly mentioned, but major feature with details later verified in Apple’s Q&A lounges. Starting with SKAdNetwork 4.0, both coarse and fine conversion values can increase or decrease. In prior versions of SKAdNetwork, conversion values could only increase, forcing marketers to adopt conversion value strategies where they could only update conversion values up to 64 times.

Our takeaways and open questions: 

  • The introduction of coarse conversion values allows you to get some data if the max privacy threshold isn’t met. It’s better than nothing, but far from the “more conversion value granularity” that is on every marketers wishlist.
  • On the new privacy thresholds:
    • It’s not clear if today’s single privacy threshold maps to low (doubtful), medium, or high tiers.
    • It’s not clear how the “source-app-id” (currently gated behind the single privacy threshold for SKAN 3.0 and below) behaves under the new privacy threshold.
    • It’s not clear if the “conversion value” privacy thresholds are the same as those for source IDs (previously campaign IDs).
  • While “fine” conversion value updates are no longer subject to the “only increasing” requirement, the strict postback window changes effectively mean conversion models based on “fine” conversion values are capped to 24 hours. This means that you can get a LOT more information out of “fine” conversion values, but only in the first 24 hours after install.
  • 7-day (and greater) modeling techniques on SKAdNetwork data are even more important. Postbacks 2 and 3 can potentially be used to increase accuracy of >24 hour modeled conversion data.
  • SKAdNetwork 4.0 is the biggest update to SKAdNetwork functionality since 2.0. How will the industry adopt such significant changes, knowing that iOS adoption rates will likely mean advertisers need parallel (and very different) marketing strategies for SKAN 3.0- and SKAN 4.0+? Will some advertisers manage complexity by simply focusing on a smaller target audience (SKAN 4.0+)?

Mobile Web to App Support

In SKAN 4.0, we will have web-to-app support! Apple dove into some initial details of the new web-to-app support for SKAdNetwork.

web-to-app attribution

This announcement cannot be understated. Since SKAdNetwork 2.0, lack of web-to-app measurement has been one of the biggest non-addressed use cases that caused marketers to scratch heads to find a solution for.

Skadnetwork web-to-app

To quickly recap, SKAdNetwork is now supported for “clicks” (no mention of “views”) leading to the app store for “first party sites” and “embedded cross site iframes.”

There’s quite a bit to unpack here both in terms of how it works, as well as the impact to broader strategies on iOS marketing and measurement, so we’ll have a separate post about web to app support and what it means for us all.

SKAdNetwork Testability Updates

Last but not least, Apple added a few new features to aid in testing, including:

  • Validating Ad Impression implementation
  • Testing SKAdNetwork postbacks

Testing postbacks

As an MMP, we’re particularly excited to play around with the postback testing functionality. At this point, we only have fairly sparse details, but we’d like to learn more about:

  • What properties are supported? Can we customize all key value parameters present in an SKAdNetwork postback?
  • Is the postbackURL validated in any way? For example, does it only work for the URL registered adNetworkIdentifier, or developer via NSAdvertisingAttributionReportEndpoint?
  • How do we identify what is a test postback vs a real one?

Much, much more to come

It’s still very early days in terms of SKAdNetwork 4.0 details, and there’s a lot more to learn, share, build, and test. Although there is no mention of when 4.0 will be released (only mentions of “Later this year”), we’ll be keeping an eye out for more information.

We’ll be posting much more on this in the next few weeks.

Stay up to date on the latest happenings in digital marketing

Simply send us your email and you’re in! We promise not to spam you.