Every fortnight we’ll bring you some technical updates that we feel you’ll find useful.
Today’s topics are CTV standards (in six parts), trafficking automation trend and a Project Rearc update.
CTV Standards
Amit Shetty at IAB Tech Lab has been working hard on a six-part series on CTV Standards, the first three of which have now been published.
The six core topics can be viewed below:
The first 3 parts (of 6) are now available via the links below:
Privacy, Data, and Identity for CTV Advertising
Brand Safety in CTV Advertising
Anti-Fraud & Transparency in CTV Advertising
Trafficking Automation
A genuinely heartening recent trend has been making lives easier for Ops teams on the buy side, agency trafficking teams in particular, which is enabling them to automatically wrap their campaign tags with ad server and third-party verification scripts.
The effort in operationally managing this cleanly has always traditionally been a classic pain-point for Ops teams – and remains regularly misunderstood by other departments. Particularly if changes are required, assets have to be re-trafficked or when (inevitably) everything is needed yesterday.
Long may this trend continue… please see some related links below:
Flashtalking’s Verification Trafficking Automation with DoubleVerify & Moat
Google’s DV360 integration with Integral Ad Science’s Automated Tag API
Project Rearc – an update
As per our recent webinar on Identity & Project Rearc the use cases for both marketers and publishers have now been completed by the Project Rearc working groups.
We’ll be providing a summary of these in a future webinar event before Xmas. Along with this we’ll also work with IAB Tech Lab to summarise and categorise the types of submissions and proposals we’re seeing as constructive long-term solutions for the project.
With that in mind we thought we’d provide a very short update on this, just to provide some initial guidance on what we’ll update you all on more fully in a few weeks’ time. See below for more… and look out for the webinar on this critical work later this year, most likely in early December sometime.
– The Privacy Sandbox (reminder)
– TURTLEDOVE
– SPARROW
– Dovekey
– Event Conversion Measurement API
– Centralised Universal ID proposals
The Privacy Sandbox: initially released in August 2019, and the general approach of which falls into the ‘on-device’ category – in which data resides locally within the browser (or device) and then any specific advertising use cases (targeting, measurement, and decisioning) are implemented on-device via privacy-preserving means. Click here for more info
TURTLEDOVE: stands for ‘Two Uncorrelated Requests, Then Locally-Executed Decision On Victory’ and builds upon Privacy Sandbox by providing a proposed mechanism for re-targeting without any users being made identifiable. Again all ad-decisioning and auction mechanics are executed within the browser. Click here for more info
SPARROW: stands for ‘Secure Private Advertising Remotely Run On Webserver’ and is a proposal from Criteo to enhance TURTLEDOVE by providing more controls and better transparency whilst still maintaining privacy guarantees for users. SPARROW looks to move the core processes out of browsers and onto a dedicated, third-party server – known as the gatekeeper. This would enable any DSPs and SSPs to include their own bidding models and auction logics. See below for more info and click here for more info

Dovekey: a Google proposal submitted in September 2020 which introduces the concept of a 3rd party KEY-value server to handle all the bidding and auction processes of TURTLEDOVE. See below for a short explanation and click here for more info

- The browser sends a regular contextual ad request as described in TURTLEDOVE.
- The SSP returns the winning contextual ads, along with derived contextual signals (from SSP and DSP separately.) The final contextual signal is formed as the concatenation of those from a DSP and an SSP.
- The browser constructs the key by combining the contextual signal and the interest-group ID (
ig_id), and sends those keys in a request to a KV server. - The KV server returns all the bids associated with the requested keys.
- The browser runs a simple auction between interest-group candidates fetched from the KV server and the winning contextual ad.
- If a contextual ad wins, then the browser can proceed with rendering the ads.
- If interest-group ad wins, the browser can send another request to the KV server to get the creative or creatives can be pre-fetched ahead of time via the interest group request, as discussed in the TURTLEDOVE proposal.
Event Conversion Measurement API: an update, again from Google, released in October 2020 designed to enable marketers to see when ad clicks lead to a revenue generation opportunity, without revealing the user’s identity. This API is at an early experimental stage and only supports click-throughs for now, so view-through conversion measurement isn’t supported quite yet. Click here for more info
Centralised Universal ID proposals: a number of submissions (mainly from AdTech vendors) have been received, which are essentially along a similar theme of having a set of agreed standards for benevolent centralised secure and fully anonymised universal identity solutions, accessible by all approved parties. See below for a visual example of this.

Look out for more info from the Data Council in a dedicated webinar before Xmas…