API Protected Audience (in precedenza FLEDGE)

Nell'ambito di Privacy Sandbox, Chrome ha proposto l'API Protected Audience, un'API in-browser che consente agli inserzionisti e alle aziende di ad tech di mostrare annunci con targeting per gruppi di interesse senza fare affidamento sui cookie di terze parti, proteggendo al contempo gli utenti dal monitoraggio cross-site.

Chrome sta eseguendo una prova dell'origine per l'API Protected Audience. Gli acquirenti Authorized Buyers sono idonei a partecipare ai test dell'API Protected Audience nell'inventario dei publisher di Ad Manager. I bidder possono ottenere quanto segue testando l'API Protected Audience:

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

Gli acquirenti Authorized Buyers interessati a eseguire test devono consultare la sezione Onboarding per informazioni dettagliate.

Riepilogo del flusso di pubblicazione

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

Diagramma di flusso

  1. Un offerente collabora con i suoi inserzionisti per mantenere i gruppi di interesse per ciascun inserzionista. Spesso, gli inserzionisti aggiungono 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 di interesse.
  4. L'utente finale visita una pagina web del publisher. Il browser dell'utente richiede il tag annuncio publisher di Google.
  5. Il tag annuncio publisher di Google effettua 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 del gruppo di interesse. In OpenRTB questo valore viene specificato con il campo BidResponse.ext.igbid, mentre nel protocollo Google RTB ritirato viene specificato con il campo 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ò contenere anche indicatori facoltativi specifici per l'acquirente che verranno trasmessi alla funzione di offerta dell'offerente durante l'asta nel browser. In OpenRTB questo valore viene specificato con il campo BidResponse.ext.igbid.igbuyer.buyerdata, mentre nel protocollo Google RTB ritirato viene specificato con il campo BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals. Per ulteriori informazioni, consulta la sezione Modifiche alla risposta all'offerta.
  8. Google esegue l'asta lato server e restituisce una risposta all'offerta al browser. L'asta lato server prende in considerazione le offerte tradizionali lato server. La risposta all'offerta può contenere informazioni su un'offerta vincente contestuale (se presente).
  9. La risposta all'offerta contiene una configurazione dell'asta per l'asta nel browser. Questi possono includere indicatori contestuali di ciascun acquirente partecipante (inviati tramite buyerdata di OpenRTB o per_buyer_signals del protocollo Google RTB precedente), informazioni sul vincitore contestuale e impostazioni per l'idoneità delle offerte.
  10. Il tag editore di Google richiama l'API Protected Audience runAdAuction() per avviare l'asta on-device del gruppo di interesse. Google include solo gli acquirenti inclusi come InterestGroupBuyer in InterestGroupBidding durante la configurazione dell'asta.
  11. Google trasmette gli indicatori facoltativi specifici per l'acquirente di ogni offerente idoneo alla configurazione dell'asta Protected Audience.
  12. Se i gruppi basati sugli interessi di un determinato offerente hanno specificato trustedBiddingSignalsUrl, il browser invia una richiesta all'trustedBiddingSignalsUrl di ogni gruppo per recuperare gli indicatori in tempo reale per ciascun gruppo. Per saperne di più, consulta le specifiche dell'API Protected Audience.
  13. Il browser richiama generateBid() dell'offerente per ogni gruppo di interesse che ha attivato l'opzione ed è idoneo a partecipare all'asta nel browser. Questo passaggio calcola l'offerta e seleziona una creatività. generateBid() ha accesso agli indicatori facoltativi dell'acquirente forniti dall'offerente e agli indicatori di Trusted Bidding per il gruppo di interesse specificato.
  14. Il browser richiama scoreAd() del venditore (in questo caso, Google) per assegnare un ranking a ogni offerta nell'asta dell'annuncio del gruppo basato sugli interessi. Le offerte vengono classificate e filtrate in base alle protezioni del publisher, alle norme pubblicitarie e ad altri vincoli.
  15. Il browser esegue un'asta con le offerte dei gruppi di interesse idonei. L'offerta contestuale con il ranking più alto partecipa all'asta nel browser.
  16. Dopo l'asta, se viene selezionato un gruppo di interesse vincente, il browser richiama reportResult() del venditore e reportWin() dell'offerente per comunicare a ciascuna parte il vincitore dell'asta nel browser.
  17. Se un annuncio del gruppo di interesse vince, il tag publisher di Google esegue il rendering dell'annuncio in un iframe.

Dettagli del flusso di pubblicazione

Prima della pubblicazione di annunci

Revisione delle creatività

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

Requisiti per renderUrls:

  • Il renderUrl inviato tramite l'API deve corrispondere al renderUrl utilizzato nell'asta di annunci del gruppo di interesse.
  • Ogni renderUrl può rappresentare un solo inserzionista o una sola campagna pubblicitaria. Un determinato renderUrl non può essere utilizzato per pubblicare annunci per conto di più inserzionisti. Ogni renderUrl deve essere mappato a una singola creatività.
  • renderUrl deve essere accessibile e recuperabile dai sistemi di revisione delle creatività offline di Google fino a 7 giorni dopo l'ultima offerta fatta per l'annuncio.
Real-time Bidding API

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

Analisi 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 la scansione automatica delle creatività, Google trova le creatività nell'asta nel browser e le analizza automaticamente, in modo che siano idonee per le aste future.

Ecco come attivare la scansione automatica delle creatività:

  • Aggiungi tutte le origini renderUrl della creatività del gruppo di interesse all'account acquirente autorizzato.

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

    Authorized-Buyers-Creative-ID

    string

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

    string

    L'insieme degli URL di destinazione dichiarati per la creatività codificati in base alla 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 creatività con l'API Real-time Bidding, dovrai inviarle di nuovo dopo 15 giorni. Se utilizzi la scansione automatica delle creatività, il processo di scansione le analizza nuovamente in automatico.

ID report acquirente

Puoi suddividere le metriche dei report (ad esempio le impressioni) utilizzando le dimensioni fornite dall'acquirente (ad esempio, ID campagna o ID inserzionista). Per aggiungere una dimensione per la spesa del gruppo di interesse, specifica un buyerAndSellerReportingId per il tuo annuncio quando aggiungi il dispositivo dell'utente al gruppo di interesse. Per ulteriori dettagli, consulta la 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);

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

Asta lato server

Modifiche alle richieste di offerta

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

Indicare il supporto per l'asta di gruppo di interesse

Le richieste di offerta hanno nuovi campi per indicare il supporto delle aste dei gruppi di interesse:

  • OpenRTB:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • Protocollo RTB di Google (ritirato):
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

Puoi utilizzare questo campo per distinguere le opportunità di impressione che supportano l'asta dei gruppi di interesse nel browser Protected Audience e quelle che supportano solo l'asta tradizionale dell'exchange lato server. L'enumerazione AuctionEnvironment può avere i seguenti valori:

  • SERVER_SIDE_AUCTION (OpenRTB JSON: 0): l'asta che determina l'annuncio vincente viene eseguita sui server dell'exchange.
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1): richieste con supporto di Protected Audience, in cui un'asta contestuale viene eseguita sui server dell'exchange e l'offerta del gruppo basato sugli interessi e l'asta finale vengono eseguite nel browser.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): l'asta contestuale viene eseguita sui server dell'exchange e la logica di offerta per le offerte dei gruppi di interesse e la logica di assegnazione del punteggio per determinare l'annuncio vincente finale vengono eseguite nei server di offerte e aste.
Indica le dimensioni dell'area annuncio Protected Audience

La richiesta di offerta include i seguenti campi per fornirti le dimensioni dello spazio pubblicitario Protected Audience:

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • Protocollo RTB di Google (ritirato):
    • 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 potrebbero essere diverse da quelle della richiesta contestuale, ad esempio quelle visualizzate nei campi BidRequest.imp.banner.format.w e BidRequest.imp.banner.format.h di OpenRTB o nei campi BidRequest.adslot.width e BidRequest.adslot.height del protocollo Google RTB ritirato.

La richiesta contestuale potrebbe avere più dimensioni. L'annuncio vincitore dell'asta sul dispositivo deve occupare un solo spazio di dimensioni fisse.

Indicare il rendering degli annunci Protected Audience

Il rendering degli annunci Protected Audience può essere eseguito o meno a seconda della fase di integrazione corrente (vedi esperimento di non rendering). Il campo render_interest_group_ads nella richiesta di offerta indica se l'annuncio Protected Audience vincente verrà visualizzato.

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

Le richieste di offerta contestuali nell'ambito dei test dell'API Protected Audience possono continuare a includere identificatori tradizionali basati sui cookie quando disponibili dal browser, ad esempio i campi BidRequest.user.id e BidRequest.user.buyerid oppure BidRequest.google_user_id e BidRequest.hosted_match_data nel protocollo RTB di Google ritirato. La presenza di questi identificatori nelle richieste di offerta è soggetta alle norme sulla privacy esistenti. Ti consigliamo di non fare affidamento sugli identificatori basati sui cookie per il targeting e le offerte durante i test, in modo da prepararti meglio per un acquisto efficiente quando i cookie di terze parti non saranno più disponibili.

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.

In preparazione al ritiro dei cookie di terze parti (3PCD) nel 2024, Chrome ora offre test facilitati da Chrome.

Siti e fornitori possono utilizzare i test facilitati da Chrome per testare i propri sistemi in base a 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 di esperimenti 3PCD specifico a cui puoi accedere tramite l'API Chrome nel browser.

Google trasmette l'etichetta non modificata dall'API Chrome alla richiesta di offerta RTB. A causa delle piccole porzioni di traffico di una singola etichetta, Google non sempre include l'etichetta nei contesti con limitazioni della privacy.

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

  • OpenRTB: BidRequest.device.ext.cdep
  • Protocollo RTB di Google (ritirato): BidRequest.device.cookie_deprecation_label

Modifiche alle risposte all'offerta

Indicare la partecipazione all'asta di gruppo di interesse

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

  • OpenRTB: BidResponse.ext.igbid
  • Protocollo RTB di Google (ritirato): BidResponse.interest_group_bidding

Devi fornire una risposta all'offerta contestuale. La risposta non è obbligatoria 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. Il origin viene aggiunto alla interestGroupBuyers della configurazione dell'asta quando le chiamate del Tag publisher di Google 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 sua funzione di offerta sul dispositivo tramite l'argomento perBuyerSignals. Queste informazioni possono essere incluse nella risposta all'offerta con i seguenti campi, a seconda del protocollo:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • Google RTB (ritirato): BidResponse.interest_group_bidding.per_buyer_signals
Propagare gli indicatori di rendering contestuale dell'acquirente

Le creatività dei gruppi di interesse possono utilizzare indicatori contestuali limitati durante il rendering inviando questi indicatori tramite la risposta all'offerta contestuale e ricevendoli nella richiesta dell'URL di rendering utilizzando l'espansione delle macro. Ad esempio, gli indicatori di rendering potrebbero essere utilizzati 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 gli URL nella risposta all'offerta contestuale, che Google sostituirà nell'URL di rendering del gruppo di interesse vincente costruendo la macro ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

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

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB (ritirato): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

Nella risposta all'offerta possono essere inclusi fino a tre set di indicatori di rendering con suffissi macro diversi per distinguere i vari indicatori. Ad esempio, un suffisso potrebbe essere utilizzato per trovare corrispondenze con un insieme specifico di indicatori applicabili solo alle creatività con la macro corrispondente nel relativo URL di rendering, riducendo così le dimensioni del trasferimento dei dati.

L'acquirente del gruppo di interesse non potrà partecipare all'asta Protected Audience se gli indicatori non sono sicuri per gli URL, i suffissi delle macro non sono univoci o se vengono forniti più di tre set di indicatori.

Specifica il prezzo di offerta massimo nel browser

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, come il prezzo dell'offerta vincente.

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

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

  • OpenRTB: BidResponse.igbid.igbuyer.maxbid(espresso in unità di valuta CPM)
  • Protocollo RTB di Google (ritirato): 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 RTB di Google (ritirato): 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 RTB di Google (ritirato): BidRequest.adslot.matching_ad_data.billing_id

Se l'ID fatturazione a cui attribuire le impressioni delle offerte dei gruppi basati sugli interessi non viene fornito, lo strumento di offerta 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 l'altro per la spesa del 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.

Gli ID fatturazione di tutti gli account secondari con budget disponibile idoneo a fare offerte per l'impressione vengono visualizzati nella richiesta di offerta per la selezione dell'attribuzione della spesa. Contatta il tuo account manager per modificare il budget per un ID fatturazione del gruppo di interesse.

Durante l'asta nel browser

Generare offerte nel browser

Utilizza generateBid() per generare offerte nel browser.

Google fornisce i seguenti parametri:

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

Vengono restituiti i seguenti parametri:

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

Ecco un esempio:

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

Consulta la sezione Offerte on-device delle specifiche di Protected Audience per una spiegazione della funzione generateBid().

Valuta dell'offerta

Le offerte dell'asta nel browser vengono inserite in unità di CPM della valuta dell'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 alfabetico ISO 4217 valido, ad esempio "USD", "EUR" o "JPY".

In OpenRTB, utilizza il nuovo campo cur nell'oggetto InterestGroupBuyer nell'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 nel messaggio InterestGroupBuyer 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 offerte nella stessa valuta indicata nella risposta all'offerta contestuale. Compila la nuova proprietà bidCurrency nel valore restituito di generateBid:

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

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

Controlli della qualità degli annunci

L'applicazione delle norme relative alle creatività e dei controlli per i publisher potrebbe essere più restrittiva per le offerte basate sul gruppo di interesse nel browser durante il test dell'API Protected Audience per i partner RTB.

Assistenza per il Regolamento sui servizi digitali

Ai sensi dell'articolo 26 del Regolamento sui servizi digitali, i publisher possono richiedere agli acquirenti di eseguire il rendering delle informative sulla trasparenza negli annunci. Quando il controllo "Chiedi agli acquirenti di mostrare solo annunci con informazioni sulla trasparenza ai sensi del DSA sul mio sito o nella mia app nel SEE" è attivato da un publisher, gli acquirenti di gruppi basati sugli interessi possono determinare per quali opportunità dovranno eseguire il rendering della trasparenza dell'acquirente annotando i valori di BidRequest.regs.dsa.required e BidRequest.dsa.pubrender nella richiesta di offerta (BidRequest.dsa.dsa_support e BidRequest.dsa.publisher_rendering_support rispettivamente nel protocollo Google RTB ritirato).

Quando un offerente che vuole partecipare alle aste dell'API Protected Audience riceve l'indicatore nella richiesta di offerta che segnala che è necessario mostrare la 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 Google RTB ritirato). In caso contrario, l'acquirente non verrà incluso nell'asta dell'API Protected Audience.

Per ulteriori informazioni sulla trasparenza degli annunci ai sensi del Digital Services Act, consulta l'articolo del Centro assistenza: Supporto del Digital Services Act.

Filtro delle offerte

Google applica i controlli per i publisher e le norme pubblicitarie durante l'asta sul dispositivo.

Dopo l'asta nel browser

Report auction result to buyer: reportWin()

Google non compila i seguenti argomenti:

  • auctionSignals
  • sellerSignals

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

Per ulteriori informazioni, consulta la sezione Report dell'acquirente su eventi di rendering e annuncio della spiegazione dell'API Protected Audience.

Macro

Il renderUrl che fa riferimento alla creatività dell'API Protected Audience può includere uno o più segnaposto, chiamati macro. Al termine dell'asta del gruppo di interesse, ma prima del rendering, le macro vengono sostituite dai valori corrispondenti. renderUrl utilizzato nell'asta on-device può includere le seguenti macro:

${GDPR} Si espande a 0 se il GDPR non si applica o a 1 se si applica. Consulta la documentazione.
${GDPR_CONSENT_XXXX} Si espande nella stringa trasparenza e consenso (TC) associata alla richiesta. Se la stringa trasparenza e consenso (TC) risulta vuota o non valida, questa macro non si espande.

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

Le creatività con la macro ${GDPR_CONSENT_XXXX} potrebbero essere bloccate se il fornitore registrato al GVL di IAB associato all'ID GVL di IAB che hai inserito non ha il consenso dell'utente.

La macro ${GDPR_CONSENT_XXXX} deve apparire solo una volta all'interno di 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 dell'acquirente al momento del rendering specificati 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 includere un _OPTIONAL_SUFFIX per fornire fino a tre diversi valori di segnale di rendering.

Conteggio delle impressioni

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

Poiché l'evento utilizzato da Google per il conteggio delle impressioni nelle aste in-browser Protected Audience potrebbe essere diverso da quello utilizzato per il conteggio delle impressioni dai suoi partner acquirenti RTB, i conteggi delle impressioni potrebbero differire.

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 inserzionista dalle aste in-browser Protected Audience viene attribuita a un singolo account inserzionista in base al mapping delle origini del proprietario del gruppo di interesse configurate per l'inserzionista. L'attribuzione della spesa a diversi account secondari di un offerente non è supportata.

Limite di budget giornaliero

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

L'account può continuare a partecipare alle aste contestuali lato server dopo aver raggiunto 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 feedback per gli acquirenti di gruppi basati sugli interessi richiesti per l'inclusione in un'asta Protected Audience sul dispositivo. Ogni acquirente del gruppo basato sugli interessi specificato da un offerente in una risposta all'offerta riceverà un oggetto di feedback, indipendentemente dal numero di offerte che l'acquirente del gruppo basato sugli interessi fa nell'asta Protected Audience. Le seguenti informazioni saranno disponibili nell'oggetto feedback dell'acquirente del gruppo basato sugli interessi:

  • 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 per aggiudicarsi l'asta complessiva.
  • L'offerta minima per vincere per l'acquirente del gruppo di interesse per battere l'offerta con il ranking più alto del componente lato server dell'asta complessiva.
  • Il codice di stato dell'acquirente del gruppo di interesse. I codici di stato possibili sono definiti in interest-group-buyer-status-codes.txt.

Consulta la documentazione del protocollo per RTB di Authorized Buyers e estensioni OpenRTB per i nomi dei campi specifici.

Notifica di feedback sull'offerta

Chrome fornisce un'API di debug temporanea per l'API Protected Audience che consente ad Ad Manager di inviare notifiche di debug server-to-server in tempo reale che contengono feedback su un'offerta Protected Audience. Questa notifica includerà i motivi per cui le offerte potrebbero essere state filtrate nell'asta in-browser Protected Audience, oltre ad altre informazioni su un'offerta descritte di seguito.

Gli offerenti possono contattare il proprio account manager per configurare un URL statico che verrà utilizzato per inviare le notifiche di feedback sul debug delle offerte 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 per Protected Audience. Nel protocollo OpenRTB, questo valore è specificato con BidRequest.ext.google_query_id, mentre il protocollo Google RTB ritirato utilizza BidRequest.google_query_id.
  • %%INTEREST_GROUP_OWNER%%: L'origine del proprietario del gruppo di interesse.
  • %%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 codici di 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 di feedback sull'offerta è una funzionalità temporanea che dipende dall'API ForDebuggingOnly temporanea di Chrome.

TURTLEDOVE a livello di prodotto

Annunci composti da più parti o TURTLEDOVE a livello di prodotto(PLTD) è supportato per i partner RTB di Google durante il test dell'API Protected Audience. Durante l'integrazione, comunica al tuo account manager se prevedi di testare PLTD, poiché sono necessarie risorse e configurazioni aggiuntive.

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 apri un ticket utilizzando il Centro assistenza Authorized Buyer.
  3. Una volta configurato l'account, sia Google che il partner possono verificare l'integrazione seguendo i passaggi descritti in Fasi di test.

Revisione delle creatività

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

  • Includi il parametro di query &pltd=True in renderUrl per il contenitore dell'annuncio componente (chiamato anche renderUrl di primo livello) per distinguere renderUrls di primo livello durante la revisione delle creatività.
  • Esegui il rendering di una creatività rappresentativa quando il contenitore dell'annuncio componente viene recuperato per una revisione della creatività da parte di Google. Per capire quando deve essere restituito il rendering di un annuncio rappresentativo, puoi fare riferimento al parametro di query validation=True impostato dal sistema di revisione delle creatività di Google.

Elenco di controllo per l'integrazione

  • Configura un endpoint di richiesta di offerta che popolerà i campi correlati all'API Protected Audience nella risposta all'offerta contestuale, ad esempio interest_group_bidding.
  • Implementa il tagging sulle pagine dell'inserzionista per unire il browser dell'utente al gruppo basato sugli interessi.
  • Implementa generateBid() e reportWin().
  • Seleziona le origini dei proprietari dei gruppi basati sugli interessi e aggiungile all'account Authorized Buyer.
    • Le origini del proprietario del gruppo di interesse devono corrispondere a quelle in cui sono ospitate le funzioni generateBid().
    • Per completare questo passaggio, contatta l'account manager o invia un ticket utilizzando il Centro assistenza per gli acquirenti autorizzati.
  • Configura il pretargeting per l'inventario pertinente ai test dell'API Protected Audience.
  • Invia le creatività per la revisione e l'approvazione tramite l'API Creatività.
  • (Facoltativo) Configura gli endpoint degli indicatori di offerta attendibili.
  • (Facoltativo) Configura una pagina dell'inserzionista di test che consenta agli ingegneri di Google di aggiungere il proprio 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 il feedback in tempo reale sul tuo account per ricevere feedback per gli acquirenti di gruppi basati sugli interessi 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 da server a server che fornisca un feedback sull'offerta Protected Audience per lo stato di un'offerta da un'asta Protected Audience sul dispositivo per facilitare il debug di problemi imprevisti. Per maggiori dettagli, consulta la notifica di feedback sull'offerta.

Fasi del test

Fase 1: test manuale

Ecco come attivare manualmente un'asta Protected Audience, assicurarsi che l'annuncio possa essere visualizzato e registrare l'impressione:

  1. Utilizza Chrome 101 o versioni successive.
  2. Attiva l'API Privacy Sandbox e Fenced Frame utilizzando chrome://flags/#privacy-sandbox-ads-apis e chrome://flags/#enable-fenced-frames. Scopri di più su Testare 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 di test per publisher fornita da Google per attivare un'asta Protected Audience:

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

    Il gruppo basato sugli interessi nel browser deve fare un'offerta sufficientemente alta per vincere l'asta, in quanto potrebbe competere con le offerte lato server convenzionali. Google fornisce inoltre una pagina di test dedicata per ogni partner, in cui solo il partner in questione può partecipare all'asta. Potrebbe essere più facile vincere in modo affidabile le aste nel browser in 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 di risposta da reportWin().
    3. La console della pagina dell'editore 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 di stato della creatività.

Fase 2: (facoltativo) esperimento senza rendering

Dopo che Google e il partner hanno verificato manualmente che il partner può partecipare all'asta Protected Audience, Google attiva il partner per la fase successiva del test.

Google destina una piccola quantità di traffico live all'esecuzione delle aste Protected Audience. Dopodiché, Google e il partner non devono più attivare manualmente un'asta Protected Audience. Il risultato dell'asta Protected Audience non viene visualizzato. Ciò 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 Buyer. 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 rendering, Google può consentire al partner di eseguire il rendering dell'annuncio vincente Protected Audience. Google ha una piccola quantità di traffico in cui le aste Protected Audience sono idonee alla pubblicazione e vengono visualizzati gli annunci dei gruppi basati sugli interessi vincenti. Le offerte in-browser degli offerenti partecipanti competono con le offerte tradizionali.

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

Altre caratteristiche

Le seguenti funzionalità sono estensioni del protocollo principale.

Parallelizzazione

Il parallelismo è un'ottimizzazione che riduce la latenza dell'asta end-to-end avviando la richiesta di annuncio contestuale in parallelo con le richieste ai server attendibili dell'acquirente specificati in trustedBiddingSignalsUrl.

La parallelizzazione riduce la latenza, ma influisce sull'idoneità degli acquirenti dei gruppi di interesse e sul supporto per gli esperimenti coordinati. La parallelizzazione si applica a tutti gli offerenti che partecipano all'asta dei gruppi di interesse sul dispositivo. Gli offerenti non devono intraprendere alcuna azione per partecipare alle aste parallele, ma devono acquisire familiarità con il modo in cui la parallelizzazione può influire sulla loro idoneità nelle aste sul dispositivo. Gli ID gruppo di esperimenti per gli esperimenti coordinati non sono ancora supportati nelle aste parallele.

Riepilogo del flusso di pubblicazione

Ecco un riepilogo del flusso dell'asta parallela: Diagramma di flusso

Idoneità dell'acquirente del gruppo di interesse sul dispositivo

Per le aste parallele, la chiamata di navigator.runAdAuction avviene prima che venga restituita la risposta dell'annuncio contestuale. Per avviare chiamate al server attendibile dell'acquirente, navigator.runAdAuction richiede che il parametro interestGroupBuyers venga trasmesso come valore, mentre i parametri dell'asta rimanenti accettano promesse Javascript che possono essere risolte dopo la risposta dell'annuncio contestuale. Poiché interestGroupBuyers viene trasmesso 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 parametri interestGroupBuyers delle esecuzioni navigator.runAdAuction precedenti sullo stesso dominio vengono memorizzati nella cache del tag editore di Google nel browser dell'utente.

La parallelizzazione presenta diverse considerazioni importanti:

  1. Gli indicatori dell'asta che non sono necessari per le richieste del server attendibile dell'acquirente, come perBuyerSignals, possono continuare a essere specificati nelle risposte all'offerta RTB nello stesso modo delle aste non parallelizzate. 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é la parallelizzazione si basa sulla memorizzazione nella cache dell'elenco degli acquirenti di gruppi basati sugli interessi, Google non esegue sempre un'asta parallela, in quanto la cache di parallelizzazione potrebbe essere vuota o scaduta. Se la cache è vuota o scaduta, Google esegue un'asta standard non parallela dell'API Protected Audience e utilizza l'intenzione dell'acquirente per partecipare all'asta non parallela per creare la cache dell'acquirente del gruppo di interesse.

  3. Se almeno un acquirente per qualsiasi offerente viene memorizzato nella cache per il dominio dell'editore corrente, Google eseguirà un'asta parallela, che verrà indicata 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 di gruppi di interesse registrati per un determinato offerente inclusa nell'asta parallela avrà una voce ParallelAuctionBuyer corrispondente:

    • 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 un'origine acquirente specifica non è presente nella cache, l'acquirente in questione non può essere aggiunto all'asta on-device corrente. Ciò è indicato da una richiesta con parallelized=True che non contiene una voce ParallelAuctionBuyer per una determinata origine dell'acquirente del gruppo di interesse. Tuttavia, gli offerenti che indicano interesse includendo InterestGroupBuyer validi e idonei nella risposta all'offerta vedranno le origini dell'acquirente del gruppo basato sugli interessi corrispondente aggiunte alla cache e queste origini saranno idonee per le richieste parallele future dallo stesso browser e dominio. L'intenzione di partecipare alle aste dei gruppi di interesse può essere indicata nei seguenti campi:

    • Protocollo RTB di Google: 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 alla risposta all'offerta potrebbero ricevere una chiamata al server attendibile dell'acquirente ma non parteciperanno all'asta parallela.