Why we need multiple IGs per domain #361
Comments
@gianni-99 FLEDGE Android mentions a 1000 custom audiences per app and 4000 total on device limitation. I looked for a1k IGs per browser web limit in the spec, the core explainer, or first OT details but do not see it. |
|
The codebase has a limit to the number of IGs if I understand correctly |
|
We are encountering the same issue on our side for segmented audiences. As explained above it seems not scalable to create 1000s of interest groups.
This has the downside of not being able to update the user bidding signals or customize the list of ads/ad components by user for the same interest group. Even though they might not have changed because the user didn't visit the advertiser there could be some update around the running campaigns or advertiser catalogs.
If nothing is shared among interest groups it seems just like some kind of batching. So it might increase the cap over 1000 but there will be the next cap. This doesn't seem like a real long term fix that addresses the use case of segmented audiences.
This seems like the best option. It would ensure the consistency between interest group creation that allows user bidding signals without k-anonymity constraint and interest group update. In terms of privacy having a daily update call for each user seems not to expose any additional cross site information that I could not already see with first party data as long as the daily update calls are not bundled at the same time for the very same user. The update call could be spread randomly during the whole day for each IG. It would be like the user made one visit to the website each day. |
|
Thank you to everyone who has weighed in on this issue and other related issues (e.g. #333). As we’ve been hard at work on improving FLEDGE auction latency (e.g. #302, 304, 305, 310) it has become clear that the proliferation of interest groups, even from a single joining site and from a single interest group owner, is contributing to added FLEDGE auction latency. It also requires the browser to store large numbers of interest groups, sometimes approaching the browser guardrails for maximum numbers of interest groups. We’ve spent a long time investigating the different options here. The k-anonymity requirement on interest group updates has the unfortunate side effect of sometimes requiring one adtech to add a user to many interest groups on just one site. The act of breaking per-site user information into many interest groups is going uselessly beyond our goal of sharding a user’s identity per site in ways that are not improving user privacy and introducing inefficiencies into FLEDGE that could potentially harm user experience. The k-anonymity requirement on interest group updates was added to protect user privacy when updating interest groups. Each update request only contains per-site user identity, so the cross-site identity join risks occur from side channels like IP address and timing correlation. The use of a k-anonymity requirement for interest group updates is not a particularly strong privacy protection, mostly because the cost to add a user to an interest group (and increase the chance of passing the k-anonymity requirement on updating) is not high. After very careful consideration we’ve decided to remove the k-anonymity requirement on FLEDGE interest group updates, and to consider other potential more direct protections (e.g. IP address privacy or a trusted update server as mentioned in #333) at a later date when the related technologies are more developed, deployed and adopted. As the browser generally doesn't perform background network fetches, we're also proposing sticking with performing interest group updates immediately after auctions, as documented for the Origin Trial, rather than background fetches as the explainer currently says. |
|
I'm closing this issue as I think the original issue should be resolved now. |
Intro
This issue is to explain why, with the current Fledge API, our implementation needs to have multiple IGs per domain on the browser and why we might need more than 1000 IGs per browser. We would like to discuss how to overcome this cap (by either allowing more efficient IG processing and more IGs on device or by combining more ads and components in fewer IGs).
Why IGs contain a large set of eligible ads
It is our understanding that, with the current FLEDGE API, the IG can only contain ads that are eligible for the current browser. This is a practical consequence of the difference in data available at tagging time and at daily update time. In fact, at tagging time, it is possible to use the whole 1P user profile to determine ads, while at daily update time we can only issue 1 single k-anonymous update url per IG.
As a result, to limit the communication bandwidth at daily update time, the IG’s daily update url should identify only ads relevant for the browser. At the same time, to limit the number of IGs each IG has to identify a large set of ads that are relevant for this user.
Advertisers with many userlists and segmented audiences might require a large number of IGs.
Why fewer IGs are desirable
Currently, having lots of IGs imposes severe latency penalties during the auction process, specifically because generate bid JS needs a separate context for each IG.
A few issues have been trying to address this problem (162, 304, 310, 333, 339) and we could further improve the situation by consolidating more ads into a single IG or structure per domain.
How can we get to 1 IG per domain - dailyUpdate fix
To get to 1 IG per domain we need to be able to issue update calls that are specific to the ads eligible for this device. Two options come to mind to achieve this goal
In the second solution, k-anonymity would still be viable as only part of the ads and components on devices could be updated depending on their popularity.
How can we get to 1 IG per domain - the super-IG aggregation
Another option is to aggregate IGs into a new structure (a super-IG of sorts) that will include a part or all the IGs from a same domain. This structure would easily coexist with issue 339 implementation by making some of the same origin IG relationship explicit.
The generate bid JS functions would then be called on the super IG and have access to all the IGs included. This has the potential to reduce latency (since a single call covers more IGs) and data usage as negative targeted IGs could be derived from the list of IGs in the super IG (similarly to issue 162).
Going forward
We would like to get feedback on this issue of IG capping. Specifically, hitting the 1,000 IGs cap might become an issue as we ramp up OT. We propose 3 solutions to this issue:
Any of these solutions could help reduce the impact of having multiple IGs and hopefully will allow us to extend the cap by an order of magnitude or more.
The text was updated successfully, but these errors were encountered: