Ask for guidance: How to count unique user reach and impression reach?

[eysegal]

A common requirement for advertisers is to know how many users are assigned to an audience in a 30 days window (MAU - Monthly Active Users) and how many opportunities for impressions (Reach Estimation). We are reviewing https://developers.google.com/privacy-sandbox/relevance/shared-storage/unique-reach but it seems that it's more suitable to use when adding a user to an interest group where we need to count the users and impressions on the publisher size, since it better represents the usability and opportunities of the audience.

We would be happy to know how what is the best way to do that as part of Protected Audiences.

[michaelkleber]

I agree that the Shared Storage and Private Aggregation APIs seem like the natural way to address this use case. Can you say more about what blockages you're running into there?

[eysegal]

What's the best way to do it on the publisher side? Is there a way to get all the IGs and report them using Private Aggregation API? If so, what's promising a single count per 30 days?

[michaelkleber]

I'm not sure I fully understand your desired usage patterns, so apologies if this doesn't match what you're looking for. But I was imagining something like this:

1. At the same time that you add a user to an IG, note that information in Shared Storage (both the IG and the timestamp).
2. When the user is on the publisher page, run a Shared Storage worklet. For each IG that you noted in Shared Storage recently enough:
   1. Check whether you have already reported it for reach estimation
   2. If you have not recently +1'd the reach count for that IG, then send a Private Aggregation report
   3. Save the timestamp at which you sent this report, so that you don't report the same reach count again soon

I agree that this would be somewhat easier if it were possible for Shared Storage to automatically know which IGs the browser is in, and maybe we should consider that feature in the future. But for now, you can use Shared Storage to basically maintain your own second copy of that information.

[jkarlin]

@eysegal You might be interested in issue #1190 where I propose being able to read interest groups in shared storage worklets for reporting purposes.

[eysegal]

Thanks @jkarlin, so I'm a bit confused, what you wrote isn't what @michaelkleber's wrote to in the 2nd point? Is it still a suggestion or can we implement it? Also, @michaelkleber would we be able to get the publisher (domain), country and platform?

[jkarlin]

What I wrote is a proposal (not yet implemented and available) to read your interest groups from within a shared storage worklet, which you could then send private aggregate reports on. If you think the proposal sounds useful to you, please add your support on issue #1190 as that makes it more likely to be implemented.

[michaelkleber]

Also, @michaelkleber would we be able to get the publisher (domain), country and platform?

Yes, any information that you have today is information that you can write into Shared Storage for your reporting process to use later.

Thanks @jkarlin, so I'm a bit confused, what you wrote isn't what @michaelkleber's wrote to in the 2nd point?

My suggested approach is something you can implement today, but it involves duplicated work — adding a user to an IG using joinAdInterestGroup() and at the same time noting the addition using sharedStorage.set(). Josh is pointing out a proposal that would get rid of the need for the duplication and generally make your use case easier. So I agree that voicing your support on #1190 makes sense: As developers, "I want to do thing X, it's mostly-possible but not well supported right now, this change would make my life better" is exactly the kind of thing that leads to us implementing new features.

[eysegal]

Commented, thanks. So @michaelkleber if I understand correctly, what you wrote refers to when registering an IG, on the advertiser side, while what I'm asking is basically what's discussed in #1190