Panoramica dei report sull'attribuzione per il mobile

Aggiornamenti recenti

• È stato aggiornato l'elenco delle prossime modifiche e dei problemi noti

• Ti presentiamo la nuova funzionalità di nuova query, il cui rilascio è previsto per il secondo semestre del 2025. Le nuove query consentono alle tecnologie pubblicitarie di elaborare i report del servizio di aggregazione più volte, supportando un'analisi flessibile per diverse esigenze di misurazione. Partecipa alla discussione su GitHub per saperne di più e fornire feedback.

Panoramica

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

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

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

• Consente di ottenere dati sulle conversioni con una fedeltà più elevata solo nei report aggregabili

• Introduce limiti di frequenza per i trigger disponibili (conversioni) e il numero di tecnologie pubblicitarie che possono essere associate a una singola sorgente di attribuzione

• Incorpora varie tecniche di aggiunta di rumore

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

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

• Report sulle conversioni:aiutano gli inserzionisti a misurare il rendimento delle loro campagne mostrando i conteggi e i valori delle conversioni (trigger) 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 delle frodi pubblicitarie.

A livello generale, l'API Attribution Reporting funziona nel modo seguente, 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 dell'attribuzione, ovvero i clic o le visualizzazioni degli annunci, con l'API Attribution Reporting.
3. La tecnologia pubblicitaria registra i trigger, ovvero le conversioni degli utenti sull'app o sul sito web dell'inserzionista, con l'API Attribution Reporting.
4. L'API Attribution Reporting abbina gli attivatori alle origini dell'attribuzione, ovvero a un'attribuzione di conversione, e uno o più attivatori vengono inviati off-device tramite report a livello di evento e aggregabili alle tecnologie pubblicitarie.

Ottenere l'accesso alle API Attribution Reporting

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

Registrare un'origine attribuzione (clic o visualizzazione)

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

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

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

• ID evento origine: questo valore rappresenta i dati a livello di evento associati a questa origine dell'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 nome del pacchetto dell'app in cui si verifica l'evento trigger.
• Scadenza (facoltativo): scadenza, in secondi, per la rimozione della fonte dal dispositivo. Il valore predefinito è 30 giorni, con un valore minimo di 1 giorno e un valore massimo di 30 giorni. Questo valore viene arrotondato al giorno più vicino. Può essere formattato come stringa o numero intero non firmato a 64 bit.
• Finestra di report sugli eventi (facoltativo): durata in secondi dopo la registrazione dell'origine durante la quale è possibile creare report sugli eventi per questa origine. Se la finestra del report sugli eventi è trascorsa, ma la scadenza non è ancora trascorsa, un trigger può comunque essere abbinato a una sorgente, ma non viene inviato un report sugli eventi per quel trigger. Non può essere maggiore della data di scadenza. Può essere formattato come un numero intero senza segno a 64 bit o una stringa.
• Finestra del report aggregabile (facoltativo): durata in secondi dopo la registrazione dell'origine durante la quale è possibile creare report aggregabili per questa origine. Non può essere maggiore della data di scadenza. Può essere formattato come numero intero senza segno a 64 bit o come stringa.
• Priorità dell'origine (facoltativo): utilizzata per selezionare l'origine dell'attribuzione a cui deve essere associato un determinato trigger, nel caso in cui più origini dell'attribuzione possano essere associate al trigger. Deve essere un numero intero a 64 bit formato come stringa.
  
  Quando viene ricevuto un trigger, l'API trova l'origine attribuzione corrispondente con il valore di priorità dell'origine più alto e genera un report. Ogni piattaforma di tecnologia pubblicitaria può definire la propria strategia di assegnazione delle priorità. Per maggiori dettagli su come la priorità influisce sull'attribuzione, consulta la sezione Esempio di assegnazione della priorità.
  
  I valori più alti indicano priorità più elevate.
• Finestre di attribuzione di installazione e post-installazione (facoltative): utilizzate per determinare l'attribuzione per gli eventi post-installazione, descritti più avanti in questa pagina.
• Filtra dati (facoltativo): utilizzato per filtrare in modo selettivo alcuni trigger, ignorandoli di fatto. Per maggiori dettagli, consulta la sezione Filtri di attivazione in questa pagina.
• Chiavi di aggregazione (facoltativo): specifica la segmentazione da utilizzare per i report aggregabili.

Facoltativamente, la risposta dei metadati dell'origine attribuzione può includere dati aggiuntivi nell'intestazione Reindirizzamenti del 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 dell'origine.

I seguenti passaggi mostrano un esempio di flusso di lavoro:

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

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

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

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

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

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

4. L'API invia una richiesta a ogni URL specificato in Attribution-Reporting-Redirect. In questo esempio, vengono specificati due URL di partner tecnologici pubblicitari, quindi l'API effettua 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 tecnologia pubblicitaria risponde con intestazioni contenenti quanto segue:

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

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

Registrare un'origine attribuzione da WebView

WebView supporta il caso d'uso in cui un'app esegue il rendering di un annuncio all'interno di una WebView. Questa operazione viene gestita da WebView chiamando direttamente registerSource(). Questa chiamata associa l'origine dell'attribuzione all'app anziché all'origine di primo livello. È supportata anche la registrazione delle origini dai contenuti web incorporati all'interno di un contesto del browser; sia i chiamanti API sia le app devono modificare le impostazioni per farlo. Consulta Registrare l'origine e l'attivatore dell'attribuzione da WebView per istruzioni per i chiamanti API e Registrazione dell'origine e dell'attivatore dell'attribuzione da WebView per istruzioni per le app.

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

Registrare un trigger (conversione)

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

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

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

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

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

• Chiave di deduplicazione (facoltativa): utilizzata per identificare i casi in cui lo stesso attivatore viene registrato più volte dalla stessa piattaforma di tecnologia pubblicitaria per la stessa origine dell'attribuzione. Deve essere un numero intero con segno a 64 bit formattato come una stringa.

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

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

• Filtri (facoltativo): utilizzati per filtrare in modo selettivo i trigger o i dati dei trigger. Per maggiori dettagli, consulta la sezione Filtri di attivazione in questa pagina.

(Facoltativo) La risposta del server ad tech 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.

Più tecnologie pubblicitarie possono registrare lo stesso evento trigger utilizzando reindirizzamenti nel campo Attribution-Reporting-Redirect o più chiamate al metodo registerTrigger(). Ti consigliamo di utilizzare il campo chiave di deduplicazione per evitare di includere trigger duplicati nei report nel caso in cui la stessa tecnologia pubblicitaria fornisca più risposte per lo stesso evento trigger. 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 dei trigger.

I seguenti passaggi mostrano un esempio di flusso di lavoro:

1. L'SDK ad tech chiama l'API per avviare la registrazione del trigger utilizzando un URI pre-registrato. Per ulteriori informazioni, consulta Registrarsi per un account Privacy Sandbox.

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

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

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

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

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

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

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

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

Funzionalità di attribuzione

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

Algoritmo di attribuzione con priorità all'origine applicato

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

I parametri di priorità forniscono modi per personalizzare l'attribuzione dei trigger alle fonti:

• Puoi attribuire i trigger a determinati eventi pubblicitari rispetto ad altri. Ad esempio, puoi scegliere di dare più importanza ai clic rispetto alle visualizzazioni o concentrarti sugli eventi di determinate campagne.
• Puoi configurare l'origine e l'attivatore dell'attribuzione in modo che, se raggiungi i limiti di frequenza, sia più probabile che tu riceva i report più importanti per te. Ad esempio, potresti voler assicurarti che le conversioni per cui è possibile fare offerte o le conversioni di alto valore abbiano maggiori probabilità di essere visualizzate in questi report.

Nel caso in cui più tecnologie pubblicitarie registrino un'origine attribuzione, come descritto più avanti in questa pagina, questa attribuzione avviene in modo indipendente per ogni tecnologia pubblicitaria. Per ogni tecnologia pubblicitaria, l'origine attribuzione con la priorità più alta viene attribuita all'evento trigger. Se sono presenti più origini dell'attribuzione con la stessa priorità, l'API sceglie l'ultima origine dell'attribuzione registrata. Tutte le altre fonti di attribuzione non selezionate vengono scartate e non sono più idonee per l'attribuzione dei trigger futuri.

Filtri attivatore

La registrazione di origine e attivatore include funzionalità facoltative aggiuntive per fare quanto segue:

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

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

Un altro scenario in cui le piattaforme di tecnologia pubblicitaria potrebbero voler filtrare selettivamente i trigger è quello di forzare una finestra di scadenza più breve. Al momento della registrazione dell'attivazione, una tecnologia pubblicitaria può specificare (in secondi) una finestra temporale a partire dal momento in cui si è verificata la conversione; ad esempio, una finestra temporale di 7 giorni verrebbe definita come: "_lookback_window": 604800 // 7d

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

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

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

• Non è specificato alcun trigger_data.
• L'origine e il trigger specificano la stessa chiave di filtro, ma i valori non corrispondono. Tieni presente che, in questo caso, il trigger 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 alla stessa origine di attribuzione che ha generato l'installazione, anche se sono presenti altre origini di attribuzione idonee che si sono verificate più di recente.

L'API può supportare questo caso d'uso consentendo alle tecnologie pubblicitarie di impostare un periodo di attribuzione post-installazione:

• Quando registri un'origine dell'attribuzione, specifica una finestra di attribuzione dell'installazione durante la quale sono previste le installazioni (in genere 2-7 giorni, intervallo accettato da 1 a 30 giorni). Specifica questa finestra temporale come numero di secondi.
• Quando registri un'origine attribuzione, specifica una finestra di esclusività dell'attribuzione post-installazione in cui tutti gli eventi trigger 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 l'installazione di un'app e attribuisce internamente l'installazione all'origine di attribuzione con priorità. Tuttavia, l'installazione non viene inviata alle tecnologie pubblicitarie e non viene conteggiata ai fini dei limiti di frequenza rispettivi delle piattaforme.
• La convalida dell'installazione dell'app è disponibile per qualsiasi app scaricata.
• Tutti i trigger futuri che si verificano all'interno della finestra di attribuzione post-installazione vengono attribuiti alla stessa origine di attribuzione dell'installazione convalidata, a condizione che l'origine di attribuzione sia idonea.

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

La tabella seguente mostra un esempio di come le tecnologie pubblicitarie possono utilizzare l'attribuzione post-installazione. Supponi che tutte le origini e tutti i trigger di attribuzione vengano registrati dalla stessa rete di tecnologie pubblicitarie e che tutte le priorità siano le stesse.

Il seguente elenco fornisce 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 dell'attribuzione a cui viene accreditata l'installazione.
• Nell'esempio della tabella precedente, l'attivatore 1 e l'attivatore 2 rappresentano rispettivamente una prima apertura e una conversione post-installazione. Tuttavia, le piattaforme di tecnologia pubblicitaria possono registrare qualsiasi tipo di trigger. In altre parole, il primo trigger non deve essere un trigger di prima apertura.
• Se vengono registrati altri trigger dopo la scadenza di post_install_exclusivity_window, il clic 1 è ancora idoneo per l'attribuzione, a condizione che non sia scaduto e non abbia raggiunto i limiti di frequenza.
  • Il clic 1 potrebbe comunque essere perso o eliminato se viene registrata un'origine di attribuzione con priorità più alta.
• Se l'app dell'inserzionista viene disinstallata e reinstallata, l'installazione viene conteggiata come una nuova installazione verificata.
• Se il clic 1 fosse stato un evento di visualizzazione, sia il trigger "prima apertura" che quello post-installazione gli vengono comunque attribuiti. L'API limita l'attribuzione a un trigger per visualizzazione, ad eccezione dell'attribuzione post-installazione, in cui sono consentiti fino a due trigger per visualizzazione. Nel caso dell'attribuzione post-installazione, la tecnologia pubblicitaria potrebbe ricevere due diverse finestre di reporting (a 2 giorni o alla scadenza dell'origine).

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:

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

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

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

Dare la priorità a più trigger per una singola sorgente di attribuzione

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

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

Nei casi in cui sono presenti più trigger oltre questi limiti, è utile introdurre una logica di assegnazione delle priorità per recuperare i trigger più importanti. Ad esempio, gli sviluppatori di una tecnologia pubblicitaria potrebbero voler dare la priorità all'ottenimento di trigger "acquisto" rispetto a trigger "aggiungi al carrello".

Per supportare questa logica, è possibile impostare un campo di priorità separato sul trigger e i trigger con priorità più alta vengono selezionati prima dell'applicazione dei limiti, all'interno di una determinata finestra di reporting.

Consenti a più tecnologie pubblicitarie di registrare origini o trigger di attribuzione

È normale che più di una tecnologia pubblicitaria riceva report sull'attribuzione, in genere per eseguire la deduplicazione cross-network. Pertanto, l'API consente a più tecnologie pubblicitarie di registrare la stessa origine o lo stesso trigger di attribuzione. Una tecnologia pubblicitaria deve registrare sia le origini attribuzione sia i trigger per ricevere postback dall'API e l'attribuzione viene eseguita tra le origini attribuzione e i trigger che la tecnologia pubblicitaria ha registrato con l'API.

Gli inserzionisti che vogliono utilizzare una terza parte per eseguire la deduplicazione cross-network possono continuare a farlo utilizzando una tecnica simile alla seguente:

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

Origini dell'attribuzione

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

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

È possibile elencare più URL di tecnologie pubblicitarie partner nel campo Attribution-Reporting-Redirect e le tecnologie pubblicitarie partner non possono specificare il proprio campo Attribution-Reporting-Redirect.

L'API consente inoltre a diverse tecnologie pubblicitarie di chiamare registerSource().

Trigger

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

Quando un inserzionista utilizza più tecnologie pubblicitarie per registrare lo stesso evento trigger, deve essere utilizzata una chiave di deduplicazione. La chiave di deduplicazione serve a distinguere queste segnalazioni ripetute dello stesso evento registrato dalla stessa piattaforma di tecnologia pubblicitaria. Ad esempio, una tecnologia pubblicitaria potrebbe fare in modo che il proprio SDK chiami l'API direttamente per registrare un trigger e inserire il proprio URL nel campo di reindirizzamento della chiamata di un'altra tecnologia pubblicitaria. Se non viene fornita alcuna chiave di deduplicazione, i trigger duplicati potrebbero essere segnalati a ogni ad tech come unici.

Gestire i trigger duplicati

Una tecnologia pubblicitaria può registrare lo stesso trigger 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 di reporting.
• L'app dell'inserzionista utilizza più SDK per la misurazione delle conversioni, che reindirizzano tutti alla stessa tecnologia pubblicitaria. Ad esempio, l'app dell'inserzionista utilizza due partner di misurazione, MMP n. 1 e MMP n. 2. Entrambe le MMP reindirizzano alla tecnologia pubblicitaria n. 3. Quando si verifica un attivatore, entrambe le MMP lo registrano con l'API Attribution Reporting. La tecnologia pubblicitaria n. 3 riceve quindi due reindirizzamenti separati, uno dalla MMP n. 1 e uno dalla MMP n. 2, per lo stesso trigger.

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

Metodo consigliato: chiave di deduplicazione

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

Le tecnologie pubblicitarie possono scegliere di registrare solo il primo attivatore con una determinata chiave di deduplicazione oppure possono scegliere di registrare più attivatori o tutti gli attivatori. Le tecnologie pubblicitarie possono specificare deduplication_key durante la registrazione di trigger duplicati.

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

Metodo alternativo: le tecnologie pubblicitarie concordano i tipi di trigger per inserzionista

Nelle situazioni in cui le tecnologie pubblicitarie non vogliono utilizzare la chiave di deduplicazione o in cui l'app dell'inserzionista non può trasmettere una chiave di deduplicazione, esiste un'opzione alternativa. Tutte le tecnologie pubblicitarie che misurano le conversioni per un determinato inserzionista devono collaborare per definire diversi tipi di trigger per ciascun inserzionista.

Le tecnologie pubblicitarie che avviano la chiamata di registrazione del trigger, 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 trigger per l'inserzionista. Le tecnologie pubblicitarie possono quindi inviare un sottoinsieme di questi attivatori duplicati ai report a livello di evento. Le tecnologie pubblicitarie possono anche includere questo duplicate_trigger_id nelle chiavi di aggregazione.

Esempio di attribuzione cross-network

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

Per iniziare, la tecnologia pubblicitaria A, la tecnologia pubblicitaria B e l'MMP devono completare la registrazione per utilizzare l'API Attribution Reporting. Per saperne di più, consulta Registrarsi per un account Privacy Sandbox.

Il seguente elenco fornisce una serie ipotetica di azioni dell'utente che si verificano a distanza di un giorno l'una dall'altra e il modo in cui l'API Attribution Reporting gestisce queste azioni rispetto alla tecnologia pubblicitaria A, alla tecnologia pubblicitaria B e all'MMP:

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

La tecnologia pubblicitaria 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 della tecnologia pubblicitaria A.

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

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

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

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

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

L'API risponde nello stesso modo del giorno 1, tranne per il fatto che una visualizzazione viene registrata per la tecnologia pubblicitaria A e l'MMP.

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

L'MMP chiama registerTrigger() con il suo 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 Ad tech A e Ad tech B nell'intestazione Attribution-Reporting-Redirect. L'API invia richieste ai server di tecnologia pubblicitaria A e tecnologia pubblicitaria 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 pertanto l'installazione viene attribuita al clic del giorno 1.
• La tecnologia pubblicitaria B riceve l'attribuzione dell'installazione il giorno 2.
• L'MMP imposta la priorità dei clic più alta rispetto alle visualizzazioni e l'installazione viene attribuita al clic del secondo giorno. Il clic del secondo giorno è l'evento annuncio più recente e con la priorità più elevata.

Attribuzione su più reti senza reindirizzamenti

Sebbene consigliamo di utilizzare i reindirizzamenti per consentire a più tecnologie pubblicitarie di registrare origini e trigger di attribuzione, ci rendiamo conto che potrebbero esserci scenari in cui l'utilizzo dei reindirizzamenti non è fattibile. Questa sezione descrive in dettaglio come supportare l'attribuzione cross-network senza reindirizzamenti.

Flusso di alto livello

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

Registrazione dell'origine

Al momento della registrazione dell'origine, l'ad tech di pubblicazione può scegliere di condividere le chiavi di aggregazione dell'origine o un sottoinsieme di queste chiavi 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 trigger per lo stesso inserzionista. Tuttavia, spetta alla tecnologia pubblicitaria di pubblicazione e alla tecnologia pubblicitaria di misurazione del trigger collaborare per determinare i tipi di chiavi di aggregazione necessari, i loro nomi e la modalità di decodifica delle chiavi in dimensioni leggibili.

Registrazione del trigger

Al momento della registrazione del trigger, la tecnologia pubblicitaria di misurazione sceglie quali componenti della chiave lato sorgente applicare a ciascun componente della chiave del trigger, inclusi quelli condivisi dalle tecnologie pubblicitarie di pubblicazione.

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

Attribuzione

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

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

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

L'attribuzione per l'MMP ora include:

• Tecnologia pubblicitaria A, poiché l'MMP ha registrato una sorgente dal reindirizzamento di questa tecnologia pubblicitaria.
• Tecnologia pubblicitaria B, poiché la tecnologia pubblicitaria B ha condiviso le chiavi e l'MMP l'ha inclusa nella configurazione dell'attribuzione.

L'attribuzione per l'MMP non include:

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

Debug

Per supportare il debug dell'attribuzione cross-network senza reindirizzamenti, un campo aggiuntivo, shared_debug_key, è disponibile per le tecnologie pubblicitarie da impostare al momento della registrazione dell'origine. Se impostato sulla registrazione della sorgente originale, verrà impostato anche sulla sorgente derivata corrispondente come debug_key durante la registrazione dell'attivazione per l'attribuzione cross-network senza reindirizzamenti. Questa chiave di debug è allegata come source_debug_key nei report sugli eventi e aggregati.

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

• Misurazione da app ad app in cui è consentito l'AdId
• Misurazione da app a web in cui è consentito l'utilizzo dell'ID pubblicità e la corrispondenza tra l'origine app e il trigger web
• Misurazione web-to-web (nella stessa app browser) quando ar_debug` è presente sia nell'origine che nel trigger

Scoperta delle chiavi per l'attribuzione cross-network senza reindirizzamenti

La scoperta delle chiavi ha lo scopo di semplificare il modo in cui le tecnologie pubblicitarie (di solito gli MMP) implementano la configurazione dell'attribuzione ai fini dell'attribuzione cross-network quando una o più tecnologie pubblicitarie di pubblicazione utilizzano chiavi di aggregazione condivise (come descritto in Attribuzione cross-network senza reindirizzamenti sopra).

Quando una MMP esegue una query sul servizio di aggregazione per generare report di riepilogo per campagne che includono origini derivate, il servizio di aggregazione richiede alla 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 può essere molto lungo o sconosciuto. Gli elenchi di chiavi possibili sono difficili da monitorare e probabilmente sono piuttosto complessi e costosi da elaborare. Considera i seguenti esempi:

• L'elenco di tutte le chiavi possibili è lungo:
  • Una rete pubblicitaria che pubblica annunci sta eseguendo un'iniziativa complessa di acquisizione utenti che include 20 campagne, ognuna con 10 gruppi di annunci e ogni gruppo di annunci con 5 creatività aggiornate ogni settimana in base al rendimento.
• L'elenco di tutte le chiavi possibili è sconosciuto:
  • Una rete pubblicitaria che pubblica annunci in molte app mobile in cui l'elenco completo degli ID app publisher non è noto al momento del lancio della campagna.
  • Un inserzionista lavora su più reti pubblicitarie di pubblicazione che non reindirizzano all'MMP durante la registrazione della sorgente; 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 della scoperta delle chiavi:

• Il servizio di aggregazione non richiede più un'enumerazione completa delle possibili chiavi di aggregazione.
• Anziché dover specificare l'elenco completo delle chiavi possibili, un MMP può creare un insieme di chiavi vuoto (o parzialmente vuoto) e impostare una soglia, in modo che nell'output vengano incluse solo le chiavi (non dichiarate in precedenza) con valori superiori alla soglia.
• La MMP riceve un report riepilogativo che include valori rumorosi per le chiavi che hanno valori di contribuzione superiori alla soglia impostata. Il report potrebbe includere anche chiavi che non hanno contributi di utenti reali associati e sono puramente rumore.
• La MMP utilizza il campo x_network_bit_mapping nella registrazione dei trigger per determinare a quale chiave corrisponde quale tecnologia pubblicitaria.
• 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 chiavi di aggregazione senza conoscerle in anticipo ed evitare di elaborare un volume elevato di chiavi sorgente a scapito di un rumore aggiunto.

Reindirizzamenti a catena

Fornendo più intestazioni Attribution-Reporting-Redirect in una risposta del server HTTPS di registrazione di origine o trigger, una tecnologia pubblicitaria può utilizzare l'API Attribution Reporting per eseguire più registrazioni di origine e trigger con una singola chiamata API di registrazione.

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

Entrambi i tipi di intestazioni sono facoltativi e nessuno può essere fornito se non sono necessari reindirizzamenti. Puoi fornire uno o entrambi i tipi di intestazioni. Le richieste di registrazione di origine e trigger (inclusi i reindirizzamenti) vengono ritentate in caso di errore di rete. Il numero di 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. Per ulteriori dettagli, consulta la guida all'implementazione cross-web e cross-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 dell'attribuzione (clic o visualizzazione) a pochi bit di dati di attivazione ad alta fedeltà.
• I report aggregabili non sono necessariamente collegati a un'origine di attribuzione specifica. Questi report forniscono dati sui trigger più ricchi e con una fedeltà superiore rispetto ai report a livello di evento, ma questi dati sono disponibili solo in forma aggregata.

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

Report a livello di evento

Dopo che un trigger viene attribuito a un'origine attribuzione, viene generato e memorizzato sul dispositivo un report a livello di evento finché non può essere inviato all'URL postback di ciascuna tecnologia pubblicitaria durante una delle finestre temporali per l'invio dei report, descritte in dettaglio più avanti in questa pagina.

I report a livello di evento sono utili quando sono necessarie pochissime informazioni sul trigger. I dati dei trigger a livello di evento sono limitati a 3 bit per i dati dei trigger per i clic, il che significa che a un trigger può essere assegnata una delle otto categorie, e a 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 specifico o un orario di attivazione. 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 come i seguenti:

• 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 che tutelano la privacy applicati a tutti i report

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

Limiti al numero di tecnologie pubblicitarie

Esistono limiti al numero di ad tech che possono registrarsi o ricevere report dall'API, con una proposta attuale che prevede 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 tecnologie pubblicitarie possono registrare una singola origine o un singolo trigger di attribuzione (tramite Attribution-Reporting-Redirect)

Limiti al numero di destinazioni univoche

Questi limiti rendono difficile la collusione di un insieme di tecnologie pubblicitarie tramite l'interrogazione di 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 supporta non più di 200 destinazioni uniche per app di origine al minuto.
• Per una singola tecnologia pubblicitaria, l'API supporta non più di 50 destinazioni uniche al minuto per app di origine in tutte le origini registrate. Questo limite impedisce a una tecnologia pubblicitaria di utilizzare l'intero budget del limite di frequenza menzionato in precedenza.

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

Un'origine dei report per app di origine al giorno

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

Considera lo scenario seguente, in cui una singola tecnologia pubblicitaria vuole utilizzare più origini dei 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 della tecnologia pubblicitaria A, verrà rifiutata dall'API. L'origine report 2 della tecnologia pubblicitaria A non potrebbe registrare correttamente una sorgente sullo stesso dispositivo nell'app B fino al giorno successivo.

Periodo di raffreddamento e limiti di frequenza

Per limitare la quantità di informazioni sull'identità dell'utente tra una coppia {origine, destinazione}, l'API limita la quantità totale di informazioni inviate in un determinato periodo di tempo per un utente.

L'attuale proposta prevede di limitare ogni tecnologia pubblicitaria a 100 trigger 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ò tentare di misurare. Più basso è il limite, più difficile è per una tecnologia pubblicitaria utilizzare l'API per tentare di misurare l'attività di navigazione degli utenti non associata alla visualizzazione degli annunci.

La proposta attuale prevede di limitare ogni tecnologia pubblicitaria a 100 destinazioni distinte con origini non scadute per app di origine.

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

Fidelizzazione limitata dei dati dei trigger

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

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

Framework per il rumore della privacy differenziale

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

Il rumore viene applicato per stabilire se un evento di origine dell'attribuzione viene segnalato in modo veritiero. Una sorgente di attribuzione viene registrata sul dispositivo con probabilità $ 1-p $ che la sorgente di attribuzione venga registrata normalmente e con probabilità $ p $ che il dispositivo scelga in modo casuale tra tutti i possibili stati di output dell'API (incluso il mancato invio di qualsiasi report o l'invio di più report falsi).

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

Per valori bassi di ε, l'output reale è protetto dal meccanismo di risposta k-randomizzato. I parametri esatti del rumore sono in fase di elaborazione 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 relativi agli attivatori disponibili (conversioni)

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

• 1-2 attivatori per le origini dell'attribuzione della visualizzazione di annunci (2 attivatori disponibili solo in caso di attribuzione post-installazione)
• 3 trigger per le origini dell'attribuzione degli annunci con clic

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

I report a livello di evento per le origini di attribuzione delle visualizzazioni di annunci vengono inviati 1 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 dell'attribuzione di visualizzazione dell'annuncio (tramite l'attribuzione post-installazione), i report a livello di evento possono essere inviati agli intervalli della finestra di generazione dei report specificati nel seguente modo.

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

• 2 giorni:il dispositivo raccoglie tutti i trigger 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 i trigger che si sono verificati più di 2 giorni, ma non più di 7 giorni dopo la registrazione dell'origine dell'attribuzione. Il report viene inviato 7 giorni e 1 ora dopo la registrazione dell'origine attribuzione.
• Un periodo di tempo personalizzato,definito dall'attributo "expiry" di un'origine dell'attribuzione. Il report viene inviato 1 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 le tecnologie pubblicitarie sono invitate a utilizzare quando iniziano i test di utilità, ma potrebbe non essere ideale per tutti i casi d'uso. L'API Attribution Reporting supporterà configurazioni facoltative e più flessibili, in modo che le tecnologie pubblicitarie abbiano un maggiore controllo sulla struttura dei report a livello di evento e possano massimizzare l'utilità dei dati.

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

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

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

• Varia la frequenza dei report specificando il numero di finestre del report
• Variare il numero di attribuzioni per registrazione della fonte
• Ridurre la quantità di rumore totale diminuendo i parametri precedenti
• Configurare le finestre di reporting anziché utilizzare quelle predefinite

La fase 2 (a livello di evento completamente flessibile) potrebbe essere utilizzata per eseguire tutte le funzionalità della fase 1 e:

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

Se riduci una dimensione della configurazione predefinita, la tecnologia pubblicitaria può 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 menzionati in precedenza.

Oltre a impostare dinamicamente i livelli di rumore in base alla configurazione scelta da una tecnologia pubblicitaria, avremo alcuni limiti dei parametri per evitare costi di calcolo elevati e configurazioni con troppi stati di output (in cui il rumore aumenterà notevolmente). Ecco un esempio di insieme di limitazioni. Ti invitiamo a fornire un feedback sulla proposta di design:

• Un massimo di 20 report totali, a livello globale e per trigger_data
• Massimo 5 possibili finestre di generazione di report per trigger_data
• Cardinalità massima di 32 dati di attivazione (non applicabile alla fase 1: livello evento flessibile Lite)

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

Report aggregabili

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

I report aggregabili forniscono dati di attivazione a fedeltà più elevata dal dispositivo più rapidamente, oltre a quanto offerto per i report a livello di evento. Questi dati ad alta fedeltà possono essere appresi solo in aggregato e non sono associati a un trigger o a un utente specifico. Le chiavi di aggregazione hanno una lunghezza massima di 128 bit e consentono ai report aggregabili di supportare casi d'uso di reporting come i seguenti:

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

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

La progettazione complessiva di come l'API Attribution Reporting prepara e invia i report aggregabili, mostrata nel diagramma, è la seguente:

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

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

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

Servizi di aggregazione

I seguenti servizi forniscono funzionalità di aggregazione dei dati e proteggono dall'accesso non autorizzato ai dati aggregati.

Questi servizi sono gestiti da parti diverse, descritte in modo più dettagliato più avanti in questa pagina:

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

Servizio di aggregazione

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

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

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

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

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

Key Management Service

Questo servizio verifica che un servizio di aggregazione esegua una versione approvata del binario e poi fornisce al servizio di aggregazione nella tecnologia pubblicitaria le chiavi di decrittografia corrette per i dati dei trigger.

Contabilizzazione dei report aggregabili

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

API Aggregatable Reports

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

Registrare i dati di origine aggregabili

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

• (Key) Key name: 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) Pezzo di chiave:un valore bitstring per la chiave.

La chiave del bucket dell'istogramma finale è completamente definita al momento dell'attivazione eseguendo un'operazione OR binaria su queste parti e su quelle lato trigger.

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

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

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

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

La registrazione dei trigger include due campi aggiuntivi.

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

• Componente chiave:un valore bitstring per la chiave.
• Chiavi sorgente:un elenco di stringhe con i nomi delle chiavi lato sorgente dell'attribuzione con cui la chiave trigger deve essere combinata per formare le chiavi finali.

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

Ogni trigger può dare più contributi ai report aggregabili. L'importo totale dei contributi a un determinato evento di origine è vincolato da un parametro $ L1 $, che è la somma massima dei contributi (valori) in tutte le chiavi aggregate per una determinata origine. $ L1 $ si riferisce alla sensibilità o alla norma L1 dei contributi dell'istogramma per evento di origine. Il superamento di questi limiti causa l'eliminazione silenziosa dei contributi futuri. La proposta iniziale è di impostare $ L1 $ su $ 2^{16} $ (65536).

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

Nell'esempio seguente, il budget per la privacy viene suddiviso equamente tra campaignCounts e geoValue dividendo il contributo di $ L1 $ 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 scalabilità possono essere invertiti per ottenere i valori corretti, modulo rumore applicato:

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

Privacy differenziale

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

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

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

Grazie a questa integrazione cross-API, le ad tech possono:

• Crea una mappa di coppie chiave-valore di URI da utilizzare per 1) la generazione di report sulle interazioni e 2) la registrazione delle origini.
• Includi CustomAudience nel mapping delle chiavi lato origine per i report di riepilogo aggregati (utilizzando l'API Attribution Reporting).

Quando un utente visualizza o fa clic su un annuncio:

• L'URL utilizzato per segnalare queste interazioni 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 CustomAudience (o altre informazioni contestuali pertinenti sull'annuncio, come il posizionamento dell'annuncio o la durata della visualizzazione) utilizzando questo URL in modo che questi metadati possano essere propagati ai report di riepilogo quando la tecnologia pubblicitaria esamina il rendimento aggregato della campagna.

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

Esempi di priorità di registrazione, attribuzione e report

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

• Tutte le origini e i trigger dell'attribuzione vengono registrati dalla stessa tecnologia pubblicitaria per lo stesso inserzionista.
• Tutte le origini e tutti i trigger di attribuzione si verificano durante la prima finestra di reporting degli eventi (entro 2 giorni dalla visualizzazione iniziale degli annunci in un'app publisher).

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

1. L'utente vede un annuncio. La tecnologia pubblicitaria registra una sorgente di attribuzione con l'API, con una priorità di 0 (visualizzazione n. 1).
2. L'utente vede un annuncio registrato con una priorità di 0 (visualizzazione n. 2).
3. L'utente fa clic su un annuncio registrato con una priorità di 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 trigger con l'API, con una priorità di 0 (conversione n. 1).
   • Man mano che i trigger vengono registrati, l'API esegue prima l'attribuzione prima di generare i report.
   • Sono disponibili tre origini attribuzione: visualizzazione 1, visualizzazione 2 e clic 1. L'API attribuisce questo trigger al clic n. 1 perché è quello con la priorità più alta e più recente.
   • La visualizzazione 1 e la visualizzazione 2 vengono eliminate e non sono più idonee per l'attribuzione futura.
5. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrata con una priorità di 1 (conversione n. 2).
   • Il primo clic è l'unica origine di attribuzione idonea. L'API attribuisce questo trigger al clic n. 1.
6. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrata con una priorità di 1 (conversione n. 3).
   • Il primo clic è l'unica origine di attribuzione idonea. L'API attribuisce questo trigger al clic n. 1.
7. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrata con una priorità di 1 (conversione n. 4).
   • Il primo clic è l'unica origine di attribuzione idonea. L'API attribuisce questo trigger al clic n. 1.
8. L'utente effettua un acquisto nell'app dell'inserzionista, registrato con una priorità di 2 (conversione n. 5).
   • Il primo clic è l'unica origine di attribuzione idonea. L'API attribuisce questo trigger al clic n. 1.

I report a livello di evento hanno le seguenti caratteristiche:

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

I report aggregabili hanno le seguenti caratteristiche:

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

  In qualità di ad tech, crei i batch in base alle informazioni che vengono trasmesse non criptate nei report aggregabili. Queste informazioni sono contenute nel campo shared_info del report aggregabile e includono timestamp e origine del report. Non puoi eseguire il batch in base a informazioni criptate nelle coppie chiave-valore di aggregazione. Alcune strategie di base che puoi seguire sono raggruppare i report giornalieri o settimanali. Idealmente, i batch dovrebbero contenere almeno 100 report ciascuno.

• Spetta alla tecnologia pubblicitaria decidere quando e come raggruppare in batch i report aggregabili e inviarli al servizio di aggregazione.

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

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

Report di debug transitorio

L'API Attribution Reporting è un modo nuovo e piuttosto complesso per eseguire la misurazione dell'attribuzione senza identificatori cross-app. Pertanto, stiamo supportando un meccanismo di transizione per ottenere maggiori informazioni 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 dell'ID pubblicità). Ciò garantisce che l'API possa essere compresa appieno durante l'implementazione, contribuisce a eliminare eventuali bug e consente di confrontare più facilmente il rendimento con 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 sul debug dei report con la misurazione da app a web e da web ad app.

Report di debug sull'attribuzione riuscita

Le registrazioni di origine e 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 passati invariati sia nei report a livello di evento che in quelli aggregati.

Se viene creato un report con chiavi di debug sia di origine sia 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 e includono entrambi i campi delle chiavi di debug. L'inclusione di queste chiavi in entrambi consente di collegare i report normali al flusso separato dei report di debug.

• Per i report a livello di evento:
  • I report di debug duplicati vengono inviati con un ritardo limitato e pertanto non vengono eliminati dai limiti relativi ai trigger disponibili, il che consente alla tecnologia pubblicitaria di comprendere l'impatto di questi limiti per i report a livello di evento.
  • I report a livello di evento associati a eventi trigger falsi non avranno trigger_debug_key. Ciò consente alle tecnologie pubblicitarie di comprendere meglio come viene applicato il rumore nell'API.
• Per i report aggregabili:
  • Supporteremo un nuovo campo debug_cleartext_payload che contiene 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 nelle registrazioni di origini attribuzione o trigger. Questi report di debug vengono inviati con un ritardo limitato dopo le registrazioni di origini o trigger di attribuzione a un .Endpoint well-known/attribution-reporting/debug/verbose.

Ogni report dettagliato contiene i seguenti campi:

• Tipo: la causa della generazione del report. Consulta l'elenco completo dei tipi di report dettagliati.
  • In generale, esistono report dettagliati sull'origine e report dettagliati sul trigger.
  • I report dettagliati sull'origine richiedono che l'ID pubblicità sia disponibile per l'app publisher, mentre i report dettagliati sui trigger richiedono che l'ID pubblicità sia disponibile per l'app inserzionista.
  • I report dettagliati sui trigger (ad eccezione di trigger-no-matching-source) possono includere facoltativamente source_debug_key. Può essere incluso solo se l'ID pubblicità è disponibile anche per l'app editore.
• Corpo: il corpo della segnalazione, che dipende dal tipo.

Le tecnologie pubblicitarie 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 sull'origine richiedono l'attivazione solo nell'intestazione di registrazione dell'origine.
• I report di debug degli attivatori richiedono l'attivazione solo nell'intestazione di registrazione dell'attivatore.

Come utilizzare i report di debug

Se si è verificata una conversione (in base al sistema di misurazione esistente) ed è stato ricevuto un report di debug per quella conversione, significa che il trigger è 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.

Quando non c'è corrispondenza, i motivi possono essere diversi.

Funziona come previsto:

• Comportamenti delle API che tutelano la privacy:
  • Un utente raggiunge il limite di frequenza dei report, il che impedisce l'invio di tutti i report successivi nel periodo di tempo; oppure una sorgente viene rimossa a causa del limite di destinazione in attesa.
  • Per i report a livello di evento: il report è soggetto a una risposta casuale (rumore) e viene eliminato oppure potresti ricevere un report casuale.
  • 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.
  • Sono stati superati i limiti di contributo per i report aggregabili.
• Logica di business definita dalla tecnologia pubblicitaria:
  • Un trigger viene filtrato utilizzando filtri o regole di priorità.
• Ritardi o interazioni con la disponibilità di rete (ad es. l'utente spegne il dispositivo per un periodo di tempo prolungato).

Cause non intenzionali:

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

Considerazioni future e domande aperte

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

Inoltre, vorremmo ricevere feedback dalla community su alcuni problemi:

1. Esistono casi d'uso in cui vorresti che l'API inviasse report per l'installazione verificata? Questi report verranno conteggiati ai fini dei limiti di frequenza rispettivi delle piattaforme di tecnologia pubblicitaria.
2. Prevedi difficoltà con il trasferimento di InputEvent dall'app alla tecnologia pubblicitaria per la registrazione dell'origine?
3. Hai casi d'uso speciali per l'attribuzione per app precaricate o reinstallate?