Introduce a new field joinPriority in InterestGroups for displacement

[akhild-google]

Existing system

In the existing system of turtledove FLEDGE API, there is a max groups per owner limit which is apparently set to 1000 currently. So, whenever an owner crosses this limit, InterestGroups excess of this limit is cleared. It appears that the interest groups which are not yet expired and the ones which have farthest expiration are retained while ones that are soon to expire are flushed out of the browser. While this is one technique to flush out the interest groups, it’s almost always not the most desired way to do so for the Ad Networks. So, we propose a way to add a new field joinPriority in InterestGroups table which chooses to join or leave Interest Groups

Implementation

Existing

https://crsrc.org/c/content/browser/interest_group/interest_group_storage.cc;drc=1548075f9b31cc1495edbbfbc1eba116ef480593;l=1889

SELECT name
FROM interest_groups
WHERE owner = <owner>
  AND expiration >= <now>
  AND <next_update_after> >= next_update_after
ORDER BY expiration DESC

Suggestion

• Create and use the new field joinPriority

  SELECT name
  FROM interest_groups
  WHERE owner = <owner>
  AND expiration >= <now>
  AND <next_update_after> >= next_update_after
  ORDER BY join_priority DESC, expiration DESC

[dmdabbs]

Can you (re)use the existing priority interest group attribute used at auction time to implement a seller's interest group participation limits...

The priority is used to select which interest groups participate in an auction when the number of interest groups are limited by the perBuyerGroupLimits attribute of the auction config. If not specified, a priority of 0.0 is assigned. There is no special meaning to these values. These values are only used to select interest groups to participate in an auction such that if there is an interest group participating in the auction with priority x, all interest groups with the same owner having a priority y where y > x should also participate (i.e. generateBid will be called). In the case where some but not all interest groups with equal priority can participate in an auction due to perBuyerGroupLimits, the participating interest groups will be uniformly randomly chosen from the set of interest groups with that priority. https://github.com/WICG/turtledove/blob/main/FLEDGE.md#12-interest-group-attributes

[akhild-google]

Thanks David, it's a fair point.

Using priority may make things work. But, like you said the API associates priority with auction participation while join_priority determines which interest group to retain and which one to drop.

I agree that for some/many Interest Group owners, reusing priority may work around using a dedicated field to displace interest groups. But, there could be some owner who wants to separate auction priority with join priority for specific business needs. So, I proposed join_priority as a separate field to have separation of concerns

[dmdabbs]

True. Based on the SQL, lower join_priority values will have higher priority versus priority's higher values. Is that difference intended?

[akhild-google]

no, From my example I meant the opposite. Higher float value join_priority IGs will be retained and lower ones will be let go(with expiration time as a tie breaker).

But, I'm okay with your suggestion also (retaining lower float value join_priority IGs and drop the higher priority ones).

It appears that the SQL from the code above retains top 1000 rows(as of current version) queried and drops the others

[dmdabbs]

That would be

ORDER BY join_priority *DESC*, expiration DESC

(based on the SQL in our warehouse. Maybe SQL Lite is different.)

[akhild-google]

Oh, I see what you mean. I meant the same as what you just described. Thanks for the catch

ORDER BY join_priority DESC, expiration DESC

updating the original post with this

[nbwray-work]

Is there any chance this feature request can be prioritized? Being able to control which interest groups are dropped when the cap is exceeded would improve utility of PA API.

[fhoering]

@michaelkleber As discussed in the W3C meeting from 04/09/2024 Criteo is supporting this ticket.

Today there are two limitations for one IG owner: total size must not exceed 10 MB and there should not be more the 2000 IGs (https://wicg.github.io/turtledove/#interest-group-storage-maintenance) While this seems like a lot there can be several reasons why more and larger IGs are needed: advertisers with a large product catalogs, users that visit a lot of advertisers aka the most valuable users, partners with a lot of campaigns, upper funnel campaigns, .. Today there is no way to control this limit easily beyond heuristics and it seems it is also not possible to detect eventual anomalies or monitor the share of users where IGs are erased often. So adding some aggregated monitoring of the IG size could also be useful.