Panoramica di Attribution Reporting per dispositivi mobili

Nota: questo documento riflette Privacy Sandbox sulle attuali proposte di design di Android ed è soggetti a ulteriori modifiche. Invitiamo i tuoi feedback e i tuoi commenti per aiutarci a queste iniziative.

Inviare un feedback

Aggiornamenti recenti

• È stato aggiornato l'elenco delle prossime modifiche e dei problemi noti
• Introduzione della configurazione flessibile a livello di evento Lite, come ponte per l'intera configurazione flessibile a livello di evento
• A partire da settembre 2023, registerWebSource, registerWebTrigger, registerAppSource e registerAppTrigger devono utilizzare stringhe per i campi che si aspetta un valore numerico (ad esempio priority, source_event_id, debug_key, trigger_data, deduplication_key e così via)
• Nel quarto trimestre del 2023, il supporto di Google Cloud nell'API Android Attribution Reporting Essere aggiunta per generare report di riepilogo utilizzando il servizio di aggregazione su Google Cloud, qui si riflettono le tempistiche più specifiche. Per saperne di più, consulta la guida al deployment informazioni sulla configurazione del servizio di aggregazione con Google Cloud.
• Nuovi limiti di frequenza per la tutela della privacy per il numero di destinazioni uniche.
• La funzionalità aggiornata per i filtri degli attivatori delle finestre temporali sarà disponibile nel primo trimestre del 2024. Consulta la nota per ulteriori informazioni.

Panoramica

Attualmente, le soluzioni di attribuzione e misurazione mobile usano spesso identificatori trasversali come l'ID pubblicità. L'API Attribution Reporting è progettato per migliorare la privacy dell'utente eliminando il ricorso alla condivisione identificatori degli utenti e per supportare casi d'uso chiave per l'attribuzione e le conversioni la misurazione nelle app e sul web.

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

• Limita il numero di bit disponibili per report a livello di evento
• Consente di ottenere dati sulle conversioni più affidabili solo in 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 tra due app o domini diversi.

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

• Report sulle conversioni:consentono agli inserzionisti di misurare il rendimento del loro campagne mostrando il numero di conversioni (attivatore) e le conversioni (attivatore) in varie dimensioni, ad esempio per campagna, gruppo di annunci e la creatività dell'annuncio.
• Ottimizzazione:fornisce report a livello di evento che supportano l'ottimizzazione di sulla spesa pubblicitaria, fornendo dati di attribuzione per impressione che possono essere utilizzati per: addestrare i modelli ML.
• Rilevamento di attività non valide:fornisce report che possono essere utilizzati negli annunci non validi. rilevamento e analisi del traffico e delle frodi pubblicitarie.

A livello generale, l'API Attribution Reporting funziona come segue, che in seguito di questo documento descrivono in modo più dettagliato:

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

di Gemini Advanced.

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

Accedere alle API Attribution Reporting

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

Registrare un'origine attribuzione (clic o visualizzazione)

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

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

Quando l'API effettua 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 di origine: questo valore rappresenta i dati a livello di evento associati. con questa origine di attribuzione (visualizzazione o clic sull'annuncio). Deve essere un file non firmato a 64 bit numero intero formattato come stringa.
• Destinazione: un'origine il cui eTLD+1 o il nome del pacchetto dell'app in cui si verifica un evento di trigger.
• Scadenza (facoltativo): scadenza, in secondi, per quando l'origine deve essere. eliminato 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 un numero intero senza segno o una stringa a 64 bit.
• (Facoltativo) Finestra del report sugli eventi: durata in secondi dopo l'origine. registrazione durante la quale è possibile creare report sugli eventi per questa origine. Se la finestra del report sugli eventi è trascorsa, ma la scadenza non è ancora trascorsa, l'attivatore può comunque essere abbinato a un'origine, ma il report sugli eventi non inviati per quel trigger. Non può essere superiore alla scadenza. Formattabile come un numero intero senza segno o una stringa a 64 bit.
• Finestra del report aggregatore (facoltativa): durata in secondi dopo l'origine. durante i quali è possibile creare report aggregabili per questo sorgente. Non può essere superiore alla scadenza. Può essere formattato come file a 64 bit un valore intero senza segno o una stringa.
• Priorità origine (facoltativo): utilizzata per selezionare l'origine dell'attribuzione a cui a cui deve essere associato un determinato attivatore, nel caso in cui le attribuzioni multiple e le origini potrebbero essere associate al trigger. Deve essere un modello a 64 bit numero intero formattato come stringa.
  
  Quando viene ricevuto un trigger, l'API trova l'origine di attribuzione corrispondente con il valore di priorità più alto per la sorgente e genera un report. Ogni piattaforma di ad tech può definire la propria di definizione delle priorità. Per ulteriori dettagli sull'impatto della priorità Consulta la sezione relativa all'esempio di assegnazione delle priorità.
  
  Superiore indicano priorità più elevate.
• Finestre di attribuzione installazione e post-installazione (facoltativo): utilizzato per Determinare l'attribuzione per gli eventi post-installazione, descritti più avanti in questa pagina.
• (Facoltativo) Filtra i dati: utilizzato per filtrare selettivamente alcuni attivatori, ignorandoli efficacemente. Per ulteriori dettagli, consulta filtri attivatori di questa pagina.
• (Facoltativo) Chiavi di aggregazione: specifica segmentazione da utilizzare per report aggregabili.

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

La guida per gli sviluppatori include esempi che mostrano come accettare la registrazione di origine.

I passaggi seguenti mostrano un flusso di lavoro di esempio:

1. L'SDK ad tech chiama l'API per avviare la registrazione dell'origine 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 ad tech risponde con intestazioni contenenti quanto segue:

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

4. L'API effettua una richiesta a ciascun URL specificato Attribution-Reporting-Redirect. In questo esempio, due URL di partner vengono specificati, quindi l'API effettua una richiesta https://adtechpartner1.example?their_ad_click_id=567 e un'altra richiesta a https://adtechpartner2.example?their_ad_click_id=890.

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

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

   Nota: ad tech le risposte possono specificare diversi metadati Attribution-Reporting-Register-Source.

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

Registrare un'origine di attribuzione da WebView

WebView supporta il caso d'uso in cui un'app esegue il rendering di un annuncio 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. Registrazione di origini da contenuti web incorporati all'interno di un contesto del browser, sia i chiamanti dell'API che le app devono per regolare le impostazioni. Consulta la sezione Registra l'origine dell'attribuzione e attiva da WebView per istruzioni per i chiamanti dell'API e Per istruzioni, procedi all'origine dell'attribuzione e attiva la registrazione da WebView per le app.

Poiché i tecnici pubblicitari utilizzano codice comune su Web e WebView, WebView segue HTTP 302 reindirizza alla piattaforma le registrazioni valide. Non prevediamo per supportare l'intestazione Attribution-Reporting-Redirect in questo scenario, contattaci se hai un caso d'uso interessato.

Registra un attivatore (conversione)

Le piattaforme di ad tech possono registrare gli attivatori, come installazioni o eventi post-installazione con il metodo registerTrigger().

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

L'API segue i reindirizzamenti. La risposta del server ad tech deve includere una richiesta HTTP chiamata Attribution-Reporting-Register-Trigger, che rappresenta informazioni su uno o più trigger registrati. I contenuti dell'intestazione devono essere Codifica JSON e includere i seguenti campi:

• Dati attivatore: dati utilizzati per identificare l'evento di trigger (3 bit per i clic, 1 per le viste). Deve essere un numero intero con segno a 64 bit formattato come stringa.
• (Facoltativo) Priorità dell'attivatore: rappresenta la priorità di questo attivatore rispetto ad altri attivatori per la stessa origine di attribuzione. Deve essere a 64 bit numero intero con segno formattato come stringa. Per ulteriori dettagli su come la priorità influisce sui report, consulta la sezione relativa all'assegnazione delle priorità.
• Chiave di deduplicazione (facoltativa): utilizzata per identificare i casi in cui l'attivatore viene registrato più volte dalla stessa piattaforma di tecnologia pubblicitaria, la stessa origine dell'attribuzione. Deve essere un numero intero a 64 bit formattato come stringa.
• Chiavi di aggregazione (facoltative): A elenco di dizionari che specificano le chiavi di aggregazione e i report aggregabili.
• (Facoltativo) Valori di aggregazione: un elenco di quantità di valore che contribuiscono a ogni chiave.
• Filtri (facoltativi): utilizzati per filtrare selettivamente. o attivare i dati. Per ulteriori dettagli, consulta filtri attivatori di questa pagina.

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

Più esperti di tecnologia pubblicitaria possono registrare lo stesso evento di attivazione utilizzando entrambi i reindirizzamenti in campo Attribution-Reporting-Redirect o più chiamate al Metodo registerTrigger(). Ti consigliamo di utilizzare la chiave di deduplicazione per evitare di includere attivatori duplicati nei report nel caso in cui ad tech fornisce più risposte per lo stesso evento di trigger. Scopri di più su come e quando utilizzare una chiave di deduplicazione.

La guida per gli sviluppatori include esempi che mostrano come accetta la registrazione trigger.

I passaggi seguenti mostrano un flusso di lavoro di esempio:

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

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

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

3. Il server HTTPS di questa 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
   

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

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

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

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

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

Funzionalità di attribuzione

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

Algoritmo di attribuzione con priorità all'origine applicato

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

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

• Puoi attribuire gli attivatori a determinati eventi relativi agli annunci piuttosto che ad altri. Ad esempio: puoi scegliere di enfatizzare i clic piuttosto che le visualizzazioni oppure sugli eventi di determinate campagne.
• Puoi configurare l'origine dell'attribuzione e attivare l'attivatore in modo che, se premi di frequenza cardiaca, è più probabile che ricevano i report che sono per te è importante. Ad esempio, potresti voler fare in modo che conversioni o conversioni di valore elevato hanno maggiori probabilità di report.

Nel caso in cui più ad tech registrano un'origine di attribuzione, come descritto più avanti in questa pagina, questa attribuzione avviene indipendentemente ciascuna tecnologia pubblicitaria. Per ogni tecnologia pubblicitaria, l'origine di attribuzione con la priorità più elevata. viene attribuito all'evento trigger. Se ci sono più origini dell'attribuzione con la stessa priorità, l'API sceglie l'ultima origine di attribuzione registrata. Tutte le altre origini di attribuzione che non vengono selezionate vengono ignorate e non vengono non sarà più idoneo per l'attribuzione futura dell'attivazione.

Filtri attivatore

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

• Filtrare selettivamente alcuni attivatori ignorandoli efficacemente.
• Scegli i dati dei trigger per i report a livello di evento in base ai dati di origine.
• Scegli di escludere un attivatore dai report a livello di evento.

Per filtrare selettivamente gli attivatori, la tecnologia pubblicitaria può specificare i dati del filtro, di chiavi e valori, durante la registrazione di origine e di trigger. Se la stessa chiave è specificato sia per l'origine sia per l'attivatore, l'attivatore viene ignorato se l'incrocio è vuoto. Ad esempio, un'origine può specificare "product": ["1234"], dove product è la chiave del filtro e 1234 è il valore. Se il filtro trigger è impostato su "product": ["1111"], l'attivatore viene ignorato. In caso contrario, chiave di filtro dell'attivatore corrispondente a product, i filtri vengono ignorati.

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

Per stabilire se un filtro corrisponde, l'API controlla innanzitutto la finestra di ricerca. Se disponibile, la durata dalla registrazione dell'origine deve essere minore o uguale a alla durata della finestra temporale.

Nota: la logica e la funzionalità del filtro temporale descritte saranno attive in D124. Puoi trovare dettagli più specifici sulle tempistiche di pubblicazione. Logica precedente finestre temporali richieste che devono essere specificate all'ora, sia sul sito di origine che lato trigger. Questa logica delle funzionalità aggiornata è incompatibile con le versioni precedenti, il che significa origini che utilizzano la precedente "_lookback_window" la chiave non avrà esito positivo registrati.

Le piattaforme di ad tech possono anche scegliere di attivare dati in base ai dati sugli eventi di origine. Per 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.
• Origine e attivatore specificano la stessa chiave di filtro, ma i valori non corrispondono. Tieni presente che, in questo caso, l'attivatore viene ignorato sia a livello di evento che aggregabili.

Attribuzione post-installazione

In alcuni casi, è necessario che i trigger post-installazione vengano attribuiti al la stessa origine di attribuzione che ha generato l'installazione, anche se sono presenti altre più recenti.

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

• Quando registri un'origine attribuzione, specifica un'attribuzione delle installazioni finestra durante il quale sono previste le installazioni (generalmente 2-7 giorni, da 1 a 30 giorni). Specifica questa finestra temporale come un numero di secondi.
• Quando registri un'origine attribuzione, specifica un'attribuzione post-installazione finestra di esclusività in cui dovrebbero trovarsi tutti gli eventi trigger post-installazione associate all'origine di attribuzione che ha generato l'installazione (generalmente 7-30 giorni, intervallo accettato da 0 a 30 giorni). Specifica questa finestra temporale come di secondi.
• L'API Attribution Reporting verifica quando avviene l'installazione di un'app e attribuisce internamente l'installazione all'attribuzione che dà priorità alla fonte sorgente. Tuttavia, l'installazione non viene inviata al team AdTech e non viene considerata ai fini del calcolo della piattaforma i rispettivi limiti di frequenza.
• La convalida dell'installazione delle app è disponibile per qualsiasi app scaricata.
• Eventuali attivatori futuri che si verificano all'interno della finestra di attribuzione post-installazione vengono attribuiti alla stessa origine di attribuzione dell'installazione convalidata, purché l'origine dell'attribuzione sia idonea.

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

La tabella seguente mostra un esempio di come i tecnici pubblicitari possono utilizzare la post-installazione l'attribuzione dei contenuti. Supponiamo che tutte le origini e gli attivatori di attribuzione vengano registrati da sulla stessa rete ad tech e tutte le priorità sono le stesse.

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

Il seguente elenco fornisce alcune note aggiuntive relative alla fase post-installazione attribuzione:

• Se l'installazione verificata non avviene entro il numero di giorni specificato entro il giorno install_attribution_window, l'attribuzione post-installazione non viene applicata.
• Le installazioni verificate non vengono registrate dai tecnici pubblicitari e non vengono inviate report. Non vengono conteggiate ai fini dei limiti di frequenza di un ad tech. Installazioni verificate vengono utilizzati solo per identificare l'origine di attribuzione a cui viene attribuita la installare l'app.
• Nell'esempio della tabella precedente, il trigger 1 e il trigger 2 rappresentano un conversione per la prima apertura e una conversione post-installazione. Tuttavia, ad tech possono registrare qualsiasi tipo di trigger. In altre parole, la prima un trigger di prima apertura.
• Se vengono registrati altri attivatori dopo post_install_exclusivity_window scade, il clic 1 è ancora idoneo per l'attribuzione, supponendo che non sia è scaduto e non ha raggiunto i limiti di frequenza.
  • Il clic 1 potrebbe comunque perdere o essere eliminato, se una priorità più alta sia registrata l'origine dell'attribuzione.
• Se l'app dell'inserzionista viene disinstallata e reinstallata, la reinstallazione viene conteggiata come nuova installazione verificata.
• Se invece il clic 1 è stato un evento di visualizzazione, viene utilizzato entrambi i valori e post-installazione gli attivatori sono ancora attribuiti. L'API limita l'attribuzione a uno attiva per visualizzazione, tranne nel caso dell'attribuzione post-installazione, dove fino a sono consentiti due attivatori per vista. Nel caso dell'attribuzione post-installazione, ad tech può ricevere 2 finestre di reporting diverse (a 2 giorni o alla fonte la scadenza del periodo di conservazione).

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

Consentiamo ai browser web di supportare nuove funzionalità esposte al web, come una funzionalità simile Privacy Sandbox per l'API Attribution Reporting per il web che possono chiamare le API Android per attivare l'attribuzione nelle app e sul web.

Scopri di più sui cambiamenti che le app e le tecnologie pubblicitarie devono apportare per supportare percorsi dei trigger per misurazione cross-app e web.

Dare priorità a più attivatori per una singola origine di attribuzione

Una singola origine dell'attribuzione può generare più attivatori. Ad esempio, un il flusso di acquisto potrebbe prevedere un'"installazione di app" attiva una o più opzioni "aggiungi al carrello" trigger e un "purchase" trigger. Ogni attivatore è attribuito a uno o più fonti di attribuzione in base algoritmo di attribuzione con priorità alla fonte, descritti più avanti in questa pagina.

Esistono limiti al numero di attivatori che possono essere attribuiti a una singola attribuzione source; per ulteriori dettagli, leggi la sezione sulla visualizzazione dei dati di misurazione in report sull'attribuzione più avanti in questa pagina. Nei casi in cui ci siano più trigger che vanno oltre questi limiti, è utile introdurre per recuperare i trigger più preziosi. Ad esempio, gli sviluppatori di un ad tech potrebbe voler dare la priorità alle attività di "acquisto" attiva su "aggiungi al carrello" trigger.

Per supportare questa logica, è possibile impostare un campo di priorità separato sull'attivatore e gli attivatori con priorità più alta vengono selezionati prima dell'applicazione dei limiti, all'interno di un specifica finestra di reporting.

Nota: gli attivatori a priorità inferiore che sono già stati segnalati utilizzano sempre il budget.

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

È comune che più di una tecnologia pubblicitaria riceva i report sull'attribuzione. In genere, per eseguire la deduplicazione su più reti. Di conseguenza, l'API consente ad tech di registrare la stessa origine o attivatore di attribuzione. Un'ad tech deve registrare sia le origini di attribuzione sia gli attivatori per ricevere postback dalla API, mentre l'attribuzione avviene tra le origini dell'attribuzione e attiva che ad tech si sia registrato con l'API.

Inserzionisti che vogliono utilizzare una terza parte per eseguire su più reti la deduplicazione può continuare a farlo, utilizzando una tecnica simile alla seguente:

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

Origini di attribuzione

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

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

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

Inoltre, l'API consente a tecnologie pubblicitarie diverse per ogni chiamata registerSource().

Trigger

Per la registrazione dell'attivatore, le terze parti sono supportate in modo simile: le tecnologie pubblicitarie può utilizzare il campo Attribution-Reporting-Redirect aggiuntivo oppure possono chiamare il metodo registerTrigger().

Quando un inserzionista utilizza più tecnologie pubblicitarie per registrare lo stesso evento di attivazione, È necessario utilizzare una chiave di deduplicazione. La chiave di deduplicazione serve a distinguere questi report ripetuti relativi allo stesso evento, registrati dalla stessa tecnologia pubblicitaria completamente gestita. Ad esempio, un ad tech potrebbe far sì che il suo SDK chiami l'API direttamente registrare un attivatore e inserire il proprio URL nel campo di reindirizzamento del chiamata. Se non viene fornita alcuna chiave di deduplicazione, potrebbero essere segnalati trigger duplicati ogni tecnologia pubblicitaria come unica.

Gestire gli attivatori duplicati

Un ad tech può registrare lo stesso trigger più volte con l'API. Scenarios include:

• L'utente esegue la stessa azione (attivatore) più volte. Ad esempio: l'utente sfoglia lo stesso prodotto più volte negli stessi report finestra.
• 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 usa 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 si registrano che si attivano con l'attribuzione API di reporting. L'AdTech n. 3 riceve quindi due reindirizzamenti separati: uno MMP n. 1 e MMP n. 2, per lo stesso trigger.

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

Metodo consigliato: chiave di deduplicazione

Il metodo consigliato prevede che l'app dell'inserzionista trasmetta una deduplicazione univoca chiave per qualsiasi tecnologia pubblicitaria o SDK che usa per la misurazione delle conversioni. Quando 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.

I tecnici pubblicitari possono scegliere di registrare solo il primo attivatore con un determinato chiave di deduplicazione oppure puoi scegliere di registrare più trigger o tutti i trigger. I tecnici pubblicitari possono specificare il deduplication_key durante la registrazione di duplicati trigger.

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

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

Nei casi in cui i tecnici pubblicitari non vogliono utilizzare la chiave di deduplicazione l'app dell'inserzionista non può trasmettere una chiave di deduplicazione; esiste un'opzione alternativa. Tutti i tecnici pubblicitari che misurano le conversioni per un determinato inserzionista devono collaborare per definire tipi di trigger diversi per ogni inserzionista.

Le tecnologie pubblicitarie che avviano la chiamata di registrazione dell'attivatore, ad esempio gli SDK, includono una negli URL specificati in Attribution-Reporting-Redirect, ad esempio duplicate_trigger_id. Il parametro duplicate_trigger_id può includere informazioni come il nome dell'SDK e il tipo di attivatore per quell'inserzionista. Tecnologie pubblicitarie può inviare un sottoinsieme di questi trigger duplicati ai report a livello di evento. 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 annunci piattaforme tecnologiche (AdTech A e Ad tech B) e un partner di misurazione (MMP).

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

Il seguente elenco fornisce una serie ipotetica di azioni dell'utente che avvengono a un giorno di distanza e il modo in cui l'API Attribution Reporting gestisce queste azioni in merito ad Ad tech A, Ad tech B e MMP:

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

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

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

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

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

Come l'Ad tech A, l'Ad tech B ha incluso anche l'URI MMP nella Intestazione Attribution-Reporting-Redirect. L'API effettua una richiesta a MMP URI e il clic sia registrato con i metadati provenienti dal server MMP la risposta corretta.

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

L'API risponde come il primo giorno, ma la visualizzazione è registrati per AdTech A e MMP.

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

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

MMP include anche gli URI per Ad tech A e Ad tech B Intestazione Attribution-Reporting-Redirect. L'API invia richieste all'AdTech A e Ad tech B e la conversione viene registrata di conseguenza i metadati dalle risposte del server.

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

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

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 attribuita al clic del giorno 1.
• L'installazione viene attribuita ad AdTech B il secondo giorno.
• MMP imposta la priorità dei clic su un valore superiore a quello delle visualizzazioni e ottiene l'installazione attribuite al clic del secondo giorno. Il clic del giorno 2 ha la priorità più alta, l'evento annuncio più recente.

Attribuzione su più reti senza reindirizzamenti

Anche se consigliamo di utilizzare i reindirizzamenti per consentire la registrazione di più tecnologie pubblicitarie origini e fattori scatenanti dell'attribuzione, riconosciamo che possono verificarsi scenari in cui l'utilizzo di reindirizzamenti non è fattibile. In questa sezione viene illustrato come supportare su più reti senza reindirizzamenti.

Flusso di alto livello

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

Registrazione di origine

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

Le chiavi di aggregazione condivise sono disponibili per qualsiasi tecnologia pubblicitaria che registra un attivatore per per lo stesso inserzionista. Tuttavia, dipende dalla tecnologia pubblicitaria e dall'attivatore le tecnologie pubblicitarie di misurazione per collaborare sui tipi di chiavi di aggregazione necessarie, i nomi e come decodificare le chiavi in dimensioni leggibili.

Attiva registrazione

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

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

Attribuzione

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

• L'utente ha fatto clic sugli annunci pubblicati dalle tecnologie pubblicitarie A, B, C e D. L'utente quindi ha installato l'app dell'inserzionista, che utilizza un partner di tecnologia pubblicitaria per la 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.
• Ad tech D non reindirizza né condivide chiavi di aggregazione.

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

L'attribuzione per la MMP ora include:

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

L'attribuzione per il modello MMP non include:

• Ad tech C, poiché l'MMP non l'ha inclusa nella configurazione di attribuzione.
• Ad tech D, poiché non reindirizzano né condividono le chiavi di aggregazione.

di Gemini Advanced.

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

Debug

Per supportare il debug per l'attribuzione su più reti senza reindirizzamenti, è disponibile un campo aggiuntivo, shared_debug_key, che il team ad tech può impostare registrazione di origine. Se impostata nella registrazione di origine originale, impostato nell'origine derivata corrispondente come debug_key durante la registrazione del trigger per l'attribuzione su più reti senza reindirizzamenti. Questa chiave di debug è collegata come source_debug_key nei report sugli eventi e aggregati.

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

• Misurazione da app a app in cui si trova l'ID pubblicità consentito
• Misurazione da app a web in cui l'ID pubblicità è consentito e corrisponde a sia l'origine dell'app che l'attivatore web
• La misurazione da Web a Web (lo stesso browser) quando è presente ar_debug sia nell'origine che nell'attivatore

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

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

Quando una MMP interroga il servizio di aggregazione per generare report di riepilogo per di campagne che includono origini derivate, il servizio di aggregazione richiede l'MMP e specificare l'elenco di possibili chiavi come input per il job di aggregazione. In alcuni casi, l'elenco delle potenziali chiavi di aggregazione dell'origine può essere molto lungo oppure sconosciuto. Elenchi lunghi di possibili chiavi sono difficili da monitorare e sono anche piuttosto complessa e costosa da elaborare. Considera quanto segue. esempi:

• L'elenco di tutte le chiavi possibili è lungo:
  • Una rete pubblicitaria pubblicata sta conducendo una complessa iniziativa di acquisizione utenti che include 20 campagne, ognuna con 10 gruppi di annunci, e ogni gruppo di annunci con cinque creatività che vengono aggiornate ogni settimana in base al rendimento.
• L'elenco di tutte le chiavi possibili è sconosciuto:
  • Una rete pubblicitaria pubblica pubblica annunci su molte app mobile in cui l'elenco completo degli ID app dei publisher non è noto al momento del lancio della campagna.
  • Un inserzionista sta lavorando su più reti pubblicitarie pubblicate che sono Non reindirizzare a MMP alla registrazione di origine. ogni annuncio pubblicato rete ha una struttura e valori chiave diversi, che potrebbero non essere condivise in anticipo con l'MMP.

Con l'introduzione della funzionalità Key Discovery:

• Il servizio di aggregazione non richiede più l'enumerazione completa dei possibili e le chiavi di aggregazione.
• Anziché specificare l'elenco completo delle possibili chiavi, un file MMP può creare un insieme di chiavi vuoto (o parzialmente vuoto) e impostare una soglia, in modo che (non predichiarate) le chiavi con valori che superano la soglia sono incluse in l'output.
• MMP riceve un rapporto di riepilogo che include valori "rumorosi" per le chiavi presentano valori contributivi superiori alla soglia impostata. Il report può includere anche Chiavi a cui non sono associati contributi reali degli utenti e che sono puramente rumorosi.
• MMP utilizza il campo x_network_bit_mapping nella registrazione dell'attivatore per determinare quale tecnologia pubblicitaria corrisponde a ciascuna chiave.
• MMP può quindi contattare la tecnologia pubblicitaria di pubblicazione appropriata per comprendere i valori. nella chiave di origine.

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

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

Visualizzare i dati di misurazione nei report sull'attribuzione

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

• I report a livello di evento associano una determinata Origine dell'attribuzione (clic o visualizzazione) con bit limitati di alta fedeltà attivare i dati.
• I report aggregati non sono necessariamente collegati con una specifica origine di attribuzione. Questi report forniscono dati più dettagliati precisione superiore dei dati di trigger rispetto ai report a livello di evento, ma questi dati sono disponibili in forma aggregata.

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

Report a livello di evento

Dopo che un attivatore viene attribuito a un'origine di attribuzione, viene generato un report a livello di evento. generati e archiviati sul dispositivo finché non può essere inviato al server URL postback durante uno degli finestre temporali per l'invio di rapporti, descritti più dettagliatamente più avanti in questa pagina.

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

Il report a livello di evento contiene dati come i seguenti:

• Destinazione:nome del pacchetto dell'app dell'inserzionista o eTLD+1 in cui l'attivatore successo
• Attribution Source ID: lo stesso ID origine dell'attribuzione utilizzato per registrare un'origine di attribuzione
• Tipo di trigger:1 o 3 bit di dati di trigger a bassa fedeltà, a seconda del tipo di origine dell'attribuzione

Meccanismi incentrati sulla tutela della privacy applicati a tutte le segnalazioni

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

Limiti al numero di tecnologie pubblicitarie

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

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

Limiti del numero di destinazioni univoche

Questi limiti rendono difficile per un insieme di tecnologie pubblicitarie eseguire query su una 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 non supporta più di oltre 200 destinazioni uniche al minuto per app di origine.
• In tutti i video registrati per una singola tecnologia pubblicitaria, l'API supporta non più di 50 destinazioni, per app di origine, al minuto. Questo limite impedisce a una tecnologia pubblicitaria esaurire l'intero budget grazie al limite di frequenza indicato in precedenza.

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

Un'origine report per app di origine al giorno

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

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

1. L'origine segnalante 1 dell'AdTech A registra una sorgente nell'App B
2. 12 ore dopo, l'origine segnalante 2 della tecnologia pubblicitaria A tenta di registrare una fonte nell'App B

La seconda sorgente, per l'origine segnalante 2 dell'AdTech A, viene rifiutata tramite Google Cloud CLI o tramite l'API Compute Engine. L'origine segnalante 2 dell'AdTech A non riesce a registrare correttamente un sullo stesso dispositivo nell'App B fino al giorno successivo.

Attenuazione e limiti di frequenza

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

L'attuale proposta prevede di limitare ogni ad tech a 100 attivatori attribuiti per {app di origine, app di destinazione, 30 giorni, dispositivo}.

Numero di destinazioni uniche

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

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

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

Fedeltà limitata dei dati di trigger

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

Devi valutare se e come ridurre le informazioni espresse nei trigger pertanto funzionano con il numero limitato di bit disponibili nei report a livello di evento.

Framework per il rumore della privacy differenziale

Uno degli obiettivi di questa API è consentire la misurazione a livello di evento per soddisfare requisiti di privacy differenziale usando le risposte k-randomizzate per generare per ogni evento di origine.

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

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

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

Per valori bassi di ↂ, l'output vero è protetto dalla funzione meccanismo di risposta. I parametri di rumore esatti sono in fase di sviluppo e sono soggetti da modificare in base al feedback, con una proposta corrente quanto segue:

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

Limiti sugli attivatori disponibili (conversioni)

Sono previsti limiti al numero di attivatori per origine di attribuzione, con un proposta attuale di quanto segue:

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

di Gemini Advanced.

Nota: descrive il comportamento predefinito dell'API per il numero di attribuzioni per utilizzando i report a livello di evento. Con l'introduzione delle funzionalità flessibili i report a livello di evento Ottobre 2023, i tecnici pubblicitari possono ora configurare questa dimensione dei report in base a ciò che funziona meglio per il loro caso d'uso.

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

I report a livello di evento per le origini di attribuzione delle visualizzazioni di annuncio vengono inviati un'ora dopo il la fonte scade. Questa data di scadenza può essere configurata, ma non può essere inferiore a 1 giorni o più di 30 giorni. Se a una visualizzazione di annuncio vengono attribuiti due attivatori origine dell'attribuzione (tramite l'attribuzione post-installazione), i report a livello di evento possono da inviare agli intervalli della finestra di report specificati come segue.

Non è possibile configurare report a livello di evento per le origini di attribuzione dei clic sugli annunci vengono inviati prima o dopo la scadenza dell'origine, in momenti specifici relativi a quando è stata registrata la fonte. Il tempo che intercorre tra l'origine dell'attribuzione e e la scadenza del report è suddivisa in più finestre di report. Ogni finestra del report ha un (dalla data di origine dell'attribuzione). Alla fine di ogni report finestra, il dispositivo raccoglie tutti i trigger verificatisi a partire dalla precedente finestra di reporting e invia un report pianificato. L'API supporta seguenti finestre di reporting:

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

di Gemini Advanced.

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

Configurazione flessibile a livello di evento

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

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

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

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

• Variare la frequenza dei report specificando il numero di finestre di report
• Variare il numero di attribuzioni per registrazione della sorgente
• Riduci la quantità di rumore totale diminuendo i parametri sopra indicati
• Configura le finestre di reporting anziché utilizzare i valori predefiniti

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

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

La riduzione di una dimensione della configurazione predefinita consente aumentare un'altra dimensione. In alternativa, la quantità totale di rumore in un evento di livello inferiore possono essere ridotti diminuendo nettamente i parametri sopra menzionati.

Oltre a impostare dinamicamente i livelli di rumore in base alla tecnologia pubblicitaria scelta abbiamo dei limiti di parametri per evitare calcoli di grandi dimensioni e configurazioni con troppi stati di output (dove il rumore aumenterà considerevolmente). Ecco un esempio di insieme di restrizioni. Feedback è incoraggiato su la [proposta di progettazione][50]:

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

Man mano che gli ad tech iniziano a utilizzare questa funzionalità, tieni presente che l'uso di valori estremi può causano una grande quantità di rumore o una mancata registrazione se i livelli di privacy sono non rispettata.

Nota: la fase 1 (a livello di evento flessibile Lite) è stata rilasciata in versione beta in Ottobre 2023. La fase 2 (a livello di evento completamente flessibile) è programmata per il rilascio in beta nel primo trimestre del 2024.

Report aggregati

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

I report aggregati forniscono dati di trigger più accurati dal dispositivo rapidamente, oltre a quanto offerto per i report a livello di evento. Questi dati a fedeltà superiore possono essere appresi solo in aggregati e non vengono associati a un determinato trigger o utente. Le chiavi di aggregazione possono contenere fino a 128 e questo permette di creare report aggregabili per supportare casi d'uso di reporting, come segue:

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

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

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

1. Il dispositivo invia report aggregabili criptati alla tecnologia pubblicitaria. In un nell'ambiente di produzione, i tecnici pubblicitari non possono usare direttamente questi report.
2. La tecnologia pubblicitaria invia un batch di report aggregabili al servizio di aggregazione per l'aggregazione.
3. Il servizio di aggregazione legge un batch di report aggregabili, decripta e le aggrega.
4. I dati aggregati finali vengono inviati all'ad tech in un report di riepilogo.

di Gemini Advanced.

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

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 l'attivatore è successo.
• Data: la data in cui l'evento rappresentato dall'origine dell'attribuzione. si è verificato un errore.
• Payload: attiva i valori, raccolti come coppie chiave/valore criptate, che viene utilizzato nel servizio di aggregazione attendibile per calcolare aggregazioni.

Servizi di aggregazione

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

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

• Il servizio di aggregazione è l'unico che i tecnici pubblicitari dovrebbero eseguire deployment.
• Gestione delle chiavi e report aggregabile di contabilità sono gestiti da servizi chiamati coordinatori. Questi coordinatori attestano che il codice che esegue il servizio di aggregazione è il codice disponibile pubblicamente fornito a Google e che tutti gli utenti del servizio di aggregazione abbiano la stessa chiave i servizi di contabilità per report aggregabili applicati.

Servizio di aggregazione

Le piattaforme di ad tech devono, in anticipo, eseguire il deployment di un servizio di aggregazione basato su su file binari forniti da Google.

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

• Garantisce che il codice operativo nel TEE sia lo specifico programma binario offerto realizzati da Google. Se questa condizione non è soddisfatta, il servizio di aggregazione non può accedere alle chiavi di decriptazione necessarie per il proprio funzionamento.
• Offre sicurezza per il processo in esecuzione, isolandolo dall'esterno il monitoraggio o le manomissioni.

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

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

Key Management Service

Questo servizio verifica che un servizio di aggregazione stia eseguendo una versione approvata del file binario, quindi fornisce il servizio di aggregazione nella tecnologia pubblicitaria con 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 un trigger specifico, che può contenere più chiavi di aggregazione, e limita l'accesso al numero appropriato di decrittografia. Fai riferimento al servizio di aggregazione per la proposta di progettazione dell'API Attribution Reporting per maggiori dettagli.

API Aggregatable Reports

L'API per creare report aggregabili utilizza la stessa base API come durante la registrazione di un'origine di attribuzione per i report a livello di evento. Le seguenti sezioni descrivono le estensioni dei tramite Google Cloud CLI o tramite l'API Compute Engine.

Registrare i dati di origine aggregati

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

• (Chiave) Nome chiave:una stringa per il nome della chiave. Utilizzata come chiave di join per si combinano con i tasti lato trigger per formare la chiave finale.
• (Valore) Key pezzo: un valore bitstring per la chiave.

La chiave del bucket a istogramma finale viene definita completamente al momento dell'attivazione eseguendo una OR su queste parti e sulle parti lato trigger.

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

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

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

• Conteggio aggregato delle conversioni a livello di campagna
• Aggrega i valori di acquisto a livello geografico

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

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

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

Registra l'attivatore aggregabile

La registrazione del trigger include due campi aggiuntivi.

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

• Elemento chiave: un valore bitstring per la chiave.
• Chiavi di origine:un elenco di stringhe con i nomi lato origine dell'attribuzione. tasti con cui la chiave dell'attivatore deve essere combinata per formare le chiavi finali.

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

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

Il rumore nel servizio di aggregazione viene scalato in modo proporzionale a questo parametro. Detto ciò, si consiglia di scalare in modo appropriato i valori riportati per un una data chiave aggregata, in base alla porzione di budget di 11 $ assegnata alla stessa. Questo aiuta a garantire che nei report aggregati venga applicata la fedeltà quando viene applicato il rumore. Questo meccanismo è molto flessibile e può supportano molte strategie di aggregazione.

Nell'esempio seguente, il budget per la privacy è suddiviso equamente tra campaignCounts e geoValue suddividendo il contributo di $ L1 $ per ciascuno:

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

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

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

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

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

L'esempio precedente genera i seguenti contributi a istogrammi:

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

Nota: filters continuano ad applicare i report aggregabili e ogni dizionario in aggregatable_trigger_data può comunque avere filtri di conversione facoltativamente applicati, proprio come i filtri attivatore per i report a livello di evento.

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

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

Privacy differenziale

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

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

Integrazione di API Protected Audience e API Attribution Reporting

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

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

• Crea una mappa di URI chiave-valore da utilizzare per entrambi 1) report sull'interazione e 2) registrazione origine.
• Includi CustomAudience nella mappatura delle chiavi lato di origine per i dati aggregati report di riepilogo (utilizzando l'API Attribution Reporting).

Quando un utente visualizza o fa clic su un annuncio:

• Anche l'URL usato per segnalare queste interazioni con Protected Audience da utilizzare per registrare una visualizzazione o un clic come fonte idonea con l'API Attribution Reporting.
• La tecnologia pubblicitaria può scegliere di trasmettere un segmento di pubblico personalizzato (o altri segmenti di pubblico informazioni sull'annuncio, come il posizionamento o la durata di visualizzazione), utilizzando URL in modo che questi metadati possano propagarsi ai report di riepilogo quando è esaminare il rendimento aggregato delle campagne.

Per saperne di più su come attivare questa funzionalità in Protected Audience, consulta le pertinente dell'articolo esplicativo dell'API Protected Audience.

Priorità di registrazione, attribuzione ed esempi di report

Questo esempio mostra una serie di interazioni degli utenti e la definizione di tecnologia pubblicitaria l'origine dell'attribuzione e le priorità degli attivatori potrebbero influire sui report attribuiti. Nella in questo esempio si suppone quanto segue:

• Tutti gli attivatori e le origini dell'attribuzione vengono registrati dalla stessa tecnologia pubblicitaria, per lo stesso inserzionista.
• Tutte le origini e gli attivatori dell'attribuzione si verificano durante il primo evento finestra di report (entro 2 giorni dalla prima visualizzazione degli annunci in un dell'app del publisher).

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

1. L'utente vede un annuncio. Ad tech registra un'origine di attribuzione con l'API, con una priorità pari a 0 (visualizzazione n. 1).
2. L'utente vede un annuncio registrato con una priorità pari a 0 (visualizzazione n. 2).
3. L'utente fa clic su un annuncio registrato con una priorità pari a 1 (clic n. 1).
4. L'utente effettua una conversione (raggiunge la pagina di destinazione) nell'app di un inserzionista. La tecnologia pubblicitaria Registra un trigger con l'API, con priorità 0 (conversione n. 1).
   • Quando i trigger vengono registrati, l'API esegue l'attribuzione prima generando report.
   • Sono disponibili tre origini di attribuzione: visualizzazione 1, 2 e fai clic su 1. L'API attribuisce questo trigger al clic su 1 perché è il la priorità più alta e il più recente.
   • Le viste 1 e 2 vengono ignorate e non sono più idonee per il futuro l'attribuzione dei contenuti.
5. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con un priorità di 1 (conversione n. 2).
   • Il clic 1 è l'unica origine di attribuzione idonea. Gli attributi dell'API questo trigger per fare clic su 1.
6. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con un priorità di 1 (conversione n. 3).
   • Il clic 1 è l'unica origine di attribuzione idonea. Gli attributi dell'API questo trigger per fare clic su 1.
7. L'utente aggiunge un articolo al carrello nell'app dell'inserzionista, registrato con un priorità di 1 (conversione n. 4).
   • Il clic 1 è l'unica origine di attribuzione idonea. Gli attributi dell'API questo trigger per fare clic su 1.
8. L'utente effettua un acquisto nell'app dell'inserzionista, registrato con una priorità. di 2 (conversione 5).
   • Il clic 1 è l'unica origine di attribuzione idonea. Gli attributi dell'API questo trigger per fare clic su 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 attribuiti a una vista vengono inviati dopo le finestre di report applicabili.
• Durante il periodo del report, se sono presenti attivatori registrati con questi hanno la precedenza e sostituiscono l'attivatore più recente.
• Nell'esempio precedente, l'ad tech riceve tre report sugli eventi dopo Finestra di report di due giorni per le conversioni n. 2, conversione n. 3 e conversione n. 5.
  • Tutti e 5 gli attivatori sono attribuiti al clic n. 1. Per impostazione predefinita, invia report per i primi tre attivatori: conversione n. 1, conversione n. 2, e la conversione 3.
  • Tuttavia, la priorità della conversione n. 4 (1) è superiore a quella della conversione n. 1 priorità (0). Il report sugli eventi della conversione 4 sostituisce il report della conversione 1 report sugli eventi da inviare.
  • Inoltre, la priorità della conversione 5 (2) è più elevata di qualsiasi altra trigger. Il report sugli eventi della conversione 5 sostituisce il report della conversione 4 in da inviare.

I report aggregati hanno le seguenti caratteristiche:

• I report aggregabili criptati vengono inviati al team ad tech non appena vengono elaborati, alcune ore dopo la registrazione dei trigger.

  In qualità di ad tech, crei i loro batch in base alle informazioni che arrivano e non criptati nei report aggregabili. Queste informazioni sono contenute in il campo shared_info nel report aggregabile e include il timestamp e l'origine del report. Non puoi creare batch basati su informazioni criptate in le coppie chiave-valore di aggregazione. Alcune semplici strategie che puoi seguire sono raggruppando i report ogni giorno oppure ogni settimana. Idealmente, i batch dovrebbero contenere 100 report ciascuno.

• Sta alla tecnologia pubblicitaria quando e come raggruppare i report aggregabili. e inviare 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 report 5aggregabili, uno per ogni trigger registrato.

Report di debug transitorio

L'API Attribution Reporting è un modo nuovo e abbastanza complesso per eseguire l'attribuzione senza identificatori cross-app. Di conseguenza, supportiamo meccanismo di transizione per saperne di più sui report sull'attribuzione quando L'ID pubblicità sia disponibile (l'utente non ha disattivato la personalizzazione usando l'ID pubblicità e l'app del publisher o dell'inserzionista ha dichiarato l'ID pubblicità. autorizzazioni). Ciò garantisce che l'API possa essere compresa completamente durante un'implementazione, eliminare eventuali bug e confrontare più facilmente alternative basate sull'ID pubblicità. Esistono due tipi di report di debug: attribuzione-successo e dettagliato.

Leggi la guida sui report di debug transitorio per maggiori dettagli sul debug i report con misurazioni da app a web e da web ad app.

Report di debug dell'attribuzione riuscita

Le registrazioni di origine e di attivazione accettano entrambe un nuovo campo debug_key a 64 bit (formattata come stringa), compilata dalla tecnologia pubblicitaria. source_debug_key e trigger_debug_key vengono trasmessi inalterati sia a livello di evento che di aggregati report.

Se viene creato un report con chiavi di debug sia di origine sia di trigger, viene restituito il report di debug viene inviato con un ritardo limitato a un Endpoint .well-known/attribution-reporting/debug/report-event-attribution. La 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 separato dei report di debug.

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

Report di debug dettagliati

I report di debug dettagliati consentono agli sviluppatori di monitorare alcuni errori nel 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 di registrazioni per un di Google.Endpoint well-known/attribution-reporting/debug/verbose.

Ogni report dettagliato contiene i seguenti campi:

• Tipo: cosa ha generato la generazione del report. Consulta l'elenco completo report dettagliati.
  • In generale, esistono report dettagliati sulle fonti che attivano i report dettagliati.
  • I report dettagliati di origine richiedono che l'ID pubblicità sia disponibile per dell'app del publisher e attivare report dettagliati richiedono che l'ID pubblicità sia disponibili per l'app dell'inserzionista.
  • Attivare report dettagliati (ad eccezione di trigger-no-matching-source) può includere facoltativamente source_debug_key. Può essere incluso solo se l'ID pubblicità è disponibile anche per il dell'app del publisher.
• Corpo: il corpo del report, che dipende dal tipo.

I tecnici pubblicitari devono attivare la ricezione di report di debug dettagliati utilizzando un nuovo campo del dizionario debug_reporting nel Attribution-Reporting-Register_Source e Attribution-Reporting-Register-Trigger.

• I report dettagliati di origine richiedono l'attivazione solo nell'intestazione della registrazione di origine.
• I report di debug trigger richiedono l'attivazione solo nell'intestazione della registrazione dell'attivatore.

Come utilizzare i report di debug

Se è avvenuta una conversione (in base al sistema di misurazione esistente) e report di debug per tale conversione, significa che l'attivatore è stato registrazione riuscita.

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

Se non esistono corrispondenze, i motivi possono essere diversi.

Funziona come previsto:

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

Cause non intenzionali:

• Problemi di implementazione:
  • L'intestazione di origine non è configurata correttamente.
  • L'intestazione del trigger 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 esplorando il futuro Funzionalità potenziali, ad esempio modelli di attribuzione non basati sull'ultimo clic e cross-device e casi d'uso di misurazione.

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

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