search

IABTechLab / 1st-party-curated-addressability

Apache License 2.0
7 stars 2 forks source link

Seat level targeting #3

Open anderagakura opened 1 year ago

anderagakura commented 1 year ago

Two questions :

  1. List of seats : Today, the SSP updates the list of all the seat ids manually with the DSPs (some does automatically but it's rare). The question : How to make sure that the SSP targets the right seats if the listing is not automatic or even accurate (the name of each seat can vary from a SSP to an other SSP)? Use of Buyer.json?
  2. Sustainability : For instance, the SSP authorizes Seat A but not the Seat B to receive the X 1P data. How do you avoid bid request duplications?
avuim commented 1 year ago

Alexandre, regarding your point 1:

The spec does a binary definition to which DSPs an SSP is allowed to pass the IDs (see Authorized Connections) while the spec does a DSP specific spec of seats which are allowed to receive the IDs (see Authorized Functions). The spec leaves the space to DSPs to act in their fashion, since the configuration is not part of the bid request/response. Despite of that, from the publishers side it would be a very good development if Buyer.json is more widely accepted/used and can be incorporated into the concept of Authorized Functions and there the seatId attribut.

anderagakura commented 1 year ago

Alexandre, regarding your point 1:

The spec does a binary definition to which DSPs an SSP is allowed to pass the IDs (see Authorized Connections) while the spec does a DSP specific spec of seats which are allowed to receive the IDs (see Authorized Functions). The spec leaves the space to DSPs to act in their fashion, since the configuration is not part of the bid request/response. Despite of that, from the publishers side it would be a very good development if Buyer.json is more widely accepted/used and can be incorporated into the concept of Authorized Functions and there the seatId attribut.

@avuim Of course, this proposal does not intend to solve buyers identification between SSP and DSP but intend to help the publisher to better manage which buyer receives the data. What I'm trying to say is as the publisher wants to declare the seats per DSP in a manual way, how to make sure that the seat is live (or KO), belongs to the right buyer (Id, misunderstanding, change...) or what is the right process to achieve this goal. Definitely buyers.json could help if more adopted.

Just a thought regarding (Sub-)Object: dsp in Authorized Functions part. To whitelist all seats, instead of using [0], perhaps the use of a asterisk would be more explicit [*].

avuim commented 1 year ago

@avuim Of course, this proposal does not intend to solve buyers identification between SSP and DSP but intend to help the publisher to better manage which buyer receives the data. What I'm trying to say is as the publisher wants to declare the seats per DSP in a manual way, how to make sure that the seat is live (or KO), belongs to the right buyer (Id, misunderstanding, change...) or what is the right process to achieve this goal. Definitely buyers.json could help if more adopted.

Agree!

Just a thought regarding (Sub-)Object: dsp in Authorized Functions part. To whitelist all seats, instead of using [0], perhaps the use of a asterisk would be more explicit [*].

Good point. Feel free to make a PR.

avuim commented 1 year ago

Alexandre, regarding your point 2:

Similar to feedback on your 1st point, the proposal does not intend to solve bid request/response (in-)efficiency. Further seat access to 1P data is defined on DSP side as part of the Authorized Functions. Nevertheless, since sustainability is an important topic taken into account, I would ask Jochen Schlosser (Adform), Tom Peruzzi (Yieldlab/Active Agent) and Thomas Mendrina (Xandr) to add their 5 cents to it from a tech perspective. In my opinion, its an DSP internal topic to be solved, not an SSP topic in the first place.