Add Additional Bids and Negative Targeting to the Explainer. #780
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
dmdabbs
reviewed
Sep 5, 2023
| "bid": 1.99, | ||
| "bidCurrency": "USD", | ||
| "render": "https://www.example-dsp.com/ad/123.jpg", | ||
| "adComponents": [adComponent1, adComponent2], |
There was a problem hiding this comment.
Is this a copy/paste remnant? If not, then how are ad components used in add'l bids?
There was a problem hiding this comment.
This was intentionally copied from 3.2 On-Device Bidding, alongside the other parts of the bid. Ad components for additional bids are handled the same way they are for bids created by a call to generateBid(), except that, because there's no stored InterestGroup associated with the additional bid, the restriction that each adComponent must match a value from the InterestGroup's adComponents field doesn't apply. I've added some clarification in the text below.
dmdabbs
reviewed
Sep 5, 2023
FLEDGE.md
Outdated
|
|
||
| #### 6.1. Auction Nonce | ||
|
|
||
| To prevent unintended replaying of additional bids, any auction config, whether top-level or component auction config, must include an auction nonce value if it includes additional bids. The auction nonce is fetched provided like so: |
dmdabbs
reviewed
Sep 5, 2023
FLEDGE.md
Outdated
| } | ||
| ``` | ||
|
|
||
| If an additional bid needs to specify two or more negative interest groups, all of those negative interest groups must be joined from the same site, and that site must be identified ahead of time in the additional bid using the joiningOrigin field: |
There was a problem hiding this comment.
that site must be identified ahead of time in the additional bid using the joiningOrigin field
Both site and origin are used. Which is it? Specifying a site would give adtechs & advertisers flexibility similar to that afforded in ARA where destination site(s) are specified when registering an event. Advertisers may have multiple subdomains/properties where a negative IG could have been tagged.
There was a problem hiding this comment.
Point well taken regarding the distinction between site and origin. The restriction on multiple negative interest groups is that they must be from the same origin. I've updated the wording here to make it clearer.
dmdabbs
reviewed
Sep 5, 2023
FLEDGE.md
Outdated
|
|
||
| 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. | ||
|
|
||
| To facilitate negative targeting in Protected Audience auctions, each additional bid is allowed to identify one or more negative interest groups. If the user has been joined to any of the identified negative interest groups, the additional bid is dropped; otherwise it participates in the auction, competing alongside bids created by calls to generateBid(). |
There was a problem hiding this comment.
each additional bid is allowed to identify one or more negative interest groups
An additional bid may specify no negative targeting?
There was a problem hiding this comment.
Yes. An additional bid that specifies no negative interest groups is always accepted into the auction. I've updated the text here to clarify that.
dmdabbs
reviewed
Sep 5, 2023
FLEDGE.md
Outdated
|
|
||
| When the buyer issues an additional bid, that bid needs to be signed using their Ed25519 secret key. During a key rotation, the buyer may need to provide a signature of the additional bid with both the old and the new additionalBidKeys while negative interest groups stored on users' devices are updated to the new key. It's for this reason that additional bids may have more than one signature provided alongside the bid. | ||
|
|
||
| If the signature doesn't verify successfully, the additional bid proceeds as if the negative interest group is not present. This "failing open" ensures that only the owner of the negative interest group, who created the additonalBidKey, is allowed to negatively target the interest group, and that nobody else can learn whether the interest group is present on the device. Because the signature check "fails open", buyers should make sure they're using the right keys; for example it might be pertinent to verify a bid signature before submitting the additional bid. |
There was a problem hiding this comment.
signature doesn't verify successfully, the additional bid proceeds as if the negative interest group is not present
I suppose this implicitly answers the earlier question whether an additional bid may specify no negative IG info.
There was a problem hiding this comment.
Yes. Hopefully this is clarified by the text added above.
dmdabbs
reviewed
Sep 5, 2023
FLEDGE.md
Outdated
|
|
||
| When a buyer joins a user into a negative interest group, they must provide their 32-byte Ed25519 public key, expressed as a base64-encoded string, via the negative interest group's additionalBidKey field. This can be seen in the example above in section 6.2.1 Negative Interest Groups. The additionalBidKey can be then updated via the negative interest group's updateURL, for example, to enable a buyer to rotate their Ed25519 key pair faster than they could with the expiration of their negative interest groups alone. | ||
|
|
||
| When the buyer issues an additional bid, that bid needs to be signed using their Ed25519 secret key. During a key rotation, the buyer may need to provide a signature of the additional bid with both the old and the new additionalBidKeys while negative interest groups stored on users' devices are updated to the new key. It's for this reason that additional bids may have more than one signature provided alongside the bid. |
There was a problem hiding this comment.
the buyer may need to provide a signature of the additional bid with both the old and the new additionalBidKeys while negative interest groups stored on users' devices are updated to the new key
Does the provision of dual keys 'trigger' a call to the optional updateURL, or does this happen in the normal PAAPI course of it being called once daily sometime after a bid win?
There was a problem hiding this comment.
Negative interest groups are updated at the same time and in the same way as regular interest groups. I've added some text here to clarify.
dmdabbs
reviewed
Sep 5, 2023
| // seller and topLevelSeller must match the auction's configuration. | ||
| "seller": "https://www.example-ssp.com", | ||
| "topLevelSeller": "https://www.another-ssp.com" | ||
| } |
There was a problem hiding this comment.
Buyers have so far remained insulated from multi-seller mechanics/identities. If I read this correctly, a buyer's signed additional bid must contain the topLevelSeller.
There was a problem hiding this comment.
The seller and topLevelSeller fields here are meant to echo those present in the browserSignals argument to generateBid(). I've removed the brief descriptions of these fields inlined in the additional bid JSON snippet above, and instead add richer descriptions in the paragraphs below it, including a clarification of this point.
There was a problem hiding this comment.
A seller may have a relationship with a topLevelSeller that is opaque to a buyer. Or a buyer might not care who exactly the topLevelSeller is. Is there a mechanism for a buyer to specify an additional bid in such a way that matches any topLevelSeller, including no topLevelSeller at all?
dmdabbs
reviewed
Sep 5, 2023
| "render": "https://www.example-dsp.com/ad/123.jpg", | ||
| "adComponents": [adComponent1, adComponent2], | ||
| "allowComponentAuction": true, | ||
| "modelingSignals": 123, |
There was a problem hiding this comment.
Since additional bids are not targeted using IG data, and are not subject to k-anon, will the modelingSignals be noised & bucketed?
There was a problem hiding this comment.
Yes. For consistency, the values passed into reportAdditionalBidWin() for additional bids will be the same as those passed into reportWin() for winning bids generated from stored interest groups.
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.
JensenPaul
added
the
Non-breaking Feature Request
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.
github-actions bot
added a commit
that referenced
this pull request
Sep 13, 2023
SHA: 7ab0ab5 Reason: push, by JensenPaul Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The design for additional bids and negative targeting was first discussed at #319. A short summary of these features 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.