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

1. Have 1 daily update url specific to this device (for example by including the advertiser 1P identifier in the url)
   • This url would not be k-anonymous by definition
2. Have multiple urls each covering a set of ads (worst case scenario 1 daily update url per ad in the IG)
   • Requires a mapping between update urls and ads
   • AdComponents needs to be updated as well and might require specific urls

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:

• Drop k anonymity constraint for daily update to use 1p advertiser ids
• Modify daily update API to target subset of ads and components
• Aggregate IGs into super structures to give access to multiple IGs at bid time (and increase the cap over 1,000)

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.