Make Real-time reporting API opt-in not seller-dependent for buyers

[ccharnay67]

Hello,

At the moment, opt-in for real-time reporting API has to go through seller auction configuration. This makes it a bit more difficult for buyers, including us, to enable the API and start receiving reports, as we depend on sellers and whether they would prioritize this ask.

We understand the considerations that led to this design choice the considerations that led to this design choice. We would be in favour of enabling the reports for buyers by default, as is the case with Private Aggregation API where sending reports does not need to be enabled by sellers.

If avoiding wasted bandwidth is a concern, could you consider a way for buyers to indicate opt-in without going through the sellers? Maybe through a field in the interest groups?

Thank you.

[wojtek-rybak]

At RTB House, we likewise think that the current mechanism requiring coordination with the sellers is inconvenient, and a new mechanism allowing the use of the API without involving the sellers would be useful.

@michal-kalisz raised a similar issue under the initial draft. Although his suggestion was dismissed, further discussion was promised.

Dear Chrome team, are there any plans to add such a feature?

[dmdabbs]

A Wednesday WICG call would be a great place to raise awareness directly with the Chrome team.

[wojtek-rybak]

Thank you @dmdabbs, I will certainly do this.

[wojtek-rybak]

As I mentioned earlier, the current opt-in mechanism is not particularly useful for our needs as a buyer. Our main concerns are:

• Lack of control: We cannot turn off the API at will, which limits our ability to respond to system overloads.

• Lack of visibility: There is no way to confirm whether a specific seller is actually sending reports, making it more difficult to integrate with a new seller.

After some brainstorming, we came up with two ideas for improving the current opt-in mechanism. These ideas are arranged in order of preference, starting with the most preferred option.

I’m sharing this list here, but as suggested earlier, I will also present it at the upcoming WICG call.

1. Use Contextual Signals
   The browser (or B&A services) could process predefined keys from perBuyerSignals that act as configurations set by the buyer. For example, we could introduce a special key, buyerAuctionConfig, which the browser would process to read configurations provided by the buyer.
   Advantages:

   • The buyer has full control over API activation and can use it for sampling or monitoring specific sellers.
   • The buyer always knows whether the Real-Time API is enabled.
   • This is a generic mechanism that can be extended to other uses in the future.
   • It does not require changes to existing integrations.
   • No additional calls are needed.

2. Use .well-known/dsp-auction-config.json
   This approach involves providing an optional resource: a JSON file containing auction configuration from the buyer’s side. The browser could cache this response based on HTTP cache headers. If this configuration exists, it would override the settings provided by the seller.
   Advantages:

   • The buyer controls API activation and can enable it independently of the seller. A more fine-grained per-seller configuration is also possible.
   • It allows for browser-side sampling, which can be implemented using additional parameters in the configuration file.
   • It does not require changes to existing integrations.
   • The buyer can define cache duration, balancing performance and responsiveness for toggling the API on/off.

[fhoering]

Ideally we don't introduce any additional network calls and we also don't reuse something from inside the per buyer signals as the should be kept in full control of the buyer to be able to be encoded, signed or encrypted.
I would vote for a new field in the Open RTB bid response that the seller propagates to auctionConfig, so similar to how currencies work.