Guida all'integrazione e ai test di Protected Audience (precedentemente nota come FLEDGE) per le SSP

Nell'ambito di Privacy Sandbox, Chrome ha proposto Protected Audience , un'API integrata nel browser che consente a inserzionisti e aziende di ad tech di selezionare e scegliere come target gruppi di interesse (elenchi dei segmenti di pubblico) senza fare affidamento su cookie di terze parti, proteggendo al contempo gli utenti dal monitoraggio tra siti. Sviluppatore guida

Le SSP possono testare l'API Protected Audience con le campagne display e Video 360 e Google Ads per:

• Esegui l'iterazione e scopri l'efficacia dei flussi dell'API Protected Audience.
• Proponi e genera feedback sui potenziali miglioramenti dell'API in pubblico forum, ad esempio GitHub.
• Prepararsi a supportare la pubblicità personalizzata tramite Protected Audience senza fare affidamento su cookie di terze parti.

La seguente guida descrive i dettagli di integrazione tra una SSP e Display & Video 360 e Google Ads. Le SSP interessate a coordinare un test dovrebbero ricevere contatto con il proprio Display & Rappresentante della partnership Video 360.

Registrazione

Le SSP devono registrarsi in modo da utilizzare l'API Protected Audience.

Riepilogo del flusso di pubblicazione

Il seguente diagramma mostra il flusso generico che descrive i principali punti di interazione tra Chrome, SSP, Display e Video 360 e Google Ads.

Opzioni di integrazione

Opzione 1: diretto / venditore singolo

Passaggi:

1. Il tag annuncio SSP invia una richiesta di annuncio al server SSP indicando che il browser supporta l'API Protected Audience.
2. Il server SSP invia una richiesta di offerta contestuale OpenRTB al DSP indicando che browser supporta l'API Protected Audience
3. Il DSP risponde con una risposta all'offerta OpenRTB contenente indicatori per il asta on-device.
4. Il server SSP invia una risposta all'annuncio con la configurazione dell'asta al tag annuncio SSP.
5. Il tag annuncio SSP avvia l'asta on-device chiamando runAdAuction(), trasmettere indicatori dalla risposta all'offerta openRTB della DSP tramite perBuyerSignals.
6. Chrome chiama server di offerte DSP affidabile per le coppie chiave/valore per recuperare indicatori delle offerte in tempo reale.
7. Chiamate di Chrome generateBid() Funzione JavaScript DSP per ciascun gruppo di interesse partecipante.
8. Chrome chiama il server di punteggio SSP attendibile per chiave/valore. per recuperare indicatori di punteggio in tempo reale.
9. Chiamate di Chrome scoreAd() Funzione JavaScript SSP per ciascun gruppo di interesse partecipante.
10. Chiamate di Chrome reportWin() Funzione JavaScript della DSP per segnalare il vincitore alla DSP.
11. Chiamate di Chrome reportResult() Funzione JavaScript SSP per segnalare il vincitore alla SSP.

Numero minimo di modifiche sul lato SSP

• Il tag annuncio SSP deve essere aggiornato a

  • rilevare se il browser supporta l'API Protected Audience
  • Inviare queste informazioni come parte della richiesta di annuncio al server SSP [1]
  • avvia un'asta on-device chiamando runAdAuction() che trasmette indicatori della risposta all'offerta OpenRTB [5] della DSP (vedi il campo dei dati degli acquirenti nella la struttura delle richieste di offerta e delle risposte di seguito).

• il server SSP deve

  • propagare le informazioni sul supporto dell'API Protected Audience alla DSP nel campo della richiesta di offerta OpenRTB [2] (consulta la sezione sull'offerta la struttura di richieste e risposte di seguito).
  • propagare gli indicatori degli acquirenti della piattaforma DSP nella risposta all'offerta OpenRTB all'annuncio della SSP. (consulta la sezione di seguito sulla struttura della richiesta di offerta / risposta all'offerta) [4]

• [Optional] SSP deve implementare un server SSP attendibile per recuperare i dati in tempo reale indicatori di punteggio per supportare i controlli di qualità degli annunci, applicazione delle impostazioni del publisher [8]

• La SSP deve implementare JavaScript con "scoreAd(...)" e "reportResult(...)" funzioni [9], [11]

Opzione 2: multi-venditore

Passaggi:

1. L'adattatore SSP invia una richiesta di annuncio al server SSP per indicare che il browser supporta l'API Protected Audience.
2. Il server SSP invia una richiesta di offerta contestuale OpenRTB al DSP indicando che supporta l'API Protected Audience,
3. Il server DSP risponde con una risposta all'offerta openRTB contenente indicatori per asta on-device.
4. Il server SSP invia una risposta all'annuncio con la configurazione dell'asta al tag annuncio SSP.
5. L'adattatore SSP Prebid fornisce la configurazione dell'asta dei componenti all'ad server del publisher del tag.
6. Il tag dell'ad server del publisher invia una richiesta di annuncio al server di annunci del publisher.
7. Il tag dell'ad server del publisher avvia l'asta on-device chiamando runAdAuction(...) tramite Google Cloud CLI o tramite l'API Compute Engine.
8. Chrome chiama server di offerte DSP affidabile per le coppie chiave/valore per recuperare indicatori delle offerte in tempo reale.
9. Chiamate di Chrome generateBid() Funzione JavaScript DSP per ogni gruppo di interesse partecipante.
10. Chrome chiama il server di punteggio SSP attendibile per chiave/valore. per recuperare indicatori di punteggio in tempo reale.
11. Chiamate di Chrome scoreAd() Funzione JavaScript SSP per ciascun gruppo di interesse partecipante.
12. Chiamate di Chrome reportWin() Funzione JavaScript della DSP per segnalare il vincitore al DSP.
13. Chiamate di Chrome reportResult() Funzione JavaScript SSP per segnalare il vincitore alla SSP.

Numero minimo di modifiche sul lato SSP

• L'adattatore SSP deve essere aggiornato a

  • rilevare se il browser supporta Protected Audience
  • Inviare queste informazioni come parte della richiesta di annuncio al server SSP [1]
  • fornisce la configurazione dell'asta dei componenti al tag annuncio dell'ad server del publisher [5].
  • Se Google Ad Manager è l'ad server del publisher, la SSP può * Utilizza Protected Audience di Prebid modulo * Chiama il tag annuncio setConfig() di Google Ad Manager API con più venditori

• il server SSP deve

  • propagare le informazioni sul supporto di Protected Audience alla DSP tramite il campo nella richiesta di offerta OpenRTB [2] (consulta la sezione sull'offerta la struttura di richieste e risposte di seguito).
  • propagare gli indicatori degli acquirenti della piattaforma DSP nella risposta all'offerta OpenRTB all'annuncio della SSP. (consulta la sezione di seguito sulla struttura della richiesta di offerta / risposta all'offerta) [4]

• [Optional] SSP deve implementare un server SSP attendibile per recuperare i dati in tempo reale indicatori di punteggio per supportare i controlli di qualità degli annunci, applicazione delle impostazioni del publisher [10]

• La SSP deve esporre JavaScript con scoreAd() e reportResult() le funzioni [11], [14].

Servizi di offerte e aste

Stiamo valutando con attenzione le offerte e Servizi aste (B&A) proposal

Quando vengono visualizzati e Video 360 è pronto per testare l'API Protected Audience con B&A. ti contatteremo per fornirti maggiori dettagli.

Protocollo OpenRTB

Richiesta di offerta

Per distinguere le opportunità di impressioni che supportano Protected l'asta on-device dell'API Audience da quelle che supportano solo le aste standard asta della piattaforma di scambio lato server, un nuovo campo enum chiamato ae per l'asta ambiente" deve essere aggiunto come estensione all'oggetto Imp in OpenRTB richiesta di offerta per specificare quale ambiente di asta è supportato area impressioni. L'enum ae può avere i seguenti valori:

• 0: aste lato server standard
• 1: richieste con supporto dell'API Protected Audience, in cui viene inserito un parametro l'asta viene eseguita sui server dello scambio e le offerte basate sul gruppo di interesse e l'asta finale viene eseguita nel browser

{
  "id": …
  "imp": [{
    "id": "1"
    "video": {...}
    "ext": {
      "ae": 1
    }]
}

Risposta all'offerta

Oltre alle offerte contestuali, una risposta all'offerta viene utilizzata anche per trasmettere le informazioni pertinenti alla Rete Display e Partecipazione di Video 360 e Google Ads al Aste del gruppo di interesse dell'API Protected Audience. La risposta all'offerta viene aggiornata a supportano le aste basate su gruppi di interesse nel seguente modo:

{
  "seatbid": [{
    "bid": [{
      … // Traditional contextual bids
    }]
  }],

  "ext": {
    // InterestGroupBidding object which holds information for running an
    // in-browser interest group auction.
    "igbid": [{
      // ID of the Imp object of the impression to which
      // these interest group bidding signals apply to.
      "impid": "1",

      // InterestGroupBuyer object which holds DSP information for the in-browser
      // auction.
      "igbuyer": [{
        // Origin of Display & Video 360 and Google Ads to participate in the
        // interest group auction. For more info regarding the origin see:
        // https://developer.mozilla.org/en-US/docs/Glossary/Origin
        "origin": "https://td.doubleclick.net",

        // Buyer-specific signals to use in auctionConfig as perBuyerSignals.
        // Used by the buyer's interest group bidding function. Can be left empty
        "buyerdata": ...,

        // Buyer experiment group id to support coordinated experiments with
        // buyers' trusted servers. This experiment id should be added to the
        // `perBuyerExperimentGroupIds` map in auctionConfig.
        "buyer_experiment_group_id": 12345
      }]
    }]
  }
}

Sono supportati i seguenti scenari.

• SCENARIO 1: Pubblicità display e Video 360 e Google Ads vogliono partecipare solo in un'asta contestuale. In questo scenario non è presente un campo igbid.

• SCENARIO 2: Pubblicità display e Video 360 e Google Ads vogliono partecipare solo in un'asta basata su gruppo di interesse. In questo scenario, le campagne display e Video 360 e Google Ads eliminerà il campo dell'offerta utenza nella risposta all'offerta e che restituiscono informazioni igbid. In altre parole, la presenza di un campo igbid indica il fatto che le campagne display e Video 360 e Google Ads vogliono i propri gruppi basati sugli interessi per partecipare all'asta on-device.

• SCENARIO 3: Pubblicità display e Video 360 e Google Ads vogliono partecipare sia le aste contestuali che quelle basate su gruppi di interesse. In questo scenario, le campagne display e Video 360 e Google Ads restituiranno entrambi i campi dell'offerta predefinita nella risposta all'offerta. e igbid.

Metadati con offerta annuncio

L'API Protected Audience consente passing arbitrary metadata sull'annuncio dalla funzione generateBid().

Display e Video 360 prevede di affidarsi a quanto segue: specification per i metadati degli annunci: API Protected Audience e OpenRTB.

Vale a dire Display & Video 360 restituisce i seguenti campi nell'annuncio :

Attributo PA	Tipo	Descrizione OpenRTB
ad.seat	String; obbligatorio	ID dell'acquirente (ad es. inserzionista, agenzia) per conto del quale viene fatta questa offerta.
ad.adomain	String[]	Dominio dell'inserzionista per il controllo degli elenchi di blocco (ad es. "ford.com"). Può trattarsi di un array per le creatività a rotazione. Le piattaforme di scambio pubblicitario possono imporre che sia consentito un solo dominio.
ad.cid	stringa	ID campagna per facilitare il controllo della qualità degli annunci.
ad.crid	stringa	ID creatività per il controllo della qualità degli annunci.
ad.language	stringa	Lingua della creatività utilizzando ISO-639-1-alpha-2. Il codice non standard "xx" può essere utilizzata anche se la creatività non ha contenuti linguistici (ad es. un banner con solo il logo dell'azienda). Deve essere presente solo un valore tra language o langb.
ad.w	integer	Larghezza della creatività nei pixel indipendenti dal dispositivo (DIPS).
ad.h	integer	Altezza della creatività nei pixel indipendenti dal dispositivo (DIPS).

Esempio

{
  "seat": "123"
  "adomain": ["example.com"]
  "cid": "12345"
  "crid": "12345"
  "language": "en"
  "w": 300
  "h": 250
}

Report sugli eventi

L'API Protected Audience fornisce un'API di reporting a livello di evento descritta in questo Post di GitHub: Fenced Frame Ads Reporting. Anche se il nome indica la segnalazione degli annunci con frame schermati, l'API è disponibile in sia frame recintati che iframe (vedi i dettagli here).

La piattaforma SSP può registrare un URL con il browser nella funzione reportResult utilizzando chiamata al numero registerAdBeacon() tramite Google Cloud CLI o tramite l'API Compute Engine.

Display e Video 360 chiamerà reportEvent() API con destinazione "component-seller" dalla creatività per generare un report impressioni ed eventi di clic. Ciò comporterà l'invio di un beacon al URL registrato.

Tieni presente che Display & Video 360 chiamerà l'API reportEvent() per le impressioni e clic con dati del post vuoti.

Esempio

registerAdBeacon({
 'impression': 'https://ssp.example/impression?ssp_event_id=abc',
});
registerAdBeacon({
 'click': 'https://ssp.example/click?ssp_event_id=abc',
});

Etichetta del test sul ritiro dei cookie

Display e Video 360 parteciperà a Chrome-facilitated testing di dei cookie di terze parti. Per poter svolgere i test chiediamo ai partner di trasmettere le etichette di Chrome nella richiesta di offerta OpenRTB in base a quanto segue: specification:

Oggetto: Device.ext

Attributo	Tipo	Descrizione
CDR	Stringa	l'etichetta ricevuta da Chrome o da un partner upstream.

Documenti correlati

• API Protected Audience su sviluppatori di Chrome
• Primo esperimento su GitHub