Encrypted Seller Defined Audiences (eSDA)
Currently, a hypothetical concept whereby a DSP and Anonymised synchronise audience data using an encrypted object (seller-defined audience data) in the bid request.
Conceptualisation of eSDA process flow
DSP responsibilities
Agree on a set taxonomy of audiences with Anonymised
Agree on ortb2.x extension object with Anonymised [noting that this is also a discussion amongst members of the No ID No Problem initiative of which Anonymised is an active participant]. Currently assuming ortb2.x.data.ext.eseg.
Enable audiences in line items
Share audience IDs with Anonymised [mutual development]
Obtain decryption key from Anonymised [mutual development]
Decrypt object in bid request (ortb2.x.data.ext.eseg) to receive segment value for the targeted audience
Include audience in bid logic
Anonymised responsibilities
Receive audience IDs from DSP [mutual development]
Facilitate Anonymised segment assignment to these audience IDs
Facilitate encryption/decryption routine and its management
Determine relevant DSP audiences in header bidding and include in the encrypted payload
Enable encryption of the payload, for header bidding this would be performed in the Anonymised RTD module, using ortb2.x.data.ext.eseg.
Other Parties
In the case of a bid request being ingested by an SSP, the SSP would simply pass on the encrypted SDA in the ortb2.x.data.ext.eseg object.
In the case of header bidding being a relevant pathway, we would need to talk to Amazon regarding its TAM header bidding solution, to complement the functionality of our RTD module.