BuyerAndSellerReportingId overwrites BuyerReportingId

[zhuoli-fledge]

As per the privacy sandbox guidance, buyerAndSellerReportingId will overwrite buyerReportingId when generateBid does not return selectedBuyerAndSellerReportingId.

This is unexpected because buyerReportingId contains information that buyer does not want to share with seller. If an ad contains buyerReportingId, buyerAndSellerReportingId and selectableBuyerAndSellerReportingIds but generateBid does not return selectedBuyerAndSellerReportingId, buyer still wants to know buyerReportingId.

[dmdabbs]

Chrome permits returning an empty string for selectableBASRI (pretty sure you still have to declare this in each of the IG's ads 🙄) so you can get all your ids.

[zhuoli-fledge]

Chrome permits returning an empty string for selectableBASRI (pretty sure you still have to declare this in each of the IG's ads 🙄) so you can get all your ids.

The problem is not at selectableBASRI but at selectedBASRI. Even if the buyer provides buyerReportingId, buyerAndSellerReporingId, selectableBASRI (non-empty) for a particular ad, it does not mean that generateBid will always return selectedBASRI. When the selectedBASRI is not returned from generateBid, buyer still wants to know the buyerReportingId, which currently is infeasible because of this overwriting behavior.

[dmdabbs]

When the selectedBASRI is not returned from generateBid, buyer still wants to know the buyerReportingId, which currently is infeasible because of this overwriting behavior.

I'm with you there.
As I understand it, one can return selectedBuyerAndSellerReportingId="" and unlock your other ids in reporting.
IMO ids, especially BASRI (intended to accommodate seat ids), need a rethink.

[zhuoli-fledge]

As I understand it, one can return selectedBuyerAndSellerReportingId="" and unlock your other ids in reporting.

Yes this will do the work. I hope if Chrome folks can confirm this behavior.

[zhuoli-fledge]

Additionaly, if selectedBASRI is not from selectableBASRI, what is the overwriting behavior here?

[dmdabbs]

As I recall from the FLEDGE call, the empty string selectedBASRI returned with the bid must be present in the corresponding ad in IG.ads[].selectableBASRI[]. Per Explainer,

if it's not in the array, the bid is ignored

My bid was rejected with

Worklet error: https://testhost.net/static/bidding-logic.js generateBid() bids sequence entry: Invalid selected buyer and seller reporting id

[zhuoli-fledge]

As I recall from the FLEDGE call, the empty string selectedBASRI returned with the bid must be present in the corresponding ad in IG.ads[].selectableBASRI[]. Per Explainer,

if it's not in the array, the bid is ignored

My bid was rejected with

Worklet error: https://testhost.net/static/bidding-logic.js generateBid() bids sequence entry: Invalid selected buyer and seller reporting id

This means that when an ad has selectableBASRI, the buyer should always put an empty string just in case generateBid can set selectBASRI as this empty string. In this way the overwriting behavior can be prevented.

This sounds odd to me. I hope Chrome folks can clarify if this is the intention.

[jeremybaoty]

Hi Zhuoli and David,

Thanks for having this discussion here. I agree with David’s suggestions:

• In Zhuoli’s case, we recommend always returning a value in selectedBuyerAndSellerReportingId

• selectedBuyerAndSellerReportingId="" can be returned if no real selectableBuyerAndSellerReportingId is selected in a bid. This does mean that you need to add an empty string into selectableBuyerAndSellerReportingIds, so that the empty string can be a valid value in selectedBuyerAndSellerReportingId.

• Please note that returning a selectedBuyerAndSellerReportingId - even an empty string - will cause the bid to be considered k-anonymous only if the reporting IDs are also k-anonymous, as described in the Reporting IDs developer guide.

We designed it this way to ensure that the existing API behavior won’t be impacted by the new change. buyerReportingId, buyerAndSellerReportingId, and the overwriting behavior (buyerAndSellerReportingId overwrites buyerReportingId) already exist today. With the introduction of selectableBuyerAndSellerReportingIds, we understand that some developers want to use all of these reporting IDs at the same time, but we also don’t want to introduce a breaking change to existing users of the original fields; therefore, we only cancel the overwriting behavior when selectedBuyerAndSellerReportingId is present in a bid.

If you used buyerReportingId prior to the introduction of selectableBuyerAndSellerReportingId, we want to bring to your attention the fact that if you begin to use buyerAndSellerReportingId on Chrome clients without selectableBuyerAndSellerReportingId support or with that support disabled, you will not receive your buyerReportingId. To ensure you receive your buyerReportingId you should avoid using buyerAndSellerReportingId. One way to do this while still using selectableBuyerAndSellerReportingId is to repeat in each entry of selectableBuyerAndSellerReportingId the data you would otherwise have included in buyerAndSellerReportingId. It may be advisable to avoid buyerAndSellerReportingId if you want to continue always receiving buyerReportingId until selectableBuyerAndSellerReportingId is fully rolled out (i.e. the chance of an emergency roll-back has subsided).

We are currently working on rolling out selectableBuyerAndSellerReportingIds to 100%, so that ad tech partners can test it out smoothly. Currently it’s rolled out at 10%. Stay tuned!