What's new with SKAdNetwork

♪ instrumental hip hop music ♪ Hello and welcome to WWDC. I’m Nikhil and today, I’ll share with you the changes coming to SKAdNetwork. Before diving into the future, let’s remember where we are and how we got here. At Apple, we believe privacy is a fundamental human right and protecting it is woven into everything we do here. Which is why we created SKAdNetwork. SKAdNetwork is Apple’s privacy-preserving install attribution system. Attribution data is sent back to the advertiser while preserving the user’s privacy. SKAdNetwork involves three actors: ad networks, publisher apps, and advertiser apps. Let's also define some terms used commonly within SKAdNetwork. Impression: an impression in the context of this discussion is input from the publisher app to SKAdNetwork. Engagement: an engagement happens when the user interacts with the advertiser app. The advertiser app captures these engagements in the form of conversion value updates. And finally, conversions, which are also called postbacks. The postback contains attribution data which is sent to the ad network. The attribution data provides a signal to the ad network that this was a successful conversion of the original ad. The ad network generates a signed impression for the advertiser app. The publisher app uses this impression and displays this ad. The user then taps the ad and installs the app. When launched for the first time, the app calls an API to signal the conversion. The app can then repeatedly call this API to update the conversion value and capture various levels of engagement and return on ad spent. Once the timer expires, we send the postback containing the attribution data to the ad network.

Taking a quick look at the version history for SKAdNetwork. SKAdNetwork 2.0 introduced privacy-preserving ad attribution. 2.2 enabled publisher apps to show custom ads. 3.0 added postbacks for non-winning impressions. And in iOS 15.0, we introduced postback copies for developers for all versions of SKAdNetwork.

For more on the history of SKAdNetwork, refer to the session "Meet privacy-preserving ad attribution" from WWDC 2021.

Now let’s talk about the future, SKAdNetwork 4.0. Let’s have a look at the new features. We are going to start by looking at a few changes to the API designed to provide more data to advertisers. Following this, we will look at the conversion side of things. We will then move on to attribution for ads on the web, and wrap up by talking about SKAdNetwork testability. Hierarchical IDs and conversion values are the first new feature coming to SKAdNetwork 4.0.

Before diving into the new feature, I would like to define crowd anonymity. Crowd anonymity is the term we use to refer to the privacy-preserving way in which SKAdNetwork delivers attribution data. Counts of installs determine the level of privacy assured to the person using your app. At the lower end, we send less attribution data to the advertiser in the postback. When the install count is low, we take extra steps to protect privacy by limiting the trackable information sent back. As the count scales up and the user’s uniqueness starts to blend into the crowd, we send more data back. Finally, as the count reaches the highest tier, we are able to send the most data back while still preserving privacy. In SKAdNetwork 4.0, we have a way to send more data while retaining our privacy protections. For this, we are changing the campaign identifier field. At present, this is a 2 digit field. We will increase the range of this field to 4 digits and rename it to source identifier. The new name reflects our way of thinking about this field as being capable of representing anything you choose to use it for and not solely for identifying campaigns.

Though this is a single number, we encourage thinking about it as three hierarchical numbers, a 2, 3, and 4 digit number. Thinking about the source identifier field as a hierarchical set of numbers is helpful in ascribing meaning to the different numbers. As an example, the 2 digits could represent the ad campaign, the 3rd could represent the bucketed location of the user, and the 4th could stand for ad placement on screen. Alternatively, the 2 digits could stand for treatments, the 3rd digit could represent bucketed time of day, and the 4th digit could stands for the size of the ad shown. These are simply examples, and ultimately, what we wanted here was to open this field up to you to use as best fits your need. Continuing the theme of providing more data, the conversion value is also changing. Currently this is a 6 bit value. With SKAdNetwork 4.0, we are introducing two conversion values: a fine-grained value and a coarse-grained value. The fine-grained value is the same as the conversion value today. The coarse-grained value can assume one of three values. Considering a conversion value of high 42, where high is the coarse value and 42 is the fine value, the install count required to receive the coarse value is lower than that needed for the fine value. Consequently, apps will receive the former much faster than the latter. Note however, that only one of these will be sent back to the advertiser. Let us take a look at how crowd anonymity affects these new fields.

Using our earlier example of 5739 as the source identifier, at the low end of crowd anonymity, you can expect to receive the 2 digit component of the source identifier, which in this case is 39. At the medium level, you can expect to receive the 3 digit component. And at the highest level, you can expect to receive the full 4 digit source identifier back. As the crowd anonymity level increases, more digits of the source identifier are sent back. And taking our earlier example of high 42 for the conversion value, at the low end of crowd anonymity, you will not receive a conversion value in your postback. At the medium level, you will receive the coarse conversion value. And at the highest level, you will receive the fine-grained conversion value in your postback. As the crowd anonymity increases, the conversion value returned changes. Let’s take a look at the API changes. If you are using instances of SKAdImpression to show your ads, you can set the new sourceIdentifier property on the SKAdImpression instance.

If you are setting your impression via a dictionary, you can set the sourceIdentifier value using the new source identifier key.

For advertised apps, you will call the new updatePostbackConversionValue method which has been changed to now take a coarse-grained conversion value in addition to the fine-grained conversion value as shown here. We recommend that you use the completion handler to do any follow up tasks after updating your postback’s conversion values. Here are some recommendations on adopting the new hierarchical IDs and conversion values API. Different portions of the source identifier will be returned depending on the privacy level of the install. Consider this when composing source identifiers for your impressions. Coarse conversion values are at a much lower granularity than fine conversion values. Consider this when ascribing meaning to their values. Conversion values can increase or decrease. And finally, when making changes to your server to process SKAdNetwork 4.0 postbacks, make them capable of parsing the new source identifiers and coarse conversion values. That wraps up our introduction to hierarchical IDs and conversion values, providing more data to advertisers while retaining our privacy protections. Let’s focus on another critical area of the attribution flow, conversions. SKAdNetwork today uses a single conversion model.

From the time of install, we update the conversion value to capture various user engagements. And after a certain amount of time elapses, we send the postback to the ad network. Let’s have a look at an example. Let’s use Food Truck. Food Truck puts you in control of your food truck. Customize, control, and create your own unique donut delivery experience. As Food Truck’s developer, I want to know the value of my advertising spend. As an example of this, when the user starts Food Truck, I will update the conversion value to mark this. Once they pick up their first batch for delivery, I update the conversion value again. Due to this batch of donuts requiring a certain amount of time to age, the user waits. Somewhere in the aging time, the conversion is sent in the form a postback to both the ad network and optionally to me. However, when the user finally delivers the donut, I will have no way of measuring this or any further user actions since the postback has already been sent. In other words, re-engagement is lost. This is what we are changing. We are moving from a single postback to three postbacks. The postbacks are tied to definite time windows and are sent at the end of those windows. Let’s revisit the earlier example. As before, the user starts Food Truck and proceeds to pick the first batch up for delivery. The first postback’s time window elapses and we send it out. The user delivers the donuts. Whereas earlier, this would not have been captured, now we find ourselves in the second postback’s time window. We update the conversion value to capture this. The second postback’s time window passes and we send it out. Using the tools in the app, the user creates a brand new donut recipe and then heads out again to deliver a fresh batch. The third window elapses and the third postback is sent out. There are more opportunities to measure the value of the conversion and to receive these measurements more often. A few points to note about multiple conversions: Only the first postback will get the fine conversion value. The additional postbacks can carry the coarse conversion value. Only the winner and developer will receive the additional postbacks. Next, let’s review SKAdNetwork attributions for ads on the web. We know that publisher apps show ads which open product pages in the App Store. The App Store, in turn, works with SKAdNetwork to attribute installs while providing the privacy protections that our users rely on. We want to extend the same privacy to ads shown on web pages. Let’s take a look at how this will work. The user taps on a link for an ad in Safari. Safari launches the App Store and lands on the product page for the advertised app. Two things happen here. The App Store fetches the ad impression from the ad network server, and the user installs the app. Following this, everything flows as it does today, and eventually, SKAdNetwork sends the postback out. Let’s have a look at how the link is composed. The href portion contains the App Store link for the app being advertised. The attributionDestination tells Apple where to fetch the signed ad impression from. And the attributionSourceNonce helps the ad network find the exact ad impression to send back.

Note that this link can be served on first party sites and in embedded cross site iframes. Let’s take a closer look at the URL construction. We extract the eTLD+1 component from the attribution destination. To this, we then add the well-known qualifier and two more path components. This gives us the URL to which we will make the HTTP POST request to get the signed impression. Note that the protocol and highlighted path components are fixed. You, the ad network, decide the value of the host component.

SKAdNetwork will make an HTTP POST request to the URL constructed as just discussed. The POST body will be JSON. You will recognize the source_nonce as being the same as in the original ad link. This value is what the ad network will use to identify the signed impression it wants to serve.

Let’s look at what we expect to receive from this POST request. This is a signed impression, ready for consumption by SKAdNetwork. Note the source domain field in the impression. This is the link analog of the source app ID in the app driven SKAdNetwork flow. Looking at how to get started using this new entry into the SKAdNetwork system, ad networks have to do the following: Create the uniquely identifiable parts of the link and the link itself. Expose an endpoint capable of serving signed impressions at the location constructed as we discussed before. Update your postback servers to parse and understand the new optional source domain field. For webpages that want to use the links to SKAdNetwork, simply embed the ad links provided to you by your ad network. That was an introduction to SKAdNetwork attribution for ads on the web. We are incredibly excited to see this feature being adopted across the wider advertising ecosystem. Next, we will go over how you can test your SKAdNetwork implementations. At a high level, SKAdNetwork deals with impressions and postbacks. From working with our developer community we know that on the side of impressions, signing and configuring have been points of friction. And with postbacks, receiving and validating them in a test-friendly manner has been an area for improvement. To help improve the developer experience with SKAdNetwork, we released SKAdNetwork testability changes in Xcode 13.3. This is available as a unit testing framework within StoreKitTest that a lot of you have already been using for testing various parts of your StoreKit implementations. Let’s take a look at validating an impression. You create and configure an instance of SKAdImpression. You supply the public key counterpart of the private key used to generate the signature, and then you call the validate method on the SKAdTestSession instance. This will validate your impression and throw an error if either the impression is misconfigured or the signature is invalid. The other main area to test is the receipt of postbacks. There are 2 steps here. Step 1: adding the test postback to your test session. You will create an instance of SKAdTestPostback and configure it with the values you want in your postback. Pay special note to the postback URL, since this is where your postback will be sent to. This can point to a remote or a local server. You will then add this to your test session using the setPostbacks method on SKAdTestSession. Step 2 is to actually send the postback out. All you need to do here is to call the flushPostbacks method on SKAdTestSession and your postback will be off on it’s way.

Note that SKAdTestSession will send your postback over the network to the server you specified when composing your postback. These are a few things coming to SKAdNetwork testability later this year: Support for the new source identifier field. Support for fine and coarse conversion values. Support for testing multiple conversions. And that was a quick look at the SKAdNetwork testability changes that were first available in Xcode 13.3. Today, we talked about hierarchical IDs and conversion values, aiming to get more data to you sooner. And then we talked about multiple conversions, allowing you to measure re-engagement over a longer period. Then we talked about link-driven attribution and how we are adding a bridge to SKAdNetwork, bringing with it the same privacy protections. And we finished by talking about SKAdNetwork testability in Xcode. And that wraps up our journey through SKAdNetwork 4.0. In closing, everything we build is driven by feedback from our amazing community of developers. It has been incredibly fulfilling and humbling to hear about your experiences building a privacy first ad experience for our users. Thank you. ♪ ♪