Multiple exchange calls issue

[pbannist]

if I understand the proposed model correctly, it would be expected that each adtech firm would call document.browsingTopics() and get its set of topics to use. The challenge with this is that most publishers are currently running 10 or 15 (or more) different exchanges through Prebid and Amazon TAM. In theory, this would require 10-15+ different iframes being created to call document.browsingTopics() before that data can be passed into normal ad exchange calls.

While there's nothing philosophically wrong with that, it seems that this would create a significant amount of new overhead/latency on publisher pages. Two potential ideas are:

1. Return Topics data in the HTTP response to callers where the referer is a Topics-enabled page/site - so then ad exchanges could get the data with existing calls and not have to create new iframes with JS calls.
2. Have one of the third-party ad partners call document.browsingTopics() early in the page load process and have them make that data available to all other ad exchanges - an obvious good choice here would be Google Ads (and I have mentioned this to them).

Are there other potential solutions worth considering? And do you agree this is a problem worth addressing?

[jkarlin]

There is a real cost (both time wise and device wise) to creating a bunch of cross-origin iframes on a page only to make a single js call. As such, we're seriously considering adding headers for this. And at the same time, separating the functionality of requesting topics into the request headers #7 , and registering that the user has been viewed on the page with a corresponding response header #54.

Closing this as it's being handled in #7.