Clarification on Topics API *principles* is needed

[ogassav]

Hi all,

can you please help me to clarify several key principles of Topics API?

1. Is it a replacement of current AdWords + AdSense toolset, or rather a new cookieless "engine" inside them?
2. How does advertiser's topic query "spread" across the ad ecosystem after they set up target topic (e.g., "Cars") for their campaign - shall this query now be automatically run on every website which has Topics code integrated in its pages? I mean, since there are ~350 topics, dozens of thousands of advertisers worldwide (each with their unique set of queries at a certain given moment) and finally hundreds of thousands of websites - does Topics API check [by talking to the browser] website visitor's alignment with all 350 topics on every website, or rather with only those topics that currently are in the "query pipeline" of the particular website (e.g., 30 topics from 10 API callers, i.e. advertisers)? If this is the latter, then the advertiser should somehow define which website(s) will their query be directed to, right? [otherwise websites won't be able to define their query pipelines]
3. Is it only the ad demand side (advertiser, ad agency) that can find out user's topics (i.e. act as a Topics API caller), or the supply side (publisher, i.e. website) can do the same? In other words, can the website that the user currently browses, itself call Topics API to check visitor's "historical" topics stored in their browser? Is API caller limited in the number of topics they can place in the query (or daily or per-website, etc.)?
4. If website can act as an API caller (as discussed in previous question), are there any conditions, e.g. MIN total number of website visitors for the moment of query (for the sake of user privacy), etc.?
5. Does Topics API machine learning mechanism of the query return to its caller only "historical" topics (those from previous epochs/weeks) and not topics of the website the visitor is currently browsing?

Thank you!

[michaelkleber]

1. Is it a replacement of current AdWords + AdSense toolset, or rather a new cookieless "engine" inside them?

Topics is a piece of ads-related infrastructure that we expect to provide in browsers. Your question is more about how topics then gets used — that is, it's a question for the product development team of whatever ad tech provider you work with. We've seen many different ideas for how to use Topics, so both "it is a new targeting tool" or "it is an engine powering existing targeting tools" seem possible!

2. How does advertiser's topic query "spread" across the ad ecosystem after they set up target topic[...]?

When a person visits a publisher web site, the ad request created by the code on the publisher page may include the Topics API output for that person, along with any other information the publisher's ad providers use to pick ads. In today's world, that ad request probably includes a third-party cookie, which the ad tech provider uses to look up some behavior profile that might include the attribute "Maybe interested in Cars". In a world without third-party cookies but with the Topics API, the information "Maybe interested in Cars" can still be used for ad targeting, even though the user profile cannot be built.

3. Is it only the ad demand side (advertiser, ad agency) that can find out user's topics (i.e. act as a Topics API caller), or the supply side (publisher, i.e. website) can do the same?

Any type of site can use the Topics API. But note that advertisers are often also websites! I think it is most likely to be called by ad tech parties embedded on both advertiser and publisher web pages.

4. If website can act as an API caller (as discussed in previous question), are there any conditions[...]?

There are no conditions on whether a party can call the API. But see this description of the filtering of returned topics: a website that never observes the same user in any other context will only get information based on the user's visits to that same website.

5. Does Topics API machine learning mechanism of the query return to its caller only "historical" topics (those from previous epochs/weeks) and not topics of the website the visitor is currently browsing?

That's correct: topics are calculated for each epoch, currently once per week, and so the current visit will not have any effect on the Topics API's return values until after the next re-calculation.

[ogassav]

Thank you for this clarification Michael, may I ask to comment the last few points that are left please?

Any type of site can use the Topics API.
There are no conditions on whether a party can call the API.

So any website acting as a Publisher and participating in Topics (i.e. having Topics code integrated in their pages) can call API for every visitor of that website independently from API calls of Advertisers using this website to place their ads, right? The browser returns user topics in reply to Advertisers' API requests to their part of ad ecosystem, while Publisher gets his own list of topics (which will differ from that of Advertisers' due to filtering of returned topics that you mentioned). Did I understand this mechanism right?

But see this description of the filtering of returned topics

Yes, that's another point that is still a bit in a gray area for me. Let's assume on Epoch1 user browsed Website1 which has 2 topics - "Vacation" and "Car rental". If on Epoch2 this same user browses Website2 which has "Car rental" topic, that Website2 will get the "Vacation" topic in return to their API query too, as it already "accompanied" the "Car rental" topic on Website1 during Epoch1. I hope I understood this part of the logic correctly.

However, what if on Epoch2 the user browses Website3 instead of Website2 and that Website3 has an "Aircrafts" topic: shall topics from Website1 ("Vacation", "Car rental") stay unavailable to Website3 even though the next epoch started, because there was no "overlap" with "Aircrafts" topic in the past? In other words, API callers will only be able to see those topics, with which at least 1 of already visible topics will overlap, right?

I've heard that the iframe which runs Topics code will need to provide a token that matches its origin. What is understood under "origin" here - name of the domain the iframe is allowed to be used on, name of the company the iframe belongs to, etc.?

Browser ID (that is more of a Trust Tokens API topic, but still) - how is it formed, can it be reset by a user (like Advertising ID)?

Thank you!

[michaelkleber]

The browser returns user topics in reply to Advertisers' API requests to their part of ad ecosystem, while Publisher gets his own list of topics[...]?

Any party on the site can call the Topics API. The list of topics returned gets filtered based on what origin the call was made in, though. If the API is called in the top-level publisher page, then some topics might be filtered. If the API is called from a cross-domain iframe on the same site, then different topics might be filtered. No matter who calls the API, though, there are only a total of three topics that might show up for this particular user on this site (until they get updated for a new epoch).

Yes, that's another point that is still a bit in a gray area for me[...]

Check out the explanation of the visibility rules in our developer documentation:
https://developer.chrome.com/en/docs/privacy-sandbox/topics/#api-callers-only-receive-topics-theyve-observed
I think that should answer your questions.

I've heard that the iframe which runs Topics code will need to provide a token that matches its origin. What is understood under "origin" here - name of the domain the iframe is allowed to be used on, name of the company the iframe belongs to, etc.?

RIght now Topics is an Origin Trial, and so the iframe where the Topics API will be called needs to include an Origin Trial token to activate the experimental feature. More documentation is linked from here:
https://developer.chrome.com/en/docs/privacy-sandbox/topics/#origin-trial

Browser ID (that is more of a Trust Tokens API topic, but still) - how is it formed, can it be reset by a user (like Advertising ID)?

Sorry, I'm not familiar with "Browser ID", so I don't know where to direct you for this question.

[ogassav]

Thank you so much for the explanation and the links - appreciate your help!