Learn more about Protected Audience API auction features as we approach third-party cookie deprecation.
As we move Protected Audience API closer to general availability and approach third-party cookie deprecation in Chrome, you may be wondering about the availability of Protected Audience API services and features. Here you'll find a list of the scoped Protected Audience API features and when they'll be supported.
Feature availability timeline
Feature | Available for testing | Status |
---|---|---|
Event-level auction win reporting | Now | Supported until at least 2026. This feature is intended to make the transition to Protected Audience API reporting from third-party cookie reporting easier. Thus, this reporting will not be supported after ad techs have had time to update their reporting mechanisms. |
Trigger-based aggregation | Now | Available for testing in Chrome Canary/Dev M113+ and Beta/Stable M115+. |
Trusted Execution Environment (TEE) usage for Key/Value service | Now | Required no sooner than Q3 2025. |
Fenced frames | Now | Required no sooner than 2026. |
Improved Protected Audience API + Attribution Reporting integration | 2023 Q2 | Available for testing in Chrome Stable M112+. |
K-anonymity | Later in 2023 Q4 | For rendering creatives, the k-anonymity threshold of "a crowd of 50 users per creative over 30 days" must be met. |
Bidding and Auction services | Targeted for testing in H2 2023. | In development. |
Additional features
Feature | Available for testing | Status |
---|---|---|
Event-level user bidding signals for modeling (Github Issue) | 2023 | Available in Chrome in Q2 2023. |
Per-Buyer Latency Reporting | 2023 | Available in Chrome in Q1 2023. |
Per-buyer wall-time timeout | 2023 | Available in Chrome in Q1 2023. |
Buyer reporting ID for custom breakdowns | 2023 | Available in Chrome in Q3 2023. |
Direct seller destination support | 2023 | Available in Chrome in Q1 2023. |
Accuracy-limited ad cost for cost-per-click billing | 2023 | Available in Chrome in Q2 2023. |
Currency for highest bid and highest other scoring bid | 2023 | Available in Chrome in Q3 2023. |
Macro Support for Third-party Ad Trackers (3PAT) | 2023 | Available in Chrome in Q3 2023. |
Support for Negative Interest Group Targeting | Later in 2023 | Expected in Chrome in Q4 2023. |
Secure Propagation of Auction Signals without WebBundles Github Issue |
Later in 2023 | Expected in Chrome in Q4 2023 |
Bulk Interest Group Deletion Github Issue |
Later in 2023 | Expected in Chrome in Q4 2023 |
Increase Interest Group Cap from 1K to 2K Github Issue |
Later in 2023 | Expected in Chrome in Q4 2023 |
Support for Bidding and Auction Beta 1 Explainer |
Origin Trial, later in 2023 | Expected in Chrome (via Origin Trial) in Q4 2023 |
Event-level auction win reporting
We initially indicated that the event-level auction win reporting would be a
temporary solution, and Private Aggregation API will be used to generate summary reports. After listening to feedback and examining the relative complexity of aggregation-based solutions, particularly for billing, we have decided to not remove support for event-level auction win results reporting with reportResult()
and reportWin()
functions having the ability to call sendReportTo()
until sometime after third-party cookie deprecation.
Event-level auction win reporting will be supported until at least 2026, and we will provide advanced notice before the API transitions to any alternative solutions.
Auction loss reporting will continue to be supported through the Private Aggregation API.
Trigger-based aggregate reporting
During a Protected Audience auction, you can send an aggregatable report when triggered by an event using Private Aggregation API’s contributeToHistogramOnEvent()
method. The triggering event can come from the auction itself, such as an auction win or loss, which allows you to generate an auction loss report. The event can also come from a fenced frame outside of the auction using Fenced Frame Ads Reporting API’s window.fenced.reportEvent()
to trigger the aggregatable report submission.
See the contributeToHistogramOnEvent()
section of the Private Aggregation page to learn more.
Trusted Execution Environment usage for Key/Value service
The Protected Audience API Key/Value service allows the auction to retrieve real-time signals when the bid is generated by the buyer and the ad is scored by the seller. The Key/Value service will eventually be required to run in a trusted execution environment (TEE) to ensure that the user's data is kept private.
Running the Key/Value service in a TEE will not be required until sometime after third-party cookie deprecation. We will provide at least 12 months notice before TEE usage is mandatory. Until then, you can continue to use your own server for real-time key/value signals. Note that running the Key/Value service in a TEE with user-defined functions (UDFs) will be available for testing by the end of Q1 2023 with on-device Protected Audience API.
Fenced frames
Fenced frames are a new HTML element that limits communication between the content and the embedder, and is used for rendering content based on cross-site data. The Protected Audience API will render content into a fenced frame.
After working closely with various stakeholders and examining the significant effort to accommodate this change, Chrome will not mandate fenced frames until at least 2026 to maintain ecosystem inclusivity,and Chrome will provide significant advanced notice. Until then, if fenced frames are not used, you will need to use an iframe to render the opaque URN. Also, it should be noted that sellers could still require the use of Fenced Frames.
Proposal | Status |
---|---|
Web API changes for urn to config Explainer |
Available in Chrome in Q1 2023. |
Add size to API for K-Anon check for URLs and Frame Size Github Issue |
Available in Chrome in Q2 2023. |
Protected Audience Fenced Frames support for event-level reports with Attribution Reporting Github Issue |
Available in Chrome in Q1 2023. |
Protected Audience, Fenced Frames, and Private Aggregation API support urn-iframes reportEvent Github Issue |
Available in Chrome in Q1 2023. |
Protected Audience component ads reporting Github Issue |
Available in Chrome in Q2 2023. |
Deprecate src attribute for the config attributeGithub Issue |
Available in Chrome in Q2 2023. |
Creative Macros in Fenced Frames for Ads Reporting (FFAR) GitHub Issue |
Available in Chrome in Q3 2023. |
Send Automatic Beacons Once GitHub Issue |
Available in Chrome in Q3 2023. |
Serializable Fenced Frames Configs GitHub Issue |
Available in Chrome in Q3 2023. |
Additional Fortmat Option for Protected Audience Ad Size Macros GitHub Issue |
Available in Chrome in Q4 2023. |
Automatic beacons sending to all registered URLs GitHub Issue, GitHub Issue |
Available in Chrome in Q4 2023. |
Improved Protected Audience API and Attribution Reporting integration
Recently, challenges have been pointed out around the integration of the Attribution Reporting API and Protected Audience API, especially where fenced frames are involved.
For event-level reporting with the Protected Audience API, we have a proposed set of initial improvements to make this integration easier which you can learn more about in the explainer. The integration will be available for both fenced frames and iFrames. Event-level reporting will be available for testing in Chrome Stable M112+.
For those who need Attribution Reporting with the Protected Audience API, we are working on more flexible solutions to capture more bidding signals with aggregatable reports, and we will publish a proposal once it is ready.
K-anonymity
For a creative to be considered k-anonymous, the tuple of interest group owner, bidding script URL, creative URL, and creative size must meet the threshold of a crowd of 50 users per creative (k=50
) within the past 30 days before the ad can be served. The creative is available to be served as soon as it hits the 50 users threshold and does not need to wait for 30 days.
The k-anonymity enforcement will be ramped up gradually. Later in 2023, we will begin to check the render URL for k-anonymity. Later in Q1 2025, we will begin to check the ad size in addition to the URL for k-anonymity.
You can learn more about the parameters from the k-anonymity explainer.
Bidding and Auction Services
We have heard some concerns about Protected Audience API latency and are actively working on improving on-device latency. Both Chrome and Android plan to provide Bidding and Auction Services as an additional way to run bidding and scoring logic besides on-device auctions. Bidding and Auction services is a Protected Audience API service solution for running auctions off-device, which we believe will allow for even faster performance.
We will continue to support on-device auctions, and the use of the Bidding and Auction Services is not required unless it fits your use cases.
More details can be found in the blog post.
What's next?
We want to engage in conversations with you to ensure we build an API that works for everyone.
Discuss the API
Like other Privacy Sandbox APIs, this API is documented and discussed publicly.
Experiment with the API
You can experiment and participate in conversation about the Protected Audience API.