Manage budgets and rate limits
Check out the relevant GitHub issues for changes to privacy budget:
There is no current privacy budget that applies across APIs. Additionally, we have implemented a new rate limit: one origin per source, site or enrollment, for every 24 hours (Chrome, Android). You can check out the complete list of rate limits for Attribution Reporting API to find out about on-device limits such as pending sources and max-destination for Chrome. You can also find the list of Private Aggregation limits.
For the Topics API, the rate limits are as follows:
- The maximum number of API usage context domains allowed to be stored per page load is 30. This means that on a page, all domains can invoke the API to get topics. But only the first 30 domains are allowed to set topics.
- For Topics on Android, rate limited at one call per app per second (open to feedback).
Measurement FAQs
If any ad tech registers an impression with Origin 1 www.foo.com and conversion with Origin 2 www.example.foo.com, is the attribution scoped to enrollmentID or origin?
No, attribution is not allowed cross origins. Attribution scope is at the origin level.
Can aggregatable reports from two different origins which belong to the same enrollment be aggregated together in a single batch?
The team is investigating ways to support multiple origins in the same batch. We don't have a timeline for feature availability at this time but refer to our Status page for the most up-to-date timelines.
Can two different origins from the same enrollment do registration for the same source event?
The one origin per {source, site/enrollment} would only allow you to successfully register on one of them. You can check out documentation for more information.
Are separate enrollments required for Web>Web versus App>Web versus Web>App?
Different enrollments for Web>Web versus App>Web versus Web>App won't be allowed unless they are different lines of business and therefore must be associated with different enrolled sites. For most cases, we expect you to use the same enrollment for Web>Web versus cross App and Web because these should share the same attribution scope (that is, attribution should be deduped across web and app).
Relevance FAQs
Can one buyer A with a separate enrollment from another buyer B create an IG and allow buyer B to use it in bidding?
- Chrome: No. However, buyer A can delegate creation of an IG to another site B that has no role as buyer with the IG retaining buyer A as the owner. This is the only way we support an IG being created by an entity other than the (eventual) buyer that submits a bid in the PA auction.
- Android: No. However Android also supports delegation, where an on-device caller can request the platform to fetch a custom audience from a specific buyer (buyer B). The buyer B must be an enrolled ad tech.
How can the parties sending reports via ReportResult or ReportWin check the enrollment status?
- Chrome: The Chrome implementation is currently not checking for enrollment status of the ReportResult or ReportWin destinations.
- Android: There is no need for these parties to do anything. The PA flow will check for the enrollment for either of the specified destinations.
Do the destinations for event-level engagement reporting, including third-party ad measurement partners need to be enrolled?
- Chrome: Yes. Any entities receiving data directly from the Privacy Sandbox APIs using engagement reporting need to enroll.
- Android: See Event Reporting for more details.
Does the limit of 1000 IGs per owner per device apply to a single enrollment?
- Chrome: Not necessarily. The limit of 1000 IGs is at the origin level. If ad tech decides to use several origins per site or enrollment, then each of those origins gets its own allocation of 1000 IGs per device
- Android: The custom audience limits are applied per user profile (4000) and per app (1000) which is applied to a single enrollment.