Panoramica dei report sull'attribuzione per il mobile

Nota: questo documento riflette le attuali proposte di progettazione di Privacy Sandbox su Android ed è soggetto a ulteriori modifiche. Ti invitiamo a inviare i tuoi feedback e commenti per aiutarci a migliorare.

Aggiornamenti recenti

• Aggiornamento dell'elenco delle modifiche imminenti e dei problemi noti

• È stata introdotta la configurazione a livello di evento flessibile lite, come passaggio intermedio alla configurazione a livello di evento flessibile completa

• A partire da settembre 2023, registerWebSource, registerWebTrigger, registerAppSource e registerAppTrigger devono utilizzare stringhe per i campi che prevedono un valore numerico (ad esempio priority, source_event_id, debug_key, trigger_data, deduplication_key e così via).

• Nel quarto trimestre del 2023 verrà aggiunto il supporto di Google Cloud nell'API Android Attribution Reporting per generare report di riepilogo utilizzando il servizio di aggregazione su Google Cloud. Qui sono riportate le tempistiche più specifiche. Per ulteriori informazioni sulla configurazione di Aggregation Service con Google Cloud, consulta la guida all'implementazione.

• Nuovi limiti di frequenza per la tutela della privacy per il numero di destinazioni univoche.

• La funzionalità aggiornata per i filtri degli trigger della finestra temporale sarà disponibile nel primo trimestre del 2024. Per ulteriori informazioni, consulta la nota.

Panoramica

Attualmente, le soluzioni di attribuzione e misurazione mobile usano comunemente identificatori trasversali come l'ID pubblicità. L'API Attribution Reporting è progettata per migliorare la privacy degli utenti eliminando il ricorso a identificatori di utenti trasversali, nonché per supportare casi d'uso chiave per l'attribuzione e la misurazione delle conversioni su app e sul web.

Questa API dispone dei seguenti meccanismi strutturali che offrono un framework per migliorare la privacy, descritti in modo più dettagliato nelle sezioni successive di questa pagina:

• Limita il numero di bit disponibili per i report a livello di evento

• Attiva i dati sulle conversioni con una maggiore fedeltà solo nei report aggregabili

• Vengono introdotti limiti di frequenza per gli attivatori disponibili (conversioni) e il numero di tecnologie pubblicitarie che possono essere associate a una singola origine di attribuzione

• Incorpora varie tecniche di aggiunta di rumore

I meccanismi precedenti limitano la possibilità di collegare l'identità utente a due app o domini diversi.

L'API Attribution Reporting supporta i seguenti casi d'uso:

• Report sulle conversioni: aiuta gli inserzionisti a misurare il rendimento delle loro campagne mostrando loro i conteggi e i valori delle conversioni (attivatori) in varie dimensioni, ad esempio per campagna, gruppo di annunci e creatività dell'annuncio.
• Ottimizzazione:fornisci report a livello di evento che supportano l'ottimizzazione della spesa pubblicitaria, fornendo dati di attribuzione per impressione che possono essere utilizzati per addestrare i modelli di ML.
• Rilevamento di attività non valide: fornisci report che possono essere utilizzati per il rilevamento e l'analisi del traffico non valido e della frode pubblicitaria.

A livello generale, l'API Attribution Reporting funziona nel seguente modo, come descritto in modo più dettagliato nelle sezioni successive di questo documento:

1. La tecnologia pubblicitaria completa una procedura di registrazione per utilizzare l'API Attribution Reporting.
2. L'ad tech registra le sorgenti di attribuzione, ovvero i clic o le visualizzazioni degli annunci, con l'API Attribution Reporting.
3. L'ad tech registra gli attivatori, ovvero le conversioni degli utenti sull'app o sul sito web dell'inserzionista, con l'API Attribution Reporting.
4. L'API Attribution Reporting associa gli attivatori alle sorgenti di attribuzione, ovvero a un'attribuzione delle conversioni, e uno o più attivatori vengono inviati al di fuori del dispositivo tramite report a livello di evento e aggregabili alle ad tech.

Nota: per ulteriori informazioni su come implementare questo design per un caso d'uso di attribuzione app-to-app, consulta la sezione sull'attribuzione cross-network della Guida per gli sviluppatori dell'API Attribution Reporting. Per scoprire come implementare un caso d'uso da app a web o da web ad app, consulta la proposta di progettazione della misurazione tra app e web.

Accedere alle API Attribution Reporting

Le piattaforme di tecnologia pubblicitaria devono registrarsi per accedere alle API Attribution Reporting. Per saperne di più, consulta Registrarsi per un account Privacy Sandbox.

Registra un'origine attribuzione (clic o visualizzazione)

L'API Attribution Reporting si riferisce ai clic e alle visualizzazioni degli annunci come origini dell'attribuzione. Per registrare un clic o una visualizzazione dell'annuncio, chiama registerSource(). Questa API prevede i seguenti parametri:

• URI dell'origine dell'attribuzione: la piattaforma invia una richiesta a questo URI per recuperare i metadati associati all'origine dell'attribuzione.
• Evento di input:un oggetto InputEvent (per un evento di clic) o null (per un evento di visualizzazione).

Quando l'API invia una richiesta all'URI dell'origine attribuzione, la tecnologia pubblicitaria deve rispondere con i metadati dell'origine attribuzione in un nuovo intestazione HTTPAttribution-Reporting-Register-Source, con i seguenti campi:

• ID evento di origine: questo valore rappresenta i dati a livello di evento associati a questa origine di attribuzione (clic o visualizzazione dell'annuncio). Deve essere un numero intero senza segno a 64 bit formato come stringa.
• Destinazione: un'origine il cui nome del pacchetto dell'app o del dominio di primo livello esteso avviene l'evento di attivazione.
• Scadenza (facoltativa): la scadenza, in secondi, per l'eliminazione della fonte dal dispositivo. Il valore predefinito è 30 giorni, con un valore minimo di 1 giorno e un valore massimo di 30 giorni. Il valore viene arrotondato al giorno più vicino. Può essere formattato come stringa o come numero intero non firmato a 64 bit.
• Finestra del report sugli eventi (facoltativa): durata in secondi dopo la registrazione dell'origine durante la quale è possibile creare report sugli eventi per questa origine. Se la finestra di generazione del report sugli eventi è terminata, ma la scadenza non è ancora trascorsa, un attivatore può comunque essere associato a una sorgente, ma non viene inviato un report sugli eventi per quell'attivatore. Non può essere maggiore di Scadenza. Può essere formattato come stringa o come numero intero non firmato a 64 bit.
• Finestra dei report aggregabili (facoltativa): durata in secondi dopo la registrazione della fonte durante la quale è possibile creare report aggregabili per questa fonte. Non può essere maggiore di Scadenza. Può essere formattato come stringa o come numero intero senza segno a 64 bit.
• Priorità dell'origine (facoltativa): utilizzata per selezionare l'origine di attribuzione a cui deve essere associato un determinato attivatore, nel caso in cui siano disponibili più origini di attribuzione. Deve essere un numero intero a 64 bit con segno formato come stringa.
  
  Quando viene ricevuto un attivatore, l'API individua l'origine di attribuzione corrispondente con il valore di priorità dell'origine più elevato e genera un report. Ogni piattaforma di tecnologia pubblicitaria può definire la propria strategia di assegnazione della priorità. Per maggiori dettagli su come la priorità influisce sull'attribuzione, consulta la sezione Esempio di definizione della priorità.
  
  I valori più elevati indicano priorità più elevate.
• Finestre di attribuzione di installazione e post-installazione (facoltative): utilizzate per determinare l'attribuzione per gli eventi post-installazione, descritti più avanti in questa pagina.
• Filtra dati (facoltativo): utilizzato per filtrare in modo selettivo alcuni attivatori, ignorandoli di fatto. Per ulteriori dettagli, consulta la sezione Filtri di attivazione in questa pagina.
• Chiavi di aggregazione (facoltative): specifica la segmentazione da utilizzare per i report aggregabili.

Se vuoi, la risposta dei metadati dell'origine dell'attribuzione può includere dati aggiuntivi nell'intestazione Reindirizzamenti dei report sull'attribuzione. I dati contengono URL di reindirizzamento che consentono a più tecnologie pubblicitarie di registrare una richiesta.

La guida per gli sviluppatori include esempi che mostrano come accettare la registrazione delle origini.

I passaggi riportati di seguito mostrano un esempio di flusso di lavoro:

1. L'SDK ad tech chiama l'API per avviare la registrazione dell'origine attribuzione, specificando un URI da chiamare per l'API:

   registerSource(
       Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
       myClickEvent);
   

2. L'API invia una richiesta a https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA, utilizzando una delle seguenti intestazioni:

   <!-- For click events -->
   Attribution-Reporting-Source-Info: navigation
   
   <!-- For view events -->
   Attribution-Reporting-Source-Info: event
   

3. Il server HTTPS di questa tecnologia pubblicitaria risponde con intestazioni contenenti quanto segue:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "234",
       "expiry": "60000",
       "priority": "5"
   }
   Attribution-Reporting-Redirect:
   https://adtechpartner1.example?their_ad_click_id=567
   Attribution-Reporting-Redirect:
   https://adtechpartner2.example?their_ad_click_id=890
   

4. L'API invia una richiesta a ogni URL specificato in Attribution-Reporting-Redirect. In questo esempio, sono specificati due URL di partner di tecnologia pubblicitaria, pertanto l'API invia una richiesta a https://adtechpartner1.example?their_ad_click_id=567 e un'altra a https://adtechpartner2.example?their_ad_click_id=890.

5. Il server HTTPS di questa tecnologia pubblicitaria risponde con intestazioni contenenti quanto segue:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "789",
       "expiry": "120000",
       "priority": "2"
   }
   

   Nota: le risposte degli esperti di tecnologia pubblicitaria possono specificare metadati diversi nell'Attribution-Reporting-Register-Source.

Tre sorgenti di attribuzione di navigazione (clic) vengono registrate in base alle richieste mostrate nei passaggi precedenti.

Registra un'origine di attribuzione da WebView

WebView supporta il caso d'uso in cui un'app esegue il rendering di un annuncio all'interno di un WebView. Questo viene gestito da WebView che chiama direttamente registerSource() come richiesta in background. Questa chiamata associa l'origine dell'attribuzione all'app instead of all'origine di primo livello. È supportata anche la registrazione delle origini dai contenuti web incorporati in un contesto del browser. Per farlo, sia gli utenti che chiamano l'API sia le app devono modificare le impostazioni. Consulta Registrare l'origine e l'attivatore dell'attribuzione da WebView per le istruzioni relative agli utenti che chiamano l'API e Registrazione dell'origine e dell'attivatore dell'attribuzione da WebView per le istruzioni relative alle app.

Poiché le tecnologie pubblicitarie utilizzano un codice comune su web e WebView, WebView segue i reindirizzamenti HTTP 302 e trasmette le registrazioni valide alla piattaforma. Non prevediamo di supportare l'intestazione Attribution-Reporting-Redirect per questo scenario, ma contattaci se hai un caso d'uso interessato.

Nota: per consentire a WebView di utilizzare l'API Attribution Reporting, l'app di incorporamento deve essere configurata con le autorizzazioni corrette.

Registra un trigger (conversione)

Le piattaforme di tecnologia pubblicitaria possono registrare gli attivatori, ovvero le conversioni come le installazioni o gli eventi post-installazione, utilizzando il metodo registerTrigger().

Il metodo registerTrigger() prevede il parametro URI attivatore. L'API invia una richiesta a questo URI per recuperare i metadati associati all'attivatore.

L'API segue i reindirizzamenti. La risposta del server ad tech deve includere un'intestazione HTTP chiamata Attribution-Reporting-Register-Trigger, che rappresenta informazioni su uno o più attivatori registrati. Il contenuto dell'intestazione deve essere codificato in JSON e includere i seguenti campi:

• Dati di attivazione: dati per identificare l'evento di attivazione (3 bit per i clic, 1 bit per le visualizzazioni). Deve essere un numero intero a 64 bit con segno formattato come stringa.

• Priorità dell'attivatore (facoltativa): rappresenta la priorità di questo attivatore rispetto ad altri attivatori per la stessa origine attribuzione. Deve essere un numero intero con segno a 64 bit formattato come stringa. Per ulteriori dettagli su come la priorità influisce sui report, consulta la sezione Priorità.

• Chiave di deduplica (facoltativa): utilizzata per identificare i casi in cui lo stesso attivatore viene registrato più volte dalla stessa piattaforma ad tech per la stessa origine attribuzione. Deve essere un numero intero a 64 bit con segno formato come stringa.

• Chiavi di aggregazione (facoltative): un elenco di dizionari che specifica le chiavi di aggregazione e i report aggregabili di cui deve essere aggregato il valore.

• Valori di aggregazione (facoltativo): un elenco di importi di valore che contribuiscono a ogni chiave.

• Filtri (facoltativo): utilizzati per filtrare in modo selettivo gli attivatori o i dati degli attivatori. Per ulteriori dettagli, consulta la sezione Filtri di attivazione in questa pagina.

Se vuoi, la risposta del server ad tech può includere dati aggiuntivi nell'intestazione Attribution Reporting Redirects. I dati contengono URL di reindirizzamento che consentono a più tecnologie pubblicitarie di registrare una richiesta.

Più tecnologie pubblicitarie possono registrare lo stesso evento di attivazione utilizzando i reindirizzamenti nel Attribution-Reporting-Redirect campo o più chiamate al registerTrigger() metodo. Ti consigliamo di utilizzare il campo chiave di deduplica per evitare di includere attivatori duplicati nei report nel caso in cui la stessa tecnologia pubblicitaria fornisca più risposte per lo stesso evento di attivazione. Scopri di più su come e quando utilizzare una chiave di deduplicazione.

La Guida per gli sviluppatori include esempi che mostrano come accettare la registrazione degli attivatori.

I passaggi riportati di seguito mostrano un esempio di flusso di lavoro:

1. L'SDK ad tech chiama l'API per avviare la registrazione dell'attivatore utilizzando un URI preregistrato. Per saperne di più, consulta Registrarsi per un account Privacy Sandbox.

   registerTrigger(
       Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
   

2. L'API invia una richiesta a https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA.

3. Il server HTTPS di questa tecnologia pubblicitaria risponde con intestazioni contenenti quanto segue:

   Attribution-Reporting-Register-Trigger: {
       "event_trigger_data": [{
       "trigger_data": "1122",
       // This returns 010 for click-through conversions (CTCs) and 0 for
       // view-through conversions (VTCs) in reports
       "priority": "3",
       "deduplication_key": "3344"
       }],
   }
   Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567
   

   Nota: solo la tecnologia pubblicitaria che avvia la chiamata API può specificare i partner in Attribution-Reporting-Redirect.

4. L'API invia una richiesta a ogni URL specificato in Attribution-Reporting-Redirect. In questo esempio viene specificato un solo URL, pertanto l'API invia una richiesta a https://adtechpartner.example?app_install=567.

5. Il server HTTPS di questa tecnologia pubblicitaria risponde con intestazioni contenenti quanto segue:

   Attribution-Reporting-Register-Trigger: {
   "event_trigger_data":[{
     "trigger_data": "5566",
     "priority": "3",
     "deduplication_key": "3344"
   }]
   }
   

   Vengono registrati due trigger in base alle richieste nei passaggi precedenti.

Funzionalità di attribuzione

Le sezioni seguenti spiegano come l'API Attribution Reporting associa gli attivatori delle conversioni alle origini di attribuzione.

Algoritmo di attribuzione con priorità alla sorgente applicato

L'API Attribution Reporting utilizza un algoritmo di attribuzione con priorità per l'origine per abbinare un attivatore (conversione) a un'origine attribuzione.

I parametri di priorità consentono di personalizzare l'attribuzione degli attivatori alle fonti:

• Puoi attribuire gli attivatori ad alcuni eventi correlati agli annunci rispetto ad altri. Ad esempio, puoi scegliere di dare maggiore enfasi ai clic anziché alle visualizzazioni o concentrarti sugli eventi di determinate campagne.
• Puoi configurare l'origine e l'attivatore dell'attribuzione in modo che, se raggiungi i limiti di frequenza, sia più probabile che tu riceva i report più importanti per te. Ad esempio, potresti voler assicurarti che le conversioni disponibili per l'offerta o quelle di alto valore abbiano maggiori probabilità di essere visualizzate in questi report.

Nel caso in cui più ad tech registrino un'origine attribuzione, come descritto più avanti in questa pagina, questa attribuzione avviene in modo indipendente per ogni ad tech. Per ogni ad tech, l'origine attribuzione con la priorità più alta viene attribuita all'evento di attivazione. Se sono presenti più origini di attribuzione con la stessa priorità, l'API sceglie l'ultima origine di attribuzione registrata. Eventuali altre origini di attribuzione non selezionate vengono ignorate e non sono più idonee per l'attribuzione degli attivatori futuri.

Filtri attivatore

La registrazione di origini e attivatori include funzionalità facoltative aggiuntive per:

• Filtra in modo selettivo alcuni attivatori, ignorandoli di fatto.
• Scegli i dati di attivazione per i report a livello di evento in base ai dati di origine.
• Scegli di escludere un trigger dai report a livello di evento.

Per filtrare in modo selettivo gli attivatori, la tecnologia pubblicitaria può specificare i dati del filtro, costituiti da chiavi e valori, durante la registrazione delle origini e degli attivatori. Se viene specificata la stessa chiave sia per l'origine sia per l'attivatore, quest'ultimo viene ignorato se l'intersezione è vuota. Ad esempio, una sorgente può specificare "product": ["1234"], dove product è la chiave del filtro e 1234 è il valore. Se il filtro attivatore è impostato su "product": ["1111"], l'attivatore viene ignorato. Se non esiste una chiave del filtro di attivazione corrispondente a product, i filtri vengono ignorati.

Un altro scenario in cui le piattaforme di ad tech potrebbero voler filtrare selettivamente gli attivatori è per forzare una finestra di scadenza più breve. Al momento della registrazione dell'attivatore, una tecnologia pubblicitaria può specificare (in secondi) una finestra temporale a partire dalla data e dall'ora in cui si è verificata la conversione. Ad esempio, una finestra temporale di 7 giorni viene definita come: "_lookback_window": 604800 // 7d

Per decidere se un filtro corrisponde, l'API controlla prima la finestra temporale. Se disponibile, la durata dalla registrazione dell'origine deve essere inferiore o uguale alla durata dell'intervallo di ricerca.

Nota: la logica e la funzionalità del filtro temporale descritti entreranno in vigore nel primo trimestre del 2024. Puoi trovare dettagli più specifici sulle tempistiche di rilascio. La logica precedente richiedeva di specificare le finestre temporali in base all'ora sia per l'origine sia per l'attivatore. Questa logica della funzionalità aggiornata non è compatibile con le versioni precedenti, il che significa che le origini che utilizzano la chiave "_lookback_window" precedente non verranno registrate correttamente.

Le piattaforme di tecnologia pubblicitaria possono anche scegliere i dati di attivazione in base ai dati sugli eventi di origine. Ad esempio, source_type viene generato automaticamente dall'API come navigation o event. Durante la registrazione dell'attivatore, trigger_data può essere impostato come un valore per "source_type": ["navigation"] e un altro per "source_type": ["event"].

Gli attivatori vengono esclusi dai report a livello di evento se una delle seguenti condizioni è vera:

• Non è stato specificato alcun trigger_data.
• L'origine e l'attivatore specificano la stessa chiave di filtro, ma i valori non corrispondono. Tieni presente che, in questo caso, l'attivatore viene ignorato sia per i report a livello di evento sia per quelli aggregabili.

Attribuzione post-installazione

In alcuni casi, è necessario che gli attivatori post-installazione vengano attribuiti alla stessa sorgente di attribuzione che ha generato l'installazione, anche se sono presenti altre sorgenti di attribuzione idonee che si sono verificate di recente.

L'API può supportare questo caso d'uso consentendo agli esperti di tecnologia pubblicitaria di impostare un periodo di attribuzione post-installazione:

• Quando registri un'origine di attribuzione, specifica un periodo di attribuzione delle installazioni durante il quale si prevedono le installazioni (in genere 2-7 giorni, intervallo accettato da 1 a 30 giorni). Specifica questa finestra temporale come numero di secondi.
• Quando registri un'origine attribuzione, specifica una finestra di esclusività dell'attribuzione post-installazione in cui tutti gli eventi di attivazione post-installazione devono essere associati all'origine attribuzione che ha generato l'installazione (in genere 7-30 giorni, intervallo accettato da 0 a 30 giorni). Specifica questa finestra temporale come numero di secondi.
• L'API Attribution Reporting convalida quando viene eseguita un'installazione di app e attribuisce internamente l'installazione alla sorgente di attribuzione con priorità per sorgente. Tuttavia, l'installazione non viene inviata alle ad tech e non viene conteggiata ai fini dei rispettivi limiti di frequenza delle piattaforme.
• La convalida dell'installazione dell'app è disponibile per qualsiasi app scaricata.
• Eventuali attivatori futuri che si verificano all'interno della finestra di attribuzione post-installazione vengono attribuiti alla stessa sorgente di attribuzione dell'installazione convalidata, a condizione che la sorgente di attribuzione sia idonea.

In futuro, potremmo valutare la possibilità di estendere il design per supportare modelli di attribuzione più avanzati.

La tabella seguente mostra un esempio di come le tecnologie pubblicitarie possono utilizzare l'attribuzione post-installazione. Supponiamo che tutte le origini e gli attivatori di attribuzione vengano registrati dalla stessa rete ad tech e che tutte le priorità siano uguali.

Evento	Giorno in cui si verifica l'evento	Note
Fai clic 1	1	install_attribution_window è impostato su 172800 (2 giorni) e post_install_exclusivity_window è impostato su 864000 (10 giorni)
Installazione verificata	2	L'API attribuisce internamente le installazioni verificate, ma queste installazioni non sono considerate attivatori. Pertanto, al momento non vengono inviati report.
Trigger 1 (prima apertura)	2	Primo attivatore registrato dall'ad tech. In questo esempio, rappresenta una prima apertura, ma può essere qualsiasi tipo di attivatore. Attribuito al clic 1 (corrisponde all'attribuzione dell'installazione verificata).
Fai clic 2	4	Utilizza gli stessi valori per install_attribution_window e post_install_exclusivity_window come per il clic 1
Trigger 2 (post-installazione)	5	Secondo trigger registrato dall'ad tech. In questo esempio, rappresenta una conversione post-installazione, ad esempio un acquisto. Attribuito al clic 1 (corrisponde all'attribuzione dell'installazione verificata). L'attributo del clic 2 viene ignorato e non è idoneo per l'attribuzione futura.

Di seguito sono riportate alcune note aggiuntive sull'attribuzione post-installazione:

• Se l'installazione verificata non avviene entro il numero di giorni specificato da install_attribution_window, l'attribuzione post-installazione non viene applicata.
• Le installazioni verificate non vengono registrate dalle tecnologie pubblicitarie e non vengono inviate nei report. Non vengono conteggiati ai fini dei limiti di frequenza di una tecnologia pubblicitaria. Le installazioni verificate vengono utilizzate solo per identificare l'origine di attribuzione a cui viene accreditata l'installazione.
• Nell'esempio della tabella precedente, l'attivatore 1 e l'attivatore 2 rappresentano rispettivamente una prima apertura e una conversione post-installazione. Tuttavia, le piattaforme di ad tech possono registrare qualsiasi tipo di attivatore. In altre parole, il primo trigger non deve essere un trigger di prima apertura.
• Se vengono registrati altri attivatori dopo la scadenza di post_install_exclusivity_window, il primo clic è ancora idoneo per l'attribuzione, a condizione che non sia scaduto e non abbia raggiunto i limiti di frequenza.
  • Il primo clic potrebbe comunque essere perso o ignorato se è registrata un'origine di attribuzione di priorità più elevata.
• Se l'app dell'inserzionista viene disinstallata e reinstallata, la reinstallazione viene conteggiata come nuova installazione verificata.
• Se il clic 1 era invece un evento di visualizzazione, gli attivatori di "prima apertura" e post-installazione vengono comunque attribuiti. L'API limita l'attribuzione a un trigger per visualizzazione, tranne nel caso dell'attribuzione post-installazione, in cui sono consentiti fino a due trigger per visualizzazione. Nel caso dell'attribuzione post-installazione, la tecnologia pubblicitaria potrebbe ricevere due diverse finestre di generazione di report (a 2 giorni o alla scadenza della fonte).

Sono supportate tutte le combinazioni di percorsi di trigger basati su app e web

L'API Attribution Reporting consente l'attribuzione dei seguenti percorsi di trigger su un singolo dispositivo Android:

• App-to-app: l'utente vede un annuncio in un'app e poi effettua una conversione in quell'app o in un'altra app installata.
• App-to-web: l'utente visualizza un annuncio in un'app e poi effettua una conversione in un browser mobile o per app.
• Web-to-app: l'utente visualizza un annuncio in un browser mobile o per app, poi effettua una conversione in un'app.
• Web-to-web: l'utente visualizza un annuncio in un browser mobile o per app, poi effettua una conversione nello stesso browser o in un altro browser sullo stesso dispositivo.

Consentiamo ai browser web di supportare nuove funzionalità esposte sul web, ad esempio funzionalità simili all'API Attribution Reporting di Privacy Sandbox per il web, che può chiamare le API Android per abilitare l'attribuzione su app e web.

Scopri le modifiche che le app e le tecnologie pubblicitarie devono apportare per supportare i percorsi di attivazione per la misurazione cross-app e web.

Assegnare la priorità a più attivatori per una singola sorgente di attribuzione

Una singola origine attribuzione può generare più attivatori. Ad esempio, un flusso di acquisto potrebbe includere un attivatore "installazione app", uno o più attivatori "aggiunta al carrello" e un attivatore "acquisto". Ogni attivatore viene attribuito a una o più fonti di attribuzione in base all'algoritmo di attribuzione con priorità alla fonte, descritto più avanti in questa pagina.

Esistono limiti al numero di attivatori che possono essere attribuiti a una singola fonte di attribuzione. Per maggiori dettagli, leggi la sezione sulla visualizzazione dei dati di misurazione nei report sull'attribuzione più avanti in questa pagina.

Se sono presenti più attivatori oltre questi limiti, è utile introdurre una logica di assegnazione della priorità per recuperare gli attivatori più importanti. Ad esempio, gli sviluppatori di una tecnologia pubblicitaria potrebbero dare la priorità agli attivatori "acquisto" rispetto agli attivatori "aggiungi al carrello".

Per supportare questa logica, è possibile impostare un campo di priorità separato sull'attivatore e scegliere gli attivatori con la priorità più alta prima dell'applicazione dei limiti, all'interno di una determinata finestra di generazione di report.

Nota: gli attivatori di priorità inferiore che sono già stati registrati consumano sempre il budget.

Consentire a più tecnologie pubblicitarie di registrare attivatori o origini di attribuzione

È normale che più di una tecnologia pubblicitaria riceva report sull'attribuzione, in genere per eseguire la deduplica su più reti. Di conseguenza, l'API consente a più professionisti del marketing pubblicitario di registrare la stessa origine o lo stesso attivatore dell'attribuzione. Un fornitore di tecnologia pubblicitaria deve registrare sia le origini di attribuzione sia gli attivatori per ricevere i postback dall'API. L'attribuzione viene eseguita tra le origini di attribuzione e gli attivatori registrati dall'ad tech nell'API.

Gli inserzionisti che vogliono utilizzare una terza parte per eseguire la deduplica su più reti possono continuare a farlo utilizzando una tecnica simile alla seguente:

• Configurazione di un server interno per registrare e ricevere report dall'API.
• Continuare a utilizzare un partner di misurazione mobile esistente.

Origini dell'attribuzione

I reindirizzamenti dell'origine dell'attribuzione sono supportati nel metodo registerSource():

1. La tecnologia pubblicitaria che chiama il metodo registerSource() può fornire un campo Attribution-Reporting-Redirect aggiuntivo nella risposta, che rappresenta l'insieme degli URL di reindirizzamento della tecnologia pubblicitaria partner.
2. L'API chiama quindi gli URL di reindirizzamento in modo che l'origine dell'attribuzione possa essere registrata dalle tecnologie pubblicitarie partner.

Nel campo Attribution-Reporting-Redirect possono essere elencati più URL di tecnologia pubblicitaria partner e le tecnologie pubblicitarie partner non possono specificare il proprio campo Attribution-Reporting-Redirect.

L'API consente inoltre a diverse tecnologie pubblicitarie di effettuare ciascuna chiamata registerSource().

Trigger

Per la registrazione degli attivatori, le terze parti sono supportate in modo simile: le tecnologie pubblicitarie possono utilizzare il campo Attribution-Reporting-Redirect aggiuntivo o chiamare ciascuna il metodo registerTrigger().

Quando un inserzionista utilizza più tecnologie pubblicitarie per registrare lo stesso evento di attivazione, deve essere utilizzata una chiave di deduplica. La chiave di deduplica serve a distinguere questi report ripetuti dello stesso evento registrati dalla stessa piattaforma di ad tech. Ad esempio, un fornitore di tecnologia pubblicitaria potrebbe fare in modo che il proprio SDK chiami direttamente l'API per registrare un attivatore e avere il proprio URL nel campo di reindirizzamento della chiamata di un altro fornitore di tecnologia pubblicitaria. Se non viene fornita una chiave di deduplica, gli attivatori duplicati potrebbero essere segnalati come unici a ogni tecnologia pubblicitaria.

Gestire gli trigger duplicati

Una tecnologia pubblicitaria può registrare lo stesso attivatore più volte con l'API. Gli scenari includono quanto segue:

• L'utente esegue la stessa azione (attivatore) più volte. Ad esempio, l'utente sfoglia lo stesso prodotto più volte nella stessa finestra del report.
• L'app dell'inserzionista utilizza più SDK per la misurazione delle conversioni, che tutti indirizzano alla stessa tecnologia pubblicitaria. Ad esempio, l'app dell'inserzionista utilizza due partner di misurazione, MMP 1 e MMP 2. Entrambi gli MMP reindirizzano alla tecnologia pubblicitaria 3. Quando si verifica un attivatore, entrambi gli MMP lo registrano con l'API Attribution Reporting. La tecnologia pubblicitaria 3 riceve quindi due reindirizzamenti separati, uno dalla MMP 1 e uno dalla MMP 2, per lo stesso attivatore.

In questi casi, esistono diversi modi per eliminare i report a livello di evento sugli attivatori duplicati, in modo da ridurre la probabilità di superare i limiti di frequenza applicati ai report a livello di evento. Il metodo consigliato è utilizzare una chiave di deduplica.

Metodo consigliato: chiave di deduplica

Il metodo consigliato è che l'app dell'inserzionista trasmetta una chiave di deduplica unica a qualsiasi tecnologia pubblicitaria o SDK che utilizza per la misurazione delle conversioni. Quando si verifica una conversione, l'app passa una chiave di deduplica alle tecnologie pubblicitarie o agli SDK. Queste tecnologie pubblicitarie o questi SDK continuano quindi a passare la chiave di deduplica ai reindirizzamenti utilizzando un parametro negli URL specificati in Attribution-Reporting-Redirect.

Gli esperti di tecnologia pubblicitaria possono scegliere di registrare solo il primo attivatore con una determinata chiave di deduplica oppure possono scegliere di registrare più attivatori o tutti gli attivatori. Gli esperti di tecnologia pubblicitaria possono specificare deduplication_key quando registrano attivatori duplicati.

Se una tecnologia pubblicitaria registra più attivatori con la stessa chiave di deduplica e la stessa origine attribuita, nei report a livello di evento viene inviato solo il primo attivatore registrato. Gli attivatori duplicati vengono comunque inviati nei report aggregabili criptati.

Metodo alternativo: le tecnologie pubblicitarie concordano sui tipi di attivatori per inserzionista

Se le tecnologie pubblicitarie non vogliono utilizzare la chiave di deduplica o se l'app dell'inserzionista non può trasmettere una chiave di deduplica, esiste un'opzione alternativa. Tutte le tecnologie pubblicitarie che misurano le conversioni per un determinato inserzionista devono collaborare per definire tipi di attivatori diversi per ogni inserzionista.

Le tecnologie pubblicitarie che avviano la chiamata di registrazione dell'attivatore, ad esempio gli SDK, includono un parametro negli URL specificati in Attribution-Reporting-Redirect, ad esempio duplicate_trigger_id. Questo parametro duplicate_trigger_id può includere informazioni come il nome dell'SDK e il tipo di attivatore per l'inserzionista. Le tecnologie pubblicitarie possono quindi inviare un sottoinsieme di questi attivatori duplicati ai report a livello di evento. Anche le tecnologie pubblicitarie possono includere questo duplicate_trigger_id nelle proprie chiavi di aggregazione.

Esempio di attribuzione su più reti

Nell'esempio descritto in questa sezione, l'inserzionista utilizza due piattaforme di tecnologia pubblicitaria per la pubblicazione (Ad Tech A e Ad Tech B) e un partner di misurazione (MMP).

Per iniziare, l'ad tech A, l'ad tech B e la piattaforma MMP devono completare la registrazione per utilizzare l'API Attribution Reporting. Per ulteriori informazioni, consulta Registrarsi per un account Privacy Sandbox.

Il seguente elenco fornisce una serie ipotetica di azioni utente che si verificano ciascuna con un giorno di distanza e illustra in che modo l'API Attribution Reporting gestisce queste azioni rispetto ad Ad Tech A, Ad Tech B e MMP:

Giorno 1: l'utente fa clic su un annuncio pubblicato dalla tecnologia pubblicitaria A

La tecnologia pubblicitaria A chiama registerSource() con il proprio URI. L'API invia una richiesta all'URI e il clic viene registrato con i metadati della risposta del server della tecnologia pubblicitaria A.

La tecnologia pubblicitaria A include anche l'URI della piattaforma di gestione dei dati in-market nell'intestazione Attribution-Reporting-Redirect. L'API invia una richiesta all'URI dell'MMP e il clic viene registrato con i metadati della risposta del server dell'MMP.

Giorno 2: l'utente fa clic su un annuncio pubblicato dalla tecnologia pubblicitaria B

La tecnologia pubblicitaria B chiama registerSource() con il proprio URI. L'API invia una richiesta all'URI e il clic viene registrato con i metadati della risposta del server di Ad Tech B.

Come la tecnologia pubblicitaria A, anche la tecnologia pubblicitaria B ha incluso l'URI della piattaforma di gestione dei dati indirizzi (MMP) nell'Attribution-Reporting-Redirect header. L'API invia una richiesta all'URI del fornitore di dati di marketing (MMP) e il clic viene registrato con i metadati della risposta del server del fornitore di dati di marketing.

Giorno 3: l'utente visualizza un annuncio pubblicato dalla tecnologia pubblicitaria A

L'API risponde nello stesso modo del primo giorno, tranne per il fatto che una visualizzazione è registrata per la tecnologia pubblicitaria A e la piattaforma di misurazione del marketing.

Giorno 4: l'utente installa l'app, che utilizza la piattaforma di misurazione del marketing per la misurazione delle conversioni

L'MMP chiama registerTrigger() con il proprio URI. L'API invia una richiesta all'URL e la conversione viene registrata con i metadati della risposta del server dell'MMP.

L'MMP include anche gli URI per la tecnologia pubblicitaria A e la tecnologia pubblicitaria B nell'Attribution-Reporting-Redirect. L'API invia richieste ai server di Ad Tech A e Ad Tech B e la conversione viene registrata di conseguenza con i metadati delle risposte del server.

Il seguente diagramma illustra la procedura descritta nell'elenco precedente:

Esempio di come l'API Attribution Reporting risponde a una serie di azioni utente.

L'attribuzione funziona nel seguente modo:

• La tecnologia pubblicitaria A imposta la priorità dei clic più in alto rispetto alle visualizzazioni e, di conseguenza, ottiene la registrazione dell'installazione attribuita al clic del primo giorno.
• La tecnologia pubblicitaria B riceve l'attribuzione dell'installazione il giorno 2.
• L'MMP imposta la priorità dei clic più alta rispetto alle visualizzazioni e ottiene l'installazione attribuita al clic del secondo giorno. Il clic del secondo giorno è l'evento correlato all'annuncio più recente e con la massima priorità.

Attribuzione su più reti senza reindirizzamenti

Sebbene consigliamo di utilizzare i reindirizzamenti per consentire a più esperti di tecnologia pubblicitaria di registrare trigger e origini di attribuzione, siamo consapevoli che potrebbero esserci scenari in cui l'utilizzo dei reindirizzamenti non è fattibile. Questa sezione illustra in dettaglio come supportare l'attribuzione cross-network senza reindirizzamenti.

Flusso di alto livello

1. Al momento della registrazione dell'origine, la rete ad tech di pubblicazione condivide le proprie chiavi di aggregazione delle origini.
2. Al momento della registrazione dell'attivatore, l'inserzionista o il partner di misurazione sceglie quali elementi chiave lato sorgente utilizzare e specifica la configurazione dell'attribuzione.
3. L'attribuzione si basa sulla configurazione dell'attribuzione, sulle chiavi condivise e su eventuali origini effettivamente registrate dall'inserzionista o dal partner di misurazione (ad es. da un'altra rete ad tech di pubblicazione che ha attivato i reindirizzamenti).
4. Se l'attivatore viene attribuito a una sorgente da una tecnologia pubblicitaria di pubblicazione senza reindirizzamento, l'inserzionista o il partner di misurazione può ricevere un report aggregabile che combina i componenti chiave della sorgente e dell'attivatore definiti nel passaggio 2.

Registrazione dell'origine

Al momento della registrazione dell'origine, la rete ad tech di pubblicazione può scegliere di condividere le proprie chiavi di aggregazione delle sorgenti o un sottoinsieme di queste anziché eseguire il reindirizzamento. La tecnologia pubblicitaria di pubblicazione non è tenuta a utilizzare effettivamente queste chiavi di origine nei propri report aggregabili e può dichiararle solo per conto dell'inserzionista o del partner di misurazione, se necessario.

Le chiavi di aggregazione condivise sono disponibili per qualsiasi tecnologia pubblicitaria che registra un attivatore per lo stesso inserzionista. Tuttavia, è compito della tecnologia pubblicitaria di pubblicazione e della tecnologia pubblicitaria di misurazione dell'attivatore collaborare per stabilire quali tipi di chiavi di aggregazione sono necessari, i relativi nomi e come decodificare le chiavi in dimensioni leggibili.

Registrazione trigger

Al momento della registrazione dell'attivatore, la tecnologia pubblicitaria di misurazione sceglie quali componenti della chiave lato sorgente applicare a ogni componente della chiave dell'attivatore, incluse quelle condivise dalle tecnologie pubblicitarie di pubblicazione.

Inoltre, la tecnologia pubblicitaria di misurazione deve specificare anche la logica di attribuzione della struttura a cascata utilizzando una nuova chiamata API di configurazione dell'attribuzione. In questa configurazione, la tecnologia pubblicitaria può specificare la priorità, la scadenza e i filtri delle sorgenti su cui non aveva visibilità (ad es. le sorgenti che non utilizzavano un reindirizzamento).

Attribuzione

L'API Attribution Reporting esegue l'attribuzione last-touch con priorità per la tecnologia pubblicitaria di misurazione in base alla configurazione dell'attribuzione, alle chiavi condivise e a eventuali origini registrate. Ad esempio:

• L'utente ha fatto clic sugli annunci pubblicati dalle ad tech A, B, C e D. L'utente ha poi installato l'app dell'inserzionista, che utilizza un partner di tecnologia pubblicitaria per la misurazione (MMP).
• La tecnologia pubblicitaria A reindirizza le sue origini all'MMP.
• Le tecnologie pubblicitarie B e C non reindirizzano, ma condividono le proprie chiavi di aggregazione.
• La tecnologia pubblicitaria D non reindirizza né condivide le chiavi di aggregazione.

L'MMP registra un'origine dalla tecnologia pubblicitaria A e definisce una configurazione di attribuzione che include la tecnologia pubblicitaria B e la tecnologia pubblicitaria D.

L'attribuzione per la piattaforma di gestione del marketing ora include:

• La tecnologia pubblicitaria A, poiché l'MMP ha registrato un'origine dal reindirizzamento di questa tecnologia pubblicitaria.
• La tecnologia pubblicitaria B, poiché ha condiviso le chiavi e l'MMP le ha incluse nella configurazione dell'attribuzione.

L'attribuzione per l'MMP non include:

• La tecnologia pubblicitaria C, poiché l'MMP non l'ha inclusa nella configurazione dell'attribuzione.
• La tecnologia pubblicitaria D, in quanto non ha reindirizzato né condiviso le chiavi di aggregazione.

Nota: per ulteriori informazioni su come implementare questo design, consulta la Guida per gli sviluppatori dell'API Attribution Reporting.

Debug

Per supportare il debug per l'attribuzione cross-network senza reindirizzamenti, è disponibile un campo aggiuntivo, shared_debug_key, che le ad tech possono impostare al momento della registrazione della fonte. Se impostato durante la registrazione dell'origine originale, verrà impostato anche sull'origine derivata corrispondente come debug_key durante la registrazione dell'attivatore per l'attribuzione cross-network senza reindirizzamenti. Questa chiave di debug viene allegata come source_debug_key nei report sugli eventi e aggregati.

Questa funzionalità di debug sarà supportata solo per l'attribuzione cross-network senza reindirizzamenti nei seguenti scenari:

• Misurazione da app ad app in cui è consentito AdId
• Misurazione da app a web in cui l'AdId è consentito e corrisponde sia all'origine app sia all'attivatore web
• Misurazione da web a web (sulla stessa app browser) quando ar_debug è presente sia nell'origine sia nell'attivatore

Rilevamento delle chiavi per l'attribuzione su più reti senza reindirizzamenti

La funzionalità di rilevamento delle chiavi ha lo scopo di semplificare il modo in cui le ad tech (in genere MMP) implementano la configurazione dell'attribuzione ai fini dell'attribuzione cross-network quando una o più ad tech di pubblicazione utilizzano chiavi di aggregazione condivise (come descritto in Attribuzione cross-network senza reindirizzamenti sopra).

Quando un MMP esegue query sul servizio di aggregazione per generare report di riepilogo per le campagne che includono origini derivate, il servizio di aggregazione richiede all'MMP di specificare l'elenco delle possibili chiavi come input per il job di aggregazione. In alcuni casi, l'elenco delle potenziali chiavi di aggregazione delle origini potrebbe essere molto grande o sconosciuto. Elenchi di possibili chiavi di grandi dimensioni sono difficili da monitorare e sono anche molto complessi e costosi da elaborare. Considera i seguenti esempi:

• L'elenco di tutte le chiavi possibili è ampio:
  • Una rete pubblicitaria di pubblicazione sta implementando un'iniziativa complessa di acquisizione di utenti che include 20 campagne, ciascuna con 10 gruppi di annunci e ciascun gruppo di annunci con 5 creatività aggiornate ogni settimana in base al rendimento.
• L'elenco di tutte le chiavi possibili è sconosciuto:
  • Una rete di annunci pubblica annunci su molte app mobile per le quali non è noto l'elenco completo degli ID app del publisher al momento del lancio della campagna.
  • Un inserzionista utilizza più reti pubblicitarie di pubblicazione che non indirizzano all'MMP al momento della registrazione dell'origine. Ogni rete pubblicitaria di pubblicazione ha una struttura e valori chiave diversi, che potrebbero non essere condivisi in anticipo con l'MMP.

Con l'introduzione del rilevamento delle chiavi:

• Il servizio di aggregazione non richiede più un'enumerazione completa delle possibili chiavi di aggregazione.
• Anziché dover specificare l'elenco completo delle possibili chiavi, un MMP può creare un insieme vuoto (o parzialmente vuoto) di chiavi e impostare una soglia, in modo che nell'output vengano incluse solo le chiavi (non predefinite) con valori superiori alla soglia.
• MMP riceve un report di riepilogo che include valori con rumore per le chiavi che hanno valori che contribuiscono a superare la soglia impostata. Il report può includere anche chiavi che non hanno contributi di utenti reali associati e sono puramente con rumore.
• L'MMP utilizza il campo x_network_bit_mapping nella registrazione dell'attivatore per determinare a quale tecnologia pubblicitaria corrisponde quale chiave.
• L'MMP può quindi contattare la tecnologia pubblicitaria di pubblicazione appropriata per comprendere i valori nella chiave di origine.

In sintesi, la scoperta delle chiavi consente alle MMP di ottenere le chiavi di aggregazione senza doverle conoscere in anticipo ed evitare di elaborare un volume elevato di chiavi di origine a scapito di un aumento del rumore.

Nota: questa funzionalità è in fase di proposta e non è ancora disponibile per i test. Il tuo feedback e i tuoi commenti sono benvenuti.

Reindirizzamenti daisy chain

Fornendo più intestazioni Attribution-Reporting-Redirect nella risposta del server HTTPS di registrazione di un'origine o di un attivatore, un'ad tech può utilizzare l'API Attribution Reporting per eseguire più registrazioni di origini e attivatori con una singola chiamata API di registrazione.

Nella risposta del server, la tecnologia pubblicitaria può includere anche una singola intestazione Location (reindirizzamento 302) con un URL, che a sua volta porta a un'altra registrazione, fino a un limite impostato.

Entrambi i tipi di intestazioni sono facoltativi e non è possibile fornirne nessuno se i reindirizzamenti non sono necessari. È possibile fornire uno o entrambi i tipi di intestazioni. Le richieste di registrazione dell'origine e dell'attivatore (inclusi i reindirizzamenti) vengono riprovate in caso di errore di rete. Il numero di nuovi tentativi per richiesta è limitato a un numero fisso per evitare un impatto significativo sul dispositivo.

I reindirizzamenti non sono accettati per registerWebSource e registerWebTrigger utilizzati dai browser. Maggiori dettagli sono disponibili nella Guida all'implementazione su web e app.

Visualizzare i dati di misurazione nei report sull'attribuzione

L'API Attribution Reporting consente i seguenti tipi di report, descritti in modo più dettagliato più avanti in questa pagina:

• I report a livello di evento associano una determinata origine di attribuzione (clic o visualizzazione) a una quantità limitata di dati di attivazione ad alta fedeltà.
• I report aggregabili non sono necessariamente associati a un'origine di attribuzione specifica. Questi report forniscono dati sugli attivatori più completi e con una fedeltà superiore rispetto ai report a livello di evento, ma sono disponibili solo in forma aggregata.

Questi due tipi di report sono complementari tra loro e possono essere utilizzati contemporaneamente.

Report a livello di evento

Dopo che un attivatore è stato attribuito a un'origine di attribuzione, viene generato e archiviato sul dispositivo un report a livello di evento finché non può essere inviato nuovamente all'URL postback di ogni fornitore di tecnologia pubblicitaria durante una delle finestre temporali per l'invio dei report, descritte più dettagliatamente più avanti in questa pagina.

I report a livello di evento sono utili quando sono necessarie pochissime informazioni sull'attivatore. I dati sugli attivatori a livello di evento sono limitati a 3 bit di dati sugli attivatori per i clic, il che significa che a un attivatore può essere assegnata una di otto categorie, e 1 bit per le visualizzazioni. Inoltre, i report a livello di evento non supportano la codifica di dati lato attivatore ad alta fedeltà, come un prezzo o un'ora di attivazione specifici. Poiché l'attribuzione avviene sul dispositivo, non è supportato l'analisi cross-device nei report a livello di evento.

Il report a livello di evento contiene dati quali:

• Destinazione: nome del pacchetto dell'app dell'inserzionista o dominio di primo livello esteso + 1 in cui si è verificato l'attivatore
• ID origine attribuzione:lo stesso ID origine attribuzione utilizzato per registrare un'origine attribuzione
• Tipo di trigger:1 o 3 bit di dati di trigger a bassa fedeltà, a seconda del tipo di origine dell'attribuzione

Meccanismi che tutelano la privacy applicati a tutti i report

I seguenti limiti vengono applicati dopo aver preso in considerazione le priorità relative alle origini e agli attivatori dell'attribuzione.

Limiti al numero di tecnologie pubblicitarie

Esistono limiti al numero di tecnologie pubblicitarie che possono registrarsi o ricevere report dall'API. Al momento, la proposta è la seguente:

• 100 tecnologie pubblicitarie con origini attribuzione per {app di origine, app di destinazione, 30 giorni, dispositivo}.
• 10 tecnologie pubblicitarie con attivatori attribuiti per {app di origine, app di destinazione, 30 giorni, dispositivo}.
• 20 fornitori di tecnologia pubblicitaria possono registrare un'unica origine o un singolo attivatore dell'attribuzione (tramite Attribution-Reporting-Redirect)

Limiti al numero di destinazioni univoche

Questi limiti rendono difficile per un insieme di tecnologie pubblicitarie colludere eseguendo query su un gran numero di app per comprendere il comportamento di utilizzo delle app di un determinato utente.

• In tutte le origini registrate e in tutte le tecnologie pubblicitarie, l'API non supporta più di 200 destinazioni univoche per app di origine al minuto.
• Per tutte le origini registrate, per una singola tecnologia pubblicitaria, l'API supporta non più di 50 destinazioni univoche per app di origine al minuto. Questo limite impedisce a una tecnologia pubblicitaria di utilizzare tutto il budget del limite di frequenza menzionato in precedenza.

Le origini scadute non vengono conteggiate ai fini dei limiti di frequenza.

Un'origine report per app di origine al giorno

Una determinata piattaforma ad tech può utilizzare una sola origine report per registrare le origini su un'app publisher, per un determinato dispositivo, nello stesso giorno. Questo limite di frequenza impedisce alle tecnologie pubblicitarie di utilizzare più origini report per accedere a un budget per la privacy aggiuntivo.

Considera il seguente scenario, in cui una singola tecnologia pubblicitaria vuole utilizzare più origini report per registrare le origini in un'app publisher per un singolo dispositivo.

1. L'origine report 1 della tecnologia pubblicitaria A registra una sorgente nell'app B
2. 12 ore dopo, l'origine report 2 della tecnologia pubblicitaria A tenta di registrare una fonte sull'app B

La seconda origine, per l'origine report 2 della tecnologia pubblicitaria A, verrà rifiutata dall'API. L'origine report 2 della tecnologia pubblicitaria A non sarebbe in grado di registrare correttamente un'origine sullo stesso dispositivo nell'app B fino al giorno successivo.

Tempo di attesa e limiti di frequenza

Per limitare la quantità di fuga di identità utente tra una coppia {source, destination}, l'API riduce la quantità di informazioni totali inviate in un determinato periodo di tempo per un utente.

La proposta attuale è limitare ogni tecnologia pubblicitaria a 100 attivatori attribuiti per {app di origine, app di destinazione, 30 giorni, dispositivo}.

Numero di destinazioni uniche

L'API limita il numero di destinazioni che una tecnologia pubblicitaria può provare a misurare. Più basso è il limite, più è difficile per una tecnologia pubblicitaria utilizzare l'API per tentare di misurare l'attività di navigazione degli utenti non associata agli annunci mostrati.

La proposta attuale è limitare ogni ad tech a 100 destinazioni distinte con origini non scadute per app di origine.

Meccanismi incentrati sulla tutela della privacy applicati ai report a livello di evento

Fideltà limitata dei dati degli attivatori

L'API fornisce 1 bit per gli attivatori view-through e 3 bit per gli attivatori clickthrough. Le origini di attribuzione continuano a supportare l'intera lunghezza di 64 bit dei metadati.

Devi valutare se e come ridurre le informazioni espresse negli attivatori in modo che funzionino con il numero limitato di bit disponibili nei report a livello di evento.

Framework per il rumore della privacy differenziale

Uno degli obiettivi di questa API è consentire alla misurazione a livello di evento di soddisfare i requisiti della privacy differenziale locale utilizzando risposte k-randomizzate per generare un output con rumore per ogni evento sorgente.

Il rumore viene applicato in base al fatto che un evento di origine dell'attribuzione venga registrato in modo veritiero. Un'origine attribuzione viene registrata sul dispositivo con probabilità $ 1-p $ che l'origine attribuzione sia registrata come normale e con probabilità $ p $ che il dispositivo scelga in modo casuale tra tutti i possibili stati di output dell'API (incluso il non segnalare nulla o il segnalare più report falsi).

La risposta con k elementi casuali è un algoritmo con privacy differenziale epsilon se è soddisfatta la seguente equazione:

\[ p = \frac{k}{k + e^ε - 1} \]

Per valori bassi di ε, l'output reale è protetto dal meccanismo di risposta k-randomizzata. I parametri di rumore esatti sono in fase di sviluppo e sono soggetti a modifiche in base al feedback, con una proposta attuale che prevede quanto segue:

• p=0,24% per le sorgenti di navigazione
• p=0,00025% per le origini evento

Limiti per gli attivatori disponibili (conversioni)

Esistono limiti al numero di attivatori per origine attribuzione, con una proposta attuale che prevede quanto segue:

• 1-2 attivatori per le origini di attribuzione delle visualizzazioni dell'annuncio (2 attivatori disponibili solo nel caso di attribuzione post-installazione)
• 3 attivatori per le origini di attribuzione degli annunci basati sui clic

Nota: questa sezione descrive il comportamento predefinito dell'API per il numero di attribuzioni per ciascuna fonte che utilizza i report a livello di evento. Con l'introduzione dei report flessibili a livello di evento a ottobre 2023, gli esperti di tecnologia pubblicitaria ora possono configurare questa dimensione dei report in base a ciò che funziona meglio per il loro caso d'uso.

Finestre temporali specifiche per l'invio dei report (comportamento predefinito)

I report a livello di evento per le origini di attribuzione delle visualizzazioni dell'annuncio vengono inviati un'ora dopo la scadenza dell'origine. Questa data di scadenza può essere configurata, ma non può essere inferiore a 1 giorno o superiore a 30 giorni. Se a un'origine di attribuzione della visualizzazione dell'annuncio vengono attribuiti due attivatori (tramite l'attribuzione post-installazione), i report a livello di evento possono essere inviati negli intervalli della finestra di generazione dei report specificati di seguito.

I report a livello di evento per le origini di attribuzione dei clic sugli annunci non possono essere configurati e vengono inviati prima o alla scadenza dell'origine, in momenti specifici rispetto alla data di registrazione dell'origine. Il periodo di tempo compreso tra l'origine dell'attribuzione e la scadenza è suddiviso in più finestre di generazione di report. Ogni finestra di generazione di report ha una scadenza (dalla data e dall'ora dell'origine dell'attribuzione). Al termine di ogni finestra di generazione dei report, il dispositivo raccoglie tutti gli attivatori che si sono verificati dalla finestra di generazione dei report precedente e invia un report pianificato. L'API supporta le seguenti finestre di generazione di report:

• 2 giorni: il dispositivo raccoglie tutti gli attivatori che si sono verificati al massimo 2 giorni dopo la registrazione dell'origine attribuzione. Il report viene inviato 2 giorni e 1 ora dopo la registrazione dell'origine dell'attribuzione.
• 7 giorni:il dispositivo raccoglie tutti gli attivatori che si sono verificati più di 2 giorni, ma non più di 7 giorni, dopo la registrazione dell'origine attribuzione. Il report viene inviato 7 giorni e 1 ora dopo la registrazione dell'origine attribuzione.
• Una durata personalizzata,definita dall'attributo "expiry" di un'origine di attribuzione. Il report viene inviato un'ora dopo l'ora di scadenza specificata. Questo valore non può essere inferiore a 1 giorno o superiore a 30 giorni.

Nota: questa sezione descrive il comportamento predefinito dell'API per le finestre dei report a livello di evento. Con l'introduzione dei report flessibili a livello di evento a ottobre 2023, gli esperti di tecnologia pubblicitaria ora possono configurare questa dimensione dei report in base a ciò che è più adatto al loro caso d'uso.

Configurazione flessibile a livello di evento

La configurazione predefinita per i report a livello di evento è quella che consigliamo agli esperti di tecnologia pubblicitaria di iniziare a utilizzare quando iniziano i test di utilità, ma potrebbe non essere ideale per tutti i casi d'uso. L'API Attribution Reporting supporterà configurazioni facoltative e più flessibili, in modo che le tecnologie pubblicitarie abbiano un maggiore controllo sulla struttura dei report a livello di evento e possano massimizzare l'utilità dei dati.

Questa maggiore flessibilità verrà introdotta nell'API Attribution Reporting in due fasi:

• Fase 1: configurazione flessibile a livello di evento Lite
  • Questa versione fornisce un sottoinsieme delle funzionalità complete e può essere utilizzata indipendentemente dalla Fase 2.
• Fase 2: versione completa della configurazione flessibile a livello di evento

La Fase 1 (a livello di evento flessibile Lite) può essere utilizzata per:

• Variare la frequenza dei report specificando il numero di finestre di generazione dei report
• Variare il numero di attribuzioni per registrazione dell'origine
• Riduci la quantità di rumore totale diminuendo i parametri precedenti
• Configurare le finestre dei report anziché utilizzare quelle predefinite

La Fase 2 (a livello di evento completamente flessibile) può essere utilizzata per tutte le funzionalità della Fase 1 e per:

• Variare la cardinalità dei dati dell'attivatore in un report
• Riduci la quantità di rumore totale diminuendo la cardinalità dei dati dell'attivatore

La riduzione di una dimensione della configurazione predefinita consente alla tecnologia pubblicitaria di aumentare un'altra dimensione. In alternativa, la quantità totale di rumore in un report a livello di evento può essere ridotta diminuendo in modo netto i parametri sopra menzionati.

Oltre a impostare dinamicamente i livelli di rumore in base alla configurazione scelta da un'ad tech, imposteremo alcuni limiti di parametro per evitare costi di calcolo elevati e configurazioni con troppi stati di output (in cui il rumore aumenterà notevolmente). Di seguito è riportato un esempio di limitazioni. Ti invitiamo a inviare un feedback sulla [proposta di design][50]:

• Massimo 20 report totali, a livello globale e per trigger_data
• Massimo 5 possibili finestre di generazione di report per trigger_data
• Massimo 32 di cardinalità dei dati di attivazione (non applicabile alla Fase 1: livello di evento flessibile Lite)

Quando le tecnologie pubblicitarie inizieranno a utilizzare questa funzionalità, tieni presente che l'utilizzo di valori estremi può comportare una grande quantità di rumore o la mancata registrazione se i livelli di privacy non vengono soddisfatti.

Nota: la fase 1 (a livello di evento flessibile Lite) è stata rilasciata in versione beta a ottobre 2023. La fase 2 (a livello di evento completamente flessibile) è prevista per la versione beta più avanti nel primo trimestre del 2024.

Report aggregabili

Prima di utilizzare i report aggregabili, devi configurare il tuo account cloud e iniziare a ricevere i report aggregabili.

I report aggregabili forniscono dati sugli attivatori del dispositivo con una maggiore fedeltà e più rapidamente rispetto a quanto offerto per i report a livello di evento. Questi dati con una maggiore fedeltà possono essere appresi solo in forma aggregata e non sono associati a un determinato attivatore o utente. Le chiavi di aggregazione possono avere fino a 128 bit e questo consente ai report aggregabili di supportare casi d'uso come:

• Report per i valori di attivazione, ad esempio le entrate
• Gestione di più tipi di attivatori

Inoltre, i report aggregabili utilizzano la stessa logica di attribuzione con priorità per l'origine dei report a livello di evento, ma supportano più conversioni attribuite a un clic o una visualizzazione.

Il design complessivo di come l'API Attribution Reporting prepara e invia report aggregabili, mostrato nel diagramma, è il seguente:

1. Il dispositivo invia report aggregabili criptati alla tecnologia pubblicitaria. In un ambiente di produzione, le tecnologie pubblicitarie non possono utilizzare direttamente questi report.
2. La tecnologia pubblicitaria invia un batch di report aggregabili al servizio di aggregazione per l'aggregazione.
3. Il servizio di aggregazione legge un batch di report aggregabili, li decripta e li aggrega.
4. I dati aggregati finali vengono inviati nuovamente alla tecnologia pubblicitaria in un report di riepilogo.

Procedura utilizzata dall'API Attribution Reporting per preparare e inviare report aggregabili.

I report aggregabili contengono i seguenti dati relativi alle origini di attribuzione:

• Destinazione: il nome del pacchetto dell'app o l'URL web eTLD+1 in cui si è verificato l'attivatore.
• Data:la data in cui si è verificato l'evento rappresentato dall'origine dell'attribuzione.
• Payload: valori di attivazione, raccolti come coppie chiave/valore criptate, che vengono utilizzati nel servizio di aggregazione attendibile per calcolare le aggregazioni.

Servizi di aggregazione

I seguenti servizi forniscono funzionalità di aggregazione dei dati e proteggono da accessi non autorizzati ai dati aggregati.

Questi servizi sono gestiti da terze parti, descritti in maggiore dettaglio più avanti in questa pagina:

• Il servizio di aggregazione è l'unico che gli esperti di tecnologia pubblicitaria devono implementare.
• I servizi di gestione delle chiavi e di contabilità dei report aggregabili sono gestiti da terze parti attendibili chiamate coordinatori. Questi coordinatori attestano che il codice che esegue il servizio di aggregazione è il codice disponibile pubblicamente fornito da Google e che a tutti gli utenti del servizio di aggregazione vengono applicati gli stessi servizi di contabilità dei report aggregabili e le stesse chiavi.

Servizio di aggregazione

Le piattaforme di tecnologia pubblicitaria devono, in anticipo, implementare un servizio di aggregazione basato su file binari forniti da Google.

Questo servizio di aggregazione opera in un ambiente di esecuzione sicuro (TEE) ospitato nel cloud. Un TEE offre i seguenti vantaggi in termini di sicurezza:

• Garantisce che il codice in esecuzione nel TEE sia il codice binario specifico offerto da Google. A meno che questa condizione non sia soddisfatta, il servizio di aggregazione non può accedere alle chiavi di decrittografia di cui ha bisogno per funzionare.
• Offre sicurezza al processo in esecuzione, isolandolo da monitoraggio o manomissioni esterni.

Questi vantaggi in termini di sicurezza rendono più sicuro per un servizio di aggregazione eseguire operazioni sensibili, come l'accesso ai dati criptati.

Per maggiori informazioni su progettazione, flusso di lavoro e considerazioni sulla sicurezza del servizio di aggregazione, consulta il documento del servizio di aggregazione su GitHub.

Servizio di gestione delle chiavi

Questo servizio verifica che un servizio di aggregazione esegua una versione approvata del file binario e poi fornisce al servizio di aggregazione nell'ad tech le chiavi di decrittografia corrette per i dati di attivazione.

Contabilità dei report aggregabili

Questo servizio monitora la frequenza con cui il servizio di aggregazione di una tecnologia pubblicitaria accede a un attivatore specifico, che può contenere più chiavi di aggregazione, e limita l'accesso al numero appropriato di decrittazioni. Per maggiori dettagli, consulta la proposta di progettazione del servizio di aggregazione per l'API Attribution Reporting.

API Aggregatable Reports

L'API per la creazione di contributi ai report aggregabili utilizza la stessa API di base utilizzata per la registrazione di un'origine di attribuzione per i report a livello di evento. Le sezioni seguenti descrivono le estensioni dell'API.

Registra i dati di origine aggregabili

Quando l'API invia una richiesta all'URI dell'origine attribuzione, la tecnologia pubblicitaria può registrare un elenco di chiavi di aggregazione, denominate histogram_contributions, rispondendo con un nuovo campo chiamato aggregation_keys nell'intestazione HTTPAttribution-Reporting-Register-Source, con chiave key_name e valore key_piece:

• (Chiave) Nome chiave:una stringa per il nome della chiave. Utilizzata come chiave di join per combinarsi con le chiavi lato trigger per formare la chiave finale.
• (Valore) Componente chiave:un valore di stringa di bit per la chiave.

La chiave del bucket dell'istogramma finale è completamente definita al momento dell'attivazione mediante l'esecuzione di un'operazione OR binaria su questi componenti e sui componenti lato trigger.

Le chiavi finali sono limitate a un massimo di 128 bit; le chiavi più lunghe vengono truncated. Ciò significa che le stringhe esadecimali nel JSON devono essere limitate al massimo a 32 cifre.

Scopri di più sulla struttura delle chiavi di aggregazione e su come configurarle.

Nell'esempio seguente, una società di tecnologia pubblicitaria utilizza l'API per raccogliere quanto segue:

• Conteggi delle conversioni aggregate a livello di campagna
• Valori di acquisto aggregati a livello geografico

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

Registra l'attivatore aggregabile

La registrazione dell'attivatore include due campi aggiuntivi.

Il primo campo viene utilizzato per registrare un elenco di chiavi aggregate sul lato dell'attivatore. La tecnologia pubblicitaria deve rispondere con il campo aggregatable_trigger_data nell'intestazione HTTP Attribution-Reporting-Register-Trigger, con i seguenti campi per ogni chiave aggregata nell'elenco:

• Parte della chiave:un valore di stringa di bit per la chiave.
• Chiavi di origine:un elenco di stringhe con i nomi delle chiavi del lato di origine dell'attribuzione con cui la chiave di attivazione deve essere combinata per formare le chiavi finali.

Il secondo campo viene utilizzato per registrare un elenco di valori che devono contribuire a ogni chiave. La tecnologia pubblicitaria deve rispondere con il campo aggregatable_values nell'intestazione HTTP Attribution-Reporting-Register-Trigger. Il secondo campo viene utilizzato per registrare un elenco di valori che devono contribuire a ogni chiave, che possono essere interi nell'intervallo $ [1, 2^{16}] $.

Ogni attivatore può apportare più contributi ai report aggregabili. L'ammontare totale dei contributi a un determinato evento di origine è vincolato da un parametro $ L1 $, ovvero la somma massima dei contributi (valori) in tutte le chiavi aggregate per una determinata origine. $ L1 $ si riferisce alla sensibilità o alla norma L1 degli contributi dell'istogramma per evento di origine. Il superamento di questi limiti comporta il ritiro silenzioso dei contributi futuri. La proposta iniziale è di impostare $ L1 $ su $ 2^{16} $ (65536).

Il rumore nel servizio di aggregazione viene scalato in proporzione a questo parametro. Pertanto, è consigliabile scalare in modo appropriato i valori riportati per una determinata chiave aggregata in base alla parte di budget L1 allocata. Questo approccio contribuisce a garantire che i report aggregati mantengano la massima fedeltà possibile quando viene applicato il rumore. Questo meccanismo è molto flessibile e può supportare molte strategie di aggregazione.

Nell'esempio seguente, il budget per la privacy viene suddiviso equamente tra campaignCounts e geoValue dividendo il contributo di L1 in parti uguali per ciascuno:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

L'esempio precedente genera i seguenti contributi all'istogramma:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

Nota: filters si applicano ancora ai report aggregabili e a ogni dizionario in aggregatable_trigger_data è comunque possibile applicare facoltativamente i filtri di conversione, così come i filtri di attivazione per i report a livello di evento.

I fattori di scala possono essere invertiti per ottenere i valori corretti, modulo del rumore applicato:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Privacy differenziale

Uno degli obiettivi di questa API è avere un framework in grado di supportare la misurazione aggregata privata differenziale. Questo può essere ottenuto aggiungendo rumore proporzionale al budget L1, ad esempio scegliendo il rumore con la seguente distribuzione:

\[ Laplace(\frac{L1}{ε}) \]

Integrazione dell'API Protected Audience e dell'API Attribution Reporting

L'integrazione tra le API Protected Audience e Attribution Reporting consente alle aziende di tecnologia pubblicitaria di valutare il rendimento dell'attribuzione in varie tattiche di remarketing per capire quali tipi di segmenti di pubblico generano il ROI più elevato.

Grazie a questa integrazione cross-API, le adtech possono:

• Crea una mappa chiave-valore di URI da utilizzare sia per 1) i report sulle interazioni sia per 2) la registrazione delle origini.
• Includi CustomAudience nella mappatura delle chiavi lato sorgente per i report di riepilogo aggregati (utilizzando l'API Attribution Reporting).

Quando un utente visualizza o fa clic su un annuncio:

• L'URL utilizzato per registrare queste interazioni utilizzando Protected Audience verrà utilizzato anche per registrare una visualizzazione o un clic come origine idonea con l'API Attribution Reporting.
• La tecnologia pubblicitaria può scegliere di passare CustomAudience (o altre informazioni contestuali pertinenti sull'annuncio, come il posizionamento dell'annuncio o la durata della visualizzazione) utilizzando questo URL in modo che questi metadati possano essere propagati ai report di riepilogo quando la tecnologia pubblicitaria esamina il rendimento aggregato della campagna.

Per saperne di più su come questa funzionalità viene attivata in Protected Audience, consulta la sezione pertinente della spiegazione dell'API Protected Audience.

Esempi di priorità di registrazione, attribuzione e generazione di report

Questo esempio mostra un insieme di interazioni utente e in che modo le priorità dell'origine e dell'attivatore dell'attribuzione definite dalla tecnologia pubblicitaria possono influire sui report attribuiti. In questo esempio, supponiamo quanto segue:

• Tutte le origini e gli attivatori di attribuzione sono registrati dalla stessa tecnologia pubblicitaria per lo stesso inserzionista.
• Tutte le origini e gli attivatori di attribuzione si verificano durante la prima finestra di generazione di report sugli eventi (entro 2 giorni dalla visualizzazione iniziale degli annunci in un'app del publisher).

Considera il caso in cui un utente esegue le seguenti operazioni:

1. L'utente vede un annuncio. L'ad tech registra un'origine attribuzione con l'API, con una priorità di 0 (visualizzazione 1).
2. L'utente vede un annuncio registrato con una priorità di 0 (visualizzazione 2).
3. L'utente fa clic su un annuncio registrato con una priorità di 1 (clic 1).
4. L'utente effettua una conversione (raggiunge la pagina di destinazione) in un'app dell'inserzionista. La tecnologia pubblicitaria registra un attivatore con l'API, con una priorità di 0 (conversione 1).
   • Quando gli attivatori vengono registrati, l'API esegue prima l'attribuzione prima di generare i report.
   • Sono disponibili tre origini attribuzione: visualizzazione 1, visualizzazione 2 e click 1. L'API attribuisce questo attivatore al clic 1 perché ha la priorità più elevata ed è il più recente.
   • Le visualizzazioni 1 e 2 vengono ignorate e non sono più idonee per l'attribuzione futura.
5. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con una priorità di 1 (conversione 2).
   • Il clic 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic 1.
6. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con una priorità di 1 (conversione 3).
   • Il clic 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic 1.
7. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con una priorità di 1 (conversione 4).
   • Il clic 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic 1.
8. L'utente effettua un acquisto nell'app dell'inserzionista, registrato con una priorità di 2 (conversione 5).
   • Il clic 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic 1.

I report a livello di evento hanno le seguenti caratteristiche:

• Per impostazione predefinita, i primi tre attivatori attribuiti a un clic e il primo attivatore attribuito a una visualizzazione vengono inviati dopo le finestre di generazione dei report applicabili.
• Nella finestra dei report, se sono presenti attivatori registrati con priorità più elevata, questi hanno la precedenza e sostituiscono l'attivatore più recente.
• Nell'esempio precedente, la tecnologia pubblicitaria riceve 3 report sugli eventi dopo la finestra di generazione dei report di 2 giorni, per la conversione 2, la conversione 3 e la conversione 5.
  • Tutti e cinque gli attivatori vengono attribuiti al clic 1. Per impostazione predefinita, l'API invia report per i primi 3 attivatori: conversione 1, conversione 2 e conversione 3.
  • Tuttavia, la priorità della conversione 4 (1) è superiore a quella della conversione 1 (0). Il report sugli eventi della conversione 4 sostituisce quello della conversione 1 da inviare.
  • Inoltre, la priorità della conversione 5 (2) è superiore a quella di qualsiasi altro attivatore. Il report sugli eventi della conversione 5 sostituisce quello della conversione 4 da inviare.

I report aggregabili hanno le seguenti caratteristiche:

• I report aggregabili criptati vengono inviati alla tecnologia pubblicitaria non appena vengono elaborati, alcune ore dopo la registrazione degli attivatori.

  In qualità di fornitore di tecnologia pubblicitaria, crei i batch in base alle informazioni non criptate nei report aggregabili. Queste informazioni sono contenute nel campo shared_info del report aggregabile e includono il timestamp e l'origine report. Non puoi eseguire il batch in base a informazioni criptate nelle coppie chiave-valore di aggregazione. Alcune semplici strategie che puoi seguire sono gruppare i report su base giornaliera o settimanale. Idealmente, i batch devono contenere almeno 100 report ciascuno.

• Spetta all'ad tech decidere quando e come raggruppare i report aggregabili e inviarli al servizio di aggregazione.

• Rispetto ai report a livello di evento, i report aggregabili criptati possono attribuire più attivatori a una sorgente.

• Nell'esempio precedente vengono inviati cinque report aggregabili, uno per ogni attivatore registrato.

Report di debug di transizione

L'API Attribution Reporting è un modo nuovo e abbastanza complesso per eseguire la misurazione dell'attribuzione senza identificatori cross-app. Pertanto, supportiamo un meccanismo transitorio per scoprire di più sui report sull'attribuzione quando l'ID pubblicità è disponibile (l'utente non ha disattivato la personalizzazione utilizzando l'ID pubblicità e l'app del publisher o dell'inserzionista ha dichiarato le autorizzazioni AdID). In questo modo, l'API può essere compresa appieno durante il rollout, aiuta a rilevare eventuali bug e a confrontare più facilmente il rendimento con le alternative basate su ID pubblicità. Esistono due tipi di report di debug: attribution-success e verbose.

Leggi la guida sui report di debug di transizione per informazioni dettagliate sui report di debug con misurazione da app a web e da web ad app.

Report di debug relativi al successo dell'attribuzione

Le registrazioni di sorgenti e attivatori accettano entrambe un nuovo campo debug_key a 64 bit (formattato come stringa), che viene compilato dalla tecnologia pubblicitaria. source_debug_key e trigger_debug_key vengono trasmessi invariati sia nei report a livello di evento che in quelli aggregati.

Se viene creato un report con le chiavi di debug di origine e di attivazione, viene inviato un report di debug duplicato con un ritardo limitato a un endpoint .well-known/attribution-reporting/debug/report-event-attribution. I report di debug sono identici ai report normali, inclusi entrambi i campi chiave di debug. L'inclusione di queste chiavi in entrambi consente di collegare i report normali allo stream distinto di report di debug.

• Per i report a livello di evento:
  • I report di debug duplicati vengono inviati con un ritardo limitato e pertanto non vengono suppressed dai limiti agli attivatori disponibili, il che consente all'ad tech di comprendere l'impatto di questi limiti per i report a livello di evento.
  • I report a livello di evento associati a eventi di attivazione falsi non avranno valori trigger_debug_key. In questo modo, la tecnologia pubblicitaria può comprendere più da vicino come viene applicato il rumore nell'API.
• Per i report aggregabili:
  • Supporteremo un nuovo campo debug_cleartext_payload contenente il payload decriptato solo se sono impostati sia source_debug_key sia trigger_debug_key.

Report dettagliati sul debug

I report di debug dettagliati consentono agli sviluppatori di monitorare determinati errori nell'origine di attribuzione o nell'attivazione delle registrazioni. Questi report di debug vengono inviati con un ritardo limitato dopo l'origine dell'attribuzione o l'attivazione delle registrazioni a un canale.Endpoint well-known/attribution-reporting/debug/verbose.

Ogni report dettagliato contiene i seguenti campi:

• Tipo: indica il motivo della generazione del report. Consulta l'elenco completo dei tipi di report dettagliati.
  • In generale, esistono report dettagliati sulle origini e report dettagliati sugli attivatori.
  • I report dettagliati sulle sorgenti richiedono che l'ID pubblicità sia disponibile per l'app publisher, mentre i report dettagliati sugli attivatori richiedono che l'ID pubblicità sia disponibile per l'app inserzionista.
  • I report dettagliati attivati (ad eccezione di trigger-no-matching-source) possono includere facoltativamente source_debug_key. Questo può essere incluso solo se l'ID pubblicità è disponibile anche per l'app del publisher.
• Testo: il testo del report, che dipende dal tipo.

Gli esperti di tecnologia pubblicitaria devono attivare la ricezione di report dettagliati sul debug utilizzando un nuovo campo del dizionario debug_reporting negli intestazioni Attribution-Reporting-Register_Source e Attribution-Reporting-Register-Trigger.

• I report dettagliati sulle origini richiedono l'attivazione solo nell'intestazione di registrazione dell'origine.
• I report di debug degli attivatori richiedono l'attivazione solo nell'intestazione di registrazione dell'attivatore.

Come utilizzare i report di debug

Se è avvenuta una conversione (in base al sistema di misurazione esistente) ed è stato ricevuto un report di debug per la conversione, significa che l'attivatore è stato registrato correttamente.

Per ogni report sull'attribuzione di debug, controlla se ricevi un report sull'attribuzione normale che corrisponde alle due chiavi di debug.

La mancata corrispondenza può essere dovuta a diversi motivi.

Funziona come previsto:

• Comportamenti delle API che tutelano la privacy:
  • Un utente raggiunge il limite di frequenza dei report, pertanto tutti i report successivi non vengono inviati nel periodo di tempo in questione oppure un'origine viene rimossa a causa del limite di destinazione in attesa.
  • Per i report a livello di evento: il report è soggetto a risposte randomizzate (rumore) e viene eliminato oppure potresti ricevere un report randomizzato.
  • Per i report a livello di evento: è stato raggiunto il limite di tre report (per i clic) o uno (per le visualizzazioni) e i report successivi non hanno una priorità esplicita impostata o una priorità inferiore a quella dei report esistenti.
  • I limiti di contributo per i report aggregabili sono stati superati.
• Logica di business definita dalla tecnologia pubblicitaria:
  • Un attivatore viene escluso tramite filtri o regole di priorità.
• Ritardi o interazioni con la disponibilità della rete (ad es. l'utente spegne il dispositivo per un periodo di tempo prolungato).

Cause non intenzionali:

• Problemi di implementazione:
  • L'intestazione dell'origine non è configurata correttamente.
  • L'intestazione dell'attivatore non è configurata correttamente.
  • Altri problemi di configurazione.
• Problemi del dispositivo o della rete:
  • Errori dovuti alle condizioni della rete.
  • La risposta alla registrazione dell'origine o dell'attivatore non raggiunge il client.
  • Bug dell'API.

Considerazioni future e domande aperte

L'API Attribution Reporting è in fase di sviluppo. Stiamo anche valutando potenziali funzionalità future, come i modelli di attribuzione non basata sull'ultimo clic e i casi d'uso di misurazione cross-device.

Inoltre, vorremmo chiedere alla community un feedback su alcuni problemi:

1. Esistono casi d'uso in cui vuoi che l'API invii report per l'installazione verificata? Questi report verranno conteggiati ai fini dei rispettivi limiti di frequenza delle piattaforme di ad tech.
2. Prevedibile difficoltà con il passaggio del InputEvent dall'app alla tecnologia pubblicitaria per la registrazione dell'origine?
3. Hai casi d'uso di attribuzione speciali per app preinstallate o reinstallate?