Panoramica di Attribution Reporting per dispositivi mobili

Inviare un feedback

Aggiornamenti recenti

• È stato aggiornato l'elenco delle prossime modifiche e dei problemi noti
• Introduzione della configurazione flessibile a livello di evento Lite, come ponte per l'intera configurazione flessibile a livello di evento
• A partire da settembre 2023, registerWebSource, registerWebTrigger, registerAppSource e registerAppTrigger devono utilizzare stringhe per i campi che si aspetta 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 saperne di più, consulta la guida al deployment informazioni sulla configurazione del servizio di aggregazione con Google Cloud.
• Nuovi limiti di frequenza per la tutela della privacy per il numero di destinazioni uniche.
• La funzionalità aggiornata per i filtri degli attivatori delle finestre temporali sarà disponibile nel primo trimestre del 2024. Consulta la nota per ulteriori informazioni.

Panoramica

Attualmente, le soluzioni di attribuzione e misurazione mobile usano spesso identificatori tra 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 su app e web.

Questa API presenta i seguenti meccanismi strutturali che offrono un framework migliorare la privacy, che nelle sezioni successive di questa pagina verrà dettaglio:

• Limita il numero di bit disponibili per report a livello di evento
• Attiva i dati sulle conversioni con una maggiore fedeltà solo nei report aggregabili
• Introduce i 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 come segue, 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. La tecnologia pubblicitaria registra le origini di attribuzione, ovvero clic o visualizzazioni 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 origini dell'attribuzione, una attribuzione delle conversioni e uno o più attivatori vengono inviati al di fuori del dispositivo tramite a livello di evento e aggregatable alle tecnologie pubblicitarie.

Accedere alle API Attribution Reporting

Le piattaforme di ad tech devono registrarsi per accedere alle API Attribution Reporting; consulta Per saperne di più, registrati per un account Privacy Sandbox.

Registrare un'origine attribuzione (clic o visualizzazione)

L'API Attribution Reporting fa riferimento ai clic e alle visualizzazioni sugli annunci come attribuzione di origine. Per registrare un clic o una visualizzazione dell'annuncio, chiama registerSource(). Questa API prevede i seguenti parametri:

• Attribution source URI: la piattaforma invia una richiesta a questo URI in: 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 della sorgente di attribuzione, la tecnologia pubblicitaria deve rispondere con i metadati della sorgente di 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 quando si verifica 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. che viene arrotondato al giorno più vicino. Può essere formattato come stringa o come numero intero non firmato a 64 bit.
• (Facoltativo) Finestra del report sugli eventi: durata in secondi dopo l'origine. registrazione 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 passata, un attivatore può comunque essere associato a una sorgente, ma non viene inviato un report sugli eventi per quell'attivatore. Non può essere superiore alla scadenza. Formattabile come un numero intero senza segno o una stringa 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 superiore alla scadenza. Può essere formattato come file a 64 bit un valore intero senza segno o una stringa.
• 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 modello a 64 bit numero intero formattato come stringa.
  
  Quando viene ricevuto un trigger, l'API trova l'origine di attribuzione corrispondente con il valore di priorità più alto per la sorgente 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à.
  
  Superiore indicano priorità più elevate.
• Finestre di attribuzione installazione e post-installazione (facoltativo): utilizzato per Determinare l'attribuzione per gli eventi post-installazione, descritti più avanti in questa pagina.
• (Facoltativo) Filtra i dati: utilizzato per filtrare selettivamente alcuni attivatori, ignorandoli efficacemente. Per ulteriori dettagli, consulta filtri attivatori di questa pagina.
• (Facoltativo) Chiavi di aggregazione: specifica segmentazione da utilizzare per 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 reindirizzamenti URL, che consentire 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 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 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 ad tech 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 effettua una richiesta a ciascun URL specificato Attribution-Reporting-Redirect. In questo esempio, due URL di partner vengono specificati, quindi l'API effettua una richiesta https://adtechpartner1.example?their_ad_click_id=567 e un'altra richiesta a https://adtechpartner2.example?their_ad_click_id=890.

5. Il server HTTPS di questa ad tech risponde con intestazioni contenenti quanto segue:

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

Vengono registrate tre origini di attribuzione della navigazione (clic) in base alla 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 anziché l'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é i tecnici pubblicitari utilizzano codice comune su Web e WebView, WebView segue HTTP 302 reindirizza alla piattaforma le registrazioni valide. 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 ad tech possono registrare gli attivatori, come installazioni o eventi post-installazione con il metodo registerTrigger().

Il metodo registerTrigger() prevede il parametro Trigger URI. L'API invia 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 chiamata Attribution-Reporting-Register-Trigger, che rappresenta informazioni su uno o più attivatori registrati. I contenuti dell'intestazione devono essere Codifica JSON e includere i seguenti campi:

• Dati attivatore: dati utilizzati per identificare l'evento di trigger (3 bit per i clic, 1 per le viste). Deve essere un numero intero con segno a 64 bit 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 Assegnazione delle priorità.
• Chiave di deduplicazione (facoltativa): utilizzata per identificare i casi in cui l'attivatore viene registrato più volte dalla stessa piattaforma di tecnologia pubblicitaria, la stessa origine dell'attribuzione. Deve essere un numero intero a 64 bit con segno formattato come stringa.
• Chiavi di aggregazione (facoltative): A elenco di dizionari che specificano le chiavi di aggregazione e i report aggregabili.
• (Facoltativo) Valori di aggregazione: un elenco di quantità 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 filtri attivatori di questa pagina.

Facoltativamente, la risposta del server ad tech può includere dati aggiuntivi nel Intestazione Attribution Reporting Redirects. I dati contengono URL di reindirizzamento, quale consentire a più tecnologie pubblicitarie di registrare una richiesta.

Più tecnologie pubblicitarie possono registrare lo stesso evento di attivazione utilizzando i reindirizzamenti nel campo Attribution-Reporting-Redirect o più chiamate al metodo registerTrigger(). 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 accetta la registrazione trigger.

I passaggi seguenti mostrano un flusso di lavoro di esempio:

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 creare un account Privacy Sandbox informazioni.

   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
   

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 ad tech risponde con intestazioni contenenti quanto segue:

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

   In base alle richieste nei passaggi precedenti, vengono registrati due trigger.

Funzionalità di attribuzione

Le seguenti sezioni spiegano come l'API Attribution Reporting corrisponde gli attivatori di conversione alle origini di attribuzione.

Algoritmo di attribuzione con priorità all'origine applicato

L'API Attribution Reporting utilizza un'attribuzione con priorità in base alla fonte per abbinare un attivatore (conversione) a un'origine di attribuzione.

I parametri di priorità consentono di personalizzare l'attribuzione degli attivatori a 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 fare in modo che conversioni o conversioni di valore elevato hanno maggiori probabilità di report.

Nel caso in cui più ad tech registrano un'origine di attribuzione, come descritto più avanti in questa pagina, questa attribuzione avviene indipendentemente ciascuna tecnologia pubblicitaria. Per ogni tecnologia pubblicitaria, l'origine di attribuzione con la priorità più elevata. viene attribuito all'evento trigger. Se ci sono più origini dell'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 ignorate e non vengono non sarà più idoneo per l'attribuzione futura dell'attivazione.

Filtri attivatore

La registrazione dell'origine e dell'attivatore include ulteriori funzionalità facoltative da eseguire le seguenti:

• Filtrare selettivamente alcuni attivatori ignorandoli efficacemente.
• Scegli i dati di attivazione 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, di chiavi e valori, durante la registrazione di origine e di trigger. Se la stessa chiave è specificato sia per l'origine sia per l'attivatore, l'attivatore viene ignorato se l'incrocio è vuoto. 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. In caso contrario, chiave di filtro dell'attivatore corrispondente a product, i filtri vengono ignorati.

Un altro scenario in cui le piattaforme di ad tech potrebbero voler filtrare selettivamente gli attivatori è 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 minore o uguale a alla durata della finestra temporale.

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 è specificato alcun trigger_data.
• Origine e 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 i trigger post-installazione vengano attribuiti al la stessa origine di attribuzione che ha generato l'installazione, anche se sono presenti altre più recenti.

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 un 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 di secondi.
• L'API Attribution Reporting verifica quando avviene l'installazione di un'app e attribuisce internamente l'installazione all'attribuzione che dà priorità alla fonte sorgente. Tuttavia, l'installazione non viene inviata al team AdTech e non viene considerata ai fini del calcolo della piattaforma i rispettivi limiti di frequenza.
• 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 i tecnici pubblicitari possono utilizzare la post-installazione l'attribuzione dei contenuti. 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, non vengono inviati report a questo indirizzo punto di accesso.
Trigger 1 (prima apertura)	2	Primo attivatore registrato da ad tech. In questo esempio, rappresenta prima apertura, ma può essere di qualsiasi tipo di trigger. È attribuita 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 attivatore registrato da ad tech. In questo esempio, rappresenta conversione post-installazione, come un acquisto. È attribuita al clic 1 (corrisponde all'attribuzione dell'installazione verificata). Il 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 entro il giorno 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 conteggiate ai fini dei limiti di frequenza di un ad tech. Installazioni verificate vengono utilizzati solo per identificare l'origine di attribuzione a cui viene attribuita la installare l'app.
• Nell'esempio della tabella precedente, il trigger 1 e il trigger 2 rappresentano un conversione per la prima apertura e una conversione post-installazione. Tuttavia, ad tech possono registrare qualsiasi tipo di trigger. In altre parole, la prima 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 viene 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 invece il clic 1 è stato un evento di visualizzazione, viene utilizzato entrambi i valori e post-installazione gli attivatori sono ancora attribuiti. L'API limita l'attribuzione a uno attiva per visualizzazione, tranne nel caso dell'attribuzione post-installazione, dove fino a sono consentiti due attivatori per vista. 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 attivazione basati su app e web

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

• Da app ad 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 vede un annuncio in un'app, poi effettua la conversione in un dispositivo mobile o nel browser delle app.
• Da web ad app: l'utente visualizza un annuncio in un browser mobile o per app, poi effettua una conversione in un'app.
• Da web a 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 al web, come una funzionalità simile Privacy Sandbox per l'API Attribution Reporting per il web che possono chiamare le API Android per attivare l'attribuzione nelle app e sul web.

Scopri di più sui cambiamenti che le app e le tecnologie pubblicitarie devono apportare per supportare percorsi dei trigger per 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 è attribuito a uno o più fonti di attribuzione in base algoritmo di attribuzione con priorità alla fonte, descritti 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 di questa pagina. Nei casi in cui ci siano più trigger che vanno oltre questi limiti, è utile introdurre per recuperare i trigger più preziosi. 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 gli attivatori con priorità più alta vengono selezionati prima dell'applicazione dei limiti, entro un specifica finestra di reporting.

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

È comune che più di una tecnologia pubblicitaria riceva i report sull'attribuzione. In genere, per eseguire la deduplicazione 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'ad tech deve Registrare sia le origini dell'attribuzione che gli attivatori per ricevere postback dalla API, mentre l'attribuzione avviene tra le origini dell'attribuzione e attiva il ad tech si sia registrato con l'API.

Inserzionisti che vogliono utilizzare una terza parte per eseguire su più reti la deduplicazione può 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 esistente per la misurazione dei dispositivi mobili.

Origini di attribuzione

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

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

È possibile elencare più URL di tecnologia pubblicitaria dei partner nel Attribution-Reporting-Redirect e le tecnologie pubblicitarie dei 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

Un ad tech può registrare lo stesso trigger più volte con l'API. Gli scenari includeranno 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, entrambe le MMP si registrano che si attivano con l'attribuzione API di reporting. L'AdTech n. 3 riceve quindi due reindirizzamenti separati: uno MMP n. 1 e MMP n. 2, per lo stesso trigger.

In questi casi, esistono diversi modi per non visualizzare i report a livello di evento su duplicati per ridurre le probabilità di superare limiti di frequenza applicati ai report a livello di evento. Il metodo consigliato consiste nell'utilizzare una chiave di deduplicazione.

Metodo consigliato: chiave di deduplicazione

Il metodo consigliato prevede che l'app dell'inserzionista trasmetta una deduplicazione univoca chiave per qualsiasi tecnologia pubblicitaria o SDK che usa 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 SDK continuano quindi a passare la chiave di deduplicazione 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. I tecnici pubblicitari possono specificare il deduplication_key durante la registrazione di duplicati trigger.

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. Il parametro duplicate_trigger_id può includere informazioni come il nome dell'SDK e il tipo di attivatore per quell'inserzionista. Tecnologie pubblicitarie può inviare un sottoinsieme di questi trigger 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 l'MMP devono completare la registrazione per utilizzare l'API Attribution Reporting. Consulta Registrazione per un account Privacy Sandbox per ulteriori informazioni.

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 a l'URI e il clic viene registrato con i metadati del file risposta del server.

L'ad tech A include anche l'URI MMP nell'Attribution-Reporting-Redirect intestazione. L'API invia 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

L'AdTech B chiama registerSource() con il suo URI. L'API invia una richiesta a l'URI e il clic viene registrato con i metadati della rete risposta del server.

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 monitoraggio dei dati sui clienti (MMP) e il clic viene registrato con i metadati della risposta del server del fornitore.

Giorno 3: l'utente visualizza un annuncio pubblicato da Ad tech 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 l'MMP 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:

L'attribuzione funziona nel seguente modo:

• La tecnologia pubblicitaria A imposta la priorità dei clic più alta rispetto alle visualizzazioni e, di conseguenza, ottiene l'installazione attribuita al clic del primo giorno.
• L'installazione viene attribuita ad AdTech B il secondo giorno.
• MMP imposta la priorità dei clic su un valore superiore a quello delle visualizzazioni e ottiene l'installazione attribuite al clic del secondo giorno. Il clic del giorno 2 ha la priorità più alta, l'evento annuncio più recente.

Attribuzione su più reti senza reindirizzamenti

Sebbene consigliamo di utilizzare i reindirizzamenti per consentire a più esperti di tecnologia pubblicitaria di registrare gli attivatori e le sorgenti di attribuzione, siamo consapevoli che potrebbero verificarsi scenari in cui l'utilizzo dei reindirizzamenti non sia fattibile. In questa sezione viene illustrato come supportare su più reti senza reindirizzamenti.

Flusso di alto livello

1. Al momento della registrazione dell'origine, la rete ad tech per la pubblicazione condivide la propria origine e le chiavi di aggregazione.
2. Al momento della registrazione dell'attivatore, l'inserzionista o il partner di misurazione sceglie quale le parti chiave lato sorgente da utilizzare e specificarne la configurazione di attribuzione.
3. L'attribuzione si basa sulla configurazione dell'attribuzione, sulle chiavi condivise e su qualsiasi origine che sono state effettivamente registrate dall'inserzionista o dal partner di misurazione. (ad esempio da un'altra rete di tecnologia pubblicitaria che ha attivato i reindirizzamenti).
4. Se l'attivatore viene attribuito a un'origine da un annuncio pubblicato senza reindirizzamenti tecnologia, l'inserzionista o il partner di misurazione possono ricevere un'aggregazione che combina l'origine e gli elementi chiave dell'attivatore definiti nel passaggio 2.

Registrazione di 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, dipende dalla tecnologia pubblicitaria e dall'attivatore le tecnologie pubblicitarie di misurazione per collaborare sui tipi di chiavi di aggregazione necessarie, i nomi e come decodificare le chiavi in dimensioni leggibili.

Registrazione trigger

Al momento della registrazione dell'attivatore, la tecnologia pubblicitaria per la misurazione sceglie la chiave lato origine elementi da applicare a ogni elemento chiave dell'attivatore, incluse quelle condivise dalla pubblicazione di annunci tecnici.

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 origini non avevano visibilità (ad esempio, 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 eseguono il reindirizzamento, ma condividono le loro chiavi di aggregazione.
• Ad tech D non reindirizza né condivide chiavi di aggregazione.

Il file MMP registra una sorgente da Ad tech A e definisce una configurazione di attribuzione che include Ad tech B e Ad tech D.

L'attribuzione per la MMP ora include:

• Ad tech A, poiché l'MMP ha registrato una sorgente dal reindirizzamento di tale 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:

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

Debug

Per supportare il debug per l'attribuzione cross-network senza reindirizzamenti, è disponibile un campo aggiuntivo, shared_debug_key, che le tecnologie pubblicitarie 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 a app in cui si trova l'ID pubblicità consentito
• Misurazione da app a web in cui l'ID pubblicità è consentito e corrisponde a sia l'origine dell'app che l'attivatore web
• La misurazione da Web a Web (lo stesso browser) quando è presente ar_debug sia nell'origine che nell'attivatore

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

La scoperta chiave ha lo scopo di semplificare il modo in cui le tecnologie pubblicitarie (di solito le MMP) implementano della propria configurazione di attribuzione ai fini dell'attribuzione su più reti, quando o più tecnici pubblicitari per la pubblicazione utilizzino chiavi di aggregazione condivise (come descritto in Attribuzione su più reti senza reindirizzamenti sopra).

Quando un MMP esegue una 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 dell'origine può essere molto lungo oppure sconosciuto. Elenchi lunghi di possibili chiavi sono difficili da monitorare e sono anche piuttosto complessa e costosa da elaborare. Considera quanto segue. 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 sta lavorando su più reti pubblicitarie pubblicate che sono Non reindirizzare a MMP alla registrazione di origine. ogni annuncio pubblicato rete ha una struttura e valori chiave diversi, che potrebbero non essere condivise in anticipo con l'MMP.

Con l'introduzione della funzionalità Key Discovery:

• Il servizio di aggregazione non richiede più l'enumerazione completa dei possibili chiavi di aggregazione.
• Anziché specificare l'elenco completo delle possibili chiavi, un file MMP può creare un insieme di chiavi vuoto (o parzialmente) e impostare una soglia, in modo che (non predichiarate) le chiavi con valori che superano la soglia sono incluse in l'output.
• 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 a cui non sono associati contributi reali degli utenti e che sono puramente rumorosi.
• MMP utilizza il campo x_network_bit_mapping nella registrazione dell'attivatore per determinare quale tecnologia pubblicitaria corrisponde a ciascuna 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.

Reindirizzamenti daisy chain

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

Nella risposta del server, la tecnologia pubblicitaria può anche includere un singolo Location (reindirizzamento 302) con un URL, che a sua volta rimanda a un altro registrazione, fino a un limite prestabilito.

Entrambi i tipi di intestazioni sono facoltativi e non è possibile fornirne nessuno se non sono necessari i reindirizzamenti. È 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 un numero fisso per evitare impatti significativi sul dispositivo.

I reindirizzamenti non sono accettati per registryWebSource e registerWebTrigger utilizzati dai browser. Ulteriori dettagli sono disponibili nella pagina Cross-Web e App Guida all'implementazione.

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 fonte di attribuzione (clic o visualizzazione) a una quantità limitata di dati di attivazione ad alta fedeltà.
• I report aggregati non sono necessariamente collegati con una specifica origine di attribuzione. Questi report forniscono dati più dettagliati precisione superiore dei dati di trigger rispetto ai report a livello di evento, ma questi dati sono disponibili 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 un report a livello di evento. generati e archiviati sul dispositivo finché non può essere inviato al server URL postback durante uno degli finestre temporali per l'invio di rapporti, descritti più dettagliatamente più avanti in questa pagina.

I report a livello di evento sono utili quando sono necessarie pochissime informazioni sul trigger. 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, il cross-device non è supportato e analisi 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 l'attivatore successo
• Attribution Source ID: lo stesso ID origine dell'attribuzione utilizzato per registrare un'origine di attribuzione
• Tipo di trigger: 1 o 3 bit di dati di trigger a bassa fedeltà, a seconda del tipo di origine dell'attribuzione

Meccanismi incentrati sulla tutela della privacy applicati a tutte le segnalazioni

I seguenti limiti vengono applicati dopo le priorità relative alle origini di attribuzione e gli attivatori vengono presi in considerazione.

Limiti al numero di tecnologie pubblicitarie

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

• 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 tecnici pubblicitari possono registrare una singola origine o attivatore di attribuzione (tramite Attribution-Reporting-Redirect)

Limiti del 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 oltre 200 destinazioni uniche al minuto per app di origine.
• 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 esaurire l'intero budget grazie al limite di frequenza indicato in precedenza.

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

Un'origine report per app di origine al giorno

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

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 segnalante 2 della tecnologia pubblicitaria A tenta di registrare una fonte nell'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 {source, destination} , l'API limita 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 un ad tech utilizzare l'API per tentare per misurare l'attività di navigazione degli utenti non associata agli annunci mostrati.

L'attuale proposta prevede di limitare ogni ad tech a 100 destinazioni distinte con e non scadute per ogni app di origine.

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

Fidelità 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 gamma di 64 bit di metadati.

Devi valutare se e come ridurre le informazioni espresse nei trigger pertanto funzionano 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.

Viene applicato un rumore che indica se un evento di origine dell'attribuzione viene riportato in modo veritiero. Sul dispositivo viene registrata un'origine di attribuzione con probabilità $ 1-p $ che l'origine dell'attribuzione è registrata normalmente, e con probabilità $ p $ che il dispositivo sceglie in modo casuale tra tutti i possibili stati di output dell'API (incluse nessuna segnalazione o la segnalazione di più segnalazioni false).

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

Per valori bassi di ↂ, l'output vero è protetto dalla funzione meccanismo di risposta. 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 eventi

Limiti sugli 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 della visualizzazione dell'annuncio (due attivatori disponibili solo in nel caso dell'attribuzione post-installazione)
• 3 attivatori per le origini di attribuzione degli annunci basati sui clic

Intervalli di tempo specifici per l'invio di report (comportamento predefinito)

I report a livello di evento per le origini di attribuzione delle visualizzazioni di annuncio vengono inviati un'ora dopo il la fonte scade. Questa data di scadenza può essere configurata, ma non può essere inferiore a 1 giorni o più di 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 tempo che intercorre tra l'origine dell'attribuzione e e la scadenza del report è suddivisa in più finestre 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 che l'origine dell'attribuzione è registrato.
• Un periodo di tempo personalizzato,definito dalla "scadenza" di un l'origine dell'attribuzione. Il report viene inviato un'ora dopo la scadenza specificata nel tempo. Questo valore non può essere inferiore a 1 giorno o superiore a 30 giorni.

Configurazione flessibile a livello di evento

La configurazione predefinita per i report a livello di evento è quella consigliata per le ad tech iniziare a usare all'inizio dei test di utilità, ma potrebbe non essere l'ideale per qualsiasi d'uso diversi. L'API Attribution Reporting API supporterà elementi facoltativi e più flessibili in modo che i tecnici pubblicitari abbiano un maggiore controllo sulla struttura dei a livello di evento e possono massimizzare l'utilità dei dati.

Questa ulteriore flessibilità verrà introdotta nei report sull'attribuzione dell'API in due fasi:

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

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

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

Puoi utilizzare la Fase 2 (a livello di evento completamente flessibile) per eseguire tutte le operazioni funzionalità nella Fase 1 e:

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

La riduzione di una dimensione della configurazione predefinita consente 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 tecnologia pubblicitaria scelta abbiamo dei limiti di parametri per evitare calcoli di grandi dimensioni e configurazioni con troppi stati di output (dove il rumore aumenterà considerevolmente). Di seguito è riportato un esempio di limitazioni. Feedback è incoraggiato su la [proposta di progettazione][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 cardinalità dei dati di trigger (non applicabile per la fase 1: Lite) livello evento flessibile)

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.

Report aggregati

Prima di utilizzare i report aggregabili, devi configurare il tuo account cloud iniziare a ricevere 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 a fedeltà superiore possono essere appresi solo in aggregati e non vengono associati a un determinato trigger o utente. Le chiavi di aggregazione possono avere fino a 128 bit e questo consente ai report aggregabili di supportare casi d'uso come i seguenti:

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

Inoltre, i report aggregabili utilizzano la stessa attribuzione Priorità alla fonte come report a livello di evento, ma supportano più conversioni attribuite a un fare clic o visualizzare.

La progettazione generale del modo in cui l'API Attribution Reporting si prepara e invia I report aggregabili, mostrati nel diagramma, sono i seguenti:

1. Il dispositivo invia report aggregabili criptati alla tecnologia pubblicitaria. In un nell'ambiente di produzione, i tecnici pubblicitari non possono usare 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, decripta e le aggrega.
4. I dati aggregati finali vengono inviati all'ad tech in un report di riepilogo.

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

Servizi di aggregazione

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

Questi servizi sono gestiti da parti diverse, descritte 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 a Google e che tutti gli utenti del servizio di aggregazione abbiano la stessa chiave i servizi di contabilità per report aggregabili applicati.

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 affidabile (Trusted Execution Environment, TEE) ospitati 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 per il processo in esecuzione, isolandolo dall'esterno il monitoraggio o le manomissioni.

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

Per ulteriori informazioni sulla progettazione, il flusso di lavoro e la sicurezza di aggregazione, consulta 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 aggregati

Questo servizio monitora la frequenza con cui un servizio di aggregazione di una tecnologia pubblicitaria accede a un un trigger specifico, che può contenere più chiavi di aggregazione, e limita l'accesso al numero appropriato di decrittografia. Fai riferimento al servizio di aggregazione per la proposta di progettazione dell'API Attribution Reporting per maggiori dettagli.

API Aggregatable Reports

L'API per creare report aggregabili utilizza la stessa base API come durante 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 effettua una richiesta all'URI di origine dell'attribuzione, la tecnologia pubblicitaria può registra un elenco di chiavi di aggregazione, denominate histogram_contributions, mediante rispondendo con un nuovo campo denominato aggregation_keys nell'intestazione HTTP Attribution-Reporting-Register-Source, con chiave come key_name e valore come key_piece:

• (Chiave) Nome chiave:una stringa per il nome della chiave. Utilizzata come chiave di join per si combinano con i tasti lato trigger per formare la chiave finale.
• (Valore) Key pezzo: un valore bitstring 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 file JSON devono essere limitate al massimo 32 cifre.

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

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

• Conteggi delle conversioni aggregate a livello di campagna
• Aggrega i 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 l'attivatore aggregabile

La registrazione del trigger 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:

• Elemento chiave: un valore bitstring per la chiave.
• Chiavi di origine:un elenco di stringhe con i nomi lato origine dell'attribuzione. tasti con cui la chiave dell'attivatore 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 utilizzato per registrare un elenco di valori che devono contribuire a ogni chiave, il che può essere interi nell'intervallo $ [1, 2^{16}] $.

Ogni attivatore può apportare più contributi ai report aggregabili. La L'importo totale dei contributi a qualsiasi evento di origine è associato a un L1 $ , che è la somma massima di contributi (valori) in tutti e aggregate per una determinata origine. $ L1 $ si riferisce alla sensibilità o alla norma L1 dei contributi all'istogramma per evento sorgente. Cause del superamento di questi limiti i contributi futuri per annullarla silenziosamente. La proposta iniziale è impostare $ L1 $ su $ 2^{16} $ (65536).

Il rumore nel servizio di aggregazione viene scalato in modo proporzionale a questo parametro. Pertanto, è consigliabile scalare in modo appropriato i valori registrati per una determinata chiave aggregata in base alla parte di budget L1 allocata. Questo aiuta a garantire che nei report aggregati venga applicata la fedeltà quando viene applicato il rumore. Questo meccanismo è molto flessibile e può supportano molte strategie di aggregazione.

Nell'esempio seguente, il budget per la privacy è suddiviso equamente tra campaignCounts e geoValue suddividendo il contributo di $ L1 $ 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
  }
]

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

L'obiettivo di questa API è avere un framework che supporti in modo differenziato la misurazione aggregata privata. Questo può essere ottenuto aggiungendo rumore proporzionale al budget L1, ad esempio scegliendo il rumore con la seguente distribuzione:

Integrazione di API Protected Audience e API Attribution Reporting

Integrazione di più API in Protected Audience e Attribution Reporting Le API consentono ai tecnici pubblicitari di valutare il rendimento dell'attribuzione in vari tattiche di remarketing per capire quali tipi di segmenti di pubblico generano il ROI più elevato.

Grazie a questa integrazione tra API, i tecnici pubblicitari possono:

• Crea una mappa chiave-valore degli 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 trasmettere un segmento di pubblico personalizzato (o altri segmenti di pubblico informazioni sull'annuncio, come il posizionamento o la durata di visualizzazione), utilizzando URL in modo che questi metadati possano propagarsi ai report di riepilogo quando è esaminare il rendimento aggregato delle campagne.

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 una serie di interazioni degli utenti e la definizione di tecnologia pubblicitaria l'origine dell'attribuzione e le priorità degli attivatori potrebbero influire sui report attribuiti. Nella in questo esempio si suppone 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 dell'attribuzione si verificano durante il primo evento finestra di report (entro 2 giorni dalla prima visualizzazione degli annunci in un dell'app del publisher).

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

1. L'utente vede un annuncio. Ad tech registra un'origine di attribuzione con l'API, con una priorità pari a 0 (visualizzazione n. 1).
2. L'utente vede un annuncio registrato con una priorità pari a 0 (visualizzazione 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).
   • Quando i trigger vengono registrati, l'API esegue l'attribuzione prima generando report.
   • Sono disponibili tre origini attribuzione: visualizzazione 1, visualizzazione 2 e click 1. L'API attribuisce questo trigger al clic su 1 perché è il la priorità più alta e il più recente.
   • Le viste 1 e 2 vengono ignorate e non sono più idonee per il futuro l'attribuzione dei contenuti.
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 un priorità di 1 (conversione n. 3).
   • Il clic 1 è l'unica origine di attribuzione idonea. Gli attributi dell'API questo trigger per fare clic su 1.
7. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con un priorità di 1 (conversione n. 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.
• Durante il periodo del report, se sono presenti attivatori registrati con 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 5 gli attivatori sono attribuiti al clic n. 1. Per impostazione predefinita, invia report per i primi tre attivatori: conversione n. 1, conversione n. 2, e la conversione 3.
  • Tuttavia, la priorità della conversione n. 4 (1) è superiore a quella della conversione n. 1 priorità (0). Il report sugli eventi della conversione 4 sostituisce il report della conversione 1 report sull'evento da inviare.
  • Inoltre, la priorità della conversione 5 (2) è più elevata di qualsiasi altra trigger. 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 al team ad tech non appena vengono elaborati, alcune ore dopo la registrazione dei trigger.

  In qualità di fornitore di tecnologia pubblicitaria, crei i batch in base alle informazioni non criptate nei report aggregabili. Queste informazioni sono contenute in il campo shared_info nel report aggregabile e include il timestamp e l'origine del report. Non puoi eseguire il batch in base a informazioni criptate nelle coppie chiave-valore di aggregazione. Alcune semplici strategie che puoi seguire sono raggruppando i report ogni giorno oppure ogni settimana. Idealmente, i batch dovrebbero contenere 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 l'attribuzione senza identificatori cross-app. Di conseguenza, supportiamo meccanismo di transizione per saperne di più sui report sull'attribuzione quando L'ID pubblicità sia disponibile (l'utente non ha disattivato la personalizzazione usando l'ID pubblicità e l'app del publisher o dell'inserzionista ha dichiarato l'ID pubblicità. autorizzazioni). Ciò garantisce che l'API possa essere compresa completamente durante un'implementazione, eliminare eventuali bug e confrontare più facilmente alternative basate sull'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 inalterati sia a livello di evento che di aggregati report.

Se viene creato un report con le 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 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:
  • Report di debug duplicati vengono inviati con un ritardo limitato e pertanto non vengono soppresso dai limiti degli attivatori disponibili, che consentono la tecnologia pubblicitaria per comprendere l'impatto di questi limiti sui report a livello di evento.
  • I report a livello di evento associati a falsi eventi di trigger non avranno trigger_debug_key Ciò consente all'ad tech di comprendere più da vicino il rumore viene applicato 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 di debug dettagliati

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 report dettagliati.
  • In generale, esistono report dettagliati sulle fonti che attivano i report dettagliati.
  • I report dettagliati di origine richiedono che l'ID pubblicità sia disponibile per dell'app del publisher e attivare report dettagliati richiedono che l'ID pubblicità sia disponibili per l'app dell'inserzionista.
  • Attivare report dettagliati (ad eccezione di trigger-no-matching-source) può includere facoltativamente source_debug_key. Questo 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 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 di origine richiedono l'attivazione solo nell'intestazione della registrazione di origine.
• I report di debug trigger richiedono l'attivazione solo nell'intestazione della 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.

Se non esistono corrispondenze, i motivi possono essere diversi.

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 risposta randomizzata (rumore) e viene rimosso; in alternativa, potresti ricevere un report randomizzato.
  • Per i report a livello di evento: il limite di tre (per i clic) o di uno (per di visualizzazioni) è stato raggiunto e i successivi rapporti non contengono priorità impostata o una priorità inferiore a quella dei rapporti esistenti.
  • I limiti per i contributi 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 temporali o interazioni con la disponibilità della rete (ad esempio, l'utente cambia 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 relativi al dispositivo o alla rete:
  • Errori dovuti alle condizioni della rete.
  • La risposta di registrazione dell'origine o 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 il futuro Funzionalità potenziali, ad esempio modelli di attribuzione non basati sull'ultimo clic e cross-device e casi d'uso della misurazione.

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

1. Esistono casi d'uso in cui vuoi che l'API invii report per l'installazione verificata? Questi report sono conteggiati ai fini del calcolo delle piattaforme di tecnologia pubblicitaria i rispettivi limiti di frequenza.
2. Prevedi difficoltà nel superare InputEvent dall'app alla tecnologia pubblicitaria per la registrazione dell'origine?
3. Disponi di casi d'uso speciali per l'attribuzione per le app precaricate hai reinstallato l'app?