Panoramica di Attribution Reporting per dispositivi mobili

Aggiornamenti recenti

• È stato aggiornato l'elenco delle prossime modifiche e dei problemi noti
• È stata introdotta la configurazione a livello di evento flessibile lite, come passaggio intermedio alla configurazione a livello di evento flessibile completa
• A partire da settembre 2023, registerWebSource, registerWebTrigger, registerAppSource e registerAppTrigger devono utilizzare stringhe per i campi che prevedono un valore numerico (ad esempio priority, source_event_id, debug_key, trigger_data, deduplication_key e così via).
• Nel quarto trimestre del 2023, verrà aggiunto il supporto di Google Cloud nell'API Android Attribution Reporting per generare report di riepilogo utilizzando il servizio di aggregazione su Google Cloud. Qui vengono indicate le tempistiche più specifiche. Per ulteriori informazioni sulla configurazione di Aggregation Service con Google Cloud, consulta la guida all'implementazione.
• Nuovi limiti di frequenza per la tutela della privacy per il numero di destinazioni uniche.
• La funzionalità aggiornata per i filtri degli attivatori della finestra temporale sarà disponibile nel primo trimestre del 2024. Per ulteriori informazioni, consulta la nota.

Panoramica

Attualmente, le soluzioni di attribuzione e misurazione mobile usano comunemente identificatori trasversali come l'ID pubblicità. L'API Attribution Reporting è progettata per migliorare la privacy dell'utente 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 ha i seguenti meccanismi strutturali che offrono un framework per migliorare la privacy, che verranno descritti più dettagliatamente nelle sezioni successive di questa pagina:

• Limita il numero di bit disponibili per i report a livello di evento.
• Abilita dati sulle conversioni a fedeltà più elevata 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 del 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 nell'analisi e nel rilevamento di traffico non valido e frodi pubblicitarie.

A livello generale, l'API Attribution Reporting funziona come segue, che nelle sezioni successive di questo documento verranno descritte in modo più dettagliato:

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

Accedere alle API Attribution Reporting

Le piattaforme di ad tech devono registrarsi per accedere alle API Attribution Reporting. Per saperne di più, consulta Registrati per creare 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 sorgenti dell'attribuzione. Per registrare un clic o una visualizzazione dell'annuncio, chiama registerSource(). Questa API prevede i seguenti parametri:

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

Quando l'API invia una richiesta all'URI 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 non firmato a 64 bit formattato come stringa.
• Destinazione: un'origine il cui eTLD+1 o il nome del pacchetto dell'app in cui si verifica l'evento attivatore.
• Scadenza (facoltativo): scade, in secondi, quando la fonte deve essere eliminata 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.
• Finestra report sugli eventi (facoltativa): durata in secondi dopo la registrazione dell'origine durante la quale è possibile creare report sugli eventi per questa origine. Se la finestra di generazione del report sugli eventi è terminata, ma la scadenza non è ancora 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. Può essere formattato come un numero intero senza segno a 64 bit o una stringa.
• 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 stringa o come numero intero senza segno a 64 bit.
• Priorità origine (facoltativo): utilizzato per selezionare l'origine di attribuzione a cui associare un determinato attivatore nel caso in cui possano essere associate più origini di attribuzione all'attivatore. Deve essere un numero intero con segno a 64 bit formato come stringa.
  
  Quando viene ricevuto un attivatore, l'API individua l'origine di attribuzione corrispondente con il valore di priorità dell'origine più elevato e genera un report. Ogni piattaforma di tecnologia pubblicitaria può definire la propria strategia di assegnazione della priorità. Per maggiori dettagli su come la priorità influisce sull'attribuzione, consulta la sezione Esempio di definizione della priorità.
  
  I valori più elevati indicano priorità più elevate.
• Finestre di attribuzione di installazione e post-installazione (facoltativo): utilizzate per determinare l'attribuzione per gli eventi post-installazione, descritti più avanti in questa pagina.
• Filtra dati (facoltativo): utilizzato per filtrare in modo selettivo alcuni attivatori, ignorandoli di fatto. Per maggiori dettagli, consulta la sezione Filtri attivatori 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 come fonte.

I passaggi seguenti mostrano un flusso di lavoro di esempio:

1. L'SDK ad tech chiama l'API per avviare la registrazione dell'origine dell'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 effettua una richiesta a ciascun URL specificato in Attribution-Reporting-Redirect. In questo esempio, vengono specificati due URL di partner ad tech, quindi l'API invia una richiesta a 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"
   }
   

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

Registra un'origine di attribuzione da WebView

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

Poiché i tecnici pubblicitari utilizzano un codice comune su Web e WebView, WebView segue i reindirizzamenti HTTP 302 e trasmette 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 tecnologia pubblicitaria possono registrare gli attivatori, ovvero le conversioni come le installazioni o gli eventi post-installazione, utilizzando il metodo registerTrigger().

Il metodo registerTrigger() prevede il parametro Trigger URI. 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 informazioni su uno o più attivatori registrati. I contenuti dell'intestazione devono essere codificati in formato JSON e includere i seguenti campi:

• Dati attivatore: dati utilizzati 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 sull'impatto della priorità sui report, consulta la sezione relativa all'assegnazione delle priorità.
• Chiave di deduplica (facoltativa): utilizzata per identificare i casi in cui lo stesso attivatore viene registrato più volte dalla stessa piattaforma ad tech per la stessa origine attribuzione. Deve essere un numero intero con segno a 64 bit formattato come stringa.
• Chiavi di aggregazione (facoltative): un elenco di dizionari che specificano le chiavi di aggregazione e i report aggregabili devono avere il valore aggregato.
• (Facoltativo) Valori di aggregazione: un elenco di quantità di valori che contribuiscono a ogni chiave.
• Filtri (facoltativi): utilizzati per filtrare selettivamente gli attivatori o i dati dei trigger. Per maggiori dettagli, consulta la sezione Filtri di attivazione in questa pagina.

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

Più esperti di tecnologia pubblicitaria possono registrare lo stesso evento di attivatore 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 accettare la registrazione degli attivatori.

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

1. L'SDK ad tech chiama l'API per avviare la registrazione dell'attivatore utilizzando un URI preregistrato. Per ulteriori informazioni, consulta Registrazione per un account Privacy Sandbox.

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

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

3. Il server HTTPS di questa ad tech 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 effettua una richiesta a ogni URL specificato in Attribution-Reporting-Redirect. In questo esempio viene specificato un solo URL, pertanto l'API invia una richiesta a https://adtechpartner.example?app_install=567.

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

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

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

Funzionalità di attribuzione

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

Algoritmo di attribuzione con priorità alla sorgente applicato

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

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

• 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 dell'attribuzione e attivare l'attivazione in modo che, se raggiungi i limiti di frequenza, hai maggiori probabilità di ricevere i report per te più importanti. Ad esempio, potresti voler assicurarti che le conversioni disponibili per le offerte o le conversioni di alto valore abbiano maggiori probabilità di comparire in questi report.

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

Filtri attivatore

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

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

Per filtrare selettivamente gli attivatori, il team ad tech può specificare i dati del filtro, costituiti da chiavi e valori, durante la registrazione di origine e di trigger. Se viene specificata la stessa chiave sia per l'origine che per il trigger, l'attivatore viene ignorato se l'intersezione è vuota. Ad esempio, un'origine può specificare "product": ["1234"], dove product è la chiave del filtro e 1234 è il valore. Se il filtro attivatore è impostato su "product": ["1111"], l'attivatore viene ignorato. Se non esiste una chiave 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 è per forzare una finestra di scadenza più breve. Al momento della registrazione dell'attivatore, una tecnologia pubblicitaria può specificare (in secondi) una finestra temporale a partire dalla data e dall'ora della conversione; ad esempio, una finestra temporale di 7 giorni viene definita come: "_lookback_window": 604800 // 7d

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

Le piattaforme di ad tech possono anche scegliere di attivare dati 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 sia per quelli aggregabili.

Attribuzione post-installazione

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

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

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

In futuro, potremmo valutare l'estensione del design per supportare modelli di attribuzione più avanzati.

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

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

• Se l'installazione verificata non avviene entro il numero di giorni specificato da install_attribution_window, l'attribuzione post-installazione non viene applicata.
• Le installazioni verificate non vengono registrate dalle tecnologie pubblicitarie e non vengono inviate nei report. Non vengono conteggiati ai fini dei limiti di frequenza di una tecnologia pubblicitaria. Le installazioni verificate vengono utilizzate solo per identificare l'origine di attribuzione a cui viene attribuita l'installazione.
• Nell'esempio della tabella precedente, il trigger 1 e il trigger 2 rappresentano rispettivamente una conversione prima apertura e una conversione post-installazione. Tuttavia, le piattaforme di ad tech possono registrare qualsiasi tipo di trigger. In altre parole, il primo trigger non deve essere un trigger di apertura iniziale.
• 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.
  • Se è stata registrata un'origine di attribuzione con priorità più alta, il clic 1 potrebbe comunque perdere o essere ignorato.
• Se l'app dell'inserzionista viene disinstallata e reinstallata, la nuova installazione viene conteggiata come nuova installazione verificata.
• Se il clic 1 era invece un evento di visualizzazione, gli attivatori "prima apertura" e post-installazione vengono comunque attribuiti all'evento. L'API limita l'attribuzione a un trigger per visualizzazione, tranne nel caso dell'attribuzione post-installazione, in cui sono consentiti fino a due trigger per visualizzazione. Nel caso dell'attribuzione post-installazione, la tecnologia pubblicitaria potrebbe ricevere due finestre di report diverse (2 giorni o alla scadenza della fonte).

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

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

• App-to-app: l'utente vede un annuncio in un'app ed effettua la 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 browser mobile o di app.
• Web-to-app: l'utente vede un annuncio in un browser mobile o di un'app, poi genera la conversione in un'app.
• Web-to-web: l'utente vede un annuncio in un browser mobile o di un'app, quindi effettua la conversione nello stesso browser o in un altro browser sullo stesso dispositivo.

Permettiamo ai browser web di supportare nuove funzionalità esposte al web, come funzionalità simili a Privacy Sandbox per l'API Attribution Reporting per il web , che può chiamare le API Android per abilitare l'attribuzione su app e web.

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

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

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

Esistono limiti al numero di attivatori che possono essere attribuiti a una singola origine di attribuzione; per ulteriori dettagli, consulta la sezione su come visualizzare i dati di misurazione nei report sull'attribuzione più avanti in questa pagina. Se sono presenti più attivatori oltre questi limiti, è utile introdurre una logica di assegnazione della priorità per recuperare gli attivatori più importanti. Ad esempio, gli sviluppatori di una tecnologia pubblicitaria potrebbero dare la priorità all'attivazione degli attivatori "Acquisto" rispetto agli attivatori "Aggiungi al carrello".

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

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

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

Gli inserzionisti che vogliono utilizzare una terza parte per eseguire la 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 di misurazione mobile esistente.

Origini dell'attribuzione

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

È possibile elencare più URL di tecnologia pubblicitaria dei partner nel campo Attribution-Reporting-Redirect e i partner ad tech non possono specificare il proprio campo Attribution-Reporting-Redirect.

Inoltre, l'API consente a tecnologie pubblicitarie diverse per ogni 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 deduplicazione serve a distinguere questi report ripetuti dello stesso evento registrati dalla stessa piattaforma di tecnologia pubblicitaria. Ad esempio, una tecnologia pubblicitaria potrebbe far sì che il proprio SDK chiami direttamente l'API per registrare un trigger e avere il proprio URL nel campo di reindirizzamento della chiamata di un'altra tecnologia pubblicitaria. Se non viene fornita alcuna chiave di deduplicazione, gli attivatori duplicati potrebbero essere segnalati come univoci per ogni tecnologia pubblicitaria.

Gestire gli attivatori duplicati

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

• 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. Entrambe le MMP reindirizzano alla tecnologia pubblicitaria n. 3. Quando si verifica un attivatore, entrambi gli MMP lo registrano con l'API Attribution Reporting. La tecnologia pubblicitaria 3 riceve quindi due reindirizzamenti separati, uno dalla MMP 1 e uno dalla MMP 2, per lo stesso attivatore.

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

Metodo consigliato: chiave di deduplica

Il metodo consigliato prevede che l'app dell'inserzionista trasmetta una chiave di deduplicazione unica a eventuali tecnologie pubblicitarie o SDK che sta utilizzando per la misurazione delle conversioni. Quando si verifica una conversione, l'app passa una chiave di deduplicazione 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. Gli esperti di tecnologia pubblicitaria possono specificare deduplication_key quando registrano attivatori duplicati.

Se una tecnologia pubblicitaria registra più attivatori con la stessa chiave di 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: 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 quali il nome dell'SDK e il tipo di attivatore per l'inserzionista. Le tecnologie pubblicitarie possono quindi inviare un sottoinsieme di questi attivatori duplicati ai report a livello di evento. Gli ad tech possono anche includere questo duplicate_trigger_id nelle proprie chiavi di aggregazione.

Esempio di attribuzione su più reti

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

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

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

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

L'AdTech A chiama registerSource() con il suo URI. L'API invia una richiesta all'URI e il clic viene registrato con i metadati della risposta del server di Ad tech A.

La tecnologia pubblicitaria A include anche l'URI della piattaforma di gestione dei dati in-market nell'intestazione Attribution-Reporting-Redirect. L'API invia una richiesta all'URI 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

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

Come Ad tech A, Ad tech B ha incluso anche 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 dalla tecnologia pubblicitaria A

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

Giorno 4: l'utente installa l'app, che utilizza 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 MMP.

MMP include anche gli URI per Ad tech A e Ad tech B nell'intestazione Attribution-Reporting-Redirect. L'API invia richieste ai server di Ad Tech A e di 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 su un valore superiore rispetto alle visualizzazioni e, di conseguenza, l'installazione viene attribuita al clic il giorno 1.
• L'installazione viene attribuita ad AdTech B il secondo giorno.
• L'MMP imposta la priorità dei clic più alta rispetto alle visualizzazioni e ottiene l'installazione attribuita al clic il giorno 2. Il clic del secondo giorno è l'evento correlato all'annuncio più recente e con la massima priorità.

Attribuzione su più reti senza reindirizzamenti

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

Flusso di alto livello

1. Al momento della registrazione dell'origine, la rete di tecnologia pubblicitaria per la pubblicazione condivide le chiavi di aggregazione dell'origine.
2. Al momento della registrazione dell'attivatore, l'inserzionista o il partner di misurazione sceglie gli elementi 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 eventuali origini effettivamente registrate dall'inserzionista o dal partner di misurazione (ad es. da un'altra rete ad tech di pubblicazione che ha attivato i reindirizzamenti).
4. Se l'attivatore viene attribuito a una fonte proveniente da una tecnologia pubblicitaria per la pubblicazione senza reindirizzamenti, l'inserzionista o il partner di misurazione può ricevere un report aggregabile che combina l'origine e gli elementi chiave definiti nel passaggio 2.

Registrazione dell'origine

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

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

Registrazione trigger

Al momento della registrazione dell'attivatore, la tecnologia pubblicitaria per la misurazione sceglie le chiavi lato origine da applicare a ogni elemento chiave dell'attivatore, incluse quelle condivise dalle tecnologie pubblicitarie per la pubblicazione.

Inoltre, la tecnologia pubblicitaria di misurazione deve specificare anche la logica di attribuzione della struttura a cascata utilizzando una nuova chiamata API di configurazione dell'attribuzione. In questa configurazione, l'ad tech può specificare la priorità, la scadenza e i filtri delle origini per le quali non avevano visibilità (ad esempio, quelle 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 di misurazione (MMP).
• L'AdTech A reindirizza le proprie origini al file MMP.
• Le tecnologie pubblicitarie B e C non eseguono il reindirizzamento, ma condividono le loro chiavi di aggregazione.
• La tecnologia pubblicitaria D non reindirizza né condivide le 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 piattaforma MMP ora include:

• Ad tech A, poiché l'MMP ha registrato una sorgente dal reindirizzamento di tale tecnologia pubblicitaria.
• Ad tech B, poiché l'Ad tech B ha condiviso le chiavi e l'MMP le ha incluse nella propria configurazione di attribuzione.

L'attribuzione per il modello MMP non include:

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

Debug

Per supportare il debug per l'attribuzione su più reti senza reindirizzamenti, è disponibile un campo aggiuntivo, shared_debug_key, che le ad tech possono impostare al momento della registrazione dell'origine. Se impostato nella registrazione dell'origine originale, verrà impostato anche sull'origine derivata corrispondente come debug_key durante la registrazione del trigger per l'attribuzione su più reti senza reindirizzamenti. Questa chiave di debug viene collegata come source_debug_key nei report aggregati e sugli eventi.

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

• Misurazione da app ad app in cui AdId è consentito
• La misurazione da app a web in cui l'ID pubblicità è consentito e corrisponde sia nell'origine dell'app che nell'attivatore web
• Misurazione da web a web (sulla stessa app browser) quando ar_debug è presente sia nell'origine sia nell'attivatore

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

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

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

• L'elenco di tutte le chiavi possibili è ampio:
  • Una rete pubblicitaria pubblicata sta conducendo una complessa iniziativa di acquisizione utenti che include 20 campagne, ciascuna 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 di annunci pubblica annunci su molte app mobile per le quali non è noto l'elenco completo degli ID app del publisher al momento del lancio della campagna.
  • Un inserzionista utilizza più reti pubblicitarie di pubblicazione che non indirizzano all'MMP al momento della registrazione dell'origine. Ogni rete pubblicitaria di pubblicazione ha una struttura e valori delle chiavi diversi, che potrebbero non essere condivisi in anticipo con l'MMP.

Con l'introduzione del rilevamento delle chiavi:

• Il servizio di aggregazione non richiede più un'enumerazione completa delle possibili chiavi di aggregazione.
• Anziché specificare l'elenco completo delle chiavi possibili, un file 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 con rumore per le chiavi che hanno valori che contribuiscono a superare la soglia impostata. Il report può includere anche chiavi che non hanno contributi di utenti reali associati e sono puramente con rumore.
• L'MMP utilizza il campo x_network_bit_mapping nella registrazione dell'attivatore per determinare a quale tecnologia pubblicitaria corrisponde quale chiave.
• MMP può quindi contattare la tecnologia pubblicitaria per la pubblicazione appropriata per comprendere i valori nella chiave di origine.

In sintesi, il rilevamento delle chiavi consente alle MMP di ottenere le chiavi di aggregazione senza conoscerle in anticipo ed evita di elaborare un grande volume di chiavi di origine a scapito del rumore aggiuntivo.

Reindirizzamenti daisy chain

Fornendo più intestazioni Attribution-Reporting-Redirect nella risposta del server HTTPS di registrazione della sorgente o dell'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 una singola intestazione Location (reindirizzamento 302) con un URL, che a sua volta porta a un'altra registrazione, fino a un limite stabilito.

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

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

Visualizzare i dati di misurazione nei report sull'attribuzione

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

• I report a livello di evento associano una particolare origine di attribuzione (clic o visualizzazione) a bit limitati di dati degli attivatori ad alta fedeltà.
• I report aggregabili non sono necessariamente associati a un'origine di attribuzione specifica. Questi report forniscono dati di trigger più completi e ad alta precisione 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 è stato attribuito a un'origine di attribuzione, viene generato e archiviato sul dispositivo un report a livello di evento finché non può essere inviato nuovamente all'URL postback di ogni ad tech durante una delle finestre temporali per l'invio dei report, descritte più dettagliatamente più avanti in questa pagina.

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

Meccanismi incentrati sulla tutela della privacy applicati a tutte le segnalazioni

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

Limiti al numero di tecnologie pubblicitarie

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

• 100 tecnologie pubblicitarie con origini di 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 al numero di destinazioni univoche

Questi limiti rendono difficile per un insieme di tecnologie pubblicitarie eseguire query su un numero elevato 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 supporta non più di 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 di utilizzare tutto il budget del limite di frequenza menzionato in precedenza.

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

Un'origine report per app di origine al giorno

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

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

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

La seconda origine, per l'origine report 2 di Ad tech A, verrebbe 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 perdita di identità dell'utente tra una coppia di {source, destination}, l'API limita la quantità di informazioni totali inviate in un determinato periodo di tempo per un utente.

L'attuale proposta prevede di limitare ciascuna 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 di misurare l'attività di navigazione degli utenti non associata agli annunci mostrati.

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

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

Fideltà limitata dei dati degli attivatori

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

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

Framework per il rumore della privacy differenziale

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

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

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

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

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

Limiti sugli attivatori disponibili (conversioni)

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

• 1-2 attivatori per le origini di attribuzione della visualizzazione di annuncio (2 attivatori sono disponibili solo nel caso dell'attribuzione post-installazione)
• 3 attivatori per le origini di attribuzione dell'annuncio clic

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

I report a livello di evento per le origini di attribuzione della visualizzazione di annuncio vengono inviati un'ora dopo la scadenza dell'origine. Questa data di scadenza può essere configurata, ma non può essere inferiore a 1 giorno o superiore a 30 giorni. Se due attivatori vengono attribuiti a un'origine di attribuzione della visualizzazione dell'annuncio (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 data di registrazione dell'origine. Il periodo di tempo compreso tra l'origine dell'attribuzione e la scadenza è suddiviso in più finestre di generazione di report. Ogni finestra di generazione di report ha una scadenza (dalla data e dall'ora dell'origine dell'attribuzione). Al termine di ogni finestra di generazione dei report, il dispositivo raccoglie tutti gli attivatori che si sono verificati dalla finestra di generazione dei report precedente e invia un report pianificato. L'API supporta le seguenti finestre di generazione di report:

• 2 giorni: il dispositivo raccoglie tutti gli attivatori che si sono verificati al massimo due giorni dopo la registrazione dell'origine di attribuzione. Il report viene inviato 2 giorni e un'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 di attribuzione. Il report viene inviato 7 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 l'ora di scadenza specificata. 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 che consigliamo agli esperti di tecnologia pubblicitaria di iniziare a utilizzare quando iniziano i test di utilità, ma potrebbe non essere ideale per tutti i casi d'uso. L'API Attribution Reporting supporterà configurazioni facoltative e più flessibili, in modo che le tecnologie pubblicitarie abbiano un maggiore controllo sulla struttura dei report a livello di evento e possano massimizzare l'utilità dei dati.

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

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

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
• Configura le finestre di reporting anziché utilizzare i valori predefiniti

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

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

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

Oltre a impostare dinamicamente i livelli di rumore in base alla configurazione scelta dalla tecnologia pubblicitaria, introdurremo alcuni limiti di parametri per evitare costi di calcolo elevati e configurazioni con troppi stati di output (dove il rumore aumenterà in modo considerevole). Di seguito è riportato un esempio di insieme di restrizioni. Incoraggiamo il feedback su [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 trigger (non applicabile per la fase 1: livello di evento flessibile Lite)

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

Report aggregati

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

I report aggregabili forniscono dati sugli attivatori del dispositivo con una maggiore fedeltà e più rapidamente rispetto a quanto offerto per i report a livello di evento. Questi dati a fedeltà maggiore possono essere appresi solo in aggregati e non sono associati a un attivatore o utente specifico. 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 attivatori

Inoltre, i report aggregabili utilizzano la stessa logica di attribuzione basata sulla priorità di origine dei report a livello di evento, ma supportano più conversioni attribuite a un clic o a una vista.

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

1. Il dispositivo invia report aggregabili criptati alla tecnologia pubblicitaria. In un ambiente di produzione, 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 nuovamente alla tecnologia pubblicitaria in un report di riepilogo.

I report aggregati contengono i seguenti dati relativi alle origini dell'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 vengono utilizzate nel servizio di aggregazione attendibile per calcolare le aggregazioni.

Servizi di aggregazione

I seguenti servizi forniscono funzionalità di aggregazione e aiutano a proteggersi dall'accesso improprio ai dati di aggregazione.

Questi servizi sono gestiti da entità 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 parti affidabili chiamate coordinatori. Questi coordinatori attestano che il codice che esegue il servizio di aggregazione è il codice disponibile pubblicamente fornito da Google e che tutti gli utenti del servizio di aggregazione hanno la stessa chiave e gli stessi servizi di contabilità dei report aggregabili applicati.

Servizio di aggregazione

Le piattaforme di tecnologia pubblicitaria devono, in anticipo, eseguire il deployment di 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) ospitato nel cloud. Un TEE offre i seguenti vantaggi in termini di sicurezza:

• Garantisce che il codice operativo nel TEE sia il programma 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 tutto il processo in esecuzione, isolandolo dal monitoraggio esterno o dalle manomissioni.

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

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

Key Management Service

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

Contabilità dei report aggregati

Questo servizio monitora la frequenza con cui un 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 report aggregabili utilizza la stessa API di base utilizzata per la registrazione di un'origine dell'attribuzione per i report a livello di evento. Le sezioni seguenti descrivono le estensioni dell'API.

Registrare i dati di origine aggregati

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

• (Key) 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) Componente chiave: un valore di stringa di bit per la chiave.

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

Le chiavi finali sono limitate a un massimo di 128 bit; le chiavi più lunghe vengono truncated. Ciò significa che le stringhe esadecimali nel file JSON devono essere limitate a un massimo di 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:

• Conteggio aggregato delle conversioni a livello di campagna
• Valori di acquisto aggregati a livello geografico

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

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

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

Registra l'attivatore aggregabile

La registrazione dell'attivatore include due campi aggiuntivi.

Il primo campo viene utilizzato per registrare un elenco di chiavi aggregate sul lato 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 bitstring per la chiave.
• Chiavi di origine: un elenco di stringhe con i nomi delle chiavi lato origine dell'attribuzione con cui la chiave di attivazione deve essere combinata per formare le chiavi finali.

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

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

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

Nell'esempio seguente, il budget per la privacy viene suddiviso equamente tra campaignCounts e geoValue 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, il rumore del modulo applicato:

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

Privacy differenziale

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

Integrazione di API Protected Audience e API Attribution Reporting

L'integrazione di più API nelle API Protected Audience e Attribution Reporting consente ai tecnici pubblicitari di valutare il rendimento delle attribuzioni 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, i tecnici pubblicitari possono:

• Crea una mappa chiave-valore di URI da utilizzare sia per i report sulle interazioni sia per la registrazione dell'origine.
• 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 segnalare queste interazioni con Protected Audience verrà utilizzato anche per registrare una vista o un clic come sorgente idonea con l'API Attribution Reporting.
• La tecnologia pubblicitaria può scegliere di trasmettere il segmento di pubblico personalizzato (o altre informazioni contestuali pertinenti sull'annuncio, come il posizionamento dell'annuncio o la durata di visualizzazione) utilizzando quell'URL, in modo che questi metadati possano essere propagati ai report di riepilogo quando la tecnologia pubblicitaria sta esaminando il rendimento aggregato della campagna.

Per maggiori informazioni su come questa funzionalità viene attivata in Protected Audience, consulta la sezione pertinente della spiegazione dell'API Protected Audience.

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

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

• Tutte le origini di attribuzione e gli attivatori vengono registrati dalla stessa tecnologia pubblicitaria e per lo stesso inserzionista.
• Tutte le origini dell'attribuzione e tutti gli attivatori si verificano durante la prima finestra dei report sugli eventi (entro 2 giorni dalla prima visualizzazione degli annunci in un'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 (vista 1).
2. L'utente vede un annuncio registrato con una priorità di 0 (visualizzazione 2).
3. L'utente fa clic su un annuncio registrato con una priorità pari a 1 (clic n. 1).
4. L'utente esegue la conversione (raggiunge la pagina di destinazione) in un'app dell'inserzionista. La tecnologia pubblicitaria registra un attivatore con l'API, con una priorità pari a 0 (conversione n. 1).
   • Quando gli attivatori vengono registrati, l'API esegue prima l'attribuzione prima di generare i report.
   • Sono disponibili tre origini attribuzione: visualizzazione 1, visualizzazione 2 e click 1. L'API attribuisce questo trigger al clic su 1 perché è la priorità più alta e più recente.
   • Le visualizzazioni 1 e 2 vengono ignorate e non sono più idonee per l'attribuzione futura.
5. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con una priorità di 1 (conversione 2).
   • Il clic 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic 1.
6. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con priorità 1 (conversione n. 3).
   • Il clic 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo trigger per fare clic su 1.
7. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con una priorità di 1 (conversione 4).
   • Il clic 1 è l'unica origine di attribuzione idonea. L'API attribuisce questo attivatore al clic 1.
8. L'utente effettua un acquisto nell'app dell'inserzionista, registrato con una priorità 2 (conversione n. 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 vista vengono inviati dopo le finestre di report applicabili.
• Durante la finestra del report, se sono presenti attivatori registrati con priorità più alta, 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, l'API invia report per i primi 3 attivatori: conversione 1, conversione 2 e conversione 3.
  • Tuttavia, la priorità della conversione 4 (1) è superiore a quella della conversione 1 (0). Il report sugli eventi della conversione 4 sostituisce 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 della conversione 4 da inviare.

I report aggregati hanno le seguenti caratteristiche:

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

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

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

• Rispetto ai report a livello di evento, i report aggregabili criptati possono attribuire più attivatori a un'origine.

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

Report di debug di transizione

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

Leggi la guida sui report di debug di transizione per i dettagli sul debug dei report con la misurazione da app a web e da web ad app.

Report di debug dell'attribuzione riuscita

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

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

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

Report di debug dettagliati

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

Ogni report dettagliato contiene i seguenti campi:

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

I tecnici pubblicitari devono attivare la ricezione di report di debug dettagliati utilizzando un nuovo campo 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 di registrazione dell'origine.
• I report di debug del 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 risposte randomizzate (rumore) e viene eliminato oppure potresti ricevere un report randomizzato.
  • Per i report a livello di evento: è stato raggiunto il limite di tre report (per i clic) o uno (per le visualizzazioni) e i report successivi non hanno una priorità esplicita impostata o una priorità inferiore a quella dei report esistenti.
  • I limiti di contributo per i report aggregabili sono stati superati.
• Logica di business definita dalla tecnologia pubblicitaria:
  • Un attivatore viene escluso tramite filtri o regole di priorità.
• Ritardi o interazioni con la disponibilità della rete (ad es. l'utente spegne il dispositivo per un periodo di tempo prolungato).

Cause non intenzionali:

• Problemi di implementazione:
  • L'intestazione 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.
  • 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 valutando potenziali funzionalità future, come i modelli di attribuzione non basata sull'ultimo clic e i casi d'uso di misurazione cross-device.

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

1. Esistono casi d'uso in cui vorresti che l'API invii report per l'installazione verificata? Questi report verranno conteggiati ai fini dei rispettivi limiti di frequenza delle piattaforme di ad tech.
2. Prevedi difficoltà nel trasferire il InputEvent dall'app all'ad tech per la registrazione dell'origine?
3. Hai casi d'uso di attribuzione speciali per app preinstallate o reinstallate?