Panoramica di Attribution Reporting per dispositivi mobili

Nota: questo documento riflette le attuali proposte di design di Privacy Sandbox su Android ed è soggetto a ulteriori modifiche. Incoraggiamo il tuo feedback e i tuoi commenti per contribuire a queste iniziative.

Inviare feedback

Aggiornamenti recenti

• Aggiornato l'elenco delle prossime modifiche e dei problemi noti
• Introduzione della configurazione flessibile a livello di evento come ponte per la configurazione flessibile a livello di evento
• 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 Aggregation Service su Google Cloud. Le tempistiche più specifiche sono riportate qui. Consulta la guida al deployment per ulteriori informazioni sulla configurazione di Aggregation Service con Google Cloud.
• Nuovi limiti di frequenza per la tutela della privacy per il numero di destinazioni univoche.
• La funzionalità aggiornata per i filtri degli attivatori delle finestre temporali sarà disponibile nel primo trimestre del 2024. Per saperne di più, consulta la nota.

Panoramica

Attualmente, le soluzioni di attribuzione e misurazione mobile usano comunemente identificatori tra più parti, 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 nelle app e sul web.

Questa API presenta i seguenti meccanismi strutturali che offrono un framework per migliorare la privacy, descritti in maggiore dettaglio nelle sezioni successive di questa pagina:

• Limita il numero di bit disponibili per i report a livello di evento
• Attiva dati sulle conversioni ad alta fedeltà solo nei report aggregati
• Introduce i limiti di frequenza per gli attivatori disponibili (conversioni) e il numero di tecnologie pubblicitarie che possono essere associati a una singola origine di attribuzione
• Incorpora varie tecniche di aggiunta del rumore

I meccanismi precedenti limitano la possibilità di collegare l'identità utente tra 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 delle conversioni (attivatore) e i valori delle conversioni (attivatore) 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: fornisce report che possono essere utilizzati per il rilevamento e l'analisi di traffico non valido e frodi pubblicitarie.

A livello generale, l'API Attribution Reporting funziona come segue, che vengono descritte più dettagliatamente nelle sezioni successive di questo documento:

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

Nota: per ulteriori informazioni su come implementare questa struttura per un caso d'uso di attribuzione da app ad app, leggi la sezione sull'attribuzione su più reti della Guida per gli sviluppatori dell'API Attribution Reporting. Per scoprire come implementare un caso d'uso da app a web o web ad app, leggi la proposta di progettazione di misurazione cross-app e web.

Ottenere l'accesso alle API Attribution Reporting

Le piattaforme di ad tech devono registrarsi per accedere alle API Attribution Reporting. Consulta Registrazione per un account Privacy Sandbox per ulteriori informazioni.

Registrare un'origine di attribuzione (clic o visualizzazione)

L'API Attribution Reporting fa riferimento ai clic e alle visualizzazioni sugli annunci come origini di attribuzione. Per registrare un clic sull'annuncio o una visualizzazione di annuncio, chiama il numero 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 di attribuzione in una nuova intestazione HTTP Attribution-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 (visualizzazione o clic sull'annuncio). Deve essere un numero intero senza firma a 64 bit formattato come stringa.
• Destinazione: un'origine il cui eTLD+1 o nome del pacchetto dell'app in cui si verifica l'evento attivatore.
• Scadenza (facoltativo): la scadenza, in secondi, relativa al momento in cui l'origine deve essere eliminata dal dispositivo. Il valore predefinito è 30 giorni, con un valore minimo di 1 giorno e un valore massimo di 30 giorni. Questo valore viene arrotondato al giorno più vicino. Può essere formattato come stringa o numero intero senza segno 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 del report sugli eventi è trascorsa, ma la scadenza non è ancora trascorsa, un attivatore può comunque essere abbinato a un'origine, ma non viene inviato un report sugli eventi per questo attivatore. Non può essere superiore alla scadenza. Può essere formattato come stringa o numero intero senza segno a 64 bit.
• Finestra del report aggregato (facoltativo): durata in secondi dopo la registrazione della fonte durante la creazione di report aggregabili per questa fonte. Non può essere superiore alla scadenza. Può essere formattato come stringa o numero intero senza segno a 64 bit.
• Priorità della sorgente (facoltativa): utilizzata per selezionare l'origine di attribuzione a cui deve essere associato un determinato attivatore, nel caso in cui possano essere associate più origini di attribuzione all'attivatore. Deve essere un numero intero a 64 bit con segno formattato come stringa.
  
  Quando viene ricevuto un trigger, l'API trova l'origine di attribuzione corrispondente con il valore di priorità dell'origine più elevato e genera un report. Ogni piattaforma ad tech può definire la propria strategia di priorità. Per ulteriori dettagli su come la priorità influisce sull'attribuzione, consulta la sezione relativa all'esempio di assegnazione delle priorità.
  
  Valori più elevati indicano priorità più elevate.
• (Facoltativo) Finestre di attribuzione per l'installazione e la post-installazione: utilizzata per determinare l'attribuzione per gli eventi post-installazione, descritti più avanti in questa pagina.
• Filtra i dati (facoltativo): utilizzato per filtrare selettivamente alcuni attivatori, ignorandoli effettivamente. Per ulteriori dettagli, consulta la sezione Filtri attivatore in questa pagina.
• Chiavi di aggregazione (facoltative): specifica la segmentazione da utilizzare per i report aggregabili.

Facoltativamente, 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 di origine.

I passaggi seguenti mostrano un flusso di lavoro di esempio:

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

   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 vengono specificati due URL dei partner di tecnologia pubblicitaria, quindi 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 ad tech possono specificare diversi metadati nell'intestazione Attribution-Reporting-Register-Source.

Vengono registrate tre origini di attribuzione (clic) in base alle richieste mostrate nei passaggi precedenti.

Registrare un'origine di attribuzione da WebView

WebView supporta il caso d'uso in cui un'app esegue il rendering di un annuncio in WebView. Ciò viene gestito da WebView che chiama direttamente registerSource() come richiesta in background. Questa chiamata associa l'origine di attribuzione all'app anziché all'origine di primo livello. È supportata anche la registrazione di origini da contenuti web incorporati all'interno di un contesto del browser. Per farlo, sia i chiamanti dell'API che le app devono regolare le impostazioni. Consulta Registrare l'origine dell'attribuzione e attivare da WebView per istruzioni per i chiamanti API e Origine dell'attribuzione e attivazione della registrazione da WebView per istruzioni per le app.

Poiché gli ad tech utilizzano il codice comune per Web e WebView, WebView segue i reindirizzamenti HTTP 302 e passa 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.

Registra un trigger (conversione)

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

Il metodo registerTrigger() prevede il parametro URI dell'attivatore. L'API emette una richiesta a questo URI per recuperare i metadati associati al trigger.

L'API segue i reindirizzamenti. La risposta del server ad tech deve includere un'intestazione HTTP denominata Attribution-Reporting-Register-Trigger, che rappresenta le informazioni su uno o più attivatori registrati. I contenuti dell'intestazione devono essere con codifica JSON e includere i seguenti campi:

• Dati di trigger: dati per identificare l'evento di trigger (3 bit per i clic, 1 bit per le visualizzazioni). Deve essere un numero intero con segno a 64 bit formattato come stringa.
• (Facoltativo) Priorità dell'attivatore: rappresenta la priorità di questo attivatore rispetto ad altri attivatori per la stessa origine di 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 Assegnazione delle priorità.
• Chiave di deduplicazione (facoltativa): utilizzata per identificare i casi in cui lo stesso attivatore viene registrato più volte dalla stessa piattaforma di tecnologia pubblicitaria, per la stessa origine di attribuzione. Deve essere un numero intero con segno a 64 bit formattato come stringa.
• Chiavi di aggregazione (facoltative): un elenco di dizionari che specificano le chiavi di aggregazione e report aggregabili devono avere il valore aggregato.
• Valori di aggregazione (facoltativo): un elenco di quantità di valori che contribuiscono a ogni chiave.
• Filtri (facoltativi): utilizzati per filtrare selettivamente gli attivatori o i dati degli attivatori. Per ulteriori dettagli, consulta la sezione Filtri attivatore in questa pagina.

Facoltativamente, 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ù ad tech di registrare una richiesta.

Più tecnici pubblicitari possono registrare lo stesso evento di trigger utilizzando reindirizzamenti nel campo Attribution-Reporting-Redirect o più chiamate al metodo registerTrigger(). Ti consigliamo di utilizzare il campo chiave di deduplicazione 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 del trigger.

I passaggi seguenti mostrano un flusso di lavoro di esempio:

1. L'SDK AdTech chiama l'API per avviare la registrazione del trigger utilizzando un URI preregistrato. Per ulteriori informazioni, consulta Registrare 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 è specificato un solo URL, quindi 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"
   }]
   }
   

   Due attivatori vengono registrati in base alle richieste nei passaggi precedenti.

Funzionalità di attribuzione

Le seguenti sezioni spiegano in che modo l'API Attribution Reporting associa gli attivatori di conversione alle origini di attribuzione.

Algoritmo di attribuzione della priorità per le fonti applicato

L'API Attribution Reporting utilizza un algoritmo di attribuzione prioritario della sorgente per associare un attivatore (conversione) a un'origine di attribuzione.

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

• Puoi attribuire gli attivatori a determinati eventi annuncio rispetto ad altri. Ad esempio, potresti scegliere di porre maggiore enfasi sui clic anziché sulle visualizzazioni oppure sugli eventi di determinate campagne.
• Puoi configurare l'origine dell'attribuzione e l'attivazione in modo che, se raggiungi i limiti di frequenza, hai maggiori probabilità di ricevere i report più importanti per te. Ad esempio, potresti voler fare in modo che le conversioni disponibili o le conversioni di valore elevato abbiano maggiori probabilità di comparire in questi report.

Nel caso in cui più tecnologie pubblicitarie registrano un'origine dell'attribuzione, come descritto più avanti in questa pagina, questa attribuzione avviene in modo indipendente per ogni tecnologia pubblicitaria. Per ogni tecnologia pubblicitaria, all'evento di attivazione viene attribuita l'origine dell'attribuzione con la priorità più alta. Se ci sono più origini di attribuzione con la stessa priorità, l'API sceglie l'ultima origine di attribuzione registrata. Tutte le altre origini di attribuzione che non vengono selezionate vengono eliminate e non sono più idonee per l'attribuzione dell'attivatore futura.

Filtri attivatore

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

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

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

Un altro scenario in cui le piattaforme di ad tech possono filtrare selettivamente gli attivatori è quello di forzare una finestra di scadenza più breve. Al momento della registrazione dell'attivatore, una tecnologia pubblicitaria può specificare (in secondi) una finestra temporale dal momento in cui si è verificata la conversione. Ad esempio, una finestra temporale di 7 giorni potrebbe essere definita come: "_lookback_window": 604800 // 7d

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

Nota: la logica e la funzionalità del filtro temporale descritte saranno in vigore nel T124. Puoi trovare informazioni più dettagliate sulle tempistiche di uscita. La logica precedente richiedeva che le finestre temporali fossero specificate all'ora, sia sul lato di origine sia sul lato trigger. Questa logica delle funzionalità aggiornata è incompatibile con le versioni precedenti, pertanto le origini che utilizzano la precedente chiave "_lookback_window" 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 del trigger, è possibile impostare trigger_data come un valore per "source_type": ["navigation"] e come un valore diverso per "source_type": ["event"].

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

• Nessun trigger_data specificato.
• 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 che per i report aggregabili.

Attribuzione post-installazione

In alcuni casi, è necessario che gli attivatori post-installazione vengano attribuiti alla stessa origine di attribuzione che ha generato l'installazione, anche se esistono altre origini di attribuzione idonee che si sono verificate più di recente.

L'API può supportare questo caso d'uso consentendo ai tecnici pubblicitari di impostare un periodo di attribuzione post-installazione:

• Quando registri un'origine di attribuzione, specifica una finestra di attribuzione delle installazioni durante la quale sono previste installazioni (generalmente 2-7 giorni, intervallo accettato da 1 a 30 giorni). Specifica questa finestra temporale come un numero di secondi.
• Quando registri un'origine di attribuzione, specifica una finestra di esclusione di attribuzione post-installazione in cui tutti gli eventi di trigger post-installazione devono essere associati all'origine di attribuzione che ha generato l'installazione (generalmente 7-30 giorni, intervallo accettato da 0 a 30 giorni). Specifica questa finestra temporale come numero di secondi.
• L'API Attribution Reporting convalida quando si verifica un'installazione di app e attribuisce internamente l'installazione all'origine di attribuzione assegnata alla priorità dell'origine. Tuttavia, l'installazione non viene inviata agli ad tech e non viene conteggiata nei rispettivi limiti di frequenza delle piattaforme.
• La convalida dell'installazione delle app è disponibile per qualsiasi app scaricata.
• Tutti gli attivatori futuri che si verificano nella finestra di attribuzione post-installazione vengono attribuiti alla stessa origine di attribuzione dell'installazione convalidata, a condizione che l'origine dell'attribuzione sia idonea.

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

La seguente tabella 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 le stesse.

Evento	Giorno in cui si verifica l'evento	Note
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, che però non sono considerate attivatori. Pertanto, al momento non viene inviato alcun report.
Attivatore 1 (prima apertura)	2	Primo attivatore registrato dalla tecnologia pubblicitaria. In questo esempio, rappresenta una prima apertura, ma può essere di qualsiasi tipo. Attribuita al clic 1 (corrisponde all'attribuzione di installazione verificata).
Fai clic 2	4	Utilizza gli stessi valori di install_attribution_window e post_install_exclusivity_window di Clic 1
Trigger 2 (post-installazione)	5	Secondo attivatore registrato dalla tecnologia pubblicitaria. In questo esempio, rappresenta una conversione post-installazione come un acquisto. Attribuita al clic 1 (corrisponde all'attribuzione di installazione verificata). Il clic 2 viene ignorato e non è idoneo per l'attribuzione futura.

Il seguente elenco fornisce alcune note aggiuntive relative all'attribuzione post-installazione:

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

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 attivazione su un singolo dispositivo Android:

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

Consentiamo ai browser web di supportare nuove funzionalità esposte al web, ad esempio una funzionalità simile a Privacy Sandbox per l'API Attribution Reporting del web, che può chiamare le API Android per attivare l'attribuzione nelle app e sul web.

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

Assegnare la priorità a più attivatori per una singola origine dell'attribuzione

Una singola origine di attribuzione può generare più attivatori. Ad esempio, un flusso di acquisto potrebbe includere un attivatore "installazione di app", uno o più attivatori "add-to-cart" e un attivatore "acquisto". Ogni attivatore viene attribuito a una o più origini di attribuzione in base all'algoritmo di attribuzione prioritario delle fonti, descritto più avanti in questa pagina.

Esistono limiti al numero di attivatori che possono essere attribuiti a una singola origine di attribuzione. Per ulteriori dettagli, consulta la sezione Visualizzare i dati di misurazione nei report sull'attribuzione più avanti in questa pagina. Nei casi in cui sono presenti più trigger oltre questi limiti, è utile introdurre la logica di prioritizzazione per recuperare quelli di maggior valore. Ad esempio, gli sviluppatori di una tecnologia pubblicitaria potrebbero voler dare la priorità all'attivazione di attivatori di tipo "acquisto" rispetto a quelli di "aggiunta al carrello".

Per supportare questa logica, è possibile impostare un campo di priorità separato per l'attivatore e quelli con priorità più alta vengono scelti prima dell'applicazione dei limiti, all'interno di una determinata finestra di report.

Nota: gli attivatori a priorità più bassa che sono già stati segnalati consumano sempre il budget.

Consenti a più tecnologie pubblicitarie di registrare le origini o gli attivatori di attribuzione

È frequente che più di una tecnologia pubblicitaria riceva i report sull'attribuzione, in genere per eseguire la deduplicazione su più reti. Pertanto, l'API consente a più tecnici pubblicitari di registrare la stessa origine o lo stesso attivatore. Una 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 e gli attivatori di attribuzione registrati nell'API.

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

• Configurazione di un server interno per la registrazione e la ricezione di report dall'API.
• Continuare a utilizzare un partner esistente di misurazione per i dispositivi mobili.

Origini di 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 di URL di reindirizzamento di tecnologia pubblicitaria dei partner.
2. L'API chiama quindi gli URL di reindirizzamento in modo che l'origine dell'attribuzione possa essere registrata dai tecnici pubblicitari partner.

Più URL di tecnologie pubblicitarie dei partner possono essere elencati nel campo Attribution-Reporting-Redirect, mentre i tecnici pubblicitari partner non possono specificare il proprio campo Attribution-Reporting-Redirect.

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

Trigger

Per la registrazione del trigger, le terze parti sono supportate in modo simile: gli ad tech possono utilizzare il campo Attribution-Reporting-Redirect aggiuntivo oppure possono chiamare il metodo registerTrigger() ciascuna.

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

Gestire gli attivatori duplicati

Una tecnologia pubblicitaria può registrare lo stesso attivatore più volte con l'API. Ecco alcuni scenari:

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

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

Metodo consigliato: chiave di deduplicazione

Il metodo consigliato prevede che l'app dell'inserzionista trasmetta una chiave di deduplicazione univoca a tutti gli SDK o tecnologie pubblicitarie che utilizza per la misurazione delle conversioni. Quando si verifica una conversione, l'app passa una chiave di deduplicazione agli SDK o ai tecnici pubblicitari. Questi tecnici pubblicitari o SDK continuano a trasmettere la chiave di deduplicazione ai reindirizzamenti utilizzando un parametro negli URL specificati in Attribution-Reporting-Redirect.

I tecnici pubblicitari possono decidere di registrare solo il primo attivatore con una determinata chiave di deduplicazione oppure di registrare più attivatori o tutti. I tecnici pubblicitari possono specificare deduplication_key durante la registrazione degli attivatori duplicati.

Se una tecnologia pubblicitaria registra più attivatori con la stessa chiave di deduplicazione 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: i tecnici pubblicitari concordano i tipi di attivatori per singolo inserzionista

Nei casi in cui i tecnici pubblicitari non vogliono utilizzare la chiave di deduplicazione o in cui l'app dell'inserzionista non può passare una chiave di deduplicazione, esiste un'opzione alternativa. Tutti gli ad tech che misurano le conversioni per un determinato inserzionista devono collaborare per definire i diversi tipi di attivatori per ciascun inserzionista.

I tecnici pubblicitari che avviano la chiamata di registrazione dell'attivatore, ad esempio gli SDK, includono un parametro negli URL specificati in Attribution-Reporting-Redirect, come duplicate_trigger_id. Questo parametro duplicate_trigger_id può includere informazioni come il nome dell'SDK e il tipo di attivatore per l'inserzionista. I tecnici pubblicitari possono quindi inviare un sottoinsieme di questi attivatori duplicati ai report a livello di evento. I tecnici pubblicitari possono anche includere questo duplicate_trigger_id nelle loro 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, le tecnologie pubblicitarie A, B e MMP devono completare ciascuna registrazione per utilizzare l'API Attribution Reporting. Per ulteriori informazioni, consulta Registrare un account Privacy Sandbox.

Il seguente elenco fornisce un'ipotetica serie di azioni utente che si verificano ciascuna a un giorno di distanza e in che modo l'API Attribution Reporting gestisce queste azioni in relazione a tecnologia pubblicitaria A, tecnologia pubblicitaria B e MMP:

Giorno 1: l'utente fa clic su un annuncio pubblicato da Ad tech A

Ad tech 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 di AdTech A.

L'ad tech A include anche l'URI di MMP nell'intestazione Attribution-Reporting-Redirect. L'API effettua una richiesta all'URI di MMP e il clic viene registrato con i metadati della risposta del server di MMP.

Giorno 2: l'utente fa clic su un annuncio pubblicato da Ad tech B

Ad tech 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 AdTech B.

Come la tecnologia pubblicitaria A, anche quella B ha incluso l'URI di MMP nell'intestazione Attribution-Reporting-Redirect. L'API invia una richiesta all'URI di MMP e il clic viene registrato con i metadati della risposta del server di MMP.

Giorno 3: l'utente visualizza un annuncio pubblicato da Ad tech A

L'API risponde come nel primo giorno, ad eccezione del fatto che una visualizzazione viene registrata per AdTech A e MMP.

Giorno 4: l'utente installa l'app, che utilizza la soluzione MMP per la misurazione delle conversioni

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

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

Il seguente diagramma illustra il processo descritto nell'elenco precedente:

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

L'attribuzione funziona nel seguente modo:

• Ad tech A imposta la priorità dei clic più alta rispetto alle visualizzazioni e, di conseguenza, riceve l'installazione attribuita al clic del giorno 1.
• La tecnologia pubblicitaria B riceve l'installazione attribuita il secondo giorno.
• MMP imposta la priorità dei clic superiore alle visualizzazioni e ottiene l'installazione attribuita al clic del secondo giorno. Il clic del giorno 2 corrisponde all'evento annuncio più recente con priorità più elevata.

Attribuzione su più reti senza reindirizzamenti

Consigliamo di utilizzare i reindirizzamenti per consentire a più tecnici pubblicitari di registrare le origini e gli attivatori di attribuzione, ma siamo consapevoli che potrebbero verificarsi situazioni in cui l'utilizzo dei reindirizzamenti non è possibile. Questa sezione descrive in dettaglio come supportare l'attribuzione su più reti senza reindirizzamenti.

Flusso di alto livello

1. Al momento della registrazione della sorgente, la rete di tecnologia pubblicitaria per la pubblicazione condivide le proprie chiavi di aggregazione della sorgente.
2. Al momento della registrazione dell'attivatore, l'inserzionista o il partner di misurazione sceglie le parti chiave lato origine da utilizzare e specifica la propria configurazione di attribuzione.
3. L'attribuzione si basa sulla configurazione dell'attribuzione, sulle chiavi condivise e su qualsiasi origine effettivamente registrata dall'inserzionista o dal partner di misurazione in questione (ad es. da un'altra rete di tecnologia pubblicitaria pubblicata che ha attivato i reindirizzamenti).
4. Se l'attivatore viene attribuito a una fonte proveniente da una tecnologia pubblicitaria che non prevede reindirizzamenti, l'inserzionista o il partner di misurazione può ricevere un report aggregabile che combina la fonte e attivano gli elementi chiave definiti nel passaggio 2.

Registrazione origine

Al momento della registrazione dell'origine, la rete di tecnologia pubblicitaria pubblicata può scegliere di condividere le proprie chiavi di aggregazione dell'origine o un sottoinsieme di chiavi di aggregazione dell'origine anziché reindirizzare l'utente. La tecnologia pubblicitaria pubblicata 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 trigger per lo stesso inserzionista. Tuttavia, spetta alla tecnologia pubblicitaria pubblicata e alla tecnologia pubblicitaria di misurazione degli attivatori collaborare su quali tipi di chiavi di aggregazione sono necessarie, sui loro nomi e su come decodificare le chiavi in dimensioni leggibili.

Attiva la registrazione

Al momento della registrazione dell'attivatore, la tecnologia pubblicitaria di misurazione sceglie quali elementi chiave lato origine applicare a ciascun elemento chiave dell'attivatore, inclusi quelli condivisi dalle tecnologie pubblicitarie.

Inoltre, la tecnologia pubblicitaria di misurazione deve specificare anche la logica di attribuzione della struttura a cascata utilizzando una nuova chiamata API della configurazione di attribuzione. In questa configurazione, la tecnologia pubblicitaria può specificare la priorità dell'origine, la scadenza e i filtri per le origini per le quali non aveva visibilità (ad esempio, le origini che non hanno utilizzato un reindirizzamento).

Attribuzione

L'API Attribution Reporting esegue l'attribuzione dell'ultimo touchpoint con priorità all'origine per la tecnologia pubblicitaria di misurazione, in base alla configurazione di attribuzione, alle chiavi condivise e alle origini registrate. Ad esempio:

• L'utente ha fatto clic sugli annunci pubblicati dalle tecnologie pubblicitarie A, B, C e D. L'utente ha quindi installato l'app dell'inserzionista, che utilizza un partner di tecnologia pubblicitaria (MMP) di misurazione.
• Ad tech A reindirizza le sue origini a MMP.
• Le tecnologie pubblicitarie B e C non eseguono il reindirizzamento, ma condividono le proprie chiavi di aggregazione.
• Ad tech D non reindirizza né condivide chiavi di aggregazione.

MMP registra una sorgente dalla tecnologia pubblicitaria A e definisce una configurazione di attribuzione che include tecnologia pubblicitaria B e tecnologia pubblicitaria D.

L'attribuzione per la MMP ora include:

• Ad tech A, dato che l'MMP ha registrato una fonte dal reindirizzamento di quella tecnologia pubblicitaria.
• Ad tech B, dato che la tecnologia pubblicitaria B ha condiviso le chiavi e l'MMP le includeva nella sua configurazione di attribuzione.

L'attribuzione per il modello MMP non include:

• Ad tech C, dato che il MMP non l'ha incluso nella configurazione dell'attribuzione.
• Ad tech D, dato che non ha reindirizzato né condiviso chiavi di aggregazione.

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

Debug

Per supportare il debug dell'attribuzione su più reti senza reindirizzamenti, i tecnici pubblicitari possono impostare un campo aggiuntivo, shared_debug_key, al momento della registrazione dell'origine. Se impostato sulla registrazione della sorgente originale, verrà impostato anche sulla corrispondente sorgente derivata come debug_key durante la registrazione dell'attivatore per l'attribuzione su più reti senza reindirizzamenti. Questa chiave di debug è collegata come source_debug_key nei report aggregati e sugli eventi.

Questa funzionalità di debug sarà supportata per l'attribuzione su più reti senza reindirizzamenti solo nei seguenti scenari:

• Misurazione da app a app dove è consentito AdId
• Misurazione da app a web in cui l'ID annuncio è consentito e la corrispondenza tra l'origine app e l'attivatore web
• Misurazione da web a web (nella stessa app del browser) quando ar_debug" è presente sia nell'origine che nell'attivatore

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

Il rilevamento delle chiavi ha lo scopo di semplificare il modo in cui le tecnologie pubblicitarie (di solito i MMP) implementano la configurazione di attribuzione per l'attribuzione su più reti quando una o più tecnologie pubblicitarie pubblicate utilizzano chiavi di aggregazione condivise (come descritto nella sezione Attribuzione su più reti senza reindirizzamenti sopra).

Quando un MMP esegue una query su Aggregation Service per generare report di riepilogo per le campagne che includono origini derivate, Aggregation Service richiede che l'MMP specifichi l'elenco di possibili chiavi come input per il job di aggregazione. In alcuni casi, l'elenco di potenziali chiavi di aggregazione delle origini potrebbe essere molto lungo o sconosciuto. lunghi elenchi di possibili chiavi sono difficili da rintracciare e probabilmente saranno piuttosto complessi e costosi da elaborare. Considera i seguenti esempi:

• L'elenco di tutte le chiavi possibili è di grandi dimensioni:
  • Una rete pubblicitaria per la pubblicazione esegue un'iniziativa complessa di acquisizione utenti che include 20 campagne, ognuna con 10 gruppi di annunci e ogni gruppo di annunci con 5 creatività che vengono aggiornate ogni settimana in base al rendimento.
• L'elenco di tutte le chiavi possibili è sconosciuto:
  • Una rete pubblicitaria pubblicata sta pubblicando annunci su molte app mobile per cui l'elenco completo degli ID app del publisher non è noto al momento del lancio della campagna.
  • Un inserzionista sta lavorando su più reti pubblicitarie pubblicate che non reindirizzano alla MMP al momento della registrazione dell'origine; ciascuna rete pubblicitaria pubblicata ha una struttura di chiavi e valori diversi, che non possono essere condivisi in anticipo con MMP.

Con l'introduzione del rilevamento chiave:

• Aggregation Service 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 set di chiavi vuoto (o parzialmente vuoto) e impostare una soglia in modo che nell'output vengano incluse solo le chiavi (non predichiarate) con valori che superano la soglia.
• MMP riceve un report di riepilogo che include valori di rumore per le chiavi che hanno contribuito a valori superiori alla soglia impostata. Il report può anche includere chiavi a cui non è associato un contributo reale degli utenti e che presentano un semplice rumore.
• MMP utilizza il campo x_network_bit_mapping nella registrazione del trigger per determinare quale tecnologia pubblicitaria corrisponde a quale chiave.
• MMP può quindi contattare la tecnologia pubblicitaria appropriata per la pubblicazione per comprendere i valori nella chiave di origine.

In sintesi, il rilevamento delle chiavi consente agli MMP di ottenere le chiavi di aggregazione senza conoscerle in anticipo, evitando di elaborare un volume elevato di chiavi di origine a scapito del rumore aggiuntivo.

Nota :questa funzionalità è nella fase di proposta e non è ancora disponibile per il test. Ti invitiamo a fornire feedback e commenti.

Visualizzare i dati di misurazione nei report sull'attribuzione

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

• I report a livello di evento associano una determinata origine di attribuzione (clic o visualizzazione) a bit limitati di dati dell'attivatore ad alta fedeltà.
• I report aggregati non sono necessariamente legati a una specifica origine di attribuzione. Questi report forniscono dati dei trigger più completi e ad alta affidabilità rispetto ai report a livello di evento, ma questi dati 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 viene attribuito a un'origine di attribuzione, viene generato e archiviato un report a livello di evento sul dispositivo finché non può essere inviato di nuovo all'URL postback di ogni ad tech durante una delle finestre temporali per l'invio dei report, descritte più dettagliatamente in seguito in questa pagina.

I report a livello di evento sono utili quando sono necessarie pochissime informazioni sull'attivatore. I dati dei trigger a livello di evento sono limitati a 3 bit di dati di trigger per i clic, il che significa che a un attivatore può essere assegnata una delle otto categorie e 1 bit per le viste. Inoltre, i report a livello di evento non supportano la codifica di dati lato trigger ad alta fedeltà, come un prezzo o una data di attivazione specifici. Poiché l'attribuzione avviene sul dispositivo, non è supportata 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 eTLD+1 in cui si è verificato l'attivatore
• ID origine attribuzione: lo stesso ID origine dell'attribuzione utilizzato per registrare un'origine dell'attribuzione
• Tipo di trigger: 1 o 3 bit di dati del trigger a bassa fedeltà, a seconda del tipo di origine dell'attribuzione

Meccanismi che tutelano la privacy applicati a tutte le segnalazioni

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

Limiti al numero di tecnologie pubblicitarie

Esistono dei limiti al numero di tecnologie pubblicitarie che possono registrare o ricevere report dall'API, con una proposta corrente di quanto segue:

• 100 ad tech con origini di attribuzione per {source app, destination app, 30 days, device}.
• 10 tecnologie pubblicitarie con attivatori attribuiti per {app di origine, app di destinazione, 30 giorni, dispositivo}.
• 20 tecnici pubblicitari possono registrare una singola origine o attivatore di attribuzione (tramite Attribution-Reporting-Redirect)

Limiti al numero di destinazioni univoche

Questi limiti rendono difficile per un insieme di ad tech eseguire query su un numero elevato di app per comprendere il comportamento di utilizzo delle app di un determinato utente.

• L'API supporta non più di 200 destinazioni univoche al minuto, per app di origine e per tutte le origini registrate, e per tutte le tecnologie pubblicitarie.
• Su 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 l'intero budget del limite di frequenza indicato 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 di tecnologia pubblicitaria può utilizzare una sola origine report per registrare le fonti nell'app di un publisher, per un determinato dispositivo, nello stesso giorno. Questo limite di frequenza impedisce agli ad tech di utilizzare più origini dei report per accedere a un budget aggiuntivo per la privacy.

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

1. L'origine dei report 1 di AdTech A registra una sorgente nell'app B
2. 12 ore dopo, l'origine report di AdTech A 2 tenta di registrare un'origine nell'app B

La seconda fonte, per l'origine report 2 di AdTech A, verrebbe rifiutata dall'API. L'origine report 2 di AdTech A non sarebbe riuscita a registrare un'origine sullo stesso dispositivo nell'app B fino al giorno successivo.

Limiti di attesa e raffreddamento

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

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

Numero di destinazioni univoche

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

L'attuale proposta è di limitare ogni tecnologia pubblicitaria a 100 destinazioni distinte con origini non scadute per app di origine.

Meccanismi che tutelano la privacy applicati ai report a livello di evento

Fedeltà limitata dei dati del trigger

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

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

Framework per il rumore di privacy differenziale

Un obiettivo di questa API è consentire alla misurazione a livello di evento di soddisfare i requisiti di privacy differenziale locali utilizzando risposte k-randomizzate per generare un output rumore per ogni evento di origine.

Il rumore viene applicato se un evento di origine dell'attribuzione viene segnalato in modo veritiero. Sul dispositivo viene registrata un'origine di attribuzione con una probabilità di 1 $ a p $ che l'origine dell'attribuzione sia registrata normalmente e con probabilità che il dispositivo scelga in modo casuale tra tutti i possibili stati di output dell'API (inclusa la mancata segnalazione o la segnalazione di più segnalazioni false).

La risposta k-randomizzata è un algoritmo epsilon differenzialmente privato se viene soddisfatta la seguente equazione:

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

Per i valori bassi di Park, l'output reale è protetto dal meccanismo di risposta casuale con k. I parametri del rumore esatto sono in fase di sviluppo e sono soggetti a modifica in base al feedback, con una proposta corrente di quanto segue:

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

Limiti sugli attivatori disponibili (conversioni)

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

• 1-2 attivatori per le origini di attribuzione visualizzazione annuncio (2 attivatori disponibili solo in caso di attribuzione post-installazione)
• Tre attivatori per le origini di attribuzione degli annunci dei clic

Nota: questo descrive il comportamento predefinito dell'API per il numero di attribuzioni per origine utilizzando i report a livello di evento. Con l'introduzione dei report flessibili a livello di evento nell'ottobre 2023, gli ad tech possono ora 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 visualizzazione annuncio vengono inviati un'ora dopo la scadenza della sorgente. Questa data di scadenza può essere configurata, ma non può essere inferiore a 1 giorno o superiore a 30 giorni. Se due attivatori vengono attribuiti a un'origine di attribuzione della visualizzazione di annunci (tramite l'attribuzione post-installazione), i report a livello di evento possono essere inviati agli intervalli della finestra di report specificati come segue.

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 registrazione dell'origine. Il tempo che intercorre tra l'origine e la scadenza dell'attribuzione viene suddiviso in più finestre di report. Ogni finestra del report ha una scadenza (dalla data e ora dell'origine dell'attribuzione). Al termine di ogni finestra di segnalazione, il dispositivo raccoglie tutti gli attivatori che si sono verificati dopo la finestra precedente e invia un report pianificato. L'API supporta le seguenti finestre di reporting:

• 2 giorni: il dispositivo raccoglie tutti gli attivatori che si sono verificati al massimo due giorni dopo la registrazione dell'origine dell'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 dell'attribuzione. Il report viene inviato sette giorni e un'ora dopo la registrazione dell'origine dell'attribuzione.
• Un periodo di tempo personalizzato definito dall'attributo "scadenza" di un'origine di attribuzione. Il report viene inviato un'ora dopo la data di scadenza specificata. Questo valore non può essere inferiore a 1 giorno o superiore a 30 giorni.

Nota: questo descrive il comportamento predefinito dell'API per le finestre di report a livello di evento. Con l'introduzione dei report flessibili a livello di evento nell'ottobre 2023, gli ad tech possono ora configurare questa dimensione dei report in base a ciò che funziona meglio per il loro caso d'uso.

Configurazione flessibile a livello di evento

La configurazione predefinita per i report a livello di evento è quella che consigliamo agli ad tech di iniziare a utilizzare quando iniziano i test dell'utilità, ma potrebbe non essere la soluzione ideale per tutti i casi d'uso. L'API Attribution Reporting supporterà configurazioni facoltative e più flessibili, in modo che gli ad tech possano avere un maggiore controllo sulla struttura dei loro 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 a livello di evento flessibile 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

Puoi utilizzare la fase 1 (livello evento Lite flessibile) per:

• Varia la frequenza dei report specificando il numero di finestre di report.
• Variare il numero di attribuzioni per registrazione di origine
• Riduci la quantità di rumore totale diminuendo i parametri precedenti
• Configura le finestre di reporting anziché utilizzare le impostazioni predefinite

Puoi utilizzare la fase 2 (livello di evento completamente flessibile) per svolgere tutte le funzionalità della fase 1 e:

• Variare la cardinalità dei dati del trigger in un report
• Riduci la quantità di rumore totale diminuendo la cardinalità dei dati del trigger

La riduzione di una dimensione della configurazione predefinita consente all'ad tech di aumentarne un'altra. In alternativa, la quantità totale di rumore in un report a livello di evento può essere ridotta diminuendo nettamente i parametri indicati sopra.

Oltre a impostare dinamicamente i livelli di rumore in base alla configurazione scelta da un ad tech, avremo alcuni limiti di parametri per evitare grandi costi di calcolo e configurazioni con troppi stati di output (dove il rumore aumenterà notevolmente). Ecco un esempio di insieme di limitazioni. È incoraggiato un feedback sulla [proposta di progettazione][50]:

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

Poiché gli ad tech iniziano a utilizzare questa funzionalità, tieni presente che l'utilizzo di valori estremi potrebbe causare un'elevata quantità di rumore o la mancata registrazione se i livelli di privacy non vengono soddisfatti.

Nota: la fase 1 (livello evento flessibile Lite) è stata rilasciata in versione beta ad ottobre 2023. La fase 2 (a livello di evento completamente flessibile) sarà disponibile in versione beta entro la fine del primo trimestre del 2024.

Report aggregati

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

I report aggregati forniscono dati sui trigger più affidabili dal dispositivo e più rapidamente, più velocemente rispetto ai report a livello di evento. Questi dati ad alta fedeltà possono essere appresi solo in aggregato e non sono associati a un determinato attivatore o utente. Le chiavi di aggregazione hanno una lunghezza massima di 128 bit e ciò consente di generare report aggregabili per supportare i casi d'uso dei report come i seguenti:

• Report sui valori degli attivatori, come le entrate
• Gestione di più tipi di trigger

Inoltre, i report aggregabili utilizzano la stessa logica di attribuzione assegnata alla priorità delle fonti dei report a livello di evento, ma supportano più conversioni attribuite a un clic o a una visualizzazione.

Il design generale del modo in cui l'API Attribution Reporting prepara e invia report aggregabili, mostrati nel diagramma, è il seguente:

1. Il dispositivo invia report aggregabili criptati alla tecnologia pubblicitaria. In un ambiente di produzione, i tecnici pubblicitari 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 all'ad tech in un report di riepilogo.

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

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

• Destination: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: attiva i valori, raccolti come coppie chiave/valore criptate, che vengono utilizzati nel servizio di aggregazione attendibile per calcolare le aggregazioni.

Servizi di aggregazione

I seguenti servizi offrono funzionalità di aggregazione e aiutano a proteggere da accessi inappropriati ai dati di aggregazione.

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

• Il servizio di aggregazione è l'unico di cui i tecnici pubblicitari dovrebbero eseguire il deployment.
• I servizi di gestione delle chiavi e di contabilità dei report aggregabili sono gestiti da soggetti attendibili chiamati 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 sono applicati gli stessi servizi di contabilità dei report aggregabili e delle chiavi.

Servizio di aggregazione

Le piattaforme di tecnologia pubblicitaria devono, in anticipo, eseguire il deployment di un servizio di aggregazione basato sui file binari forniti da Google.

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

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

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

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

Key Management Service

Questo servizio verifica che un servizio di aggregazione stia eseguendo una versione approvata del programma binario, quindi fornisce al servizio di aggregazione nella tecnologia pubblicitaria le chiavi di decriptazione corrette per i dati degli attivatori.

Contabilità dei report aggregati

Questo servizio monitora la frequenza con cui il servizio di aggregazione di una tecnologia pubblicitaria accede a un trigger specifico, che può contenere più chiavi di aggregazione, e limita l'accesso al numero appropriato di decriptazioni. 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 seguenti sezioni descrivono le estensioni dell'API.

Registra i dati della fonte aggregabile

Quando l'API invia una richiesta all'URI dell'origine dell'attribuzione, l'ad tech può registrare un elenco di chiavi di aggregazione, denominato histogram_contributions, rispondendo con un nuovo campo chiamato aggregation_keys nell'intestazione HTTP Attribution-Reporting-Register-Source, con la chiave come key_name e il valore key_piece:

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

La chiave del bucket dell'istogramma finale è completamente definita al momento del trigger eseguendo un'operazione OR binaria su questi componenti e su quelli lato trigger.

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

Scopri di più su come sono strutturate le chiavi di aggregazione e su come configurarle.

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

• Aggregazione dei conteggi delle conversioni a livello di campagna
• Aggregare valori di acquisto 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 il trigger aggregabile

La registrazione del trigger include due campi aggiuntivi.

Il primo campo viene utilizzato per registrare un elenco di chiavi aggregate sul lato trigger. 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:

• Elemento chiave: un valore di stringa di bit per la chiave.
• Chiavi di origine:un elenco di stringhe con i nomi delle chiavi laterali 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 ciascuna 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 ciascuna chiave, che possono essere numeri interi compresi nell'intervallo $ [1, 2^{16}] $.

Ogni attivatore può fornire più contributi ai report aggregabili. La quantità totale di contributi a un determinato evento di origine è vincolata da un parametro L1 $, che corrisponde alla somma massima di contributi (valori) in tutte le chiavi aggregate per una determinata origine. L1 $ si riferisce alla sensibilità o alla norma L1 dei contributi all'istogramma per evento di origine. Il superamento di questi limiti comporta l'interruzione silenziosa dei contributi futuri. La proposta iniziale è di impostare $ L1 $ su 2^{16} $ (65536).

Il rumore nel servizio di aggregazione viene ridimensionato in proporzione a questo parametro. Di conseguenza, ti consigliamo di scalare in modo appropriato i valori segnalati per una determinata chiave aggregata, in base alla porzione di budget di L1 $ che le è stata assegnata. Questo approccio aiuta a garantire che i report aggregati conservino la massima fedeltà possibile quando viene applicato il rumore. Questo meccanismo è altamente flessibile e può supportare molte strategie di aggregazione.

Nel seguente esempio, il budget per la privacy è suddiviso equamente tra campaignCounts e geoValue suddividendo il contributo di L1 $ in ogni parte:

// 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 applica comunque ai report aggregabili e a ogni dizionario in aggregatable_trigger_data può essere comunque eventualmente applicati filtri di conversione, proprio come i filtri attivatori per i report a livello di evento.

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

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

Privacy differenziale

Un obiettivo di questa API è avere un framework in grado di supportare la misurazione aggregata in modo differenziato privato. Per ottenere questo risultato, aggiungi un 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 cross-API tra le API Protected Audience e Attribution Reporting consente alle tecnologie pubblicitarie di valutare il rendimento dell'attribuzione in varie tattiche di remarketing al fine di capire quali tipi di segmenti di pubblico generano il ROI più elevato.

Grazie a questa integrazione tra API, le tecnologie pubblicitarie possono:

• Crea una mappa chiave-valore degli URI da utilizzare per i report sulle interazioni 1) e per la registrazione dell'origine.
• Includi CustomAudience nella mappatura delle chiavi lato origine 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 segnalare queste interazioni tramite Protected Audience verrà anche usato per registrare una visualizzazione o un clic come origine idonea con l'API Attribution Reporting.
• La tecnologia pubblicitaria può scegliere di trasmettere CustomAudience (o altre informazioni contestuali pertinenti sull'annuncio, come il posizionamento dell'annuncio o la durata di visualizzazione) utilizzando quell'URL, in modo che i metadati possano propagarsi ai report di riepilogo quando la tecnologia pubblicitaria esamina il rendimento aggregato della campagna.

Per ulteriori informazioni su come attivare questa funzionalità in Protected Audience, consulta la sezione pertinente del messaggio esplicativo dell'API Protected Audience.

Priorità di registrazione, attribuzione ed esempi di report

Questo esempio mostra un insieme di interazioni degli utenti e il modo in cui l'origine di attribuzione definita dalla tecnologia pubblicitaria e le priorità di attivazione potrebbero influire sui report attribuiti. In questo esempio, supponiamo che:

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

Considera il caso in cui un utente:

1. L'utente vede un annuncio. Ad tech registra un'origine di attribuzione con l'API, con una priorità di 0 (vista n. 1).
2. L'utente vede un annuncio registrato con priorità 0 (vista n. 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).
   • Man mano che gli attivatori sono registrati, l'API esegue l'attribuzione prima di generare report.
   • Sono disponibili 3 origini di attribuzione: vista n. 1, vista n. 2 e clic n. 1. L'API attribuisce questo trigger al clic n. 1 perché è la priorità più alta e più recente.
   • La vista n. 1 e la vista n. 2 vengono ignorate e non sono più idonee per le attribuzioni future.
5. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con una priorità di 1 (conversione n. 2).
   • Il clic n. 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic n. 1.
6. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con una priorità di 1 (conversione n. 3).
   • Il clic n. 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic n. 1.
7. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con una priorità di 1 (conversione n. 4).
   • Il clic n. 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic n. 1.
8. L'utente effettua un acquisto nell'app dell'inserzionista, registrato con una priorità di 2 (conversione n. 5).
   • Il clic n. 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic n. 1.

I report a livello di evento presentano le seguenti caratteristiche:

• Per impostazione predefinita, i primi tre attivatori attribuiti a un clic e il primo attivatore attribuito a una vista vengono inviati dopo le finestre di report applicabili.
• All'interno della finestra di reporting, se sono presenti trigger registrati con priorità più elevata, questi hanno la precedenza e sostituiscono l'attivatore più recente.
• Nell'esempio precedente, la tecnologia pubblicitaria riceve tre report sugli eventi dopo la finestra di report di due giorni per la conversione 2, 3 e 5.
  • Tutti e 5 gli attivatori sono attribuiti al clic n. 1. Per impostazione predefinita, l'API inviava report per i primi tre attivatori: conversione 1, conversione 2 e conversione 3.
  • Tuttavia, la priorità della conversione n. 4 (1) è superiore a quella della conversione n. 1 (0). Il report sugli eventi della conversione 4 sostituisce il report sugli eventi 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 il report sulla conversione 4 da inviare.

I report aggregati presentano 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 tecnologia pubblicitaria, crei i tuoi batch in base alle informazioni non criptate nei report aggregabili. Queste informazioni sono contenute nel campo shared_info nel report aggregabile e includono il timestamp e l'origine del report. Non puoi eseguire il raggruppamento in base a informazioni criptate nelle coppie chiave-valore di aggregazione. Alcune semplici strategie che puoi seguire sono la creazione di report giornalieri o settimanali. Idealmente, i batch dovrebbero contenere almeno 100 report ciascuno.

• Spetta alla tecnologia pubblicitaria 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 fonte.

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

Report di debug di transizione

L'API Attribution Reporting è un modo nuovo e abbastanza complesso per effettuare la misurazione dell'attribuzione senza identificatori cross-app. Per questo motivo, supportiamo un meccanismo di transizione per saperne di più sui report sull'attribuzione quando l'ID pubblicità è disponibile (l'utente non ha disattivato la personalizzazione tramite l'ID pubblicità e l'app del publisher o dell'inserzionista ha dichiarato le autorizzazioni per l'ID pubblicità). In questo modo ti assicuri che l'API sia compresa nella sua interezza durante l'implementazione, elimini i bug eventuali e confrontiamo più facilmente il rendimento con le alternative basate sull'ID pubblicità. Esistono due tipi di report di debug: attribuzione riuscita e dettagliato.

Leggi la guida sui report di debug transitori per maggiori dettagli sul debug dei report con la misurazione da app al web e da web ad app.

Report sul debug di attribuzione riuscita

Le registrazioni di origini e trigger accettano entrambi un nuovo campo debug_key a 64 bit (formattato come stringa), che viene compilato dalla tecnologia pubblicitaria. I criteri source_debug_key e trigger_debug_key vengono ignorati sia nei report a livello di evento che nei report aggregati.

Se un report viene creato con chiavi di debug di origine e di attivazione, un report di debug duplicato viene inviato 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 della chiave di debug. L'inclusione di queste chiavi in entrambi consente di collegare i report normali al flusso separato dei 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 eliminati dai limiti sugli attivatori disponibili, il che consente alla tecnologia pubblicitaria di comprendere l'impatto di questi limiti per i report a livello di evento.
  • I report a livello di evento associati a eventi di trigger falsi non avranno trigger_debug_key. Ciò consente ad tech di comprendere meglio 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 entrambi i valori source_debug_key e trigger_debug_key.

Report di debug dettagliati

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

Ogni report dettagliato contiene i seguenti campi:

• Tipo: ciò che ha causato la generazione del report. Consulta l'elenco completo dei tipi di report dettagliati.
  • In generale, esistono report dettagliati sulle fonti e attivano report dettagliati.
  • I report dettagliati delle origini richiedono che l'ID pubblicità sia disponibile per l'app del publisher, mentre i report dettagliati per attivare i report dettagliati richiedono che l'ID pubblicità sia disponibile per l'app dell'inserzionista.
  • L'attivazione di report dettagliati (con l'eccezione di trigger-no-matching-source) può facoltativamente includere source_debug_key. Questo valore può essere incluso solo se l'ID pubblicità è disponibile anche per l'app del publisher.
• Corpo: il corpo del report, che dipende dal tipo.

Gli ad tech devono attivare la ricezione di report di debug dettagliati utilizzando un nuovo campo del dizionario debug_reporting nelle intestazioni Attribution-Reporting-Register_Source e Attribution-Reporting-Register-Trigger.

• I report dettagliati delle origini richiedono l'attivazione solo nell'intestazione della registrazione della sorgente.
• I report di debug dell'attivatore richiedono l'attivazione solo nell'intestazione di registrazione del trigger.

Come utilizzare i report di debug

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

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

I motivi per cui non esistono corrispondenze.

Funzionamento previsto:

• Comportamenti delle API incentrate sulla tutela della privacy:
  • Un utente raggiunge il limite di frequenza del report; di conseguenza, tutti i report successivi non vengono inviati nel periodo di tempo oppure un'origine viene rimossa a causa del limite di destinazione in attesa.
  • Per i report a livello di evento: il report è soggetto a risposta randomizzata (rumore) e viene eliminato, oppure potresti ricevere un report randomizzato.
  • Per i report a livello di evento: è stato raggiunto il limite di tre (per clic) o uno (per visualizzazioni) e per i report successivi non è stata impostata una priorità esplicita oppure è inferiore a quella dei report esistenti.
  • I limiti per i contributi aggregabili sono stati superati.
• Logica di business definita dall'ad tech:
  • Un attivatore viene filtrato tramite filtri o regole di priorità.
• Ritardi di tempo o interazioni con la disponibilità della rete (ad esempio, l'utente spegne il dispositivo per un periodo di tempo prolungato).

Cause non intenzionali:

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

Considerazioni future e domande aperte

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

Inoltre, vorremmo ricevere un feedback dalla community su alcuni problemi:

1. Ci sono casi d'uso in cui vuoi che l'API invii report per l'installazione verificata? Questi report incidono sui limiti di frequenza delle piattaforme di tecnologia pubblicitaria.
2. Prevedi difficoltà nel passare il InputEvent dall'app all'ad tech per la registrazione del codice sorgente?
3. Hai casi d'uso di attribuzione speciali per app precaricate o app reinstallate?