Enhancements to Topics module

[patmmccann]

With the release of the topics module, #8646 two enhancements immediately come to mind:

Calling the api within a frame for an entity with a larger footprint (adnxs.com, adsrvr.com, rubicon-project.com, pubmatic.com, openx.com, and other leader teir companies, as well as sharedid.org, come to mind), possibly rotating between entities or being subject to config.

Ability to specify or override user.data.name, eg cafemedia or pubmatic or hearst, if the domain calling the api is getting results over a wider footprint than pubdomain.com

Finally, the module could, if so configured, write topics to local storage for later access, as well as set targeting to GAM.

[patmmccann]

From: https://developer.chrome.com/en/docs/privacy-sandbox/topics/

"API callers only receive topics they've observed
A design goal of the Topics API is to enable interest-based advertising without the sharing of information to more entities than is currently possible with third-party cookies. The Topics API proposes that topics can only be returned for API callers that have already observed them, within a limited timeframe.

Key Term
A Topics API caller is the entity that calls the document.browsingTopics() JavaScript method, and will use the topics returned by the method to help select relevant ads. Typically, a call to document.browsingTopics() would be from code included in a site from a third party such as an adtech platform. The browser determines the caller from the site of the current document. So, if you're a third party on a page, make sure you call the API from an iframe that your site owns.

In order for document.browsingTopics()to return one or more topics, it must be called in code from the same origin as code that was on a site where those topics were observed."

[patmmccann]

Discussion in the topics committee today indicated: an ssp rotation works, and that should be able to be supplemented by config. We also should put the contents of the frame in another repo.

[dmdabbs]

Thanks @patmmccann. Sorry I was unable to make that discussion.
Sharedid.org would also be in rotation (subject to publisher control)?

[pm-nitin-nimbalkar]

@patmmccann We (PubMatic) are interested to work on this enhancement.
Can you help us to give more insights on SSP rotations works and config will look like to work on the solution for the same.

[pm-nitin-nimbalkar]

@patmmccann Current representation of Topics in OpenRTB protocol is in BidRequest.user.data like in below format specified in
https://github.com/google/ads-privacy/tree/master/proposals/topics-rtb.

Since this is the same spec which we use for other SDA purpose and it goes under bidrequest.user.data object.

Are we planning to identify the object grouping under "topics" or have some specified in object itself that this object belong to or related to topics.
Currently there is no way to identify the object in data apart from checking the segtax (taxonomy version) and segclass

[jdwieland8282]

+1 to adding topics to user.data. It sounds like the Topics segtax will be 600?

Based on what we discussed in the taxonomy PMC on 10/25/22. This issue introduces additional functionality to the existing Topics module.

This enhancement extends the data set Topics has access to by allowing an ad tech vendor to call the Topics API from n sites it renders its iframes on, which is theoretically better than a pub calling the topics api from a single domain.

Have any DSPs expressed interest in reading the Topics in an auction? I'd still support this module moving forward even if they haven't just wondering if any have.