Answers to frequently asked questions related to Privacy Sandbox relevance and measurement APIs.
How does Topics compare to Seller Defined Audiences (SDA)?
Topics and SDA provide complementary types of information, and are both in the control of the publisher. We do not believe they are in competition with each other. Instead, both work side-by-side or in different contexts to maximize buying opportunities. Buyers consider and use many signals when evaluating impressions programmatically, and we expect Topics to be one of those considerations. Sellers do not historically include audience segments in open marketplace auctions, a likely place Topics will be used. Instead, sellers have made their audiences available for programmatic purchase in deals struck with advertisers, agencies or DSPs. In those cases, the seller and the buyer are transacting purposefully on the SDA. If Topics are used in these cases, it could be for one or more of the following:
- The seller augmenting their audience definition with Topics
- The buyer using Topics as a signal for how much to bid
- The buyer using Topics to validate whether the SDA is accurate
Does Protected Audience put Google in control of audience creation?
No. Sites can continue building their own audiences both within and outside of Privacy Sandbox. When sites build audiences within Privacy Sandbox, the site owner or chosen proxy determines who can build the audiences, what those audiences are, how those audiences are updated, how those audiences will be bid on and whether to remove users from an audience.
Does Protected Audience support publisher-created Interest Groups?
Yes. We understand publishers are wary of putting their audiences into OpenRTB-based auctions today for fear of data leakage. Publishers can build audiences today in Protected Audience that do not give the bidder a cross-site view of that individual publisher user. We are excited to continue exploring ways publishers can take advantage of Protected Audience's reduced data-leakage environment.
How are ad quality rules enforced in Protected Audience auctions?
There are a number of ways ad quality rules are enforced in Protected
Audience auctions. Each of these
is similar to how ad quality rules are enforced by SSPs today. One way is to let
an auction with an unknown creative trigger the creative to go into a queue for
scanning. We have heard the feedback that SSPs want better support for this
use-case and are designing a mechanism that can create a feed of renderUrls
that the SSP can audit out of band and then store information for in their key
value server. Another way is to require pre-registration of ads. Like the
previous case, once the creative is scanned, the results can be tied into the
key value server. Then later when a buyer bids with that creative (as indicated
by a creative ID likely following the same format as OpenRTB), the seller's
scoring logic can do a lookup in the key value server and decide how to score
accordingly.
Does Protected Audience support video ads?
Yes. VAST URLs can be passed into and out of Protected Audience. As a VAST URL comes out, sell-side tech can coordinate how they will wrap the buyer's VAST URL before it is sent to the player. Ahead of the requirement to move to Fenced Frames (no sooner than 2026) and further strengthen user privacy protections, we expect the ecosystem to engage in design discussions which will certainly include video.
Does Protected Audience support native ads?
Yes. JSON URLs can be passed into and out of Protected Audience. As a JSON URL comes out, sell-side tech can coordinate how they add any desired events before the final JSON is passed to the rendering code. Ahead of the requirement to move to Fenced Frames (no sooner than 2026) to further strengthen user privacy protections, we expect the ecosystem to engage in design discussions which will likely include native.
Does Protected Audience ad rendering inhibit innovation?
No. Ad rendering has always relied on browser technologies. That doesn't change. Perhaps this concern is specific to plans to require the use of Fenced Frames in conjunction with Protected Audience in the future. Part of the reason those plans are "in the future" is because we want Fenced Frames technology to support ecosystem innovation and differentiation when it comes to ad rendering. There is time for interested developers and companies to weigh in on the direction of Fenced Frames which includes how native ads approaches can be supported.
Does Protected Audience allow for sophisticated pacing and bid valuation approaches that exist today in traditional auctions?
Protected Audience offers a
real-time option for buyers to understand campaign pace and budgets. From an
inventory standpoint, it is possible for the seller to provide auction signals
to the buyer about the context of the page and anything else. If a seller is
choosing to send a contextual bid request, the buyer can learn about the
inventory through that mechanism as well, then provide itself with contextual
signals (via perBuyerSignals) that could be used in its Protected Audience bid
generation. Early adopters are already connecting machine learning systems to
Protected Audience. We understand it will take time to tune these systems to
bidding in Protected Audience environments, but it is critical to note that
tuning is possible and is already happening.
Will the OpenRTB standard work in Protected Audience?
Yes. This work is in progress at IAB Tech Lab through a well-attended group of representative DSPs and SSPs. It appears the path forward will be to use parts of OpenRTB protocol as a communication standard inside of Protected Audience auctions, and we are aware of early adopters already building as such.
Does Protected Audience require companies to maintain two separate architectures for ad serving?
No. Protected Audience doesn't require maintaining two separate architectures. Your architectural choices are your own. As online advertising has progressed over the years so has the complexity of systems powering it. Making the internet more private for users introduces more complexity and requires work. Ad tech companies can choose to maintain two separate architectures or build Protected Audience into a combined architecture with traditional auctions.
What will happen to traditional auctions once more ad tech companies support Protected Audience?
We expect contextual auctions will remain relevant for myriad reasons, including deals, non-first-party audience targeted campaigns and many other contextual scenarios. They also remain valuable when there are no Interest Groups present or the bids in Protected Audience fail to reach floors or abide by ad quality rules.
Does the Protected Audience auction run counter to ecosystem Supply Path Optimization (SPO) efforts to reduce the total amount of intermediaries between an advertiser and a publisher and/or duplication of a given ad opportunity?
No. A winning ad in Protected Audience will pass through at most two seller entities (for example, a Supply Side Platform (SSP) and a publisher ad server) and as few as none—if the buyer builds a direct integration with the publisher.
Duplication of the same request using multiple intermediaries remains a publisher's choice. Protected Audience should not impact this one way or the other.
Protected Audience auctions do occur outside of today's server-to-server real-time system in order to not leak cross-site user data. Some may say this duplicates an ad request. Getting to technically demonstrable privacy does require some tradeoffs. However, it is possible in the long run that the ecosystem decides to use Protected Audience without traditional server-side auctions. This choice could lead to even more optimized supply paths.
Does Protected Audience reduce the value of existing traffic shaping infrastructure?
As we understand it, the thing that is changing with regard to queries-per-second is that many SSPs use cross-site IDs as a feature for determining whether or not to send a DSP a request. Reduction in cross-site IDs therefore impacts existing traffic shaping techniques. This would be true whether the publisher wants to run a Protected Audience auction or not.
We explored traffic shaping with many SSPs and found solutions including caching and contextual-based filtering. Over time we expect developers to take advantage of Private Aggregation to further aid understanding of DSP bidding preferences and to filter accordingly.
Ultimately, some legacy infrastructure built around cross-site identifiers will no longer be useful.
Will new requests resulting from a Protected Audience auction strain SSP capacity?
We've heard from some SSPs that capacity is not an issue or an important piece of an SSP value proposition from an integration standpoint. For the SSPs who are concerned about new calls in the auction process, we are aware of companies who already help SSPs with capacity concerns and are looking to expand those services to support Protected Audience. Let us know if you would like us to connect you with one of those companies.
How is priority addressed in Protected Audience when there are competing resources in the browser?
Protected Audience has generally followed the standard paradigm of building controls that let sellers decide how much time and resources the bidders can consume and building tools that let buyers decide how best to use the resources available to them. These controls and tools are available today, but their full benefit will be realized after adoption by buyers and sellers. In addition, Chrome continues to work on a variety of infrastructure improvements to auction speed (for example, crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323).
How does Protected Audience address latency concerns?
In the past, before Protected
Audience, real-time bidding that
happened on servers had sellers specifying strict timeouts on buyers' responses
to keep latency in check. We added a variety of very similar seller-specified
timeout controls (see
documentation for
perBuyerCumulativeTimeouts, perBuyerTimeouts, sellerTimeout) to Protected
Audience to accomplish this same goal of keeping latency in check. These
controls also encourage auction participants to optimize their logic to make
sure resources are used most efficiently to support the ad tech ecosystem and
high quality user experience.
Chrome also continues to work on a variety of infrastructure improvements to auction speed (e.g. crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). We invite feedback on both parts of this latency effort: additional tools that buyers and sellers would find useful, and reports of observed bottlenecks that Chrome engineers should investigate.
Is building for on-device Protected Audience a wasted effort when Bidding and Auction Services (B&A) exists?
No. On-device is sufficient for ad tech use cases. Bidding and Auction Services is an optional horizontal scale solution when ad techs want to invest more in bid computation resources than the browser allows. On-device development is a good investment, because most work would be reusable even if developers decide later to participate in Bidding and Auction services environments. The majority of the pipes and infrastructure built would continue to work similarly.
Will the cloud-based Trusted Execution Environments (TEE) requirements for Protected Audience push businesses to use Google Cloud?
Privacy Sandbox has designed the APIs to provide robust privacy and security, and we haven't taken any design decisions to benefit Google Cloud. Our support for cloud providers started with AWS because we acknowledge how many ad tech providers choose Amazon. In addition to AWS and Google Cloud, we expect to support other cloud providers in the future, and we are open to suggestions for other cloud providers. If latency is a concern, clouds offer customers location choices which shorten distances to other cloud providers.
Will Privacy Sandbox allow Trusted Execution Environments (TEEs) to run in non-public cloud data centers?
Auditable Trusted Execution Environments (TEEs) are part of our privacy and security model. We started with TEEs offered by public cloud providers due to the rigorous security measures. To be clear, the only APIs requiring use of Trusted Execution Environments in the near term are Attribution Reporting API and Private Aggregation API, and neither involves calling the TEE in real time in an auction setting. We are continuing to explore support for options beyond public cloud-based solutions.
Won't it be more expensive to run Trusted Execution Environments in public clouds as opposed to on-premise ad tech data centers?
Our current TEE privacy model benefits from the security practices of public cloud implementations, and we question any assumption that it is less expensive to operate a Trusted Execution Environment on-premises. These are some cost considerations for those practices:
Public cloud providers must hold themselves to a very high bar in terms of security. For example, AWS is a reputable cloud provider with established security practices. In particular, AWS Nitro has a documented security model for ensuring that Nitro Enclaves prevent operators from accessing data that is processed in the enclave, and protected resources (such as decryption keys) are only available to authorized code running in the Enclave. There's also physical access to consider. AWS has designed and implemented mitigations for physical access risks, including from Amazon employees. Existing hardware-based TEEs may not defend against all physical attacks, which public clouds are designed to do. Additionally, Amazon recently engaged the NCC Group, an independent research firm, to review their Nitro designs, focused on security claims related to access by internal employees. The public report indicates that the AWS designs meet their claims.
These practices cost money to put in place, support and improve over time. With globally distributed and widely available public clouds, those costs are spread out over a wide base of customers.
Does Privacy Sandbox change billing?
No. Ad tech companies and other API callers can continue to see whether something is rendered on a page and at what price.
Is frequency capping possible in Privacy Sandbox?
Protected Audience supports
cross-site frequency capping within the same Interest Group through the
prevWinsMs object. A buyer's generateBid() function within the Protected
Audience auction can create logic that can inform bidding strategy based on the
result of previous ad exposures for the same browser.
There are a few solutions that can be used for frequency capping outside of Protected Audience, but they do not fully map to the cross-site techniques that ad techs have with third party cookies.
- First-party cookies: ad techs can use their own first party data to frequency cap across their own site
- CHIPs: ad techs can manage frequency caps on a per-site level using a partitioned cookie
- Shared Storage
SelectURL(): after an ad tech has won an auction and before they render the creative, they can call Shared Storage to access cross-site data and choose the right creative based on frequency through the Select URL output gate.
A privacy-forward, non-Protected Audience frequency capping solution that provides meaningful ad tech utility is challenging for the following reasons:
- It is currently unclear based on ad tech feedback whether a frequency signal could tolerate noise.
- We have heard consistent ad tech feedback that a cross-site frequency signal would have to be available during auction time, which require non-noised cross-site signals to be available for use in any advertising auction. This could reveal a large amount of information about a user's activity across sites, undermining the privacy goals of Privacy Sandbox.
- We are sensitive to introducing latency and an on-device solution that might provide this signal could cause latency and disrupt the auction environment
- A solution would likely need to be a new API, which would have to go through the W3C proposal process.
As such, building a frequency cap solution outside of Protected Audience is not in our immediate roadmap, but we are open to feedback around potential ways to solve this use case.
What about use cases that aren't covered by Privacy Sandbox?
Privacy Sandbox APIs provide key building blocks for privacy-preserving advertising, where developers have the flexibility to determine how they are put together. The building blocks approach allows businesses to innovate and develop solutions that deliver value for their customers. It is not the intent of Privacy Sandbox to be an end to end solution for all use cases. We believe that would be a bad outcome. Instead, developers and businesses will continue to bring their ideas to life through a variety of technologies, including Privacy Sandbox APIs that they integrate into their solution(s).