Google’s Privacy Sandbox: The Path Forward for Viability
As explained in Criteo's recent blog post, the Privacy Sandbox in its current form would not provide for a healthy ad-supported web as it puts at risk an average of 60% of publisher ad generated revenue on Chrome
At Criteo, based on our Market Testing Results, we have identified a set of key features, focused on performance and utility, that would bridge the gap with a functional Privacy Sandbox. These features complement existing use case reviews, such as the IAB Tech Lab Fit Gap Analysis.
Industry collaboration on this is crucial, and we believe in open discussion and industry collaboration, with a common goal of keeping a vibrant open web post cookie deprecation.
Performance features
As we see every day, AI is a field of constant innovation. Ad Tech companies must be able to keep innovating in that space and enhance their machine learning algorithms’ performance, which translates into more spend on the open web and higher CPMs for publishers.
1. Expand the 12-bit data limitation in Protected Audience API reporting
Bidding models are trained on auction data and auction outcomes (displays, clicks, conversions). Interest Group auction data in Protected Audience is made available through modelingSignals data in ReportWin function. This channel is currently limited to 12 bits which is insufficient for accurate bidding model training and leads to advertising performance loss and Open Web advertising budget loss.
We recommend Google extend modelingSignals capacity.
2. Provide more granular win/loss auction data reporting
While in second-price auctions, bidders can bid the value of the opportunity, in first-price auctions they need to bid less to make room for their internal margin. Bid shading is setting that bid price based on a click prediction value. Bid shading relies on auction data, wins and losses. Auction loss reporting data is currently available only in an aggregated and noisy way.
We recommend Google provide more accurate auction reports for bid shading model training.
For more information, read our W3C feature request:
3. Add global click and display counters to Protected Audience
Users’ click and display data enables companies to adapt the message to customers based on previous touchpoints (displays) and engagement (clicks). It’s a key element for accurate prediction models, bringing significant performance. Such data must be made available in Protected Audience, as part of browserSignals.
We recommend Google provide click and display data as part of the Protected Audience browserSignals.
More details can be found in our W3C feature request:
4. Move part of the bid computation server side
In Protected Audience, making browserSignals and perBuyerSignals available in the call to the DSP trusted server (a.k.a. KV truster server), enables having all the bidding information in one place, server-side, and makes efficient use of bidding models. It also solves the limitations (technical complexity, resources) related to part of the bidding models running in-browser.
We recommend Google add browserSignals and perBuyerSignals to the call to the DSP trusted server.
5. Provide user-centric AB testing
AB testing based on user populations is a key element to compare bidding strategies and improves the business outcomes of such strategies.
We recommend Google provide a framework for AB testing based on user-centric populations.
Further details are available in our W3C feature request:
6. Latency
The additional latency introduced by the Protected Audience auction is problematic, as it negatively impacts user experience by causing ads to appear late on the page and reduces ad performance due to lower viewability. Criteo’s data aligns with findings from our publisher partners, showing that the median latency for Protected Audience displays is more than double that of traditional RTB displays.
We endorse the industry’s emphasis on addressing this critical issue.
See also RTB House’s study on latency:
Audience qualification
These requests enable better qualified, more valuable, audiences, translating into higher revenue for publishers.
1. Extend interest group duration to 90 days
Advertisers frequently employ strategies targeting “full-funnel” customers (those who visited the website without recency restrictions) and dedicate specific budgets to re-engage lapsed customers (those with a recency exceeding 30 days). These strategies enhance customer retention and maximize customer lifetime value. The advertising spending associated with these strategies is substantial and the 30-day limit on Protected Audience Interest Groups disrupts these efforts.
We recommend that Interest Groups’ maximum duration should be extended to at least 90 days. Note that this is a ceiling, not a fixed setting. Interest Group duration can already be set freely by the Interest Group owner, within the maximum duration allowed, which is 30 days as of today.
More information can be found in our W3C feature request:
2. Enable combining Interest Groups at bidding time
Contrary to Microsoft Ad Selection API, Google Protected Audience does not allow for combining Interest Groups data at bidding time. This reduces the utility of Protected Audience for customer acquisition and awareness campaigns.
It also favors very large first parties, like Google itself, that hold a large amount of data on their users and can fit that data into one Interest Group.
We recommend Google allow for using data from multiple Interest Groups in a combined fashion at bidding time.
3. Support exclusion targeting in Protected Audience
Excluding existing customers, or website visitors, from a campaign audience is a standard use case for acquisition campaigns that need to be preserved to ensure efficient use of marketers’ budgets.
We recommend Google provide a way to exclude a set of users based on visits or actions on a site from a Protected Audience audience.
More details are available on our W3C feature request:
Critical Functionalities
These features provide essential capabilities to ensure transparency and seamless integration, avoid fraud, and maximize sustained improvement and competition.
1. Tie deprecation of third-party cookies on mobile to the adoption of Privacy Sandbox for Android
Web advertising on mobile is across app and web, as is user navigation. Use cases where user intent collection, display, and landing are intertwined between web and app are commonplace. Attribution Reporting API already covers attribution across web and app, but only in a theoretical way. It relies on Privacy Sandbox for Android, it can work only for Android devices compatible with Sandbox for Android (available on Android 13+ versions only, less than 50% of current Android devices).
Moreover, Privacy Sandbox for Android ecosystem adoption is, as of today, virtually nonexistent. A solution for targeting across web and app has yet to be designed and made available.
We recommend Google not remove third-party cookies on mobile before a solution covers advertising across web and app.
More details are available in our W3C feature request:
2. Provide real-time data samples for debugging and monitoring
Ad Tech systems are real-time, complex, and integrated with many partners, which makes them prone to incidents. The market testing showed the continued importance of debugging and monitoring to run a healthy business.
The following capabilities are needed:
- Event-level, non-noisy, real-time, sampled data.
- Exhaustive debug mode in the Chrome worklet, into which auctions are running.
We recommend Google provide the required API and data that support real-time incident detection and efficient debugging.
Further information can be found in the W3C feature request:
3. Support traffic shaping
Traffic shaping is the ability for SSPs to select which DSPs shall receive a given bid request. As of today, it’s mainly based on a cookie-sync, when a DSP will receive only “matched traffic”, offloading most of the traffic and saving substantial server costs.
With the removal of third-party cookies, and Interest Groups being available on-device only, this mechanism no longer works.
As noted in the CMA 2024 Q1 report, the lack of an agreed-upon traffic shaping solution could distort competition between DSPs, in particular favor Google, and impact the cost-effectiveness of Open Web advertising.
We recommend Google provide a way to perform traffic shaping for Protected Audience.
More details are available in our W3C feature request:
4. Ensure PA API auction integrity
With on-device bidding and auctions, fraudsters get the ability to tamper with auction data, including bid amounts and winners which could greatly magnify the potency of fraud.
We recommend Google enable the technical guarantees to ensure PA API bids and auctions are not tampered with.
5. Share user opt-out rates from Privacy Sandbox APIs
Depending on the APIs and the jurisdiction, the Privacy Sandbox comes either with a user opt-in or opt-out mechanism. For appropriate coverage, Privacy Sandbox APIs, outside of Topics, availability needs to be around 98% on desktop and mobile individually.
We recommend Google transparently communicate about opt-in rates, existing and future plans related to user consent collection, and strive to reach optimal Privacy Sandbox user opt-in rates.
The H1 market testing has been a key step for getting closer to a working Privacy Sandbox that preserves the Open Web. We hope that, in the coming months, Google will deliver on its promise to deliver a fully functional replacement for third-party cookies.
We encourage all stakeholders to join the discussion with Google, at the W3C, IAB Tech Lab, or other venues, and support the key features above, or other relevant ones they’d like to bring to the table.
Check all our articles about the Privacy Sandbox 👇https://medium.com/criteo-engineering/tagged/privacy-sandbox
