The clock is ticking on Google’s deadline for ending support for third-party cookies within its Chrome browser. Many in the industry have been looking to Google’s ‘Privacy Sandbox’, a project where Google engineers are developing new application programming interfaces (APIs) to replace third-party cookies, for alternatives. But reports have emerged of frustrations in the industry over a lack of progress on sandbox proposals.
However one of the sandbox proposals, known as ‘TURTLEDOVE’, has seen some recent progress. Engineer Michał Jagielski and the team at Polish ad tech company RTB House has released a working simulation of TURTLEDOVE, demonstrating how the standard might work in practice.
The TURTLEDOVE API proposed within the sandbox is designed specifically to allow retargeting (where advertisers can target users who’ve previously seen their ads or visited their website) without the use of third-party cookies. It does this by assigning users to different interest groups, which are stored within the user’s browser.
Michael Kleber, one of the Google software engineers working on TURTLEDOVE, explained on Github the two steps this involves (the language Kleber uses has been simplified for our purposes):
- The browser sends two uncorrelated ad requests: (a) a contextual ad request, which is allowed to contain the URL of the page where the ad will appear, and; (b) a separate request indicating an advertiser-identified interest, but which cannot be tied to any browsing behaviour, and which can happen at a time other than while loading the web page where the ad will appear.
- The ad network must make the final decision when it comes to deciding which ad “wins” via code that executes locally within the browser, and which cannot send information outside of that device. So the ad network can then run an “on-device auction” to choose from the ads that have been sent to the device.
The framework is designed to preserve privacy by ensuring all behavioural data about an individual is stored on their browser and not shared with third-parties, rather than being stored in a remote database.
Jagielski’s simulation of TURTLEDOVE (which you can try out for yourself here) is not a working prototype of the TURTLEDOVE standard. The TURTLEDOVE API would store user data and execute auctions within the browser. Since only Google can modify the Chrome browser, Jagielski instead created a TURTLEDOVE server to act as a stand-in.
But nonetheless, Jagielski’s simulation demonstrates how re-targeting could work in the future via the TURTLEDOVE API. Jagielski has created several example websites to act as publishers, and others to act as ecommerce sites, or other site where advertisers might collect user data. Using these fake websites, we can recreate what a customer’s journey might look like, and see how their data is collected and used for retargeting.
How the simulation works
To start with, a user has no data associated with them. They then visit a publisher, ‘aboutanimals.pl’. An ad network is called to submit bids for the ad placements. Since the user doesn’t have any behavioural data associated with them, the ad network sends back a bid for a contextually relevant ad, and this ad is shown.
The user then visits an ecommerce site, ‘sportequipment.pl’, and looks at some bikes. The website tells the TURTLEDOVE server to add that user to an interest group for those bikes (sportequipment.pl_bikes_viewer, as seen at the bottom of the image). The website also sends a bike ad, which may be shown to that user in the future.
Then the user visits aboutanimals.pl again. This time, the TURTLEDOVE server remembers that the user is interested in bikes. So the auction weighs up bids for contextually relevant ads, delivered by the ad network, against the bike ad. In this case, the bid for the bike ad is higher, so it wins the auction and is shown to the user.
As the user continues browsing the internet, they are added to more interest groups. And whenever they visit a publisher site, all of the ads associated with these interest groups are weighed up against contextual ads delivered by the ad network.
The simulation also allows for publishers to block certain types of ads. One example site, ‘aboutplanes.pl’, doesn’t want to show ads relating to any other modes of transport. So if a user is has previously been placed in an interest group for trains (and no other interest groups), they will just be shown a contextually relevant ad instead.
And users can remove themselves from interest groups, either by clicking on the question mark at the top of the ad, or visiting the TURTLEDOVE server user interface.
Still work to be done
The simulation certainly seems to be a step in the right direction, but there is still plenty of work left to do on the TURTLEDOVE API before it’s ready to be used on the open web.
The simulation also doesn’t handle reporting, which Jagielski says is outside of the scope of the demo. This is still a significant issue which needs to be sovled before TURTLEDOVE is ready for deployment on the open web. The original TURTLEDOVE specification suggests measurement and reporting could be handled by the Aggregate Reporting API, another sandbox proposal. But the Aggregate Reporting API itself is still in development.
And as VAN has previously reported, there may be broader questions for TURTLEDOVE to answer. Some believe that since auctions run within the browser, users are essentially being asked to install adware on their computers, which they may rebel against. And others worry that if different browsers create different TURTLEDOVE-like APIs, we’ll end up with more fragmentation in the ad tech ecosystem.
Nonetheless, for those frustrated with a lack of progress on sandbox proposals, this working simulation will likely be a step in the right direction.