Google’s Chrome Privacy Sandbox aims to offer an alternative for a cookie-free future, built on privacy principles defined by the Chrome team, with browser capabilities to support digital advertising.
However, it’s impossible to replace everything that has been developed over the past 20 years to support online advertising in one giant leap. And let’s face it, some advertising use cases should be left in the past.
But, as bold and ambitious as Privacy Sandbox is, it’s rolling out with a lot of confusion and ambiguity. And there are plenty of unanswered questions about how it will work.
Privacy Sandbox is not a 1:1 replacement for 3PCs
As Anthony Chavez, VP of Product Management, Privacy Sandbox, recently said, “We are not trying to provide one-for-one replacements for cookies and cross-site identifiers. Full stop.”
Instead, Privacy Sandbox is an entirely new paradigm. It aims to rebuild an ad server and an ad exchange in the browser, along with several other restrictions.
Google introduced two sets of APIs to support digital advertising. One set of APIs is to show relevant ads: TOPICS is for browser-observed user behavior, and the Protected Audience API (PAAPI) provides capabilities for buyers to set up and target audience segments. The other set of APIs is a Trusted Execution Environment (TEE) for ad measurement and attribution and supporting features for privacy.
The resulting product is a multifecta of privacy-based restrictions on publishers, sellers and buyers. This requires the industry to press the reset button for critical business needs like invoicing, reporting, ad-spend optimization and decision-making feedback loops.
Last week, Google released a response to the IAB Tech Lab’s concerns about whether certain advertising use cases are compatible with the Privacy Sandbox. The IAB Tech Lab Privacy Sandbox Task Force is considering Google’s response along with all the other responses that come in during our comment period.
But there’s plenty about the new paradigm that we don’t currently understand.
1. What’s an interim feature, and what’s the end state? Privacy Sandbox includes interim features that the industry is expected to work with now, but there are myriad unclear final end states and unsettled details of how auctions will work. Are they transparent? Will the capabilities available today be guaranteed in future iterations? The uncertainty makes it hard to commit to new investments.
2. No commercial guarantee or contract from Google. Privacy Sandbox aims to take over critical business functions like conducting a real-time auction, ad serving and reporting. But what is Google’s contract with buyers and sellers? If something stops working or doesn’t work as expected, who is accountable?
This is software. And like all software, it’s not a question of if a bug is introduced, but when. Unlike a server-side software bug, a PAAPI bug is much harder to roll back immediately.
3. We’ll need one set of tech for Privacy Sandbox and another for OpenRTB, further fragmenting the internet. For example, Fenced Frames are integral to Privacy Sandbox and required for use with PAAPI, but will coexist with iframes.
In the case of a PAAPI auction win, an ad must be shown using a fenced frame. But a real time bidding auction win requires the ad to be shown using an iframe. That means advertisers will have to build their ads with two distinct instrumentations for measurement and attribution. This doesn’t scale.
4. Trusted billing. The Privacy Sandbox shifts measurement from event-level data to aggregated and delayed reporting via a TEE, but does not provide a path for accreditation from the MRC or any other auditor.
Noise – a random amount of data – will be added to summary reports to protect user privacy. But how much noise is acceptable in aggregated data for the industry or for MRC accreditation?
And what if a browser update resets data, a bug stops data reporting or a user does not update their browser? What is the guarantee that all data reported is accurate and always reported, especially when a user can actually delete all measurement data?
5. What will be the latency in ad rendering? Given that Google is recommending a traditional server side auction followed by a Privacy Sandbox auction, what is the expected latency? What are the benchmarks, especially at full scale? How will different devices and computing resources available to the Chrome browser impact the execution of auctions and ad rendering critical for user experience?
6. All work cannot be performed on-device. Google proposes TEEs for auctions and reporting. If TEE is deemed a necessary component, why not fully develop this as part of a minimum viable product before forcing the industry into a solution that doesn’t scale? How would one optimize infrastructure costs if they operate on a cloud service provider other than the one provided by the Chrome team, or on their on-premise data center?
A way forward
With so much at stake, what should Google do?
- Work with the industry to develop standardized and interoperable methods for supporting functions like campaign budgeting and pacing, frequency management, reach calculations and brand safety. Remember: Even government regulations provide a carve-out for essential business functions like measurement.
- Identify solutions like brand safety and fraud mitigation where browser assistance can provide a better solution. Enable third parties to use on-device browser capabilities or TEE services to perform these functions for their customers.
- Incorporate widely used standards like OpenRTB for auction services or VAST for video ads in services and TEE designs. This will save companies time and cost when integrating Privacy Sandbox APIs.
- Fully develop Privacy Sandbox capabilities Google wants the industry to adopt first. If TEE is a requirement, then fully develop the TEE product before asking the industry to experiment and adopt it. Remarketing is a perfect use case with current designs but that also needs a fully developed, end-to-end solution.
- Finally, open source the Google Chrome code used in execution of the Protected Audience APIs. Companies need to feel confident building their businesses on that code, especially when there’s no contract, commercial guarantee or accountability from Chrome.
Any product that aims to be the nuts and bolts of the industry needs to be a complete system that supports end-to-end business needs with required commercial guarantees, contracts, public company fiduciary requirements and Service Level Agreements. Privacy Sandbox is no exception.
“Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media.
Follow IAB Tech Lab and AdExchanger on LinkedIn.
For more articles featuring Shailley Singh, click here.
