API Protected Audience (in precedenza FLEDGE)

Nell'ambito di Privacy Sandbox, Chrome ha proposto l'API Protected Audience, un'API interna al browser che consente a inserzionisti e aziende di ad tech di mostrare annunci con targeting per gruppi di interesse senza fare affidamento su cookie di terze parti, proteggendo al contempo gli utenti dal monitoraggio tra siti.

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 sull'inventario del publisher di Ad Manager. Gli offerenti possono raggiungere i seguenti obiettivi 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 GitHub.
  • Preparati a supportare la pubblicità personalizzata tramite l'API senza fare affidamento su cookie di terze parti.

Gli acquirenti Authorized Buyers interessati ai test possono consultare la sezione Inserimento per i dettagli.

Riepilogo del flusso di pubblicazione

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

Diagramma di flusso

  1. Uno strumento di offerta collabora con i propri inserzionisti per gestire i gruppi di interesse per ciascun inserzionista. Spesso, gli inserzionisti aggiungevano un tag di offerta 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 il tag annuncio del publisher di Google.
  5. Il tag annuncio del publisher di Google invia una richiesta di annuncio contestuale a un server di 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 un valore BidResponse con il campo interest_group_bidding. Se l'offerente non specifica interest_group_bidding, Google non include l'origine dell'offerente in interestGroupBuyers nella configurazione delle aste. La risposta all'offerta può contenere anche interest_group_bidding.per_buyer_signals. per_buyer_signals verrà trasmesso alla funzione di offerta dell'offerente durante l'asta nel browser. Per ulteriori informazioni, consulta la sezione Modifiche alle risposte 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'eventuale offerta contestuale vincente (se presente).
  9. La risposta all'offerta contiene una configurazione di asta per l'asta nel browser. Possono includere indicatori contestuali di ogni acquirente partecipante (inviati tramite interest_group_bidding.per_buyer_signals), informazioni contestuali sul vincitore e impostazioni per l'idoneità dell'offerta.
  10. Il tag publisher di Google richiama l'API Protected Audience runAdAuction() per avviare l'asta del gruppo di interesse on-device. Google include solo gli acquirenti che in precedenza hanno restituito interest_group_bidding come interestGroupBuyers nella configurazione dell'asta.
  11. Google trasmette il valore per_buyer_signals di ogni offerente idoneo alla configurazione dell'asta Protected Audience.
  12. Se i gruppi di interesse di un determinato offerente hanno specificato trustedBiddingSignalsUrl, il browser invia una richiesta a trustedBiddingSignalsUrl di ogni gruppo per recuperare indicatori in tempo reale per ogni gruppo. Consulta i dettagli nella specifica 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 a per_buyer_signals fornito dall'offerente e agli indicatori di offerta attendibili per il gruppo di interesse specificato.
  14. Il browser richiama il scoreAd() del venditore (in questo caso, di Google) per assegnare un ranking a ciascuna offerta nell'asta dell'annuncio basato sul gruppo di interesse. Le offerte vengono classificate e filtrate in base a protezioni per i publisher, norme relative agli annunci e altri vincoli.
  15. Il browser esegue un'asta con le offerte idonee per il gruppo di interesse. L'offerta contestuale con il miglior ranking partecipa all'asta nel browser.
  16. Dopo l'asta, se c'è un vincitore del gruppo di interesse, il browser richiama il reportResult() del venditore e il reportWin() dell'offerente per informare ciascuna parte del vincitore dell'asta nel browser.
  17. Se un annuncio basato sul 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

Verifica delle creatività

Le creatività devono essere esaminate e approvate da Google prima di poter essere pubblicate dalle aste in-browser di Protected Audience. Puoi inviare le creatività per la revisione tramite l'API Real-Time Bidding o tramite l'analisi automatica delle creatività. Le creatività per le aste degli annunci del gruppo di interesse nel browser 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 una singola campagna pubblicitaria. Un determinato renderUrl non può essere utilizzato per visualizzare annunci per conto di più inserzionisti. Ogni elemento renderUrl deve essere mappato a una singola creatività.
  • Il renderUrl deve essere accessibile e recuperabile dai sistemi di verifica delle creatività offline di Google fino a 7 giorni dopo l'ultima offerta dell'annuncio.
Real-time Bidding API

Gli offerenti possono usare l'API Real-Time Bidding per caricare le creatività per le offerte basate sul gruppo di interesse.

Analisi automatica delle creatività

Gli offerenti possono configurare l'analisi automatica delle creatività per le creatività che non vengono caricate tramite l'API Real-Time Bidding.

Se configuri l'analisi automatica delle creatività, Google trova le creatività nell'asta in-browser e le sottopone automaticamente a scansione, 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 all'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à è 128 byte.
    Authorized-Buyers-Click-Through-URLs

    stringa

    L'insieme di URL di destinazione dichiarati per la creatività codificata secondo lo standard 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 inviarla nuovamente dopo 15 giorni. Se utilizzi l'analisi automatica delle creatività, durante la procedura di scansione le scansioni viene eseguita di nuovo 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);

buyer_reporting_id apparirà come nuova dimensione nello strumento di generazione di report di Authorized Buyers, 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:

Supporto per l'asta dell'indicazione del gruppo di interesse

Le richieste di offerta hanno un nuovo campo, auction_environment.

  • Protocollo Google RTB: BidRequest.adslot.auction_environment
  • OpenRTB: BidRequest.imp.ext.auction_environment

Puoi utilizzare questo campo per distinguere le opportunità di impressioni che supportano l'asta del gruppo di interesse nel browser Protected Audience e quelle che supportano solo la tradizionale asta di scambio lato server. L'enumerazione auction_environment può avere i seguenti valori:

  • SERVER_SIDE_AUCTION (JSON OpenRTB: 0): aste tradizionali lato server
  • ON_DEVICE_INTEREST_GROUP_AUCTION (JSON OpenRTB: 1): richieste con supporto di Protected Audience, in cui viene eseguita un'asta contestuale sui server della piattaforma di scambio pubblicitario e le offerte basate sul gruppo di interesse e l'asta finale viene eseguita nel browser.
Indica le dimensioni dell'area annuncio Protected Audience

La richiesta di offerta include i seguenti campi per fornirti le dimensioni dell'area annuncio di Protected Audience:

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

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

Queste dimensioni potrebbero essere diverse da quelle della richiesta contestuale (Adslot.widtheAdslot.height oppure in OpenRTB: BidRequest.imp.banner.format).

La richiesta contestuale potrebbe avere più dimensioni. Si prevede che l'annuncio vincente dell'asta on-device riempia solo una singola dimensione fissa dell'area.

Indicare il rendering degli annunci Protected Audience

Gli annunci Protected Audience possono essere visualizzati o meno a seconda della fase di integrazione attuale (vedi l'esperimento non di rendering). Il campo render_interest_group_ads nella richiesta di offerta indica se verrà visualizzato l'annuncio Protected Audience vincente.

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

Le richieste di offerta contestuali che rientrano nell'ambito dei test dell'API Protected Audience possono continuare a includere identificatori tradizionali basati sui cookie quando disponibili dal browser, come i campi google_user_id (BidRequest.user.id in OpenRTB) e hosted_match_data (BidRequest.user.buyerid in OpenRTB). La presenza di questi identificatori nelle richieste di offerta continuerà a essere soggetta alle norme sulla privacy esistenti. Ti consigliamo di non fare affidamento sugli identificatori basati sui cookie per scopi di targeting e offerte durante i test, per prepararti meglio a un acquisto efficiente quando i cookie di terze parti non sono più disponibili.

Google potrebbe anche eseguire esperimenti su scala ridotta in cui gli identificatori basati sui cookie vengono oscurati dalle richieste di offerta nell'ambito dei test dell'API Protected Audience. allo scopo di 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 3PCD. Nel test, i browser Chrome vengono assegnati a un gruppo di esperimenti 3PCD, 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 dell'API Chrome alla richiesta di offerta RTB. A causa delle piccole sezioni di traffico di una singola etichetta, Google non sempre include l'etichetta in contesti limitati alla privacy.

Ecco i campi in cui puoi visualizzare l'etichetta:

  • Protocollo Google RTB: BidRequest.device.cookie_deprecation_label
  • OpenRTB: BidRequest.device.ext.cdep

Modifiche alle risposte all'offerta

Indica la partecipazione all'asta del 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:

  • Protocollo Google RTB: BidResponse.interest_group_bidding
  • OpenRTB: BidResponse.ext.igbid

Devi fornire una risposta all'offerta contestuale. La risposta non è necessaria per includere un'offerta contestuale. L'oggetto InterestGroupBidding deve contenere il valore origin del proprietario del gruppo di interesse, che deve corrispondere a una delle origini configurate dall'offerente per il suo account. origin viene aggiunto al interestGroupBuyers della configurazione di asta quando Tag publisher di Google chiama runAdAuction().

Propaga gli indicatori di contesto dell'acquirente (perBuyerSignals)

Puoi includere nella risposta all'offerta contestuale gli indicatori di un acquirente, che Google propone come oggetto JSON alla sua funzione di offerta on-device tramite l'argomento perBuyerSignals. Questo valore può essere incluso nella risposta all'offerta con i seguenti campi a seconda del protocollo:

  • RTB di Google: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
Specifica il prezzo massimo dell'offerta 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 abusi 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 parte di Google per i suoi partner RTB, puoi specificare un valore di offerta massimo previsto in ogni risposta all'offerta contestuale. L'offerta massima prevista è il prezzo di offerta massimo che la tua funzione di offerta dovrebbe restituire. Se l'offerta vincente registrata dall'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 seguenti campi:

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

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

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

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

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

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

Gli account secondari possono avere fino a due ID fatturazione. L'acquirente può utilizzare un ID fatturazione per la spesa contestuale e l'altro per la spesa basata sul 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 di 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 l'attribuzione della spesa. Contatta il tuo account manager per modificare il budget per un ID fatturazione gruppo di interesse.

Durante l'asta nel browser

Genera 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 micro).
  • render: l'URL visualizzato per mostrare la creatività se l'offerta vince l'asta. Google deve rivedere e approvare questo URL, altrimenti verrà escluso dall'asta.
  • allowComponentAuction: deve essere true. Al momento Google supporta il test delle aste multi-venditore.

Esempio:

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

Per una spiegazione della funzione generateBid(), consulta la sezione Offerte on-device della specifica di Protected Audience.

Valuta dell'offerta

Le offerte all'asta nel browser sono espresse in unità di CPM della valuta scelta per l'offerta.

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

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

Esempio:

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

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

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. Inserisci 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 risposte restituisce una valuta non valida, l'offerta verrà filtrata prima dell'asta.

Controlli di qualità degli annunci

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

Assistenza per il Digital Services Act

A causa dell'articolo 26 del Digital Services Act, i publisher possono richiedere agli acquirenti di visualizzare le informative relative alla trasparenza nell'annuncio. Quando un publisher attiva il controllo "Chiedi agli acquirenti di mostrare solo annunci con informazioni sulla trasparenza DSA sul mio sito o nella mia app nel SEE" è attivato da un publisher, gli acquirenti del gruppo di interesse possono determinare le opportunità per cui saranno tenuti a mostrare la trasparenza degli acquirenti esaminando i seguenti campi nelle richieste di offerta ricevute: BidRequest.dsa.dsa_support e BidRequest.dsa.publisher_rendering_support per il protocollo di Google Authorized Buyers e BidRequest.regs.dsa.required e BidRequest.dsa.pubrender per il protocollo OpenRTB.

Quando un offerente che vuole partecipare alle aste dell'API Protected Audience riceve l'indicatore nella richiesta di offerta che indica che la trasparenza DSA deve essere mostrata per gli annunci pubblicati tramite l'API Protected Audience, deve valutare se è in grado di visualizzare correttamente le informazioni richieste e specificare impostando BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render per il protocollo di Google Authorized Buyers o BidResponse.ext.igbid.igbuyer.dsaadrenderper il protocollo OpenRTB. In caso contrario, l'acquirente non verrà incluso nell'asta dell'API Protected Audience.

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

Filtro delle offerte

Google applica i controlli per i publisher e le norme relative agli annunci durante l'asta on-device.

Dopo l'asta nel 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.

Per ulteriori informazioni, consulta la sezione Report sugli acquirenti sul rendering e sugli eventi annunci nel testo esplicativo dell'API Protected Audience.

Macro

L'elemento 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. Gli renderUrl utilizzati nell'asta on-device possono includere le seguenti macro:

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

Utilizza questa macro per trasmettere la stringa TC a un fornitore IAB registrato nell'elenco GVL in un URL. Sostituisci XXXX con l'ID GVL di IAB del fornitore registrato nell'elenco GVL di 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 nell'elenco GVL di IAB associato all'ID GVL di IAB che hai inserito non ha il consenso dell'utente.

La macro ${GDPR_CONSENT_XXXX} deve verificarsi una sola 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.

Numero di impressioni

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

Poiché l'evento utilizzato da Google per il conteggio delle impressioni nelle aste nel browser di Protected Audience potrebbe essere diverso da quello utilizzato per il conteggio delle impressioni dai partner acquirenti RTB, il numero di impressioni potrebbe essere diverso.

Uno degli obiettivi di Google per testare l'API Protected Audience è identificare e ridurre queste discrepanze.

Attribuzione delle impressioni fatturabili

Tutta la spesa di un offerente relativa alle aste in-browser di Protected Audience viene attribuita a un singolo account offerente in base alla mappatura delle origini del proprietario del gruppo di interesse configurate per l'offerente. L'attribuzione della spesa a diversi account utenze secondarie di un offerente non è supportato.

Limite di budget giornaliero

Durante i test dell'API Protected Audience, ogni account ha un limite di budget giornaliero per la spesa di Protected Audience a livello di account, che limita i rischi nell'ambiente delle aste 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 (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 di feedback in tempo reale riceveranno un feedback per gli acquirenti del gruppo di interesse a cui è stata richiesta l'inclusione in un'asta Protected Audience on-device. Ogni acquirente del gruppo di interesse che un offerente specifica in una risposta all'offerta riceverà un oggetto di feedback, indipendentemente dal numero di offerte che l'acquirente del gruppo di interesse effettua nell'asta Protected Audience. Le seguenti informazioni saranno disponibili sull'oggetto feedback sugli acquirenti del gruppo di interesse:

  • Il tipo di feedback dell'oggetto di 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 al fine di vincere l'asta complessiva.
  • L'offerta minima per vincere per l'acquirente del gruppo di interesse per superare 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 nel file interest-group-buyer-status-codes.txt.

Per i nomi dei campi specifici, consulta la documentazione sul protocollo per RTB di Authorized Buyers ed Estensioni OpenRTB.

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-server in tempo reale contenenti feedback su un'offerta Protected Audience. Questa notifica include i motivi per cui le offerte potrebbero essere state filtrate nell'asta in-browser di 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 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. Le macro riportate di seguito sono supportate:

  • %%GOOGLE_QUERY_ID%%: questa macro è sostituita dall'ID query di Google (BidRequest.google_query_id nel protocollo di Authorized Buyers e BidRequest.ext.google_query_id nel protocollo OpenRTB) che è stato inviato nella richiesta di offerta contestuale abilitata per Protected Audience.
  • %%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 codici di stato delle creatività.

Di seguito è riportato 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 sull'offerta è una funzionalità temporanea che dipende dall'API ForDebuggingOnly temporanea di Chrome.

Eventi relativi ai clic

Gli offerenti possono segnalare a Google gli eventi di clic sugli annunci Protected Audience utilizzando l'API di reporting Fenced Frame. Gli offerenti dovrebbero usare il tipo di evento click per comunicare a Google i clic. Ecco un esempio:

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

TURTLEDOVE a livello di prodotto

Gli annunci composti da più pezzi o la TARTARUGA a livello di prodotto (PLTD) sono supportati per i partner RTB di Google durante i test dell'API Protected Audience. Fai sapere al tuo account manager durante l'integrazione se prevedi di testare il test PLTD, poiché sono necessarie risorse e configurazione aggiuntive.

Onboarding

Ecco come puoi testare l'API Protected Audience:

Procedura

  1. Compila il modulo di richiesta per partecipare all'esperimento sull'API Protected Audience.
  2. Dopo aver inviato il modulo di richiesta, contatta il tuo account manager o invia una richiesta di assistenza tramite il Centro assistenza Authorized Buyers.
  3. Una volta configurato l'account, sia Google che il partner possono verificare l'integrazione tramite i passaggi descritti in Fasi di test.

Verifica delle creatività

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

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

Elenco di controllo dell'integrazione

  • Configura un endpoint della richiesta di offerta che compilerà i campi relativi all'API Protected Audience nella risposta all'offerta contestuale, ad esempio interest_group_bidding.
  • Implementa il tagging nelle pagine dell'inserzionista per partecipare al gruppo basato sugli interessi del browser dell'utente.
  • Implementa generateBid() e reportWin().
  • Seleziona le origini dei proprietari del gruppo di interesse e aggiungile all'account Authorized Buyers.
    • Le origini dei proprietari del gruppo di interesse devono corrispondere alle origini in cui sono ospitate le funzioni generateBid().
    • Contatta l'account manager o invia un ticket utilizzando il Centro assistenza Authorized Buyers per completare questo passaggio.
  • 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 Creatives.
  • (Facoltativo) Configura gli endpoint degli indicatori di offerta attendibili.
  • (Facoltativo) Configura una pagina di test dell'inserzionista che consenta ai tecnici Google di aggiungere il loro browser ai gruppi di interesse di proprietà dell'origine del tuo 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 del gruppo di interesse che hanno richiesto di essere inclusi in un'asta Protected Audience.
  • (Facoltativo) Contatta il tuo account manager per configurare un URL statico in modo da ricevere una notifica server-server che fornisca un feedback sull'offerta Protected Audience per lo stato di un'offerta in un'asta Protected Audience on-device per aiutarti a eseguire il debug di problemi imprevisti. Per informazioni dettagliate, consulta la notifica di feedback sull'offerta.

Fasi di test

Fase 1: test manuale

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

  1. Utilizza Chrome 101 o versioni successive.
  2. Abilita l'API Privacy Sandbox e il Fenced Frame utilizzando chrome://flags/#privacy-sandbox-ads-apis e chrome://flags/#enable-fenced-frames. Per ulteriori informazioni, consulta la pagina Testare la sandbox per la privacy.
  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 del publisher fornita da Google per attivare un'asta Protected Audience:

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

    Il gruppo di interesse interno al browser deve fare un'offerta sufficientemente elevata per vincere l'asta, in quanto potrebbe competere con le offerte convenzionali lato server. Google fornisce anche una pagina di test dedicata per ciascun partner, dove solo il partner in questione può partecipare all'asta. Potrebbe essere più facile vincere in modo affidabile le aste nel browser su una pagina specifica di un partner.

  6. Verifica quanto segue:

    1. Viene visualizzato l'annuncio vincente previsto.
    2. Il risultato dell'asta viene inviato lato server, il che significa che un 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 entro il giorno scoreAd().
      • externalBidStatus: un codice di stato che se l'offerta è stata rifiutata entro scoreAd(). I valori sono codici di stato delle creatività.

(Facoltativo) Fase 2: esperimento non di rendering

Dopo che Google e il partner hanno verificato manualmente che il partner può partecipare all'asta Protected Audience, Google consente al partner di passare alla fase successiva dei test.

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

Quando è tutto pronto, contatta il tuo account manager o apri un ticket tramite il Centro assistenza Authorized Buyers. Google abiliterà 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 visualizzare l'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 basati sul gruppo di interesse vincente. Le offerte nel browser degli offerenti partecipanti competono con le offerte tradizionali.

Quando è tutto pronto, contatta il tuo account manager o apri un ticket tramite il Centro assistenza Authorized Buyers. Google abiliterà l'account per questa fase.