Support for Negative Interest Group Targeting #319
Comments
|
This is tricky. There does not seem to be any great solution to this problem. I have a few suggestions below, but none is really satisfying. Given that advertisement rendering and reporting in your proposal go through the same controlled channels that normal FLEDGE interest group advertising does (i.e. Fenced Frames and reporting worklets), and that the interest group and auction configuration information flow from the same places they do in normal FLEDGE operation, I think the privacy aspects of your proposal seem reasonable. I like that your proposal encourages contextual advertising to go through the FLEDGE auction as this potentially decreases the entropy leaked by the null versus non-null auction promise result (decreasing #211 concerns). In FLEDGE today, the person using an interest group’s information to bid (represented by the origin of Option 1: Use bidding scripts Option 2: Use a signed exchange (SXG) or signed WebBundle Option 3: Use an iframe Option 4: Limit to It should be noted that several of these solutions are similar to solutions considered in #119. The interest group could list other origins they are willing to allow using this interest group for negative targeting. The listed origins would have to match one of the origins from Options 1-4. |
|
For Options 1 and 2 - normally only the IG owner can add a user to an IG, or a 3rd party explicitly delegated permission by the owner. Even forcing the bidder script to be loaded from a same-origin URL to the interest group, we're still potentially asking a bidder to bid unexpectedly. We'd probably need the bidding script to explicitly opt-in to this behavior, likely be returning an additional field in the return value to explicitly allow this use case. There are a also a rather large number of design decisions that would need to be made (Do we support bidding signals? What's the priority of the pseudo-IG? Do we need to check for k-anonymity, and if so, how do we do it? Do we have an API to also set a WASM url? What IG would we pass in to generateBid()). |
|
We would like to propose the following option for supporting negative Interest Group targeting. Disable negative targetingIf the ad owner and IG owner do not match, the ad will be shown regardless of whether the browser has joined IG or not. With this option, the matching of the owners needs to occur only if the browser has joined the negatively targeted IG. Suppose that advertiser A wants to target users who have not joined G - an interest group belonging to advertiser B. The browsers that did not join G will unconditionally allow negative targeting of G. The browser that joined G, however, will not show the ad only if the owners match. This will make A negatively targeting G fail, since the exclusion of browsers that joined G will be prevented. Use of digital signaturesInstead of passing the bid value and ad URL in as part of negativeTargetingAds, pass in a SXG or signed WebBundle that specifies the bid value and the ad URL, or contains a Seller - buyer interaction for negative IG targetingIt is SSP owned code that receives the negative IG targeting DSP data. This arrangement allows SSPs to filter and rank negative IG targeted ads before the FLEDGE auction. DSPs need to provide two categories of negative IG targeting data to the SSP.
SSP code will be able to use category 1 data to perform filter or other processing. If SSP decides that negative IG targeting metadata can proceed to the auction, it will move category 2 data into the auction config prior to initiating FLEDGE auction. DSPs could provide metadata about negative interest group targeting of ads to SSPs through the regular OpenRTB bid response (see https://iabtechlab.com/wp-content/uploads/2022/04/OpenRTB-2-6_FINAL.pdf section 4) with custom Bid object extension fields, for example ( Chrome will validate If an SSP decides that a given ad can participate in the FLEDGE auction, it will add the following to the auction config: Here, |
What does this mean? Can you clarify intent of |
|
buyer_ad_metadata will be initially consumed by the seller on the serverside. It will contain the data required by the seller to decide whether the ad can enter the auction, and the data required by the seller to optionally log information about the ad. If the seller decides to pass the ad to the browser-side auction, it will add the metadata to the auction config, possibly modifying "price" (since "price" should be seller's desirability score). On the browser, Chrome owned code will use the data to decide whether the ad wins the auction. If the ad wins, Chrome will use "nurl" to notify the buyer about the outcome of the auction. Currently, the rendering mechanism is underspecified. Nevertheless, Chrome code will also initiate the rendering if the ad wins. |
|
Using a WebBundle from the DSP that owns the IG being negatively targeted to fully generate the bid, and identify the IG being negatively targeted (or at least confirm it) does sound like it could be viable to me, from privacy and security standpoints. |
|
@MattMenke2 can you clarify what you mean by 'WebBundle from the DSP' in this context - assuming for now it is an SSP that returns an ad response to the device? |
|
I mean the IG owner. I don't think we can expose IGs to 3P scripts without buy-in from the IG owner. Using ads generated by the IG owner is the way FLEDGE currently accomplishes that. |
JensenPaul
added
the
Non-breaking Feature Request
|
Hi everyone. I've been thinking about this problem for a bit, and I have a design I'd like to propose, which is mostly aligned with the comments above. With this design, it's possible to pass additional bids into There are a few subtle differences worth noting between these additional bids and InterestGroup-based bids (those produced by calls to
Each additional bid would be represented by a JSON object containing all of the data we need for that bid to participate in the auction alongside InterestGroup-based bids. Each of the additional bids would need to be enclosed in a signed exchange (SXG, https://web.dev/signed-exchanges/) — a data structure that bundles together a URL, its associated response, and a signature for validation — so that the auction can verify that the additional bid came from the buyer, unmodified. The response payload of each additional bid's corresponding signed exchange would contain the JSON object representing that bid. That object would include the following fields, split into three categories:
This design implements a series of protections to ensure that additional bids may be used only for the auction for which the buyer intended.
For each additional bid, the URL associated with the signed exchange must have the origin of the associated buyer, but may otherwise have any path or query string that uniquely identifies that bid. The owner of the additional bid is implied by the origin of the signed exchange, and it must be this owner whose certificate is used to sign the exchange. This URL is only used in the user's browser as an identifier, and no attempt will be made to fetch an additional bid from its origin. As is the case for InterestGroups, the To get these additional bids into the auction, we'll add a new For each additional bid, the auction will first check to see if the user is a member of the specified The auction will call |
|
One clarification based on feedback received on the proposal above. This design is only intended to address the use case of negatively targeting contextual ads and other ads not triggered by the presence of a positive InterestGroup (non-remarketing). One thing that led to this confusion is that, among the data provided for each additional bid, a bid needs to specify an "InterestGroup name" via the interestGroup.name field. This InterestGroup name does not map to an existing InterestGroup, and it's only needed/used when reporting the win of an additional bid. Thanks for the feedback. |
|
@orrb1 thank you for the design proposal follow-up. Interesting stuff. Would be great to discuss in this week's Wednesday PAAPI call. I added it to end of tomorrow's agenda. Hope you or @morlovich are available to field questions & suggestions. |
This is slightly weird because additional bids are blobs containing signed exchanges, so unlike other parts of configuration we don't want to be copying them all over the place (and the worklets probably shouldn't see them, anyway), so the config just has a bool (used to track whether config is resolved) and the value is stored out-of-line. The context for this work is WICG/turtledove#319 (comment) Bug: 1464874 Change-Id: I85c20f8bd51d02938b993b0b643221be5e2806f9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4665909 Commit-Queue: Maks Orlovich <[email protected]> Reviewed-by: Mike Taylor <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Caleb Raitto <[email protected]> Cr-Commit-Position: refs/heads/main@{#1176631}
|
One piece of feedback received on the design above is that the option to specify only a single negativeInterestGroup is overly limiting. In order to improve the usability of this feature, we're expanding it to allow multiple negativeInterestGroups, with the restriction that, when multiple negativeInterestGroups are specified, all must have been joined from a single origin specified as part of the additional bid. This restriction won't apply to additional bids that specify only a single negativeInterestGroup. When a single negativeInterestGroup is specified, that InterestGroup may have been joined from any origin, or even from multiple origins. To support this, we'll use a syntax that distinguishes the single negativeInterestGroup case from the multiple negativeInterestGroups case. For a single negativeInterestGroup, we use the same syntax expressed in the design above: To specify multiple negativeInterestGroups, buyers would use the following syntax: Edit(8/23/23): Modified the joining origin to include the protocol. |
|
As we worked to implement our previous design, we ran into some headwinds with our use of Signed Exchanges (SXGs). It’s unclear if we needed all the comprehensiveness of SXGs, so we’re considering a somewhat simpler approach that involves the following tweaks to the previous proposal:
When the browser considers whether to block an additional bid based on whether its It should be noted that the browser has less verification that the Because the browser is no longer verifying the additional bid's signature in cases where the negative interest group is present, it could be tampered with. This represents a difference with the interest group that is normally passed to reporting functions |
|
I think @orrb1 meant "is not present" when he said "is present" in the last comment. |
Per WICG/turtledove#319 (comment) it's not a self-contained blob, but rather contains a payload + associated crypto public keys/signatures in a structured way. Bug: 1464874 Change-Id: I82c97bc543706b888d708b26347bc3650992d02b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4753244 Reviewed-by: Robert Sesek <[email protected]> Reviewed-by: Caleb Raitto <[email protected]> Commit-Queue: Maks Orlovich <[email protected]> Cr-Commit-Position: refs/heads/main@{#1181442}
See WICG/turtledove#319 (comment) for more context. Bug: 1464874 Change-Id: I4bc7a3cf09adcb37a39ddfdb47a4b1d4fdb846d9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4807384 Reviewed-by: Caleb Raitto <[email protected]> Commit-Queue: Maks Orlovich <[email protected]> Cr-Commit-Position: refs/heads/main@{#1189154}
|
With the shift away from signed exchanges, we no longer can verify that the additional bids are untampered with by other JavaScript in the context that calls To use response headers to convey the additional bids, the request to fetch additional bids will first need to specify the The response will then need to include the additional bids not as part of the body of the HTTP response, but rather as response header values. Each instance of the These HTTP response headers are intercepted by the browser, diverted to participate in the auction, but removed from the HTTP response headers seen in JavaScript. The additionalBids field on the auction config will be a Promise of type undefined, since it needs no value, but rather is only used to express that all additional bids for that auction have arrived. When all of the header-based additional bids for an auction have been received, the additionalBids Promise should be satisfied. The browser will use this to accept the bids provided by the |
Each additional bid may specify one or more negative targeting InterestGroups. To guarantee that only the owner of those InterestGroups may use them for negative targeting, each additional bid is signed with one or more ed25519 secret keys. The corresponding public keys are part of each InterestGroup used for negative targeting, and the browser will first verify that one of the signatures of the additional bid matches the key on the InterestGroup before allowing its use for negative targeting. More details on this are available at WICG/turtledove#319 (comment). Bug: 1464874 Change-Id: I89a33a28dc973ca0f5cda7ecd92cbeebef214253 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4808727 Reviewed-by: Robert Sesek <[email protected]> Commit-Queue: Orr Bernstein <[email protected]> Reviewed-by: Russ Hamilton <[email protected]> Cr-Commit-Position: refs/heads/main@{#1190332}
The design for additional bids and negative targeting was first discussed at WICG#319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API.
The design for additional bids and negative targeting was first discussed at WICG#319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API.
The design for additional bids and negative targeting was first discussed at WICG#319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API.
The design for additional bids and negative targeting was first discussed at WICG#319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API.
The design for additional bids and negative targeting was first discussed at WICG#319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API.
The design for additional bids and negative targeting was first discussed at WICG#319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API.
The design for additional bids and negative targeting was first discussed at WICG#319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API.
|
Owners providing addtional bids must also pass the enrollment gating, yes? |
* Add Additional Bids and Negative Targeting to the Explainer. The design for additional bids and negative targeting was first discussed at #319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API. * Add Additional Bids and Negative Targeting to the Explainer. The design for additional bids and negative targeting was first discussed at #319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API. * Add Additional Bids and Negative Targeting to the Explainer. The design for additional bids and negative targeting was first discussed at #319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API. * Add Additional Bids and Negative Targeting to the Explainer. The design for additional bids and negative targeting was first discussed at #319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API. * Add Additional Bids and Negative Targeting to the Explainer. The design for additional bids and negative targeting was first discussed at #319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API. * Add Additional Bids and Negative Targeting to the Explainer. The design for additional bids and negative targeting was first discussed at #319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API. * Add Additional Bids and Negative Targeting to the Explainer. The design for additional bids and negative targeting was first discussed at #319. A short summary of these featues follows. In online ad auctions for ad space, it’s sometimes useful to prevent showing an ad to certain audiences, a concept known as negative targeting. For example, you might not want to show a new customer advertisement to existing customers. New customer acquisition campaigns most often have this as a critical requirement. We enable this new use case in the Protected Audience API by allowing buyers to provide "additional bids", which are not generated during the auction based on InterestGroups membership like other bids, but are instead provided as part of the seller's signals request. Today, the seller uses this request to run their contextual auction and return a single winning ad that sets a lower bar that remarketing ads must beat to be shown. In this new model, the seller instead forwards some number of additional bids on behalf of the buyer to the auction running in the user's browser. Each additional bid is allowed to identify one or more InterestGroups that can be used for negative targeting. If the user has been joined to any of the identified InterestGroups, the additional bid is dropped. All remaining additional bids participate in the auction alongside bids generated by InterestGroup membership. Special care is taken to ensure that additional bids are only used in the auction for which the buyer intended them, that these bids are not modified in transit, and that the InterestGroups used for negative targeting are only usable by their owner. In this way, we're enabling advertisers to target new groups of users using the existing privacy-preserving concepts of the Protected Audience API.
Yes, that's correct. An additional bid's owner has to satisfy the same requirements as the owner of a bid created from a |
|
The negative targeting design described above has been implemented and documented in the Protected Audience explainer at https://github.com/WICG/turtledove/blob/main/FLEDGE.md#6-additional-bids. There's one upcoming change to the implementation. The only field of a negative targeting interest group that can currently be updated is Supporting a 30 day key rotation, each additional bid should be signed with both the current and previous
In Chrome versions M119 and later, |
|
@orrb1 Does the seller pass the auctionNonce to buyer in contextual call request? It seems this is not documented in https://github.com/orrb1/turtledove/blob/main/FLEDGE.md#6-additional-bids. My understanding of the auctionNonce flow is:
|
|
https://github.com/WICG/turtledove/blob/main/FLEDGE.md#63-http-response-headers mentioned the need to send a fetch request with adAuctionHeaders specified. However, some of our ad tags uses iframe navigation. Changing the default rendering mode of it would be a significant product and engineering lift. Could Chrome support an iframe-based version of the adAuctionHeaders API, e.g., create an iframe attribute, <iframe src="example.com" adAuctionHeaders>, and use that to signal to the browser that it should look for additional bids encoded as HTTP response header? |
|
@ryanluz: That's correct. Beyond that, the auction nonce also needs to appear in the JSON of the additional bid, as described at https://github.com/orrb1/turtledove/blob/main/FLEDGE.md#61-auction-nonce: "The same nonce value will need to appear in the auctionNonce field of each additional bid associated with that auction config." @xxia2021: Thanks for the feedback. We're exploring this. FYI to all: negative targeting has been launched for testing to 50% on Chrome's canary and dev releases. |
Question: How will the seller in the contextual auction know if this fetch flag was specified in the |
|
@rdgordon-index - The |
|
Thanks, @orrb1. |
@orrb1 I'm wondering what is the flag to enable this in canary/dev? |
|
@ryanluz - The flag is FledgeNegativeTargeting. Thanks. |
|
Update: Additional bids and negative targeting have now been ramped to 100% of traffic in all Chrome release channels. Those who plan to rely on these features should continue to do so conditionally using feature detection to ensure that their experience works for users using all versions of Chrome. More details on how to feature detect negative targeting can be found at https://github.com/WICG/turtledove/blob/main/PA_Feature_Detecting.md#negative-targeting. |
|
Hi - will there be any solution for a suppression campaign outside the retargeting flow? For example, when an advertiser is uploading a CSV of IDs, it wishes to exclude or when a DSP wants to serve/not serve an ad to excluded user contextually (outside the retargeting flow)? |
|
@omriariav The Negative Targeting work that Orr described is indeed a "solution for a suppression campaign outside the retargeting flow." To exclude a user from a particular contextually-targeted campaign, you add the user to a Negative Interest Group and then include the contextually-targeted ad as an Additional Bid. For details see https://github.com/WICG/turtledove/blob/main/FLEDGE.md#62-negative-targeting |
|
#319 (comment)
Contextual signals refers to what? Do you mean the "Server side auction" part of this workflow? https://developers.google.com/authorized-buyers/rtb/protected-audience-api#serving_flow_summary
Who is responsible for invoking the fetch request (or iframe logic)? Please explain where & how this happens in the workflow: https://developers.google.com/authorized-buyers/rtb/protected-audience-api#serving_flow_summary We are confused as to how
The explainer & other documentation is not very helpful in the details of negative targeting workflow. |
|
Thanks for the question about how additional bids are returned from buyers back to the on-device auction. This paragraph in the explainer aims to provide a high-level overview of this flow:
From the perspective of the browser, additional bids must be fetched from a Fetch request or iframe navigation to the seller's server, but the browser is not opinionated as to when this Fetch request or iframe navigation would need to happen. This is why the explainer isn't more explicit on how this interaction should happen. Using In the "Server side ad Auction":
In the "In browser Auction" section:
|
|
Are
but it's not clear to me from the explainer:
AFAIK, |
|
It's a mandatory field in additionalBid. I'll defer to Orr on the motivation behind this (whether it's to prevent replay attacks, or make sure the bidder is fully informed of the context of the auction, since there is no generateBid() call where that normally happens, or something else). |
The current FLEDGE API only supports positive Interest Group targeting: allowing advertisers to show ads to users that have interacted with their site. Advertisers are not just interested in re-engaging existing customers; advertisers are also interested in attracting new customers. Within FLEDGE, targeting this group of users requires an API change to support negative IG targeting: showing ads only if a user does not belong to an IG. Here we are specifically proposing a mechanism for negative IG targeting for non-FLEDGE ads.
This can be made to work in a way that is compatible with the privacy sandbox principles. We propose something like the following extension of FLEDGE.
In the
auctionConfig, we add a new optional fieldnegativeTargetingAds:where each
externalAdis only eligible if the user does not have the corresponding IG. TheexternalAdobject has adesirabilityfield, a 'bid' field for reporting purposes, and arenderfield. Note that server-side the SSP can vet the DSPs' ads, apply any sellside specific logic, and select the top one per negative IG. Then, the externally supplied ads that are eligible can compete with the positive IG ads'desirabilityoutput fromscoreAd.To maintain privacy, if one of the negative IG ads wins, then it goes through the FLEDGE rendering and reporting flow; that is, it will be rendered via the FLEDGE
auctionResultPromisebeing passed into a Fenced Frame. A null response fromrunAdAuctionwill indicate neither a positive nor negative interest group ad won the browser auction. The seller reporting would be unchanged, except perhaps from some 'browserSignals' field indicating that it was negative targeting. TheexternalAdprovides a 'reportingLogicUrl', which provides the buyer reporting functionreportWin. ThereportWinfunction should follow the same spec as when a regular IG ad wins in FLEDGE.Furthermore, the ad would be subject to the same k-anonymity requirements.
The text was updated successfully, but these errors were encountered: