Two Uncorrelated Requests, Then Locally-Executed Decision On Victory or "TURTLEDOVE" is a proposal put forth by the Google Chrome team as part of their Privacy Sandbox initiative.
The proposal lays out a vision for how advertisers can still conduct retargeting and behaviorally-targeted campaigns in a privacy-compliant way through the use of a new web browser API and on-device auction.
Behaviorally targeted or retargeting campaigns in this context mean targeting a user based on any specific web page they visited or action they performed. This type of advertising on desktop and mobile web is currently conducted with the help of third-party cookies and cookie syncing.
Advertisers that track you across the web understand your browsing habits and specific actions you perform on partner sites. Users are placed into “custom audiences” or “audience segments” based on either their interests (user visits sports sites often) or specific actions (user placed a mountain bike in their cart but did not check out).
Google refers to these groups of users in the TURTLEDOVE proposal as “interest groups”.
TURTLEDOVE is one of several efforts to preserve the tools that advertisers have grown accustomed to, in a privacy-compliant manner.
The core tenets of TURTLEDOVE are that:
- The browser would hold behavioral data
- An advertiser could use this data for targeting, but cannot combine it with any data collected while serving ads to the user
- Ad networks cannot store any interest data about a user
How does TURTLEDOVE work?
The proposed API flow is illustrated in the diagrams below, with a detailed breakdown of each step in the following section.
1. Browser (user) visits bikeshop.com and views mountain bikes
2. Bikeshop.com adds browser to ‘mountain-bikers’ interest group and permissions Ad Network to read this interest group
3. Browser notices that user visits websites displaying Ad Network ads often, so it issues a request for ads targeted at the ‘mountain-bikers’ interest group
4. Response returned from Ad Network and stored in the browser for use at a later time. Response includes ad and decision logic that will be used in an on-device auction
5. At some point in the future, the browser visits blogsite.com and an Ad Network script on the page requests a contextually-targeted ad. Ad Network returns an ad that includes a request for an on-device auction
6. Browser runs decision logic script to decide on the winner between the contextual ad and the previously stored interest group ad and displays the winning ad
Let’s take a closer look at each step in the process.
1. Browser (user) visits bikeshop.com and views mountain bikes
When users browse through online stores, they are showing intent on possibly making a purchase.
Understanding intent on a user level is an extremely important aspect of digital advertising that allows it to perform much more effectively than traditional media like print or linear TV advertising. Advertising traditionally would require brands to plaster their message across content that may or may not align with their target market.
Google’s own research led the company to conclude that users appreciate personalized advertising over non-personalized advertising. Google allowed users to click an “X” icon to close a display ad in their study and found that users are 21% more likely to close a non-personalized ad.
2. Bikeshop.com adds browser to ‘mountain-bikers’ interest group and permissions Ad Network to read this interest group
Through a new API, bikeshop.com would request that the browser add a particular user to an interest group that they manually created by a predetermined set of actions.
Since the user is browsing mountain bikes, bikeshop.com can reasonably assume they are interested in mountain bikes, so they add them to the ‘mountain-bikers’ interest group.
An ad tech partner with permission to execute JavaScript on bikeshop.com would then make a call to the browser to add the user to this interest group. I have modified Google’s example code below to reflect our example:
const myGroup = {'owner': 'www.bikeshop.com',
'name': 'mountain-bikers',
'readers': [adnetwork.com',
'adpartner.com']
};
navigator.joinAdInterestGroup(myGroup, 2592000);The API call above would add the user to the ‘mountain-bikers’ interest group for 30 days (2,592,000 seconds) and allows Ad Network's domain (adnetwork.com) permission to read the interest-group stored in the browser.
3. Browser notices that user visits websites displaying Ad Network ads often, so it issues a request for ads targeted at the ‘mountain-bikers’ interest group
As the user browses the web the browser would notice that this user comes across Ad Network’s ads regularly and that the user was added to an interest group allowed to be read by Ad Network’s domain, adnetwork.com.
The browser would then decide to make a call to Ad Network, requesting an ad for the ‘mountain-bikers’ interest group:
GET https://adnetwork.com/.well-known/fetch-ads?interest_group=www.bikeshop.com_mountain-bikers4. Response returned from Ad Network and stored in the browser for use at a later time. Response includes ad and decision logic that will be used in an on-device auction
Ad Network would then return a response with a ‘mountain-bikers’ interest group ad and relevant metadata.
[{'group-owner': 'www.bikeshop.com',
'group-name': 'mountain-bikers',
'ad-cbor-url': 'https://adnetwork.com/ads/ad-56789.wbn',
'cache-lifetime-secs': 21600,
'max-times-per-minute': 1,
'max-times-per-hour': 6,
'auction-signals': {'atf_value': 250, 'btf_value': 25},
'decision-logic-url': 'https://adnetwork.com/js/on-device-bid.js'}]The browser would store the response above and reference the returned values when it conducts an on-device auction at a later point in time (see step 6). The response includes the ad in a web bundle (.wbn) and this particular example instructs the browser to cache it for six hours and to only show it a maximum of one time per minute or six times in an hour.
5. At some point in the future, the browser visits blogsite.com and an Ad Network script on the page requests a contextually-targeted ad. Ad Network returns an ad that includes a request for an on-device auction
A script on blogsite.com will send out an ad request to Ad Network for a contextually-targeted ad. This request can include information about the current request, like the page URL, ad location, or ad size. Ad Network returns a contextual ad but this response can also include a request for the browser to conduct an on-device auction between the contextal ad and an interest group ad (if available).
const contextualBid = 107;
const metadata = {'network': 'first-ad-network.com',
'auction-signals': {'is_above_the_fold': true}};
const rendered = navigator.renderInterestGroupAd(contextualBid, metadata);
if (!rendered) {
...render the contextually-targeted ad...
}The response includes the contextual ad bid and instrucitons to run an auction and to render the winning ad.
6. Browser runs decision logic script to decide on the winner between the contextual ad and the previously stored interest group ad and displays the winning ad
This would be the 'decision-logic-url’ returned in the original interest group ad response that was stored by the browser. Calling this URL could load a script like the below:
function(adSignals, contextualSignals) {
return contextualSignals.is_above_the_fold ?
adSignals.atf_value : adSignals.btf_value;
}The contextual response from the previous step included a signal that the ad location is above the fold, which would trigger the previously-stored decision logic to return the above the fold bid value (“atf_value”) of 250 and to store it in the metadata variable.
The 'contextualBid" and the "atf_value" are then compared to decide the winning ad, which is the interest group ad since 250 > 107. The result is a mountain bike ad displayed on blogsite.com.
The above process would present a substantial change to advertising on the web, especially if they are combined with other privacy techniques Google offers further in the proposal.
Willful IP Blindness
The IP address of a user can be used as a backdoor identifier to track in the absence of a cookie or persistent identifier. Google recognizes this and proposes "willful IP blindness" as a potential solution.
Willful IP blindness could take the form of an HTTP header that a requesting sever could implement to signal that they mask the IP address to the application layer of the service it hosts. This would prevent an ad serving application from obtaining the user's actual IP address.
Without an IP address, an ad tech company could not correlate a contextual ad request with an interest group ad request, making it impossible to tie any collected data about the two requests together.
The lack of an IP address would also render geo-ip services completely useless to an ad platform, effectively killing geo-targeted campaigns. Publishers would need to pass geo-information in the ad request to enable any type of geo-targeting if an ad platform participated in willful IP blindness.
Opaque iframes
If an interest group ad wins the auction, it will need to render without access to the page to prevent any ad partner from deriving any identifying information. Google proposes an "opaque iframe" designed to limit the technical processes of communicating with the page.
Forcing an ad to render in an opaque iframe could disallow postMessage, prevent crawling the window tree using window.parent or window.frames[] or any other method of leaking information.
The opaque iframe would also prevent any network activity, rendering the ad completely locally via the previously passed web bundle. This is to prevent a timing attack that could join the contextual request with the interest group request.
TURTLEDOVE
The above process is a detailed look at the paradigm established by the two main concepts that make up the TURTLEDOVE acronym:
Two Uncorrelated Requests
A contextual ad request and interest group ad request are sent at separate points in time to prevent correlating them. This prevents any ad partner from enriching any type of a contextual ad request with interest group information or vice versa.
Then Locally-Executed Decision On Victory
The auction is executed client-side in order to maintain the separation of requests. If the auction occurred server-side, any ad partner conducting the auction could understand that the two requests originated from the same user and tie the data together to create an enriched picture of the user.
The local auction and render would also prevent an ad partner from associating interest group membership with a user profile if publishers are sending a PPID (publisher-provided ID) tied to a login with the contextual ad request. Associating browser-collected behavioral data (interest group) with a persistent identifier such as a PPID would be a violation of the core tenets of TURTLEDOVE.
But why, though?
The entire TURTLEDOVE process is a complete reimagining of how advertising should work on desktop and mobile web. It is not a simple process and would require massive change across the digital advertising ecosystem.
Rapidly evolving user expectations for privacy are forcing Google to push for innovation. With Apple positioning itself as the bastion of user privacy and Mozilla's Firefox dropping third-party cookies without a second-thought, Google is scrambling to find a way to retain users and please advertisers.
TURTLEDOVE is merely a proposal and has to face close and careful scrutiny from all the companies that could be forced to implement it. The loss of third-party cookies is not only an existential threat to companies relying on behaviorally-targeted ads on the web, but also for the open web as we know it.
Advertisers will spend their budgets on whatever channels are most effective. Walled Gardens like Facebook already present an attractive alternative with their nearly universal reach and data-rich logged in user data. If advertisers find that TURTLEDOVE or whatever equivalent cannot reach parity with walled gardens, then expect the open web to face an existential crisis of its own.