The Topics API provides one zero-argument function document.browsingTopics(), which serves three logically distinct purposes:

1. Getting topics about the user. This is the obvious one.
2. Determining caller eligibility to receive the topic from future calls of the API.
3. Building up the user's set of top 5 topics for the epoch of the current call.

It would be useful to provide a little more control over these three different aspects of the API. In particular, there is some tension between the first two and the last use case. For the first two use-cases, there is no downside (aside potentially from some latency) to calling the API. Each ad tech is incentivized to call the API whenever possible, either to get useful signals or enabling nonempty responses for future calls to the API.

On the other hand, there are potential downsides to calling the API when it comes to the third point. For example, for a very large publisher site with generic, not commercially relevant topics at the domain/subdomain level. The ad tech might like to call the API to get useful signals, but with the current API it may not be worth the risk of potentially contaminating the users' future top 5 topics with the generic, not commercially relevant topics.

It would be beneficial to perhaps provide an argument that controls the behavior, something like browsingTopics(add_current_topics=true). Since eligibility is determined per API caller there should be no ecosystem concern about "freeloaders" getting other callers topics without contributing. There also does not seem to be any detrimental effect on user privacy. While the concern mentioned above might be partially mitigated by improved Topics ranking and commercially focused taxonomy changes, it seems best to provide this flexibility for API callers so they have flexibility in how they use the API.