Private Click Measurement

Draft Community Group Report,

This version:
https://wicg.github.io/ad-click-attribution/index.html
Issue Tracking:
GitHub
Inline In Spec
Editors:
(Apple Inc.)
(Apple Inc.)

Abstract

This specification defines a privacy preserving way to attribute a conversion, such as a purchase or a sign-up, to a previous ad click.

Status of this document

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Introduction

This section is non-normative.

A popular business model for the web is to get attribution and payment for conversions, for instance purchases or sign-ups, which result from the click on an ad. Traditionally, such attribution has been facilitated by user identifying cookies sent in third-party HTTP requests to the click source. However, the same technology can be and has been used for privacy invasive cross-site tracking of users.

The technology described in this document is intended to allow for ad click attribution while disallowing arbitrary cross-site tracking.

1.1. Goals

1.2. Terminology

The four parties involved in this technology are:

The data consumed by the user agent to support ad click attribution is:

1.3. A High Level Scenario

A high level example of a scenario where the described technology is intended to come into play is this:

  1. The user makes an online search on search.example’s website.

  2. The user is shown an ad for a product and clicks it.

  3. The ad click source informs the user agent:

    • That it will want ad click attribution for this click.

    • What the intended ad click destination is.

    • What the attribution campaign id is.

  4. The user agent navigates the link and takes note that the user landed on the intended ad click destination.

  5. The user’s activity on the ad click destination leads to a conversion.

  6. A third-party HTTP request is made on the ad click destination website to ​https://search.example/.well-known/ad-click-attribution

  7. The user agent checks for pending ad click attributions for the ad click source/destination pair and if there’s a hit, makes or schedules an HTTP request to ​https://search.example/.well-known/ad-click-attribution with the ad click attribution data. One thing to consider here is whether there should be an option to send the attribution data to the ad click destination too.

2. Ad Click Source Link Format

The ad click source needs to be an anchor tag with the following properties:

<a adCampaignId="[6-bit ad campaign id]" adDestination="[ad click destination URL]">

Formally:

partial interface HTMLAnchorElement {
    [CEReactions=NotNeeded, Reflect] attribute DOMString adCampaignId;
    [CEReactions=NotNeeded, Reflect] attribute DOMString adDestination;
};

These attributes should be on HTMLHyperlinkElementUtils instead.

If an ad click on the above link triggers a top frame navigation that lands, possibly after HTTP redirects, on the [ad click destination eTLD+1], the user agent stores the request for ad click attribution as the triple { [ad click source eTLD+1], [ad click destination eTLD+1], [6-bit ad campaign id] }. If any of the conditions do not hold, such as the ad campaign id being larger than 6-bit, the request for ad click attribution is ignored.

3. Legacy Triggering of Ad Click Attribution

Triggering of attribution is what happens when there is a conversion.

Existing ad click attribution relies on third-party HTTP requests to the click source and these requests are typically the result of invisible image elements or "tracking pixels" placed in the DOM solely to fire HTTP GET requests. To allow for a smooth transition from these old pixel requests to the new Ad Click Attribution technology, we propose a server-side redirect to a well-known [WELL-KNOWN] location as a legacy triggering mechanism.

To make an existing pixel request an ad click attribution from the user agent, the top frame context of an ad click destination page needs to do the following:

  1. An HTTP GET request to the ad click source eTLD+1. This HTTP request may be the result of an HTTP redirect, such as searchUK.example HTTP 302 redirect to search.example. The use of HTTP GET is intentional in that existing “pixel requests” can be repurposed for this and in that the HTTP request should be idempotent.

  2. A secure HTTP GET redirect to ad click source eTLD+1/.well-known/ad-click-attribution/6-bit ad attribution data/optional 6-bit ad attribution priority. This ensures that the ad click source eTLD+1 is in control of who can trigger click attribution on its behalf and optionally what the priority of the attribution is. If the user agent gets such an HTTP request, it will check its stored requests for click attribution, and if there’s a match for ad click source eTLD+1, ad click destination eTLD+1, it will make or schedule a secure HTTP POST request to ad click source eTLD+1/.well-known/ad-click-attribution/6-bit ad attribution data/6-bit ad campaign id with the referer header set to ad click destination eTLD+1. The use of HTTP POST is intentional in that it differs from the HTTP GET redirect used to trigger the attribution and in that it is not expected to be idempotent. If any of the conditions do not hold, such as the ad attribution data being larger than 6-bit, the request for ad click attribution is ignored. We may have to add a nonce to the HTTP POST request to prohibit double counting in cases where the user agent decides to retry the request.

If there are multiple ad click attribution requests for the same « [ad click source eTLD+1], [ad click destination eTLD+1] » pair, the one with the highest Ad Attribution Priority will be the one sent and the rest discarded.

This needs to be reworked to monkeypatch HTML’s "follows a hyperlink" algorithm.

4. Modern Triggering of Ad Click Attribution

We envision a JavaScript API that is called on an ad click destination page as a modern means to trigger attribution at a conversion. This API call removes the necessity for third-party "pixels" which is great for ad click sources who do not want to be third party resources.

5. Privacy Considerations

The total entropy in ad click attribution HTTP requests is 12 bits (6+6), which means 4096 unique values can be managed for each pair of ad click source and ad click destination.

With no other means of cross-site tracking, neither the ad click source nor the ad click destination will know whether the user has clicked an associated ad or not when a conversion happens. This restricts the entropy under control to 6 bits at any moment.

Even if the ad click source and/or the ad click destination were to be in control of both pieces of 6-bit data, the total is 12 bits or 4096 unique values.

We believe these restrictions avoid general cross-site tracking while still providing useful ad click attribution at web scale.

In the interest of user privacy, user agents are encouraged to deploy the following restrictions to when and how they make secure HTTP POST requests to [ad click source eTLD+1]/.well-known/ad-click-attribution/[6-bit ad attribution data]/[6-bit ad campaign id]:

6. Performance Considerations

The user agent may want to limit the amount of stored ad click attribution data. Limitations can be set per ad click source, per ad click destination, and on the total amount of ad click attribution data.

7. Related Work

The Web Advertising Business Group has related work that started in January 2019. It similarly uses a .well-known path with no cookies.
https://github.com/w3c/web-advertising/blob/master/admetrics.md

Brave publised a security and privacy model for ad confirmations in March 2019.
https://github.com/brave/brave-browser/wiki/Security-and-privacy-model-for-ad-confirmations

Google Chrome published an explainer document on May 22, 2019, for a very similar technology. They cross-reference this spec in its earlier form on the WebKit wiki.
https://github.com/csharrison/conversion-measurement-api

8. Acknowledgements

Thanks to Maciej Stachowiak, Brent Fulgham, Erik Neuenschwander, Mark Xue, Steven Englehardt, and Ehsan Akghari, for their feedback on this proposal.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[WebIDL]
Boris Zbarsky. Web IDL. 15 December 2016. ED. URL: https://heycam.github.io/webidl/
[WELL-KNOWN]
M. Nottingham; E. Hammer-Lahav. Defining Well-Known Uniform Resource Identifiers (URIs). April 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5785

IDL Index

partial interface HTMLAnchorElement {
    [CEReactions=NotNeeded, Reflect] attribute DOMString adCampaignId;
    [CEReactions=NotNeeded, Reflect] attribute DOMString adDestination;
};

Issues Index

These attributes should be on HTMLHyperlinkElementUtils instead.
This needs to be reworked to monkeypatch HTML’s "follows a hyperlink" algorithm.