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

Consider adding ability to read Interest Groups in Shared Storage worklets #1190

Open
jkarlin opened this issue May 29, 2024 · 5 comments
Open

Comments

@jkarlin
Copy link

jkarlin commented May 29, 2024

The idea proposed here is to allow read-only access to an origin's (e.g., buyer's) interest groups within a Shared Storage worklet. From the worklet, you could send out private aggregate reports (e.g., create histograms) based on the IGs you've created for the given user.

Use cases I could imagine include things like, understanding how many IGs your users have, how valuable they are, how often IGs might conflict, etc. It seems like something that would be useful to ad-tech to understand what's happening on device by looking at all of their IGs collectively.

Would this be useful to you? Please let me know if so.

Pseudocode example:

Advertiser page:

navigator.joinAdInterestGroup({owner:"a.com", name: "foo"});
navigator.joinAdInterestGroup({owner:"a.com", name: "bar"});

let worklet = await sharedStorage.createWorklet("https://a.com/worklet_metrics.js". {readsIGs: true});
worklet.run("processIgs");

worklet_metrics.js

class IGReporter {
  async run(data) {
    let igs = await sharedStorage.getIGs();

    // Record how many igs the user has.
    privateAggregation.contributeToHistogram({bucket: igs.length, value: 1});
   }
}
register('processIgs', IGReporter);
@jkarlin
Copy link
Author

jkarlin commented May 29, 2024

Also worth noting that you can already write to shared storage from any protected audience worklet, so you could accumulate your data in there to help generate more useful reports.

@dmdabbs
Copy link
Contributor

dmdabbs commented May 29, 2024

getIGs() will return a list/array of the IG as available to generateBid()?

interestGroup:
The interest group object, as saved during joinAdInterestGroup() and perhaps updated via the updateURL.
priority and prioritySignalsOverrides are not included. They can be modified by generatedBid() calls, so could theoretically be
used to create a cross-site profile of a user accessible to generateBid() methods, otherwise.

@jkarlin
Copy link
Author

jkarlin commented May 29, 2024

| getIGs() will return a list/array of the IG as available to generateBid()?

Haven't explored the exact details yet, but there isn't a privacy reason to exclude things such as priority or updates.

@dmdabbs
Copy link
Contributor

dmdabbs commented Jul 11, 2024

Yes, this would be a useful addition.

There are two types of IGs - "positive" and "negative." Consider some ability to include/filter the types.
Assuming "being a negative IG" continues to be "has a non-NULL additional_bid_key" that should be uncomplicated.

Some internal IG attributes not available to buyers' auction bidding and reporting scripts could be useful to measure, assuming their exposure for aggregated reporting is privacy safe.

exact_join_time
expiration
last_updated
next_update_after
storage_size
joining_origin
joining_url

Chrome provides a simple prior bidCount to generateBid, but it does appear to store an IG's bid counts by day,

@eysegal
Copy link

eysegal commented Jul 14, 2024

Reading the IGs in a worklet would help us properly reporting IGs reach, as discussed in #1219 so we would really appreciate implementing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants