API Protected Audience (in precedenza FLEDGE)

Nell'ambito di Privacy Sandbox, Chrome ha proposto Protected Audience API: un'API integrata nel browser che consente a inserzionisti e aziende di ad tech di mostrare annunci con targeting basato sul gruppo di interesse senza fare affidamento su cookie di terze parti, proteggendo al contempo gli utenti dai il monitoraggio delle conversioni.

Chrome esegue un'origine prova per l'API Protected Audience. Authorized Buyers è idoneo a partecipare ai test dell'API Protected Audience nell'inventario del publisher di Ad Manager. Gli offerenti possono ottenere i seguenti risultati testando l'API Protected Audience:

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

Gli utenti Authorized Buyers interessati ai test possono consultare la Guida introduttiva per informazioni.

Riepilogo del flusso di pubblicazione

Ecco un riepilogo del flusso di pubblicazione degli annunci Protected Audience per i partner di Authorized Buyers:

Diagramma di flusso

  1. Un offerente collabora con i propri inserzionisti per gestire i gruppi di interesse per ciascun inserzionista. Spesso gli inserzionisti aggiungevano il tag di un offerente alla pagina dell'inserzionista per aggiungere un browser ai gruppi di interesse.
  2. Un utente finale visita la pagina di un inserzionista. La pagina potrebbe contenere il tag dell'offerente.
  3. Il tag dell'offerente richiama l'API Protected Audience joinAdInterestGroup(). Questa chiamata richiede al browser di aggiungere l'utente a un gruppo basato sugli interessi.
  4. L'utente finale visita la pagina web di un publisher. Il browser dell'utente richiede Tag annuncio del publisher di Google.
  5. Il tag annuncio del publisher di Google invia una richiesta di annuncio contestuale a un server Google.
  6. Google invia richieste di offerta contestuali agli offerenti partecipanti. Per ulteriori informazioni, consulta la sezione Modifiche alle richieste di offerta.
  7. L'offerente restituisce una risposta all'offerta che include il messaggio InterestGroupBidding , necessario per partecipare all'asta per gruppo di interesse. In OpenRTB questo viene specificato con il campo BidResponse.ext.igbid e nel protocollo Google RTB deprecato con il BidResponse.interest_group_bidding. Se l'offerente non specifica queste informazioni, Google non include l'origine dell'offerente in interestGroupBuyers nella configurazione dell'asta. InterestGroupBidding può anche contenere indicatori facoltativi specifici per l'acquirente che verranno trasmessi alla funzione di offerta dell'offerente durante l'asta in-browser. In OpenRTB questo valore viene specificato BidResponse.ext.igbid.igbuyer.buyerdata e nel campo deprecato Il protocollo Google RTB è specificato con BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals . Consulta la sezione Modifiche alle risposte all'offerta per ulteriori informazioni.
  8. Google gestisce l'asta lato server e restituisce una risposta all'offerta al browser. L'asta lato server prende in considerazione le offerte lato server tradizionali. La risposta all'offerta può contenere informazioni su un'offerta vincente contestuale (se qualsiasi).
  9. La risposta all'offerta contiene una configurazione dell'asta per l'asta in-browser. Possono essere inclusi indicatori contestuali di ciascun acquirente partecipante (inviati in precedenza tramite buyerdata di OpenRTB o per_buyer_signals del protocollo Google RTB ritirato), informazioni sul vincitore contestuale e impostazioni per l'idoneità delle offerte.
  10. Il tag publisher di Google richiama l'API Protected Audience runAdAuction() per avviare l'asta on-device del gruppo di interesse. Google include solo i compratori inclusi come InterestGroupBuyer in InterestGroupBidding durante la configurazione dell'asta.
  11. Google trasmette gli indicatori facoltativi specifici per gli acquirenti di ciascun offerente idoneo alla configurazione dell'asta Protected Audience.
  12. Se i gruppi di interesse di un determinato offerente hanno specificato il valore trustedBiddingSignalsUrl, il browser invia una richiesta al valore trustedBiddingSignalsUrl di ciascun gruppo per recuperare gli indicatori in tempo reale per ogni gruppo. Consulta i dettagli nella specifica dell'API Protected Audience.
  13. Il browser richiama il generateBid() dell'offerente per ogni gruppo di interesse attivato e idoneo a partecipare all'asta in-browser. Questo calcola l'offerta e seleziona una creatività. generateBid() ha accesso agli indicatori facoltativi per gli acquirenti forniti dall'offerente e agli indicatori per le offerte affidabili per il gruppo di interesse specificato.
  14. Il browser richiama il scoreAd() del venditore (in questo caso Google) per assegnare un ranking a ogni offerta nell'asta di annunci per gruppo di interesse. Le offerte vengono classificate e filtrate in base alle protezioni dei publisher, alle norme relative agli annunci e ad altri vincoli.
  15. Il browser esegue un'asta con le offerte idonee per gruppo di interesse. La l'offerta contestuale con il ranking più elevato partecipa all'asta nel browser.
  16. Dopo l'asta, se è presente un gruppo di interesse vincente, il browser invoca reportResult() del venditore e reportWin() dell'offerente per notificare ciascuna parte del vincitore dell'asta in-browser.
  17. Se un annuncio del gruppo di interessi si aggiudica l'asta, il tag publisher di Google lo esegue in un frame.

Dettagli del flusso di pubblicazione

Prima della pubblicazione degli annunci

Verifica delle creatività

Le creatività devono essere esaminate e approvate da Google prima di poter essere pubblicate nelle aste in-browser di Protected Audience. Puoi inviare le creatività per la revisione tramite l'API Real-time Bidding o tramite scansione automatica delle creatività. Creatività per Le aste degli annunci basati sul gruppo di interesse nel browser di Protected Audience devono includere renderUrls per la revisione.

Requisiti per renderUrls:

  • Il valore renderUrl inviato tramite l'API deve corrispondere al valore renderUrl utilizzato nell'asta dell'annuncio basato sul gruppo di interesse.
  • Ogni renderUrl può rappresentare un solo inserzionista o un singolo inserzionista campagna. Non è possibile usare un determinato renderUrl per eseguire il rendering degli annunci per conto di più inserzionisti. Ogni renderUrl deve essere mappato a una singola creatività.
  • L'elemento renderUrl deve essere accessibile e recuperabile offline da Google sistemi di revisione delle creatività per un massimo di sette giorni dopo l'ultima offerta relativa all'annuncio.
Real-time Bidding API

Gli offerenti possono utilizzare l'API Real-time Bidding per caricare le creatività per le offerte per gruppo di interesse.

Scansione automatica delle creatività

Gli offerenti possono configurare la scansione automatica delle creatività per quelle che non vengono caricate tramite l'API Real-time Bidding.

Se configuri l'analisi automatica delle creatività, Google le trova nell'asta in-browser e le analizza automaticamente, in modo che siano idonee per le aste future.

Per attivare l'analisi automatica delle creatività:

  • Aggiungi tutte le origini renderUrl della creatività del gruppo di interesse alla Account Authorized Buyers.

  • Aggiungi le seguenti intestazioni HTTP personalizzate alla risposta HTTP della creatività:

    Authorized-Buyers-Creative-ID

    stringa

    ID creatività specifico dell'acquirente. La lunghezza massima dell'ID creatività è di 128 byte.
    Authorized-Buyers-Click-Through-URLs

    stringa

    L'insieme di URL di destinazione dichiarati per la creatività codificata in base a RFC2396.

Esempio:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
Scadenza della creatività

Le creatività vengono approvate per 15 giorni. Se invii le creatività con l'API Real-time Bidding, dovrai inviarle di nuovo dopo 15 giorni. Se fai affidamento scansione automatica delle creatività, la procedura di scansione ne eseguirà automaticamente la nuova scansione.

ID report acquirente

Puoi suddividere le metriche dei report (ad es. le impressioni) utilizzando le dimensioni fornite dall'acquirente (ad es. l'ID campagna o l'ID inserzionista). Per aggiungere una dimensione per la spesa del gruppo di interesse, specifica un valore buyerAndSellerReportingId per il tuo annuncio quando aggiungi il dispositivo dell'utente al gruppo di interesse. Consulta ulteriori dettagli nella documentazione di Protected Audience.

Di seguito è riportato un esempio di come aggiungere buyerAndSellerReportingId alla configurazione del gruppo di interesse:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

buyer_reporting_id verrà visualizzato come nuova dimensione nello strumento di generazione di report dell'acquirente autorizzato, come Dimensione ID report acquirente.

Asta lato server

Modifiche alle richieste di offerta

Di seguito sono riportate le versioni iniziali dei protocolli supportati da utilizzare nell'esperimento:

Indica il supporto dell'asta basato sui gruppi di interesse

Le richieste di offerta dispongono di nuovi campi per indicare il supporto per le aste per gruppi di interesse:

  • OpenRTB:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • Protocollo RTB di Google (non più supportato):
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

Puoi utilizzare questo campo per distinguere le opportunità di impressioni che supportano l'asta basata sui gruppi di interesse in-browser di Protected Audience da quelle che supportano solo l'asta della piattaforma di scambio pubblicitario lato server tradizionale. La L'enum AuctionEnvironment può avere i seguenti valori:

  • SERVER_SIDE_AUCTION (JSON OpenRTB: 0): l'asta che determina le l'annuncio vincente viene eseguito sui server della piattaforma di scambio pubblicitario.
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1): richieste con supporto di Protected Audience, in cui viene eseguita un'asta contestuale sui server della piattaforma di scambio pubblicitario e le offerte per gruppo di interesse e l'asta finale vengono eseguite nel browser.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (JSON OpenRTB: 3): la dimensione contestuale l'asta viene eseguita sui server della piattaforma di scambio pubblicitario e la logica di offerta per interesse gruppo di offerte e la logica di punteggio per determinare l'annuncio finale vincente vengono eseguite nei server delle offerte e delle aste.
Indica le dimensioni dell'area annuncio Protected Audience

La richiesta di offerta include i seguenti campi per fornirti il campo Dimensioni dell'area annuncio del segmento di pubblico:

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • Protocollo Google RTB (deprecato):
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

Questi campi indicano le dimensioni dell'area annuncio per l'asta Protected Audience in pixel.

Queste dimensioni possono essere diverse da quelle della richiesta contestuale, come quelle viste in BidRequest.imp.banner.format.w e BidRequest.imp.banner.format.h o il protocollo Google RTB ritirato BidRequest.adslot.width e BidRequest.adslot.height.

La richiesta contestuale può avere più dimensioni. L'asta on-device si è aggiudicata che l'annuncio deve riempire solo una singola dimensione di area fissa.

Indicare la possibilità di visualizzazione degli annunci Protected Audience

Gli annunci Protected Audience possono o meno essere visualizzati a seconda del modello della fase di integrazione (consulta la sezione dell'esperimento). render_interest_group_ads della richiesta di offerta indica se l'annuncio Protected Audience vincente per il rendering dell'immagine.

  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • Protocollo Google RTB (deprecato): BidRequest.adslot.interest_group_auction.render_interest_group_ads
Riduci al minimo l'utilizzo di identificatori utente

Le richieste di offerta contestuali nell'ambito dei test dell'API Protected Audience possono continuano a includere gli identificatori tradizionali basati sui cookie, se disponibili browser, ad esempio i campi BidRequest.user.id e BidRequest.user.buyerid oppure BidRequest.google_user_id e BidRequest.hosted_match_data pollici il protocollo Google RTB obsoleto. La presenza di questi identificatori nelle richieste di offerta è soggetta alle norme sulla privacy esistenti. Ti consigliamo di non fare affidamento su identificatori basati sui cookie per il targeting e le offerte durante test per prepararsi meglio a un acquisto efficiente quando i cookie di terze parti non sono più a lungo disponibile.

Google potrebbe anche eseguire esperimenti su piccola scala in cui gli identificatori basati sui cookie vengono oscurati dalle richieste di offerta nell'ambito dei test dell'API Protected Audience. Per valutare il potenziale impatto del ritiro dei cookie di terze parti.

Per prepararti alle Ritiro dei cookie di terze parti (3PCD) nel 2024, Chrome ora offre Test facilitati da Chrome.

Siti e fornitori possono utilizzare i test agevolati da Chrome per testare i propri sistemi 3PCD. Nel test, i browser Chrome vengono assegnati a un gruppo sperimentale 3PCD, in modalità A o B. A ogni browser viene assegnata un'etichetta coerente corrispondente a un gruppo sperimentale 3PCD specifico a cui puoi accedere tramite l'API Chrome in-browser.

Google passa l'etichetta non modificata dall'API Chrome alla richiesta di offerta RTB. A causa delle piccole sezioni di traffico di una singola etichetta, Google non include sempre l'etichetta in contesti limitati per la privacy.

Di seguito sono riportati i campi in cui puoi visualizzare l'etichetta:

  • OpenRTB: BidRequest.device.ext.cdep
  • Protocollo RTB di Google (non più supportato): BidRequest.device.cookie_deprecation_label

Modifiche alla risposta all'offerta

Indica la partecipazione all'asta del gruppo di interesse

È tua responsabilità indicare esplicitamente la tua intenzione di partecipare all'asta in-browser restituendo l'oggetto InterestGroupBidding nella risposta all'offerta contestuale:

  • OpenRTB: BidResponse.ext.igbid
  • Protocollo RTB di Google (non più supportato): BidResponse.interest_group_bidding

Devi fornire una risposta all'offerta contestuale. La risposta non è obbligatoria per includere un'offerta contestuale. L'oggetto InterestGroupBidding deve contenere origin per ogni InterestGroupBuyer, che deve corrispondere a una delle origini configurate dall'offerente per il proprio account. origin viene aggiunto a interestGroupBuyers della configurazione dell'asta quando il Tag publisher di Google chiama runAdAuction().

Propagare gli indicatori di contesto dell'acquirente

Puoi includere gli indicatori di un acquirente nella risposta all'offerta contestuale, che Google propaga come oggetto JSON alla propria funzione di offerta on-device tramite l'argomento perBuyerSignals. Può essere incluso nella risposta all'offerta con il parametro seguenti campi a seconda del protocollo:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • Google RTB (non più supportato): BidResponse.interest_group_bidding.per_buyer_signals
Propaga gli indicatori di rendering contestuale dell'acquirente

Le creatività per gruppi di interesse possono utilizzare indicatori di contesto limitati durante il rendering inviandoli tramite la risposta all'offerta contestuale e ricevendoli nella richiesta dell'URL di rendering utilizzando l'espansione delle macro. Ad esempio, il rendering è possibile usare gli indicatori per personalizzare l'aspetto di una creatività al fine di migliorare il rendimento nel contesto di una determinata area annuncio o pagina del publisher.

Puoi includere gli indicatori di rendering di un acquirente serializzati come stringa sicura per l'URL in la risposta all'offerta contestuale, che Google sostituirà nell'interesse vincente l'URL di rendering del gruppo costruendo Macro ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

Gli indicatori di rendering possono essere specificati nella risposta all'offerta con quanto segue: campi, a seconda del protocollo:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB (non più supportato): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

Nella risposta all'offerta è possibile includere fino a tre insiemi di indicatori di rendering con suffissi macro diversi per distinguere gli indicatori diversi. Ad esempio, un suffisso potrebbe essere utilizzato per associare un insieme specifico di indicatori applicabili solo alle creatività con la macro corrispondente nell'URL di rendering, riducendo così le dimensioni del trasferimento di dati.

L'acquirente del gruppo di interesse non potrà più partecipare al programma Asta del segmento di pubblico, se gli indicatori non sono sicuri per gli URL, i suffissi delle macro non sono univoci o vengono forniti più di tre insiemi di indicatori.

Specifica il prezzo di offerta in-browser massimo

Nella proposta Protected Audience, il calcolo dell'offerta e l'asta finale dovrebbero essere eseguiti localmente sul dispositivo. Ciò potrebbe creare potenziali vettori di abuso che possono influire sull'integrità dei risultati finali dell'asta, ad esempio il prezzo dell'offerta vincente.

Come misura di mitigazione supportata durante i test dell'API Protected Audience da parte di Google per i suoi partner RTB, puoi specificare un valore di offerta massima previsto in ogni risposta all'offerta contestuale. L'offerta massima prevista è il prezzo dell'offerta massima che dovrebbe essere restituito dalla funzione di offerta. Se l'offerta vincente è stata registrata l'asta nel browser supera questo importo, l'offerta vincente non viene conteggiata come evento fatturabile. Questo approccio è soggetto a modifiche.

Nella risposta all'offerta, puoi specificare il valore dell'offerta massima previsto nei campi seguenti campi:

  • OpenRTB: BidResponse.igbid.igbuyer.maxbid(espresso in unità di valuta CPM)
  • Protocollo Google RTB (deprecato): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (espresso in microCPM)
Attribuire le impressioni a più account

Un offerente deve selezionare un ID fatturazione per attribuire le impressioni dell'offerta del gruppo di interesse utilizzando i seguenti campi:

  • OpenRTB: BidResponse.igbid.igbuyer.billing_id
  • Protocollo Google RTB (non più supportato): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

L'ID fatturazione selezionato deve essere un ID fatturazione idoneo della richiesta di offerta:

  • OpenRTB: BidRequest.imp.ext.billing_id
  • Protocollo Google RTB (deprecato): BidRequest.adslot.matching_ad_data.billing_id

Se non viene fornito l'ID fatturazione a cui attribuire le impressioni delle offerte basate sui gruppi di interesse, l'offerente non parteciperà all'asta Protected Audience.

Gli account secondari possono avere fino a due ID fatturazione. L'acquirente potrebbe utilizzare un ID fatturazione per la spesa contestuale e un altro per la spesa per gruppo di interesse. Contatta il tuo account manager se vuoi configurare due ID fatturazione per un account secondario.

È possibile impostare un budget giornaliero per ogni ID fatturazione. Contatta il tuo account manager per impostare il budget giornaliero per gli ID fatturazione degli account secondari.

ID fatturazione per tutti gli account secondari con budget disponibile idoneo a fare offerte in l'impressione viene visualizzata nella richiesta di offerta per la selezione dell'attribuzione della spesa. Contattaci al tuo account manager per modificare il budget di un ID fatturazione gruppo di interesse.

Durante l'asta nel browser

Genera offerte nel browser

Utilizza generateBid() per generare offerte in-browser.

Google fornisce i seguenti parametri:

  • auctionSignals: vuoto
  • perBuyerSignals: un oggetto JavaScript degli stessi indicatori forniti dall'oggetto offerente nella risposta contestuale

Vengono restituiti i seguenti parametri:

  • ad: Google ignora questo campo.
  • bid: un'offerta numerica che viene inserita nell'asta. Deve essere in unità CPM (non micro).
  • render: l'URL visualizzato per mostrare la creatività se l'offerta vince l'asta. Google deve esaminare e approvare questo URL, altrimenti verrà filtrato dell'asta.
  • allowComponentAuction: deve essere true. Google al momento supporta i test delle aste multi-venditore.

Ecco un esempio:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

Per una spiegazione della funzione generateBid(), consulta la sezione Aste on-device delle specifiche di Protected Audience.

Valuta offerta

Le offerte per l'asta in-browser vengono inserite in unità di CPM della valuta di offerta scelta.

La valuta dell'offerta deve essere indicata sia nella risposta all'offerta contestuale sia nel valore restituito di generateBid e deve essere un codice alfa ISO 4217 valido, ad esempio "USD", "EUR" o "JPY".

In OpenRTB, utilizza il nuovo campo cur nell'oggetto InterestGroupBuyer in l'estensione della risposta all'offerta di Google.

Ecco un esempio:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

Nel protocollo RTB di Google, utilizza il nuovo campo currency nella InterestGroupBuyer messaggio nella risposta all'offerta.

Ecco un esempio:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

Le funzioni generateBid degli offerenti devono restituire le offerte nella stessa valuta indicata nella risposta all'offerta contestuale. Compila la nuova proprietà bidCurrency in Valore restituito di generateBid:

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

Se la valuta della risposta all'offerta contestuale è diversa dalla valuta restaurata da generateBid o se una delle due restituisce una valuta non valida, l'offerta verrà filtrata prima dell'asta.

Controlli di qualità degli annunci

Le norme relative alle creatività e l'applicazione dei controlli dei publisher potrebbero essere più restrittive per Offerte per gruppo di interesse nel browser durante i test dell'API Protected Audience per le offerte in tempo reale partner.

Assistenza per il Regolamento sui servizi digitali

Ai sensi dell'articolo 26 del Regolamento sui servizi digitali, i publisher potrebbero richiedere agli acquirenti di mostrare le informative sulla trasparenza negli annunci. Quando l'opzione "Chiedi agli acquirenti di mostrare solo annunci con annunci dinamici della rete di ricerca informazioni sulla trasparenza sul mio sito o nella mia app nel SEE" è abilitato da un publisher, gli acquirenti dei gruppi di interesse possono determinare quali opportunità richiesta di garantire trasparenza all'acquirente annotando i valori di BidRequest.regs.dsa.required e BidRequest.dsa.pubrender nell'offerta richiesta (BidRequest.dsa.dsa_support e BidRequest.dsa.publisher_rendering_support rispettivamente nel deprecato protocollo Google RTB).

Quando un offerente che vuole partecipare alle aste dell'API Protected Audience riceve l'indicatore nella richiesta di offerta che segnala che è necessario mostrare informazioni sulla trasparenza ai sensi del DSA per gli annunci pubblicati tramite l'API Protected Audience, deve valutare se può mostrare correttamente le informazioni richieste e specificarlo impostando BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render nel Protocollo RTB di Google deprecato). In caso contrario, l'acquirente non verrà incluso nella asta dell'API Protected Audience.

Per ulteriori informazioni sulla trasparenza degli annunci nell'ambito del Regolamento sui servizi digitali, consulta Articolo del Centro assistenza: Supporto del Regolamento sui servizi digitali.

Filtro delle offerte

Google applica norme ai publisher controlli e norme durante l'asta on-device.

Dopo l'asta in-browser

Segnala il risultato dell'asta all'acquirente: reportWin()

Google non compila i seguenti argomenti:

  • auctionSignals
  • sellerSignals

Utilizza reportWin() per segnalare il risultato dell'asta all'acquirente.

Consulta i report per gli acquirenti su rendering e annuncio Eventi del messaggio esplicativo dell'API Protected Audience per saperne di più.

Macro

Il parametro renderUrl che fa riferimento alla creatività dell'API Protected Audience può includere uno o più segnaposto, chiamati macro. Dopo l'asta basata sul gruppo di interesse ma prima del rendering le macro vengono sostituite e i relativi valori. Il renderUrl utilizzato nell'asta on-device può includere quanto segue :

${GDPR} Si espande in 0 se non è applicabile il GDPR oppure a 1 se è applicabile. Consulta la documentazione.
${GDPR_CONSENT_XXXX} Si espande nella trasparenza &amp; Stringa per il consenso (TC) associata alla richiesta. Se la stringa trasparenza e consenso (TC) risulta vuota o non valida, questa macro non si espanderà.

Utilizza questa macro per passare la stringa TC a un fornitore registrato nell'elenco GVL di IAB in un URL. Sostituisci XXXX con l'ID GVL di IAB dell'elenco GVL di IAB registrato di terze parti. Se la stringa TC è vuota o non valida, questa macro non si espande.

Le creatività con la macro ${GDPR_CONSENT_XXXX} potrebbero diventare bloccato se il fornitore registrato nell'elenco GVL di IAB associato all'ID GVL di IAB inserito non ha il consenso dell'utente.

La macro ${GDPR_CONSENT_XXXX} deve apparire solo una volta in renderUrl.
${ADDL_CONSENT} Si espande nella stringa Consenso aggiuntivo (AC) associata alla richiesta.
${AD_WIDTH}, ${AD_HEIGHT) Queste macro inseriscono la larghezza e l'altezza dell'area annuncio.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

Macro contenente indicatori relativi all'acquirente al momento della visualizzazione specificato nella risposta all'offerta.

Sostituisci il segnaposto buyer.origin.example con l'origine dell'acquirente del gruppo di interesse, che deve corrispondere a interest_group_buyers.origin nella risposta all'offerta. Puoi includi un _OPTIONAL_SUFFIX per fornire fino a tre diversi i valori degli indicatori di rendering.

Conteggio di impressioni

Durante i test con i partner RTB dell'API Protected Audience, Google conteggerà impressioni quando il browser chiama la funzione reportResult() e recupera successivamente l'URL dei report di Google in una chiamata a sendReportTo().

Poiché l'evento utilizzato da Google per conteggiare le impressioni nelle aste in-browser di Protected Audience potrebbe essere diverso da quello utilizzato per conteggiare le impressioni dai partner di acquisto RTB, i conteggi delle impressioni potrebbero essere diversi.

Uno degli obiettivi di Google per il test dell'API Protected Audience è identificare e ridurre queste discrepanze.

Attribuzione delle impressioni fatturabili

Tutta la spesa di un offerente per le aste nel browser di Protected Audience è attribuiti a un singolo account offerente sulla base della mappatura dall'interesse Origini del proprietario del gruppo configurate per l'offerente. L'attribuzione della spesa a diversi account seggiolini di un offerente non è supportata.

Limite di budget giornaliero

Durante i test dell'API Protected Audience, ogni account ha un valore a livello di account Limite del budget giornaliero per la spesa di Protected Audience. Il limite di budget giornaliero limita il rischio nell'ambiente di asta interno al browser. Una volta raggiunto il limite del budget giornaliero, non riceve più richieste di offerta idonee per Protected Audience.

L'account può continuare a partecipare alle aste contestuali lato server dopo raggiungendo il limite di Protected Audience. Ad esempio, un account offerente che raggiunge il limite di Protected Audience potrebbe ricevere una richiesta di offerta con auction_environment = SERVER_SIDE_AUCTION (JSON OpenRTB: 0), anche se la richiesta di offerta è idonea per un'asta Protected Audience.

Feedback in tempo reale e offerta minima per vincere

Gli offerenti che hanno attivato la ricezione del feedback in tempo reale riceveranno il feedback per gli acquirenti di gruppi di interessi che hanno richiesto di essere inclusi in un' asta on-device Protected Audience. Per ogni acquirente del gruppo di interesse che un offerente in una risposta all'offerta riceverà un oggetto feedback, indipendentemente da come molte offerte inserite dall'acquirente del gruppo di interesse nell'asta Protected Audience. Nell'oggetto Feedback acquirente gruppo di interesse saranno disponibili le seguenti informazioni:

  • Il tipo di feedback dell'oggetto feedback sarà INTEREST_GROUP_BUYER_FEEDBACK.
  • L'origine dell'acquirente del gruppo di interesse.
  • L'offerta minima per vincere per l'acquirente del gruppo di interesse in modo da vincere il complessiva dell'asta.
  • L'offerta minima per vincere per l'acquirente del gruppo di interesse in modo da battere il l'offerta con il ranking più alto dal componente lato server dell'asta complessiva.
  • Il codice di stato dell'acquirente del gruppo di interesse. I possibili codici di stato sono definiti in interest-group-buyer-status-codes.txt.

Per i nomi specifici dei campi, consulta la documentazione del protocollo per RTB di Authorized Buyers e per le Estensioni OpenRTB.

Notifica di feedback sulle offerte

Chrome offre un servizio di debug temporaneo tramite Google Cloud per l'API Protected Audience che consente ad Ad Manager di inviare dati notifiche di debug server-to-server che contengono feedback su un oggetto Protected Offerta per pubblico. Questa notifica includerà i motivi per cui le offerte potrebbero essere state filtrate nell'asta in-browser di Protected Audience, oltre ad altre informazioni sulle offerte descritte di seguito.

Gli offerenti possono contattare il proprio account manager per configurare un URL statico che verrà utilizzato per inviare notifiche di feedback sulle offerte per il debug di Protected Audience. Questo URL statico verrà recuperato dai server di Google con le macro selezionate sostituite al termine dell'asta Protected Audience. Sono supportate le seguenti macro:

  • %%GOOGLE_QUERY_ID%%: questa macro viene sostituita dall'ID query Google inviato nella richiesta di offerta contestuale abilitata a Protected Audience. Nella il protocollo OpenRTB specificato BidRequest.ext.google_query_id, mentre lo strumento RTB di Google ritirato utilizza BidRequest.google_query_id.
  • %%INTEREST_GROUP_OWNER%%: l'origine del proprietario del gruppo basato sugli interessi.
  • %%BID_CPM%%: il prezzo dell'offerta in CPM specificato dall'acquirente nella funzione generateBid().
  • %%RENDER_URL%%: l'URL di rendering della creatività.
  • %%STATUS%%: un codice di stato se l'offerta è stata rifiutata entro scoreAd(). I valori sono stato della creatività .

Ecco un esempio di URL statico che un offerente potrebbe fornire al proprio account manager:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

La notifica del feedback sulle offerte è una funzionalità temporanea che dipende dall'API ForDebuggingOnly temporanea di Chrome.

TURTLEDOVE a livello di prodotto

Gli annunci composti da più parti o TURTLEDOVE a livello di prodotto (PLTD) sono supportati per i partner RTB di Google durante i test dell'API Protected Audience. Comunica al tuo account manager se durante l'integrazione hai intenzione di eseguire il test PLTD, perché sono necessarie ulteriori risorse e configurazioni.

Onboarding

Ecco come puoi testare l'API Protected Audience:

Passaggi

  1. Compila il modulo di richiesta. per partecipare all'esperimento dell'API Protected Audience.
  2. Dopo aver inviato il modulo di richiesta, contatta il tuo account manager o invia un ticket utilizzando il Centro assistenza Authorized Buyer.
  3. Una volta configurato l'account, sia Google sia il partner possono verificare l'integrazione seguendo i passaggi descritti nella sezione Fasi di test.

Verifica delle creatività

Per fare offerte con annunci a livello di prodotto (annunci composti da più elementi) nelle aste dell'API Protected Audience, segui questi requisiti:

  • Includi il parametro di query &pltd=True in renderUrl per (detto anche renderUrl di primo livello) per distinguere gli renderUrls di primo livello durante la verifica delle creatività.
  • Visualizza una creatività rappresentativa quando il contenitore dell'annuncio del componente è recuperate per la revisione delle creatività da parte di Google. Per capire quando un un rendering rappresentativo dell'annuncio, puoi fare riferimento validation=True parametro di query impostato dal sistema di verifica delle creatività di Google.

Elenco di controllo per l'integrazione

  • Configura un endpoint di richiesta di offerta che completi i campi correlati all'API Protected Audience nella risposta all'offerta contestuale, ad esempio interest_group_bidding.
  • Implementa il tagging nelle pagine dell'inserzionista per accedere al browser dell'utente a gruppo basato sugli interessi.
  • Implementa generateBid() e reportWin().
  • Seleziona le origini dei proprietari dei gruppi di interesse e aggiungile all'account Authorized Buyer.
    • Le origini dei proprietari dei gruppi di interesse devono corrispondere a quelle in cui sono ospitate le funzioni generateBid().
    • Contatta l'account manager o invia un ticket tramite l'account manager Centro assistenza per gli acquirenti completa questo passaggio.
  • Configurare il pretargeting per l'inventario pertinente all'API Protected Audience test.
  • Inviare creatività per la revisione e l'approvazione tramite la sezione Creatività tramite Google Cloud.
  • (Facoltativo) Configura gli endpoint degli indicatori di offerta attendibili.
  • (Facoltativo) Configura una pagina dell'inserzionista di prova che consenta agli ingegneri di Google di aggiungere il loro browser ai gruppi di interesse di proprietà dell'origine dell'acquirente del gruppo di interesse. In questo modo possiamo attivare manualmente le aste Protected Audience.
  • (Facoltativo) Attiva i feedback in tempo reale nel tuo account per ricevere feedback per gli acquirenti di gruppi di interesse che hanno richiesto di essere inclusi in un'asta Protected Audience.
  • (Facoltativo) Contatta il tuo account manager per configurare un URL statico per ricevere una notifica server-to-server che fornisca un feedback sulle offerte Protected Audience per lo stato di un'offerta da un'asta Protected Audience on-device per aiutarti a eseguire il debug di problemi imprevisti. Per maggiori dettagli, consulta la notifica relativa al feedback sulle offerte.

Fasi del test

Fase 1: test manuale

Ecco come attivare manualmente un'asta Protected Audience affinché l'annuncio possa eseguire il rendering e registrare l'impressione:

  1. Utilizza Chrome 101 o versioni successive.
  2. Attiva l'API Privacy Sandbox e il frame fenced utilizzando chrome://flags/#privacy-sandbox-ads-apis e chrome://flags/#enable-fenced-frames. Scopri di più alla pagina Testa la privacy sandbox.
  3. Invia una creatività per l'approvazione utilizzando l'API Real-time Bidding.
  4. Utilizza la pagina dell'inserzionista fornita dall'offerente per aggiungere un browser al gruppo di interesse di proprietà dell'offerente.

  5. Utilizza la seguente pagina del publisher di test fornita da Google per attivare un'asta Protected Audience:

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

    Il gruppo basato sugli interessi interno al browser deve fare offerte sufficientemente elevate per vincere l'asta, in quanto potrebbero competere con le offerte lato server convenzionali. Google offre inoltre una pagina del publisher di test dedicata per ciascun partner, dove solo il partner specificato possono partecipare all'asta. Potrebbe essere più facile vincere aste in-browser su una pagina specifica del partner.

  6. Verifica quanto segue:

    1. Viene eseguito il rendering dell'annuncio vincente previsto.
    2. Il risultato dell'asta viene inviato lato server, il che significa che l'offerente vincente riceve un ping da reportWin().
    3. La console della pagina del publisher di test registra un messaggio di debug per ogni offerta con le seguenti informazioni:
      • renderUrl: l'URL di rendering dell'offerta.
      • interestGroupOwner: il proprietario del gruppo di interesse dell'offerta.
      • accepted: questo campo è true se l'offerta è stata accettata e false se l'offerta è stata rifiutata da scoreAd().
      • externalBidStatus: un codice di stato se l'offerta è stata rifiutata entro scoreAd(). I valori sono codici stato della creatività.

Fase 2: (facoltativo) esperimento di non visualizzazione

Dopo che Google e il partner hanno verificato manualmente che il partner può partecipano all'asta Protected Audience, Google abilita il partner nella fase successiva del test.

Google alloca una piccola quantità di traffico in tempo reale per eseguire Protected Audience nelle aste. In questo modo, Google e il partner non dovranno più attivare manualmente un'asta Protected Audience. Il risultato dell'asta Protected Audience non viene visualizzato. Questo ci consente di testare l'integrazione su larga scala.

Quando è tutto pronto, contatta il tuo account manager o invia una richiesta tramite il Centro assistenza Authorized Buyers. Google attiverà l'account per questa fase.

Fase 3: esperimento di rendering

Una volta che Google e il partner hanno verificato le aste Protected Audience su larga scala senza il rendering, Google può consentire al partner di eseguire il rendering dell'annuncio vincente Protected Audience. Google registra una piccola quantità di traffico in cui Le aste dei segmenti di pubblico sono idonee alla pubblicazione, mentre gli annunci vincenti basati sul gruppo di interesse eseguire il rendering. Le offerte in-browser degli offerenti partecipanti competono con le offerte tradizionali.

Contatta il tuo account manager o invia un ticket tramite Authorized Buyers assistenza quando è tutto pronto. Google attiverà l'account per questa fase.

Altre caratteristiche

Le seguenti funzionalità sono estensioni del protocollo principale.

Parallelizzazione

La parallellizzazione è un'ottimizzazione che riduce la latenza dell'asta end-to-end avviando la richiesta di annunci contestuali in parallelo con le richieste ai server attendibili dell'acquirente specificati in trustedBiddingSignalsUrl.

La parallelizzazione riduce la latenza, ma influisce sul gruppo di interesse l'idoneità dell'acquirente e l'assistenza esperimenti coordinati. La parallelizzazione si applica a tutti gli offerenti che partecipano l'asta on-device del gruppo di interesse. Gli offerenti non devono intraprendere alcuna azione per partecipano ad aste parallele, ma devono acquisire familiarità con in che modo il caricamento in contemporanea può influire sulla sua idoneità alle aste on-device. Gli ID gruppo sperimentale per gli esperimenti coordinati non sono ancora supportati nell'ambito di aste parallele.

Riepilogo del flusso di pubblicazione

Ecco un riepilogo del flusso delle aste parallele: Diagramma di flusso

Idoneità degli acquirenti dei gruppi di interesse sul dispositivo

Per le aste parallele, la chiamata di navigator.runAdAuction avviene prima viene restituita la risposta di annuncio contestuale. Per avviare una procedura di configurazione dell'acquirente chiamate al server, navigator.runAdAuction richiede che Il parametro interestGroupBuyers deve essere trasmesso come valore, mentre i restanti parametri dell'asta accettano JavaScript. Promesse che possono essere risolte dopo la risposta all'annuncio contestuale. Poiché interestGroupBuyers viene passato prima della risposta all'annuncio contestuale, la risposta all'annuncio contestuale (incluse le risposte all'offerta) non può essere utilizzata per scegliere quali acquirenti partecipano all'asta parallelizzata per la richiesta specificata. Al contrario, i tag publisher di Google memorizzano nella cache, nel browser dell'utente, il parametro interestGroupBuyers della versione precedente navigator.runAdAuction esecuzioni sullo stesso dominio.

La parallelizzazione presenta diversi aspetti importanti:

  1. Indicatori di asta non necessari per le richieste di server attendibili dell'acquirente. come perBuyerSignals, possono continuare a essere specificati nelle risposte all'offerta RTB esattamente come per le aste non parallele. Una volta risolte le promesse per questi indicatori, i passaggi rimanenti dell'asta on-device verranno completati nello stesso modo del flusso dell'asta non parallela.

  2. Poiché il caricamento in contemporanea si basa sulla memorizzazione nella cache dell'elenco di acquirenti dei gruppi di interesse, Google non esegue sempre un'asta parallela, poiché la cache di parallelizzazione potrebbe essere vuoto o scaduto. Se la cache è vuota o scaduta, Google esegue un'asta non parallela standard dell'API Protected Audience e utilizza l'intenzione di acquisto per partecipare all'asta non parallela al fine di creare la cache degli acquirenti dei gruppi di interesse.

  3. Se almeno un acquirente per qualsiasi offerente viene memorizzato nella cache per il publisher corrente dominio, Google esegue una che sarà indicato nella richiesta di offerta:

    • Protocollo RTB di Google: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized

  4. Ogni origine acquirente del gruppo di interesse registrato per un determinato offerente che è stata inclusa nell'asta parallela avrà una voce corrispondenteParallelAuctionBuyer:

    • Protocollo RTB di Google: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer

  5. Se viene eseguita un'asta parallela, ma l'origine di un acquirente specifico non è presente nella cache, l'acquirente in questione non può essere aggiunto all'asta corrente sul dispositivo. Questo è indicato da una richiesta con parallelized=True che non contiene una voce ParallelAuctionBuyer per l'origine dell'acquirente di un determinato gruppo di interesse. Tuttavia, gli offerenti che indicano l'interesse includendo InterestGroupBuyer validi e idonei nella risposta all'offerta, avranno le origini acquirente del gruppo di interesse corrispondenti aggiunte alla cache e queste origini saranno idonee per le future richieste parallelizzate dallo stesso browser e dominio. L'intenzione di partecipare alle aste per gruppi di interesse puoi essere indicata nei seguenti campi:

    • Protocollo Google RTB: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer

  6. Le origini acquirente memorizzate nella cache (incluse nel parametro interestGroupBuyers dell'asta parallela) per le quali un offerente non indica l'intenzione di partecipare nella risposta all'offerta possono ricevere una chiamata al server attendibile dell'acquirente, ma non parteciperanno all'asta parallela.