La misurazione dell'attribuzione delle conversioni può coinvolgere più parti, tra cui il publisher, l'inserzionista, la tecnologia pubblicitaria di pubblicazione (l'entità che pubblica l'annuncio), il fornitore di misurazione e altro ancora. In questo documento illustriamo scenari comuni di misurazione delle conversioni, ma in generale qualsiasi parte che desidera ricevere un report sull'attribuzione dall'API Attribution Reporting (ARA) deve assicurarsi che vengano seguiti i passaggi di integrazione descritti in questo documento.
Ad esempio, è comune che un publisher abbia una o più tecnologie pubblicitarie responsabili della pubblicazione dell'annuncio. Ciò potrebbe includere le parti responsabili della fornitura del markup per la creatività, le parti che forniscono l'impressione o il pixel di monitoraggio sulla creatività e le parti che forniscono l'SDK o il tag per l'area annuncio sulla pagina del publisher. Queste tecnologie pubblicitarie potrebbero o meno voler ricevere report sull'attribuzione da ARA, ma sono posizionate in modo da garantire che le tecnologie pubblicitarie downstream possano ricevere report sull'attribuzione.
Inoltre, l'inserzionista potrebbe utilizzare anche un fornitore di misurazione delle conversioni di terze parti per l'attribuzione cross-network, nonché altre funzionalità di generazione di report. Gli inserzionisti utilizzano questi dati per comprendere il ritorno sull'investimento pubblicitario in più publisher e canali unici, pertanto è importante che le DSP o gli ad server comprendano come attivare l'API Attribution Reporting per supportare questi casi d'uso. Gli inserzionisti che vogliono utilizzare una terza parte possono continuare a farlo, utilizzando un fornitore di servizi di misurazione di terze parti o configurando un server interno per registrare e ricevere report dall'API.
L'API Attribution Reporting consente a più tecnologie pubblicitarie di registrare origini e trigger di attribuzione per la stessa impressione o conversione e di ricevere report separati dall'API. Ad esempio, una DSP può ricevere i propri report sull'attribuzione dall'API Attribution Reporting e consentire report separati per il fornitore di misurazione di terze parti dell'inserzionista. Un ad tech deve registrare sia le origini attribuzione che i trigger per ricevere report dall'API e l'attribuzione viene eseguita tra le origini attribuzione e i trigger che l'ad tech ha registrato individualmente con l'API.
Scenari comuni di misurazione delle conversioni
In questa sezione esamineremo due scenari comuni per la misurazione delle conversioni.
Scenario 1: sia la tecnologia pubblicitaria di pubblicazione sia il fornitore di misurazione di terze parti devono ricevere report dall'API Attribution Reporting
Un inserzionista vuole attribuire le conversioni all'inventario pubblicitario utilizzando un fornitore di misurazione di terze parti e la tecnologia pubblicitaria che ospita la creatività vuole attribuire le conversioni all'inventario pubblicitario. Questo è comune per le DSP o gli ad server degli inserzionisti (ad server di terze parti, 3PAS) che forniscono il markup per le creatività pubblicitarie, eseguono i propri report sull'attribuzione e collaborano con gli inserzionisti che si integrano con fornitori di servizi di misurazione o analisi di terze parti.
In questo caso, la tecnologia pubblicitaria di pubblicazione è anche la parte responsabile dell'attivazione degli eventi di clic e impressione nella configurazione attuale. La tecnologia pubblicitaria di pubblicazione deve impostare il nuovo attributionsrc nelle posizioni appropriate e verificare che i reindirizzamenti siano configurati correttamente. Inoltre, sia la tecnologia pubblicitaria di pubblicazione che il fornitore di misurazione di terze parti devono verificare di essere registrati e che i loro server siano pronti a ricevere e rispondere alle richieste dell'API Attribution Reporting.
Una tipica configurazione della campagna potrebbe essere simile a questa:
L'ad server dell'inserzionista (3PAS) fornisce il markup per la creatività dell'annuncio alla DSP, che include i pixel di monitoraggio delle impressioni e dei clic del fornitore di misurazione di terze parti. L'ad server deve assicurarsi che
attributionsrcsia incluso nel markup della creatività dell'annuncio.La DSP offre funzionalità per aggiungere pixel di monitoraggio delle impressioni e dei clic aggiuntivi per la misurazione e deve assicurarsi che
attributionsrcsia incluso nel markup della creatività dell'annuncio finale per cui fa offerte.
Scenario 2: solo il fornitore di misurazione di terze parti deve ricevere report dall'API Attribution Reporting
Un inserzionista vuole attribuire le conversioni all'inventario pubblicitario utilizzando un fornitore di misurazione di terze parti, ma la tecnologia pubblicitaria che ospita la creatività non ha requisiti di misurazione dell'attribuzione. Questo è comune per i publisher, le SSP o gli ad server dei publisher che ospitano le creatività e non prevedono di utilizzare autonomamente i report sull'attribuzione, ma che vogliono attivare l'API Attribution Reporting per i propri partner DSP o per le società di tagging di misurazione, ad esempio ad server, fornitori di servizi di misurazione o analisi di terze parti.
In questo caso, la parte responsabile dell'attivazione degli eventi di clic e impressione nella configurazione attuale deve aggiungere il nuovo attributo attributionsrc alle creatività e verificare che i reindirizzamenti funzionino come previsto. Ciò dipende molto dall'integrazione di ogni publisher, ma per gli eventi di clic potrebbe trattarsi della SSP, della tecnologia pubblicitaria di pubblicazione o del publisher stesso. Per gli eventi impressione, si tratta più comunemente del fornitore di servizi di misurazione di terze parti.
Nel tipico esempio di configurazione della campagna dello scenario 1, l'ad server del publisher, la SSP o il publisher stesso potrebbero dover verificare solo che l'attributo attributionsrc fornito dal DSP venga visualizzato nella pagina del publisher.
Dettagli di implementazione
La seguente tabella descrive i passaggi di implementazione dell'API Attribution Reporting a livello generale:
| Passaggi | Responsabilità del lavoro | Esempi |
|---|---|---|
| Passaggio 1: attiva l'origine dell'attribuzione per le creatività e il codice di misurazione esistenti | L'entità responsabile dell'attivazione degli eventi di impressione o della gestione degli eventi di clic aggiunge l'attributo attributionsrc. |
Per gli eventi di clic, in genere l'attributo viene aggiunto da un acquirente (DSP/ad server dell'inserzionista) che esegue il rendering della creatività.
Per gli eventi impressione, l'attributo viene aggiunto da una Demand-Side Platform (DSP), una Supply-Side Platform (SSP), un publisher, un ad server o un fornitore di servizi di misurazione e dipende dalla configurazione del publisher. Per gli annunci video che utilizzano il formato VAST, l'editore e l'SDK video aggiungono l'attributo. |
| Passaggio 2: attiva i report sull'attribuzione per le origini di terze parti | Questa operazione funziona immediatamente se utilizzi un percorso di reindirizzamento esistente con reindirizzamenti 302. Se non è possibile utilizzare i reindirizzamenti 302, è possibile utilizzare l'attributo |
In genere, se l'attributo attributionsrc viene aggiunto alla creatività, i reindirizzamenti di terze parti dovrebbero ricevere le chiamate all'API Attribution Reporting. |
| Passaggio 3: configura le risposte per le richieste dell'API Attribution Reporting | Qualsiasi entità che vuole ricevere report dall'API Attribution Reporting | La DSP e il fornitore di misurazione di terze parti utilizzato dall'inserzionista |
Tieni presente che i dettagli di ogni passaggio dipendono dal modo in cui le creatività vengono sottoposte a rendering e pubblicate nella pagina del publisher e dalle entità di tecnologia pubblicitaria che ricevono i report inviati dall'API Attribution Reporting.
Passaggio 1: attiva l'origine dell'attribuzione per le creatività e il codice di misurazione esistenti
Nel primo passaggio vengono attivate le origini attribuzione.
Come funziona l'attributo attributionsrc
Il nuovo attributo attributionsrc specifica a quale posizione verranno inviate le richieste dell'API Attribution Reporting. L'entità responsabile dell'attivazione degli eventi di impressione e clic deve aggiornare le creatività con l'attributo attributionsrc. attributionsrc deve essere aggiunto agli eventi di clic e impressione esistenti e può essere vuoto o non vuoto.
Per gli eventi di clic che utilizzano reindirizzamenti, l'attributo attributionsrc deve essere aggiunto alla navigazione. I reindirizzamenti 302 successivi alla navigazione non devono aggiungere l'attributo attributionsrc e saranno idonei all'ARA a condizione che la navigazione iniziale abbia aggiunto attributionsrc.
Quando attributionsrc è vuoto, le richieste ARA vengono inviate all'URL definito nell'attributo href del tag di ancoraggio (URL di clickthrough). Quando l'attributo attributionsrc è definito, le richieste ARA vengono inviate all'URL definito nell'attributo attributionsrc. Anche l'URL di clickthrough è idoneo per la registrazione delle origini.
In genere, utilizza un attributo attributionsrc vuoto se il server che ospita l'URL di clickthrough può ricevere e rispondere alle richieste dell'API Attribution Reporting. Definisci il tuo URL attributionsrc se vuoi che le richieste dell'API Attribution Reporting vengano inviate a un server diverso.
Esempio di attributo attributionsrc vuoto:
| La tua configurazione esistente | Con l'integrazione ARA |
|---|---|
<a href="[CLICKTHROUGH_URL]">...</a>
|
<a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>
|
Quando l'attributo attributionsrc è vuoto, le richieste dell'API Attribution Reporting verranno inviate all'URL definito dall'attributo href del tag di ancoraggio.
Esempio di attributo attributionsrc non vuoto:
| La tua configurazione esistente | Con l'integrazione ARA |
|---|---|
<a href="[CLICKTHROUGH_URL]">...</a>
|
<a href="[CLICKTHROUGH_URL]" attributionsrc="[ATTRIBUTION_SRC_URL]">...</a>
|
Quando attributionsrc non è vuoto, le richieste dell'API Attribution Reporting verranno inviate all'URL definito dal tag attributionsrc. Anche l'URL di clickthrough è idoneo per la registrazione delle origini.
Aggiungi attributionsrc per gli eventi di clic e impressione
- Eventi di clic:
- L'entità responsabile dell'aggiunta di
attributionsrcè in genere la tecnologia pubblicitaria di pubblicazione. - I tag di ancoraggio con eventi di clic devono avere un attributo
attributionsrcaggiunto. - I clic che utilizzano
window.opendevono utilizzare l'argomentowindowFeaturesdella chiamatawindow.openper specificare l'origine attribuzione.
- L'entità responsabile dell'aggiunta di
- Eventi di impressione:
- L'entità responsabile dell'aggiunta di
attributionsrcè in genere la tecnologia pubblicitaria di pubblicazione e i fornitori di misurazione. - Gli eventi impressione attivati dal tag
<img>o dal tag<script>devono includere un attributoattributionsrc. - Gli eventi impressione che utilizzano l'API Fetch devono includere un oggetto
attributionReportingnell'argomento options passato alla chiamata API Fetch.
- L'entità responsabile dell'aggiunta di
Consulta la tabella seguente per il riepilogo delle modifiche necessarie per gli eventi di clic e impressione:
| Evento | Tag | La tua configurazione esistente | Dopo l'integrazione di ARA |
|---|---|---|---|
| Clic | HTML |
<a href="[CLICKTHROUGH_URL]">...</a>
|
<a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>
|
| JavaScript | window.open("[CLICKTHROUGH_URL]", "_blank"); |
window.open("[CLICKTHROUGH_URL]", "_blank", "attributionsrc"); |
|
| Impressione | Tag HTML <img> |
<img src="[IMPRESSION_URL]">
|
<img src="[IMPRESSION_URL]" attributionsrc>
|
Tag HTML <script> |
<script src="[IMPRESSION_URL]"></script>
|
<script src="[IMPRESSION_URL]" attributionsrc></script>
|
|
| JavaScript |
const options = {...} |
const options = { |
Abilitare la registrazione dell'origine dell'attribuzione in un'asta Protected Audience
Per misurare le conversioni in un'asta Protected Audience, anziché utilizzare attributionsrc, puoi utilizzare registerAdBeacon/registerAdMacro e setReportEventDataForAutomaticBeacons/reportEvent per consentire la registrazione delle origini dell'attribuzione.
Per la generazione di report sugli indicatori Protected Audience, la funzione registerAdBeacon è disponibile all'interno dei worklet di reporting, mentre registerAdMacro è disponibile all'interno del worklet di reporting delle vittorie dell'acquirente. Successivamente, i dati sugli eventi all'interno del frame dell'annuncio possono essere aggiunti ai beacon e alle macro registrati con le funzioni reportEvent e setReportEventDataForAutomaticBeacons dell'API Fenced Frame Ads Reporting. In questo modo, gli indicatori dei worklet di reporting Protected Audience e il payload dell'evento del frame della creatività pubblicitaria possono essere associati tra loro.
L'intestazione HTTP Attribution-Reporting-Eligible viene aggiunta alla richiesta quando i beacon e le macro vengono attivati dalla chiamata reportEvent da un frame oppure quando i beacon automatici vengono attivati dal browser. Puoi utilizzare la risposta del beacon per registrare un'origine attribuzione. Le richieste di beacon potrebbero essere reindirizzate per consentire la misurazione di terze parti.
Per approfondire l'argomento, consulta la sezione Supporto di Attribution Reporting della spiegazione dell'API Fenced Frame Ad Reporting.
Attivare i report sull'attribuzione per i formati VAST
VAST è un formato comune per la pubblicazione e la misurazione dell'inventario di annunci video e molti degli eventi definiti in questo standard devono essere considerati potenziali eventi di origine idonei alla registrazione con l'API Attribution Reporting. L'appendice VAST per il supporto del reporting sull'attribuzione tratta questo argomento in dettaglio, ma in breve, tutti gli eventi <Tracking>, <Impression>, <*ClickThrough> e <*ClickTracking> sono potenziali eventi di origine dell'attribuzione. Tutte le implementazioni VAST devono fornire la copertura dell'idoneità alla registrazione per questi eventi.
L'addendum VAST definisce nuovi attributi per questi elementi per consentire l'impostazione di un URL secondario specificamente per la registrazione dell'attribuzione. Quando un evento contiene attributiontype="DOUBLE_PING" e attributionsrc="[URL]", il codice che attiva l'evento deve utilizzare [URL] come valore dell'attributo attributionsrc quando si abilita l'API Attribution Reporting. L'addendum VAST contiene esempi per ogni scenario.
Per la massima copertura, le implementazioni VAST devono, per impostazione predefinita, rendere idonei alla registrazione tutti gli eventi elencati quando vengono attivati i ping degli eventi. Ad esempio, quando viene attivato un URL evento <Impression>, l'attributo attributionsrc (vuoto) deve essere utilizzato nell'elemento <img> utilizzato per inviare la richiesta (o l'equivalente nella chiamata fetch), per consentire sempre alla parte ricevente di registrare potenzialmente l'evento con l'API Attribution Reporting.
Passaggio 2: attiva i report sull'attribuzione per le origini di terze parti
Per consentire a terze parti di utilizzare l'API Attribution Reporting, puoi utilizzare i reindirizzamenti esistenti o aggiungere un elenco di terze parti all'attributo attributionsrc. Nella maggior parte dei casi, ogni tecnologia pubblicitaria ha il proprio tracker delle impressioni indipendente, quindi i reindirizzamenti sono più pertinenti per i tracker dei clic.
Gestire le origini di terze parti in una catena di reindirizzamento esistente
In un tipico clickthrough dell'annuncio, possono essere presenti molti tracker dei clic come catena di reindirizzamenti 302 eseguiti nell'ambito della navigazione alla pagina di destinazione finale. Ogni richiesta nella catena di reindirizzamento è idonea alla registrazione con l'API Attribution Reporting se la destinazione del clic originale è stata annotata con attributionsrc o registrata con registerAdBeacon/registerAdMacro nell'API Protected Audience. Anche la tecnologia pubblicitaria nella catena di reindirizzamento deve essere registrata.
Tieni presente che il corpo della richiesta iniziale non viene inviato durante i reindirizzamenti. Per le aste Protected Audience, se eventData viene passato a reportEvent e setReportEventDataForAutomaticBeacons deve essere utilizzato nell'ambito del reindirizzamento, deve essere passato esplicitamente come parte dell'URL di reindirizzamento.
Nell'esempio seguente, utilizzeremo una tecnologia pubblicitaria di pubblicazione (serving-adtech.example) e un fornitore di misurazione di terze parti (3p-measurement.example) come due entità distinte che vogliono generare e ricevere report sull'attribuzione. La tecnologia pubblicitaria di pubblicazione in questo esempio può essere una DSP che esegue il rendering della creatività sul sito del publisher e dispone di un proprio prodotto di reporting. Il fornitore di misurazione di terze parti può essere un'entità utilizzata dall'inserzionista per i report sulle conversioni.
Al momento della registrazione dell'origine, vengono eseguiti i seguenti passaggi:
serving-adtech.exampleimposta l'attributoattributionsrcnella creatività.L'utente visita la pagina del publisher e il browser invia una richiesta aserving-adtech.example.serving-adtech.examplerisponde con l'intestazioneAttribution-Reporting-Register-Sourcee l'intestazioneLocation.serving-adtech.exampleutilizza l'intestazioneAttribution-Reporting-Register-Sourceper rispondere con i metadati relativi all'origine da registrare.serving-adtech.exampleutilizza l'intestazioneLocationper includere un reindirizzamento a3p-measurement.example. Tieni presente che è probabile che l'intestazioneLocationvenga già utilizzata nei flussi di monitoraggio dei clic esistenti per supportare i reindirizzamenti302a terze parti.
- Il browser riceve la risposta da
serving-adtech.examplee analizza l'intestazioneAttribution-Reporting-Register-Source. Il browser memorizza l'evento di origine utilizzandoserving-adtech.examplecome origine dei report. - Poiché questa richiesta è un reindirizzamento, il browser effettua anche una nuova richiesta a
3p-measurement.example. 3p-measurement.examplerisponde con una risposta che contiene l'intestazioneAttribution-Reporting-Register-Source.- Il browser riceve questa risposta da
3p-measurement.examplee leggeAttribution-Reporting-Register-Source. Il browser memorizza l'evento di origine utilizzando3p-measurement.examplecome origine dei report.
Utilizza attributionsrc per le origini di terze parti non presenti in una catena di reindirizzamento
Se più origini reporter vogliono registrare una sorgente in un evento di navigazione, ma non possono essere visualizzate in una catena di reindirizzamento per qualsiasi motivo, puoi elencare più siti come origini dell'attribuzione in attributionsrc come soluzione alternativa.
| La tua configurazione esistente | Con la modifica dell'ARA |
|---|---|
<a href="[CLICKTHROUGH_URL]">...</a>
|
<a href="[CLICKTHROUGH_URL]" attributionsrc="[REPORTING_URL_1] [REPORTING_URL_2]">...</a>
|
In questo esempio, le richieste idonee all'API Attribution Reporting verranno inviate sia a REPORTING_URL_1 che a REPORTING_URL_2. Anche la richiesta di navigazione inviata all'URL di clickthrough è idonea per registrare le origini dell'attribuzione.
Passaggio 3: configura le risposte per le richieste dell'API Attribution Reporting
Per tutte le origini che ricevono una richiesta dell'API Attribution Reporting, verifica che il server risponda con l'intestazione Attribution-Reporting-Register-Source appropriata. Consulta la guida Registra origini e la spiegazione per scoprire come deve essere strutturata la risposta.
Registrare più trigger
Puoi registrare più attivatori dell'attribuzione aggiungendo più elementi pixel sul lato della conversione (uno per attivatore). L'elemento attributionsrc è facoltativo per la registrazione dell'attivazione.
Puoi anche registrare più attivatori da un singolo elemento pixel utilizzando richieste di reindirizzamento o elencando più URL nell'elemento attributionsrc nello stesso modo della registrazione dell'origine. Gli eventi di origine e gli eventi trigger generati dalle stesse origini verranno abbinati.