Questa pagina è stata tradotta dall'API Cloud Translation.

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 il 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, per ad esempio GitHub.
Prepararti 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 di annunci Protected Audience per Authorized Buyers partner:

Diagramma di flusso

Uno strumento di offerta collabora con i propri inserzionisti per mantenere gruppi di interesse per ciascuno inserzionista. Spesso, gli inserzionisti aggiungono un tag di un offerente alla pagina dell'inserzionista per aggiungere un browser ai gruppi di interesse.
Un utente finale visita la pagina di un inserzionista. La pagina potrebbe contenere del tag.
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.
L'utente finale visita la pagina web di un publisher. Il browser dell'utente richiede Tag annuncio del publisher di Google.
Il tag annuncio del publisher di Google invia una richiesta di annuncio contestuale a un server Google.
Google invia richieste di offerta contestuali agli offerenti partecipanti. Consulta le Per ulteriori informazioni, consulta la sezione Modifiche alle richieste di offerta.
L'offerente restituisce un BidResponse con il campo interest_group_bidding. Se l'offerente non specifica interest_group_bidding, Google non includi l'origine dell'offerente in interestGroupBuyers nell'asta configurazione. La risposta all'offerta può anche contenere interest_group_bidding.per_buyer_signals. Il valore per_buyer_signals verrà trasmesso alla funzione di offerta dell'offerente durante in un'asta in-browser. Consulta la sezione Modifiche alle risposte all'offerta. per ulteriori informazioni.
Google esegue l'asta lato server e restituisce una risposta all'offerta al parametro del 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 qualsiasi).
La risposta all'offerta contiene una configurazione di asta per in un'asta. Questa può includere indicatori di contesto di ciascun acquirente partecipante (inviate tramite interest_group_bidding.per_buyer_signals), informazioni contestuali sul vincitore e impostazioni per l'idoneità alle offerte.
Il tag publisher di Google richiama l'API Protected Audience runAdAuction() per avviare l'asta on-device del gruppo di interesse. Google include solo acquirenti che in precedenza hanno restituito interest_group_bidding come interestGroupBuyers nella configurazione dell'asta.
Google trasmette i per_buyer_signals di ogni offerente idoneo all'offerta Configurazione dell'asta per segmenti di pubblico.
Se i gruppi di interesse di un determinato offerente specificavano trustedBiddingSignalsUrl, il browser invia una richiesta ai componenti di ogni gruppo trustedBiddingSignalsUrl per recuperare indicatori in tempo reale per ogni gruppo. Consulta dettagli nell'API Protected Audience del modello.
Il browser richiama il valore generateBid() dell'offerente per ogni gruppo basato sugli interessi che hanno attivato l'asta e che sono idonee a partecipare all'asta nel browser. Questo calcola l'offerta e seleziona una creatività. generateBid() ha accesso a il valore per_buyer_signals fornito dall'offerente e dall'asta attendibile indicatori per un determinato gruppo basato sugli interessi.
Il browser richiama il valore scoreAd() del venditore (in questo caso, di Google) per Assegna un ranking a ciascuna offerta nell'asta dell'annuncio basato sul gruppo di interesse. Ranking delle offerte e filtrati in base alle protezioni per i publisher, alle norme relative agli annunci e ad i vincoli.
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.
Dopo l'asta, se esiste un vincitore del gruppo di interesse, il browser richiama il reportResult() del venditore e il reportWin() dell'offerente per inviare una notifica a ogni sul vincitore dell'asta in-browser.
Se l'annuncio di un gruppo di interesse si aggiudica l'asta, il tag del publisher di Google visualizza l'annuncio in una iframe.

Dettagli del flusso di distribuzione

Prima della pubblicazione degli annunci

Verifica delle creatività

Le creatività devono essere esaminate e approvate da Google prima di poter essere pubblicate Aste nel browser 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 usare le offerte in tempo reale API per caricare creatività offerte basate su gruppi di interesse.

Analisi automatica delle creatività

Gli offerenti possono configurare l'analisi automatica delle creatività che non sono caricate tramite l'API Real-time Bidding.

Se hai impostato l'analisi automatica delle creatività, Google trova le creatività nella nel browser e ne esegue la scansione automaticamente per renderli idonei nelle 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à è 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 si inviano creatività con il ruolo API Bidding, dovrai inviare nuovamente la creatività dopo 15 giorni. Se fai affidamento su scansione automatica delle creatività, la procedura di scansione ne eseguirà automaticamente la nuova scansione.

ID report acquirente

Puoi suddividere le metriche dei report (come le impressioni) utilizzando le dimensioni forniti dall'acquirente (ad esempio, ID campagna o ID inserzionista). Per aggiungere un dimensione per la spesa basata sul gruppo di interesse, specifica un buyerAndSellerReportingId per il tuo annuncio quando aggiungi il dispositivo dell'utente al gruppo basato sugli interessi. Vedi ulteriori dettagli in Protected Audience documentazione.

Di seguito è riportato un esempio di come aggiungere buyerAndSellerReportingId a la 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 nella sezione Autorizzato Strumento di generazione dei report dell'acquirente, 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 nel esperimento:

Link anticipato al protocollo Google RTB
Link iniziale OpenRTB

Indica il supporto dell'asta basato sui gruppi di interesse

Il nuovo campo delle richieste di offerta è auction_environment.

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

Puoi usare questo campo per distinguere le opportunità di impressioni che supportano l'asta del gruppo di interesse nel browser di Protected Audience e quelle che supportano solo l'asta tradizionale delle piattaforme di scambio lato server. La L'enum 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 il supporto di Protected Audience, in cui viene eseguita un'asta contestuale sul ai server della piattaforma di scambio pubblicitario, le offerte basate sul gruppo di interesse e l'asta finale nel browser

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:

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 dell'area annuncio per l'asta Protected Audience in pixel.

Questa dimensione potrebbe essere diversa da quella della richiesta contestuale (Adslot.widtheAdslot.height o in OpenRTB: BidRequest.imp.banner.format).

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.

Indica la possibilità di rendering dell'annuncio 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.

Protocollo Google RTB: BidRequest.adslot.interest_group_auction.render_interest_group_ads
OpenRTB: BidRequest.imp.ext.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 come 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 continueranno a essere soggetti alle eventuali norme sulla privacy. Ti consigliamo di non fare affidamento su identificatori basati sui cookie per di targeting e offerta durante i test per prepararti meglio a ottenere effettuare acquisti quando i cookie di terze parti non sono più disponibili.

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

Test sul ritiro dei cookie di terze parti agevolati da Chrome

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 Modalità A o Modalità B. A ogni browser viene assegnata un'etichetta coerente corrispondenti a uno specifico gruppo sperimentale 3PCD a cui puoi accedere tramite l'API Chrome integrata nel browser.

Google trasmette l'etichetta non modificata dell'API Chrome nell'offerta RTB richiesta. 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:

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 al all'asta nel browser restituendo l'oggetto InterestGroupBidding nell'attributo 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 a includi un'offerta contestuale. L'oggetto InterestGroupBidding deve contenere origin del proprietario del gruppo di interesse, che deve corrispondere a una delle origini configurate dall'offerente per il proprio account. Il origin viene aggiunto all'asta il valore interestGroupBuyers della configurazione quando il Tag publisher di Google chiama runAdAuction().

Propaga gli indicatori contestuali dell'acquirente (perBuyerSignals)

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

RTB di Google: BidResponse.interest_group_bidding.per_buyer_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata

Propaga gli indicatori di rendering contestuale dell'acquirente

Durante il rendering, le creatività basate sui gruppi di interesse potrebbero utilizzare indicatori di contesto limitati mediante l'invio di questi indicatori tramite la risposta all'offerta contestuale e la loro ricezione nella richiesta dell'URL di rendering utilizzando l'espansione della 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:

RTB di Google: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.rsig

È possibile includere fino a tre insiemi di indicatori di rendering con suffissi macro diversi nella risposta all'offerta per distinguere indicatori diversi. Ad esempio, un suffisso possono essere utilizzati per associare un insieme specifico di indicatori applicabili solo alle creatività con la macro corrispondente nell'URL di rendering, riducendo così il trasferimento di dati dimensioni.

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 massimo dell'offerta nel browser

Nel riquadro Protected Audience proposta, il calcolo dell'offerta e l'asta finale dovrebbe essere eseguita localmente on-device. Ciò potrebbe creare potenziali vettori di comportamento illecito che possono influire sull'integrità dell'asta finale quali il prezzo di offerta vincente.

Come mitigazione supportata da Google durante i test dell'API Protected Audience per i relativi partner RTB, puoi specificare il valore dell'offerta massimo previsto in ogni risposta all'offerta contestuale. L'offerta massima prevista è il prezzo di offerta massimo che la funzione di offerta dovrebbe restituire. 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:

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 il proprio interesse gruppo di impressioni 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 per gruppo di interesse non è specificato, l'offerente non parteciperà all'asta Protected Audience.

Gli account secondari possono avere fino a due ID fatturazione. L'acquirente può usare uno l'ID fatturazione per la spesa contestuale e l'altro per la spesa basata sul gruppo di interesse. Rivolgiti al tuo account manager se vuoi configurare due ID fatturazione per un account bambino.

È 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 specifiche nel 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 partecipa all'asta. Il valore deve essere in unità CPM (non micro).
render: l'URL visualizzato per visualizzare la creatività se l'offerta si aggiudica la categoria in un'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};
}

Consulta la specifica di Protected Audience sul dispositivo Offerte per una spiegazione della funzione generateBid().

Valuta offerta

Le offerte dell'asta nel browser vengono indicate in unità di CPM della valuta dell'offerta scelta.

La valuta dell'offerta deve essere indicata sia nella risposta all'offerta contestuale sia nella il valore restituito da generateBid e deve essere un codice alpha ISO 4217 valido, ad esempio come "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"
  }
}

Offerenti Le funzioni generateBid devono restituire offerte nella stessa valuta delle indicato 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 indicata nella risposta all'offerta contestuale è diversa dalla valuta restituito da generateBid oppure se uno di questi restituisce una valuta non valida, verrà filtrata prima dell'asta.

Controlli di qualità degli annunci

Le norme relative alle creatività e l'applicazione dei controlli per i 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

A causa dell'articolo 26 del Regolamento sui servizi digitali, i publisher possono richiedere agli acquirenti di eseguire il rendering 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à necessari per garantire la trasparenza per gli acquirenti indicando i seguenti campi nella 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 è necessario mostrare informazioni sulla trasparenza ai sensi del DSA di annunci pubblicati tramite l'API Protected Audience, devono valutare visualizzare in modo appropriato le informazioni richieste e specificare BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render per il protocollo di Google Authorized Buyers BidResponse.ext.igbid.igbuyer.dsaadrenderper il protocollo OpenRTB. Altrimenti, l'acquirente non verrà incluso nell'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 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.

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

Macro

L'elemento 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 e Stringa per il consenso (TC) associata alla richiesta. Se l'Informativa sulla trasparenza e La stringa per il consenso (TC) è vuota o non valida. Questa macro non si espande. 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 nelle Stringa del consenso (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 dovrebbe corrispondere `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 il conteggio delle impressioni in Protected Audience le aste nel browser potrebbero essere diversi dall'evento utilizzato per il conteggio impressioni dai suoi partner acquirenti RTB, il numero di impressioni potrebbe essere diverso.

Uno degli obiettivi di Google per testare l'API Protected Audience è identificare e per 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. Attribuire la spesa a diversi gli account secondari di un offerente non sono supportati.

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 (OpenRTB: 0), anche se la richiesta di offerta è idonea per un dell'asta Protected Audience.

Feedback in tempo reale e offerta minima per vincere

Offerenti che hanno attivato la ricezione feedback in tempo reale riceverà un feedback per gli acquirenti del gruppo di interesse di cui è stata richiesta l'inclusione in un un'asta Protected Audience sul dispositivo. Per ogni acquirente del gruppo di interesse che un offerente specifica 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. La le seguenti informazioni saranno disponibili nel feedback degli acquirenti basato sul gruppo di interesse :

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.

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

Notifica di feedback sulle offerte

Chrome offre un servizio di debug temporaneo dell'API 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. La notifica includerà i motivi per cui le offerte potrebbero essere state filtrati nell'asta nel browser di Protected Audience, oltre ad altri informazioni su un'offerta descritti di seguito.

Gli offerenti possono contattare il proprio account manager per configurare un URL statico che verrà utilizzati per inviare notifiche di feedback sulle offerte di debug di Protected Audience. Questo l'URL statico verrà recuperato dai server Google con le macro selezionate sostituite al termine dell'asta Protected Audience. Le macro riportate di seguito sono supportati:

%%GOOGLE_QUERY_ID%%: questa macro è sostituita dall'ID query Google (BidRequest.google_query_id nel protocollo di Authorized Buyers e BidRequest.ext.google_query_id nel protocollo OpenRTB) che è stato inviato il 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 in la 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à codici.

Di seguito è riportato un URL statico di esempio 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 dalle impostazioni di Chrome API ForDebuggingOnly temporanea.

TURTLEDOVE a livello di prodotto

Annunci composti da più parti o a livello di prodotto TURTLEDOVE (PLTD) è supportata per i partner RTB di Google durante l'API Protected Audience. test. 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

Compila il modulo di richiesta. per partecipare all'esperimento dell'API Protected Audience.
Dopo aver inviato il modulo di richiesta, contatta il tuo account manager o un ticket tramite la Guida di Authorized Buyers assistenza.
Una volta configurato l'account, sia Google che il partner possono verificare seguendo i passaggi descritti nelle 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, devi rispettare 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 della richiesta di offerta che completerà l'API Protected Audience campi correlati 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 del proprietario del gruppo di interesse e aggiungile ad Authorized Buyers .
- Le origini del proprietario del gruppo di interesse devono corrispondere alle origini in cui Le funzioni generateBid() sono ospitate.
- 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 inserzionista di prova che consenta ai tecnici di Google di aggiungere il proprio browser ai gruppi di interesse di proprietà dell'acquirente del gruppo di interesse origine dati. In questo modo possiamo attivare manualmente le aste Protected Audience.
(Facoltativo) Attiva i feedback in tempo reale nel tuo account per ricevere feedback per acquirenti del gruppo di interesse hanno richiesto di essere inclusi in un segmento di pubblico Protected Audience in un'asta.
(Facoltativo) Contatta il tuo account manager per configurare un URL statico per Ricevere una notifica server-server che fornisce l'offerta Protected Audience Feedback sullo stato di un'offerta da un Protected Audience on-device per facilitare il debug di problemi imprevisti. Consulta il feedback sulle offerte Notifica per maggiori dettagli.

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:

Utilizza Chrome 101 o versioni successive.
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.
Inviare una creatività per l'approvazione utilizzando le offerte in tempo reale tramite Google Cloud.
Utilizza la pagina dell'inserzionista fornita dall'offerente per aggiungere un browser all'offerente di proprietà gruppo basato sugli interessi.
Utilizza la seguente pagina del publisher di prova fornita da Google per attivare un'impostazione Protected Asta per pubblico:

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 potrebbe 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.
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 si tratta di 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 da scoreAd().
  - externalBidStatus: un codice di stato se l'offerta è stata rifiutata entro scoreAd(). I valori sono stato della creatività codici.

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. Google e il partner non dovranno più attivare manualmente una dell'asta Protected Audience. Il risultato dell'asta Protected Audience non è eseguire il rendering. Questo ci consente di testare l'integrazione su larga scala.

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

Fase 3: esperimento di rendering

Dopo che Google e il partner hanno verificato le aste Protected Audience su larga scala senza eseguire il rendering, Google può consentire al partner di eseguire il rendering Annuncio vincente per il pubblico. 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. Offerenti partecipanti le offerte nel browser competono con le offerte.

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

Altre caratteristiche

Le seguenti funzionalità sono estensioni del protocollo principale.

Parallelizzazione

La parallelizzazione è un'ottimizzazione che riduce la latenza end-to-end dell'asta di avviando la richiesta di annuncio contestuale in parallelo con le richieste server attendibili dell'acquirente specificato 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 del gruppo di interesse on-device

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. Dal giorno interestGroupBuyers viene trasmesso prima della risposta all'annuncio contestuale, la risposta all'annuncio contestuale (incluse le risposte alle offerte) non possono essere utilizzati per scegliere quali acquirenti partecipare all'asta parallelizzata per la richiesta specifica. 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 richiede diverse considerazioni importanti:

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 relative a questi indicatori, i passaggi rimanenti delle l'asta on-device verrà completata come per l'asta non parallela il flusso delle aste.
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 una un'asta dell'API Protected Audience standard non parallela e utilizza l'intenzione dell'acquirente per partecipano all'asta non parallela per creare la cache degli acquirenti basata sul gruppo di interesse.
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 Google RTB: BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
Ogni origine acquirente registrata per il gruppo di interesse per un determinato offerente che era incluse nell'asta parallela avranno una corrispondenza Voce ParallelAuctionBuyer:
- Protocollo Google RTB: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
Se viene eseguita un'asta parallela, ma un'origine acquirente specifica non è presente in cache, l'acquirente in questione non potrà essere aggiunto all'attuale in un'asta. Ciò è indicato da una richiesta con parallelized=True priva di Voce ParallelAuctionBuyer per una determinata origine dell'acquirente del gruppo di interesse. Tuttavia, gli offerenti che dimostrano interesse includendo informazioni valide e idonee InterestGroupBuyer per la risposta all'offerta avrà l'acquirente del gruppo di interesse corrispondente aggiunte alla cache, che saranno idonee future richieste in parallelo dallo stesso browser e dominio. Intenzione di partecipare ad aste basate su gruppi di interesse possono essere indicate nei seguenti campi:
- Protocollo Google RTB: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
Origini dell'acquirente memorizzate nella cache (incluse nel campo interestGroupBuyers) per cui un offerente non indica l'intenzione di partecipare alla sua risposta all'offerta può ricevere una chiamata al server affidabile dell'acquirente ma non partecipano all'asta parallela.