Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase on device Interest Group cap to 2000 per owner #798

Closed
gianni-99 opened this issue Sep 13, 2023 · 3 comments
Closed

Increase on device Interest Group cap to 2000 per owner #798

gianni-99 opened this issue Sep 13, 2023 · 3 comments
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility

Comments

@gianni-99
Copy link

Google Ads would like to request increasing the cap of interest groups per owner to 2000.

We believe a minimum of 2000 will enable advertisers to find more success with the Protected Audience API, improve adoption and competitive parity with 3P solutions, without sacrificing any meaningful privacy-preserving benefits.

Under the current proposal, there will be a guardrail of 1000 interest groups per owner. Today, advertisers have no cap on the number of ULs and a non trivial number of users exceeds the 1000 cap.

Reasons for this change:

  • Valuing a range of advertiser needs: we believe a more restrictive cap is ignoring the needs for a wide range of advertisers as advertisers with a rich and diverse SKU set may require the ability to create numerous, niche groups.
  • At the same time constraints such as Interest Group expiration and k-anonymity will automatically ensure that each ad-tech streamlines the number of IGs each ad-tech stores and maintains over time.
@dmdabbs
Copy link
Contributor

dmdabbs commented Sep 13, 2023

advertisers have no cap on the number of ULs

Presume ULs is short for "user lists?"

a non trivial number of users exceeds the 1000 cap

Any magnitude color you can provide on non-trivial? Any evidence from your tracing/historgrams for what is is driving the expansion? Any possibility those "heavy " users are some sort of bot instance?

And this is before negative interest groups land for scaled use.

@JensenPaul JensenPaul added the Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility label Sep 19, 2023
@orrb1
Copy link
Collaborator

orrb1 commented Sep 29, 2023

Chrome’s Protected Audience implementation limits the number of IGs that one IG owner can place the user into. This limit originally served to limit user device storage resource usage and user device compute resources during auctions. We found better, more accurate, and less biased ways to accomplish both of these goals without limiting the number of IGs that one owner can place the user into, namely this and this techniques. The limit on the number of IGs has again become a problem with the advent of negative targeting IGs that don’t use significant storage or compute resources.

We're proposing splitting the limit on the number of IGs so that there are separate limits for the number of regular IGs versus the number of negative targeting IGs. We're proposing limits of:

  • 2,000 regular IGs per owner - a 2x increase from today's limit of 1,000
  • 20,000 negative targeting IGs per owner

The existing 10 MB limit on interest groups per owner will still apply to the combination of both regular IGs and negative targeting IGs.

The key factor in our decision to use separate limits is the difference in the performance impact for each of these two different types of IGs. For each regular IG, the auction needs to allocate memory for the machinery of the auction that enables that IG to generate bids. The auction then iterates through each of these regular IGs, giving each the opportunity to generate bids. Negative targeting IGs are also loaded into memory, but each is small, only about 500 bytes, and the auction takes no specific action for each negative targeting IG until one is referenced from an additional bid.

The proposed limits described above provide enough headroom to satisfy the known needs of interest group owners, while balancing those against the performance impact of increasing these limits. The caps will be raised in two stages.

  1. In the coming weeks, the total IG cap will be raised from 1,000 to 2,000. This cap will apply to both regular IGs and negative targeting IGs.
  2. With the launch of M119, negative targeting IGs will no longer be counted against the IG cap of 2,000, and will instead be bound by a distinct limit of 20,000 negative IGs.

aarongable pushed a commit to chromium/chromium that referenced this issue Sep 30, 2023
We currently enforce a limit on the number of interest groups by owner,
which is enforced at DB maintenance time. With the introduction of
negative targeting interest groups, this limit initially applied to the
combined number of regular and negative interest groups. This change
splits that limit into two separate limits: one on regular interest
groups, and a different limit on the number of negative interest groups.
The negative interest group limit is intentionally set much higher
because negative interest groups are much smaller and have a much lower
impact on auction performance. The limit currently enforced on the total
size of all interest groups by owner remains a combined limit on all of
an owner's regular and negative interest groups.

This matches the proposal posted at
WICG/turtledove#798 (comment).

Change-Id: I4886e142587404be49767cd61cebf85767061137
Bug: 1464874
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4902233
Reviewed-by: Russ Hamilton <behamilton@google.com>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Orr Bernstein <orrb@google.com>
Cr-Commit-Position: refs/heads/main@{#1203584}
@JensenPaul
Copy link
Collaborator

Closing as this was addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility
Projects
None yet
Development

No branches or pull requests

4 participants