Request for comments on Topics API use case

[Aleksei-Gorbushin-at-Walmart]

I would like to describe a use case for Topics API for an advertiser.
Any comments, suggestions, or corrections are welcome.

1. Let's say we have an advertiser which has an online shop (aka web store). E.g. very-expensive-stuff.com.
2. This site sets first-party cookies to all visitors' browsers. Let's name them vtc (visitor tracking cookies).
3. The site collects telemetry events firing "beacons" to endpoints where these events are collected and stored. E.g. in a Hive table partitioned by day and named page_views_events.
4. Later these data can be used to build audiences (with some ML black magic). E.g. "an audience of all visitors who are ready to buy product S".
5. Since 3rd-party cookies are still functional in some browsers, these audiences might be "translated" from the first-party cookies (vtc) to the 3rd-party cookies (e.g. The Trade Desk cookies - TDID).
6. Such "translated" audiences could be uploaded to DSP (e.g. The Trade Desk) and could be used to set advertisement campaigns up.

This was a current flow.

Let's take a look at how can we leverage Topics API capabilities.

1. Telemetry events could include topics that browsers return executing document.browsingTopics() call.
2. Having topics linked to the first-party cookies (vtc) allows us to create "feature table" where each vtc has some topics for every epoch (week).
3. Returning to the original flow (step 4), we can take an audience defined in first-party cookies (vtc) and translate these cookies into topics. As a result, we would have a set of topics that were interesting to visitors identified by those vtc in the audience.
4. Some topics could be more frequently seen than others. Those topics could be used to define the target audience for an advertisement campaign.

Does this approach look meaningful and workable?

[npdoty]

Thanks for walking through a use case in detail. As I understand it, Topics could definitely be used to gather some general interests of people known to be customers of a certain type, and then to target ads on other sites to a lookalike type audience of people who have those same interests (as inferred from browsing history), without ever tracking an individual user who visited your site and directly target them in another context.

I don't know how effective that advertising would be compared to the existing flow -- presumably the framing of the ads would need to be different since you're reaching mostly new visitors rather than existing customers that you think are interested in a particular purchase -- but it seems feasible. As a privacy matter, I don't know if users expect that their interests are going to be collected over time by the shop in order to construct this targeting strategy, but your use case would primarily make use of aggregated data.

(Chrome's current design for Topics would require that a widely-used third-party be embedded to determine the topics assigned to the existing visitors, beyond the topic category of the online shop itself. That design feature is an open question, but under the current design it's likely that some vendors would provide that service.)

That wouldn't be the same functionality as your current flow, which is more like re-targeting or a selected audience. There are some proposals to try to more closely replace that functionality with some different privacy properties (e.g. FLEDGE or PARAKEET).

[Aleksei-Gorbushin-at-Walmart]

Thank you @npdoty for your comments and a confirmation that my imaginary case looks reasonable ;)
I was worried that the approach might not work due to the following section in the explainer

Not every API caller will receive a topic. Only callers that observed the user visit a site about the topic in question within the past three weeks can receive the topic. If the caller (specifically the site of the calling context) did not call the API in the past for that user on a site about that topic, then the topic will not be included in the array returned by the API. The exception to this filtering is the 5% random topic, that topic will not be filtered.

Frankly speaking, I do not understand that statement, that is why I decided to describe the use case. I'm glad that you see no issues with that.

P.S. I know about FLEDGE or PARAKEET and how "interest groups" could be used theoretically.

[npdoty]

That was the reason that I included this caveat:

(Chrome's current design for Topics would require that a widely-used third-party be embedded to determine the topics assigned to the existing visitors, beyond the topic category of the online shop itself. That design feature is an open question, but under the current design it's likely that some vendors would provide that service.)

Under the current Chrome implementation, if the shopping site itself directly calls browsingTopics(), it wouldn't get access to a range of topics based on the user's browsing on other sites, because of the proposed "witnessing" limitation. Perhaps that design limitation should be changed, although the reasoning was to limit the privacy implications of sites learning new information about the user. But even with that limitation, it could be that a widely embedded third party could be embedded on the shopping site page and have an agreement to pass on the topics that it sees about the user back to the shopping site itself.

[Aleksei-Gorbushin-at-Walmart]

@npdoty, I agree with your statement about the possible workaround

But even with that limitation, it could be that a widely embedded third party could be embedded on the shopping site page and have an agreement to pass on the topics that it sees about the user back to the shopping site itself.

Do we really want to make the shopper site owners' life miserable? 😩