Meet privacy-preserving ad attribution

♪ ♪ Hi. I'm Kate. I'm an engineer on the Safari and WebKit team, and today I'm gonna be telling you about Privacy-Preserving Ad Attribution. I know a lot of you watching today's session are probably already experts on the history of ad attribution, but to make sure everyone's on the same page, I'll start with some background on cookies, advertising, and tracking.

Then, I'll introduce Private Click Measurement, a tool that allows you to privately measure ad campaigns across websites. Then I'll show you how you can expand PCM even more, to measure ad campaigns that start in apps and convert on the web.

Finally, I'll talk about improvements in privacy-preserving app-to-App Store ad attribution using SKAdNetwork.

So, let's start with the history of cookies and their role in web advertising. Cookies are useful to businesses because they provide support for something called ad attribution. Ad attribution is the process of linking an ad-related action, like a click, with a desired outcome, like a purchase. You'll also hear me refer to those desired outcomes as "conversions." This concept may seem a little abstract in words, so let's walk through an example. I happen to really like longboarding. Say I tap an ad for a longboard on my favorite search site, searchforlongboard.biz. searchforlongboard.biz can store something called a cookie in the browser. Cookies are useful little bits of text that help sites remember data about your previous visits, like products in your shopping cart.

The link on searchforlongboard.biz might navigate me to a new site, longboardshop.biz, where I add the longboard to my cart. searchforlongboard.biz can reference the cookie that it stored earlier to link my purchase with the initial ad tap I made. This is an example of ad attribution. The cookie data allows searchforlongboard.biz to measure the effectiveness of this particular ad campaign, which is really useful for its business. But what if I hadn't made an initial ad tap earlier? searchforlongboard.biz would still get the cookie data about me, which can include clicks I've made, sites I've visited, time I've spent on a page, and other detailed information about my web history and behavior. Companies like searchforlongboard.biz can use this information to follow users across sites and build detailed profiles for advertisers, all without a user's consent. We call this cross-site tracking. Most users don't expect to have an invasive experience on the web, where their interests, behavior, and personal information is stored and tracked. Tracking can break trust and create a misalignment between users and businesses. And now, more and more users have started turning to mechanisms, like ad and content blockers to limit tracking on the sites they use. From a user perspective, content blockers are great for preventing tracking, but can often lead to compatibility issues. Additionally, since content blockers block all ads, there's clearly no possibility for any sort of ad attribution. The disconnect between users and businesses around ads and tracking is hugely damaging to the web experience, and we wanted to find ways to protect user privacy while maintaining web compatibility.

So, in 2017, Apple built Intelligent Tracking Prevention, or ITP, which identifies trackers and protects users against this sort of profiling on the web, without blocking ads. With ITP, I might tap the same ad on searchforlongboard.biz, which stores a first-party cookie and navigates me to longboardshop.biz, where I add the longboard to my cart again. But now, ITP prevents cookies and other website data from being sent to third parties, like searchforlongboard.biz. So, they may know that I tapped an ad for longboards, but they won't be able to track my behavior on any other sites. ITP specifically mitigates cross-site tracking in the browser, but tracking is not unique to the web. The Identifier For Advertisers, or IDFA, has long been used to perform similar profiling of iOS users across apps.

In 2020, Apple launched SKAdNetwork, a part of the StoreKit framework. It collects and reports data about ads that lead to app installs, and it was designed to give Ad Networks privacy-preserving techniques for ad attribution. I'll talk later on about improvements to SKAdNetwork over the last year. Tracking infringes on a user's privacy without giving them the ability to identify, understand, or consent to what's being shared about them. And we aren't the only ones thinking about this. Regulations like CCPA and GDPR are requiring websites to inform their users about how their data is being used. Other browsers like Brave and Firefox are also shipping with built-in tracking protections. It's becoming clear that business models that rely on tracking aren't sustainable. We recognize the importance of providing a more private way to measure ads to help you thrive in this changing ecosystem. So the rest of our session will focus on some of the exciting new solutions we've implemented to help you measure ads with privacy. The first case I'm gonna cover is web-to-web ad attribution, meaning both the initial click or tap and the final conversion event both occur in the browser.

This year, we're so excited to introduce Private Click Measurement, or PCM, which brings privacy-preserving ad attribution to the web.

PCM is a proposed standard in the W3C Privacy Community Group. To be on track to become a full standard, it needs an implementation from another browser. We're working with other browsers to standardize PCM across the web.

PCM is an entirely on-device ad-attribution reporting mechanism. Limited entropy in the reports prevents a site from being able to identify a specific user. And when using PCM, the user isn't being tracked across sites. This means App Tracking Transparency requirements don't apply for uses of PCM.

Currently, PCM web-to-web and app-to-web are fully supported in Safari. So, throughout the rest of this presentation, whenever I refer to "the browser," I mean Safari. We are working towards adding support for other browsers as well, both those that use the WebKit engine and those that don't. Let's go back to our original longboard example to show how PCM works.

Again, I tap an ad for a longboard on searchforlongboard.biz. With PCM, this link specifies two additional pieces of information: a Source ID, which is 8 bits of entropy that you can use to specify the ad campaign, and the site that the ad will convert on, called the attribution destination site. These are stored on-device in the browser. The ad link then navigates me to longboardshop.biz. When I tap Add to Cart, longboardshop.biz can specify information about the conversion event using an additional value called the trigger data. The trigger data is 4 bits, and it might specify an action like an Add to Cart or a purchase. This is stored on-device, in the browser, as well.

So, what about reporting? Note that only the browser has both the click-side and the conversion-side information. So, if the conversion matches a stored click, the browser can format this information into a report that's useful to the advertiser, while preventing any identification of a user across sites.

The browser then schedules the report to be sent to both the source and the destination sites, randomly 24 to 48 hours later. The random delay prevents the reports from providing any time-related data that might link ad-clicks and conversions together to identify someone. As of iOS 15 and macOS 12, these reports also have IP address protection, which is crucial to prevent fingerprinting. You can find out more about IP address protection in Apple's privacy pillars in focus WWDC session.

OK, so how do you actually specify PCM data when running an ad campaign? On the source site, where the ad is being displayed, you can specify PCM data using link attributes. Here we see the Lemon Yellow Longboard campaign has an identifier 55, and converts on longboardshop.biz.

On the destination site, you can trigger an attribution event by making an HTTP GET request to the source site, potentially specifying data about the conversion event. The source site gets this request, then needs to redirect it to this well-known location. Adding the longboard to my cart has a trigger data value of 15. And if you later on wanted to override this conversion with a more important one, like a purchase, you might specify a higher 6-bit priority.

This design was intended to support legacy pixels to make adoption easy.

The last step is reporting. The report will be sent in a JSON format to this well-known location. The report provides the data that links an ad click with a conversion, but you can see that there's no identifying information about the user included. In this case, what you learn is that someone, somewhere added a lemon yellow longboard to their cart on longboardshop.biz. You can use this information to measure ad campaigns without needing to track specific users. And those are the basics for implementing Private Click Measurement to measure web-to-web ad campaigns. Now, I'll show you how you can expand PCM even more, to use in your apps. We've heard lots of feedback about the importance of measuring ad taps that start in apps and convert on the web. We realized how crucial it is that we bridge this gap, so we're excited to also be introducing PCM app-to-web attribution. Let's go through an example of how this works. Now, I open Social App, which is what I use to catch up with all of my longboarding friends. And I tap an ad for a longboard. The Source ID and destination site are stored on-device. Then, I'm navigated to longboardshop.biz in Safari. The conversion side is exactly the same as the web-to-web case. When I tap Add to Cart, longboardshop.biz can trigger a conversion with the trigger data, which is stored in the browser.

The browser combines the information into a report, then sends it to both the app reporting site and the destination site on a random 24 to 48 hour delay.

To use PCM app-to-web attribution, you should add an attribution report destination site to the app's info.plist, with the key NSAdvertising- AttributionReportEndpoint. This step is crucial, because we take the registrable domain from the report destination URL to form a well-known path for sending reports.

This well-known path is exactly the same as the web-to-web case. For PCM app-to-web, you'll also need to make some changes in your app's code. We know that, in order to measure campaigns effectively, it's important to know that an ad tap has actually occurred. So, we've added a new data structure called a UIEventAttributionView. When you display an ad in your app, you'll create a new UIEventAttributionView. Then, you'll place it over your ad. The UIEventAttributionView verifies that a user gesture has happened before reporting an attribution, so that you know that the reported data is accurate. When the user taps the ad, you then need to create a new data structure called a UIEventAttribution, which is submitted when an app opens a URL to an external website. This gets populated with four things: the source identifier, which identifies the ad campaign, in this case, for a lemon yellow longboard; the destinationURL, where the ad will be converted; the sourceDescription, a description of the content that was tapped; and the purchaser, a description of the buyer of the content. If you're using a UIScene-based life cycle management, you'll create a OpenExternalURLOptions object. Then, you should assign your event attribution object to the corresponding property and call the open function. If you're using UIApplication-based life cycle management, adding support for app-to-web campaigns is a bit different. You'll need to create a dictionary that contains the eventAttribution object. Then you can call the open function with the dictionary as the value for the options parameter. And that's pretty much it for implementing app-to-web attribution.

Before we move on to SKAdNetwork improvements, I want to touch briefly on PCM fraud prevention. Since PCM reports carry no identifying information, there's no inherent way for the server to know if a conversion report is trustworthy. So, PCM uses cryptographic signatures to prevent fraud. To explain signatures, I'm going to use a popular envelope analogy. It works like this. When the ad tap occurs on searchforlongboard.biz, the browser fetches searchforlongboard's public key. It then creates a message that searchforlongboard will validate later on. However, since we don't want searchforlongboard.biz to be able to link a click and conversion together, we'll hide this message. Think of it like putting the message in an envelope. The browser will then send the hidden message to searchforlongboard.biz. They sign the hidden message using an RSA blind signature scheme and send it back. You can think of this like carbon copy paper. The signature on the envelope will also apply to the message. So, when the browser removes the message from the envelope, it will have searchforlongboard's signature on it. When the attribution occurs, the browser sends the attribution report with searchforlongboard's signature. Now, the source and destination site can validate that the click was deemed trustworthy when it happened, using searchforlongboard's public key. Since searchforlongboard.biz never saw the original message, it can't link it with the ad click. So, that's it on fraud prevention. And I also want to talk about testing because we know that it's important for you all to be able to have a simple, fast, and easy way to test and debug. WebKit has an experimental feature called Private Click Measurement Debug Mode. You'll find it in the Safari Develop menu for macOS, under Experimental Features.

On iOS, you can turn on Debug Mode in the WebKit Experimental Features menu.

Debug Mode has enhanced Web Inspector logging, and reports will go out every 10 seconds, as opposed to 24 to 48 hours later.

That's it for using PCM to support your web-to-web and app-to-web campaigns.

I now want to pivot to talk about how you can improve your app-to-App Store ad campaigns, with recent updates to SKAdNetwork. First, let's start with a brief overview of SKAdNetwork up to this point. Note that the basics of SKAdNetwork were covered at WWDC in 2020, so it would be useful to reference those presentations for a more detailed overview of how it works. Essentially, SKAdNetwork involves three parties: ad networks, publisher apps, and advertised apps. Let's say I'm using Social App, and I'm served an ad for Longboard App by SocialAdNet. In SKAdNetwork terms, SocialAdNet is the AdNetwork, Social App is the publisher app, and Longboard App is the advertised app. If I tap the ad for Longboard App, this generates a report with the Ad network ID, Publisher app ID, Campaign ID, timestamp, and additional information for fraud prevention. This information is stored on-device, in the App Store. Let's say the ad for Longboard App takes me to the App Store, where I install and launch Longboard App. Now Longboard App calls one of two APIs offered by StoreKit: RegisterApp- ForAdNetworkAttribution or updateConversionValue. Both will trigger the SKAdNetwork reporting, and you can check out the documentation for more information on when to use which call. StoreKit will combine the useful information into a report and send it to the ad network. Now that we have some background on SKAdNetwork, I'll talk about some improvements we've made over the last year. Since we launched SKAdNetwork, we've been listening to your feedback and making changes. Each version introduced something to help you better meet your needs with ad attribution, whether that be more security, more ways to measure ads, or more attribution reporting. In this section, we'll talk about Signing Key improvements, support for View-Through Attribution, Multiple Postback and IP address Protection, and Postback to Developer. Also, note the minimum iOS version needed to utilize each new feature. First, in version 2.1, Apple introduced a stronger and more secure 256-bit public key. You should update the Apple public key you're using to validate postbacks in order to utilize this.

Detailed steps on how to verify Apple's signature can be found in the link to SKAdNetwork's documentation associated with this session.

Next, Version 2.2 added support for view-through ad campaigns. This involves creating a new SKAdImpression instance, generating a signature, and calling two new APIs: startImpression, when you start to present your custom ad to the user, and endImpression, when you finish presenting the ad. With view-through attribution, StoreKit also introduced a new parameter called Fidelity type. StoreKit-rendered click-through ads have a fidelity type of 1, while custom view-through ads have a fidelity type of 0. This gives view-through impressions a lower priority than click-through ones, and a view-through postback will only be reported if there's no competing impression with a higher fidelity. iOS 14.6 introduced multiple postback and IP address protection. Now, SKAdNetwork supports sending reports to a winner network and up to five runner-ups. The winning network is determined by the last impression that occurred before the conversion.

When a report is generated, the winner has the possibility to receive the crowd anonymity controlled values, like the sourceApp and conversion value. Runner-ups will not get this information. Also new in SKAdNetwork is the postback to developer, where the winning postback gets reported to the advertised app.

In order to utilize the postback-to-developer feature, your app will have to specify the developer reporting site in your Info.plist. This uses the same NSAdvertising- AttributionReportEndpoint key necessary for PCM app-to-web reporting.

Just like with PCM, the registrable domain from the URL specified in the plist will be used to form the well-known location where the postbacks will be sent.

Now, I'll give some best practices for successfully testing and debugging new SKAdNetwork technologies. First, a reminder that the nonce for each impression should be unique. This is important for fraud prevention and maintaining the integrity of your reports. Next, the order of the arguments matters when creating the signature. So, if you're encountering issues at this step, you can check out the documentation to make sure your argument order is correct. Next, for testing postbacks, you should always use a development-signed source app with a source app ID of 0. And lastly, a reminder that a testing profile will speed up postback transmission time and is available to download from the link associated with this session. So, that's it for SKAdNetwork improvements, and that concludes all of this year's updates for privacy-preserving ad attribution.

As you can see, there's a lot of features we've implemented and improved over the last year to help you adopt private ad attribution. So let's review what I covered today.

First, I introduced PCM, an ad-attribution mechanism that brings private ad measuring to the web. PCM supports not only ad campaigns measured entirely on the web, but also campaigns that start in apps and convert on the web.

I also went over all the updates that have gone into SKAdNetwork over the last year, that give you an even more private, secure, and useful way to measure app installs.

And lastly, I want to reiterate that so much of the design and improvements of these technologies has come from hearing from you all as developers. So, thanks. And we ask that you keep providing feedback. We welcome any thoughts on the PCM proposed standard, which can be found on the W3C Privacy Community Group GitHub page.

If you came into this with the idea that privacy and advertising don't mix, I hope this session helped you see a future where they actually align. Thanks for watching, and I hope you enjoy the rest of WWDC. [upbeat music]