Feature Request: add support for fetch endpoints to topics module

[patmmccann]

Type of issue

Feature Request

Description

Topics from the fetch headers may be more richly populated than topics gathered in the iframe. This feature request is to add support for an endpoint that reflects the topics it saw on a fetch api call headers instead of an injected frame doing a post message. Docs
Demo

[pm-harshad-mane]

The Topics are generated as per the user's browsing history so I am assuming that the generated Topics for a user will not change drastically within a day.
The Fetch end-point for Topics needs a server-side infrastructure.
To save the infra cost, we can avoid frequent calls to the end-points by caching the response on the client side in the first-party local storage.
The Topics module can take care of managing the cache and calling the SSP Fetch endpoints when the cache is stale.
@patmmccann please share your thoughts.

[patmmccann]

The Topics are generated as per the user's browsing history so I am assuming that the generated Topics for a user will not change drastically within a day.

They change weekly, but I think it is hard to predict when the week would end for a given user.

the Topics module can take care of managing the cache and calling the SSP Fetch endpoints when the cache is stale.

this seems wise, assuming it is configurable and subject to publisher device access consent, like sharedid module. However, calling the api affects the training so one would likely want to do the fetch again on a different page on the same site assuming the topics module may at some point incorporate that info. If that date comes, we'll likely need to change caching assumptions

[github-kevin-margueritte]

Hello,

As you may already know, Chrome 115 is now available and comes with the Topics API. I haven't closely followed the implementation of the iframe in Prebid and the limitations that led to the current proposal. However, I see some drawbacks with the solution proposed by Google.

As suggested in this ticket, it would be great to have an additional option on the adapter to use Fetch instead of XHR to send user topics during the bid request (this option could be implemented here). Furthermore, granting the adtech actor full control of topics and allowing them to update the classifier by returning the HTTP header Browsing-Topics: ?1 seems to be a more flexible and performant method, as recommended by Google. Are there any plans to implement this solution, and is there any way we can help with it?

[patmmccann]

@github-kevin-margueritte this comment is a dupe of another issue, #9980, recode ajax to fetch and allow topics to be appended. This issue, 9981, is specific to the topics module, which intends to share topics from a limited set of topics networks with all bidders

[remysaissy]

Follow-up on #10124 (comment) conversation since I understand it is closer to a feature request than an expected PR comment.
@jlquaccia, yes either 0 or all by default would make more sense to me in my opinion.

[jlquaccia]

@remysaissy yea since this module would require a custom config setup for each participating bidder/ssp that wants to utilize it, I think the default at this point in time should be 0.

[dgirardi]

@jlquaccia , does #10124 close this?

[jlquaccia]

@dgirardi, yes #10124 closes this ticket 👍