Regarding the Pre-bid IVT models, we highly value the ability to block traffic pre-bid, since not only can it guarantee that we don't spend budget on invalid traffic, but it also saves the resources to process this traffic.
We are concerned about the loss of some information available pre-bid and losing the ability to detect forms of IVT that are best detected pre-bid.
Interest groups seem like a good signal to distinguish human from non-human traffic based on their browsing behavior. We understand that a user not assigned to any interest group would not trigger any FLEDGE requests, which in itself should remove some forms of non-human traffic.
Besides, interest groups may be a good way to cluster together traffic from groups of bots designed to browse similar websites therefore generating similar browsing patterns. Therefore, interest groups could provide a good way to identify traffic from botnets leveraging browser-based automation frameworks or headless browsers. How does this proposal intend to filter out such traffic in the contextual FLEDGE request, if no interest-group data is passed? Would browser vendors be responsible for filtering out this traffic?
As for interest-group only requests, the main use cases for contextual data pre-bid are:
Brand safety: ability to block unsafe publishers globally or for a set of advertisers that may not want their brand to show ads on them.
For IVT, in particular app/domain spoofing: blocking traffic from untrusted publishers or from sellers not declared in a publisher's ads.txt/app-ads.txt
We understand that we would be able to apply those checks to the contextual request and pass the derived signals directly into the auction, however we would like to raise a few concerns:
For the use cases listed above, there would need to be different types of flags: whether to participate in the auction or not, and possibly allowlists/blocklists of advertisers that may or may not want to serve ads based on language, publisher or content/category. Will those signals be standardized and will there be a list of acceptable fields that we can pass?
This may lead to very long allowlists/blocklists to be passed in the auction, how can this proposal ensure this system scales and remains tractable and with acceptable latencies when having multiple buyers, each with potentially very long lists of blocked/allowed advertisers for the opportunity?
If these signals are only used in the final on-device auction, will we be required to submit several bid responses on the interest-group only request in case one of them turns out to not be eligible?
Regarding the Pre-bid IVT models, we highly value the ability to block traffic pre-bid, since not only can it guarantee that we don't spend budget on invalid traffic, but it also saves the resources to process this traffic.
We are concerned about the loss of some information available pre-bid and losing the ability to detect forms of IVT that are best detected pre-bid.
Interest groups seem like a good signal to distinguish human from non-human traffic based on their browsing behavior. We understand that a user not assigned to any interest group would not trigger any FLEDGE requests, which in itself should remove some forms of non-human traffic.
Besides, interest groups may be a good way to cluster together traffic from groups of bots designed to browse similar websites therefore generating similar browsing patterns. Therefore, interest groups could provide a good way to identify traffic from botnets leveraging browser-based automation frameworks or headless browsers. How does this proposal intend to filter out such traffic in the contextual FLEDGE request, if no interest-group data is passed? Would browser vendors be responsible for filtering out this traffic?
As for interest-group only requests, the main use cases for contextual data pre-bid are:
We understand that we would be able to apply those checks to the contextual request and pass the derived signals directly into the auction, however we would like to raise a few concerns: