In brief, Google’s Dovekey proposal refers to a part of the company’s “Privacy Sandbox” initiative, aimed at introducing a replacement to currently-applied cross-site tracking technologies with the more privacy-focused tech.
From TURTLEDOVE to DOVEKEY
The Dovekey proposal (also DOVEKEY) is basically Google’s response to Criteo’s SPARROW initiative, formerly introduced in response to the TURTLEDOVE proposal by Google.
- TURTLEDOVE
TURTLEDOVE stands for “Two Uncorrelated Requests, Then Locally-Executed Decision On Victory” and refers to a privacy-focused framework, where the ad auction takes place in a web-browser, instead of an ad server.
While TURTLEDOVE should enable handling contextual targeting activities, the brand safety issues have become a matter of industry concern, especially in view of the fact that the bidding engine would shift to a basically unauditible Chrome web-browser.
More importantly, handling the bidding process directly in a browser could take a toll on the bandwidth, increasing the latency time.
- SPARROW
In turn, SPARROW stands for “Secure Private Advertising Remotely Run On Web-server” and implies the ad auction logic is handled by a so-to-speak “Gatekeeper”, that is, a trusted third-party server.
Unlike TURTLEDOVE, the SPARROW proposal is expected to provide more bidding flexibility, while ensuring lower bandwidth consumption. More importantly, the framework implies real-time data reporting to advertisers.
On the flip side, the aspect of trust remains an issue, since it requires re-implementation of auction logic in the third-party Gatekeeper from companies on the Supply and Demand side (i.e. SSPs and DSPs, accordingly).
- DOVEKEY
According to Google, the Dovekey proposal allows eliminating the necessity of re-implementation of ad auction logic, instead introducing a notion of a Key-Value server (KV server), which works more as a so to speak “lookup table”.
This means a KV server will only receive a Key (i.e. a contextual signal (cs) + an interest group ID (ig-ID)), and return a Value, i.e. an auction bid.
Suggested Workflow
The outlined workflow implies the following:
1. A web-browser is sending a contextual ad request (as outlined in the TURTLEDOVE proposal).
2. An SSP returns winning contextual ads, along with contextual signals, obtained separately from an SSP and a DSP, with the final contextual signal being formed as a string of those.
3. The web-browser compiles a Key, which includes both a contextual signal (cs) + an interest group ID (ig-ID)), and sends it to a Key-Value server.
4. The KV server returns a bid/bids, associated with the Key.
5. An ad audion between the winning contextual ad/s and the interest group ad/s takes place in the web-browser.
If the contextual ad wins the ad auction, the web-browser proceeds with ad rendering. If the bidding interest group ad wins, the web-browser proceeds with requesting ad creative/s (usually pre-fetched) from a Key-Value server.
Note! A Key-Value server may be configured to handle the ad auction logic, too. In this case, the winning ad bids, as well as ad creatives should be returned.
Ad Tech Industry Response
The Dovekey proposal is being currently discussed by the industry professionals, including the Improving Web Advertising Business Group.
Namely, some of the ambiguous aspects/open questions include:
- number of KV servers, required to handle ad requests at scale;
- interest-group creation process;
- potential Gatekeeper entities, etc.