A more private way to measure ad conversions

(lively music) - Hey everyone. I’m Charlie Harrison, a software engineer working on the Privacy Sandbox. The Privacy Sandbox is a set of proposals to satisfy third-party cookie use cases without third-party cookies or other tracking mechanisms. I’m here to talk about one new API we’re developing to enable conversion attribution for ads without the need for third-party cookies. So what is conversion attribution? This is all about measuring which ads leads to things like purchases or other valuable actions on an advertiser’s site. This is effectively measuring the efficacy of online advertisement and it can answer questions like how well is a particular ad campaign performing? Or is the campaign a good return on investment for advertisers? These are questions advertisers and Adtech companies need to answer and we know this information is critical for a functioning ads ecosystem that helps fund the open web.

01:02 - Without it, advertisers and publishers are completely in the dark and it could even lead to perverse incentives where ads optimized for clicks, rather than actually providing value to the people who click on them. The Privacy Sandbox is a project about making the web more private by default while still supporting critical use cases like conversion measurement and we’re committed to making this use case possible. However, before diving into the technical details of the API, it’s useful to recap how this is done today using third-party cookies. Conversion attribution at its core involves connecting two events. An ad being served to a person and a future event when that person later converts or buys something. With cookies, this is easy.

01:47 - As long as the same party observes the ads served and the conversion, they can use a cookie with a unique ID to link the two events together on their server. In this example, the Adtech company can use the cookie to see that the very same person that saw the ad on the news site later purchased the shoes on the shoe merchant’s site. As Mod discussed in her talk, we’re working to improve the status quo here. The information cookies provide is so powerful that it can be used to track a person as they browse across many website. In the example here, the Adtech platform that uses the cookie learns detailed information about both the ad event and the conversion event joined together.

02:28 - That’s the kind of data that can be used to build a profile based on a person’s browsing history. In particular, we risk linking auxiliary data about each of these events. Let’s say on news.example, I use one email address to log in and to purchase shoes, I use a different email and also share my shipping address. With the power of a cross-site identifier, it is possible to link up all this information to build a profile of me online. Now, how could we improve things here and allow for this important use case in a more privacy-preserving way? The biggest change we can leverage in a new browser API to preserve privacy is to perform attribution between the ad click and the purchase all on your device, locally within the browser as opposed to in a server using a cookie.

03:16 - Because the browser has control over the linked data it will report, it can apply a bunch of techniques to preserve privacy. Firstly, instead of the advertiser learning what conversion happened after an ad click, we can limit the advertiser to learning only a little bit of information about that conversion. Unlike with cookies where you can learn an ad ID, alongside an associated purchase ID, in our API, we drastically limit the amount of information you can learn about a purchase, the conversion data, to only a small enum that describes it. Like what type of conversion it is or maybe a broad product category. This protects, by default, your identity on the advertiser site from being revealed to the context that served you an ad.

04:00 - And avoids the problem cookies have where arbitrary information can be linked. Secondly, the browser can decide to sometimes randomize that little bit of conversion information. The goal here isn’t to mislead the advertiser. In fact, we’ll tell them exactly how often we plan to randomize but they won’t know exactly which conversion reports are accurate and which had some noise added by a random number generator. This will let advertisers see the big picture without them being sure about any one particular action any person did.

04:33 - We understand analyzing data with this kind of noise in it can be challenging, so we have uploaded a script on our repo, which illustrates a technique to correct noisy data. Third, we add a delay before sending out information in conversion reports. This helps us further disassociate information about the ad click from information about the conversion or even what day a conversion occurred. All of these mitigations help us provide conversion measurement as a capability of the web platform via a new purpose-built API, designed to provide the right amount of information while ensuring robust privacy guarantees on a technical level. Note that currently the API we’ve built only supports attributing conversions to clicks and not yet views but this is an enhancement we’re working on supporting.

05:21 - Here’s a diagram showing the overall flow of the API. The API allows the ad on the publisher’s site to register its impression with the browser and for the conversions to be registered on the advertiser’s site. All this information gets stored internally by the browser and sent in a report at a later time linked together. Here’s some code pointers for how to enable impression and conversion registration. Impression registration involves adding a few new attributes to the anchor element, leading to the ad’s landing page.

05:53 - And conversions are registered by responding to HTTP requests with a redirect to a special URL the browser recognizes. We’ll go over these in more detail in a quick demo. Remember, the two key pieces needed to use the API are configuring ad creatives and conversions, such that the relevant data can be registered and stored by the browser. Let’s start on a publisher page, which embeds an ad iframe. Within the iframe, there’s an anchor element that controls navigating to the advertiser’s landing page.

06:26 - To configure this ad for measurement, this element needs a few new attributes. The impression data specifies an identifier for this ad that will show up later in reports. The conversion destination specifies the intended destination of the resulting navigation from clicking the link. The reporting origin specifies which origin should receive the report in the result of a future conversion. Once someone clicks on an ad with these attributes specified, event data is stored in the browser and eligible for attribution.

06:59 - For debugging purposes, these ad clicks can be seen in a special internal page, built into Chrome at chrome://conversion-internals. Ultimately, at some point in the future, there will be dedicated developer tooling but for now, this Chrome internals page gives us what we need. It displays all the information from the API that is stored in the browser. Now, let’s convert on the advertiser’s site. We can check out as a guest. Clicking on the Buy Now button takes us to the order confirmation page.

07:30 - This page includes a hidden single pixel image from the reportingorigin. In other words, once our purchase is complete, a request is made to the reporting origin, confirming that a conversion occurred. To signal a conversion, the reporting origin servers need to respond to this request with an HTTP redirect to a special URL recognized by the browser. We can see this in the network panel if we look at the request for this pixel. This signals to the browser internally and any impressions targeting this advertiser’s site are marked as converted with the conversion data set to two.

08:07 - Just like for the ad click, you can view the conversion in the conversion-internals page too. Here you can see all the information that will end up in the report. As you can see, these quick conversions that occur right after the add click will be delayed two days from the click. For debugging purposes, however, waiting this long is pretty inconvenient. We built a mechanism within the internals page to send reports manually. Let’s do that.

08:34 - At this point, Chrome has sent reports via an HTTP request to the Adtech servers. Let’s navigate to a page that displays all the received reports. Here we can see all the information embedded in the report, the impression data, the conversion data, and some browser-provided attribution credit. Essentially whether the ad was the last clicked on or not. And there you have it. At this point, the advertising platform can say that the ad associated with the given click ID led to a purchase.

09:02 - Maybe they’ll use this information to show more ads on the publisher’s site. If you’re interested in trying this API, there’s a few things you can do. First, you can test this out locally in Chrome today by setting a few Chrome flags listed here. The demo shown here should also be publicly available along with the open source code on GitHub. If you want to run this in a production experiment, you can register for an Origin Trial.

09:28 - The conversion measurement trial also supports our new third-party origin trials. Please try out the API and give feedback. We’d love to hear how the API works to enable your measurement needs, using attribution on your device without the need for cookies or other tracking techniques and we welcome engagement on issues in our GitHub repo. For more information and documentation, take a look at our web.dev article and check out our GitHub repo for future enhancements we’re working on, like support for view-through conversions and aggregate measurement. Thanks very much. (lively music) .