Report sull'attribuzione: misurazione su più app e Web

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

Inviare feedback

Aggiornamenti recenti

• È stata aggiunta una sezione sui report di debug transitori
• Sono state aggiunte istruzioni su come iscriversi a una lista consentita per registrare le fonti web.

Come descritto nella proposta di progettazione dell'API Attribution Reporting, l'API consente l'attribuzione dei seguenti percorsi di trigger su un singolo dispositivo con tecnologia Android:

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

Per web qui si intendono i contenuti web mostrati in un'app. I contenuti web possono essere mostrati nel contesto di un'app browser mobile o come siti web incorporati mostrati in app non basate sul browser.

I percorsi di trigger precedenti si traducono nei seguenti requisiti:

• Per gli ad tech: aggiornamenti alle chiamate API e ai report per abilitare i percorsi dall'app al web
• Per app e browser: possibilità di trasmettere ad Android la registrazione delle origini di attribuzione web e degli attivatori

Questo documento spiega in che modo l'API Attribution Reporting è estesa per supportare i percorsi di trigger da app a web, da web ad app e da web a web. Descrive inoltre le modifiche che le app e gli ad tech devono apportare per soddisfare i requisiti per il supporto di questi percorsi di attivazione.

Ottenere l'accesso alle API Attribution Reporting

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

Una volta ultimato il processo di registrazione, l'API eliminerà la registrazione se viene ricevuta una chiamata di registrazione annullata.

Al momento della registrazione, le piattaforme di tecnologia pubblicitaria devono assicurarsi di registrarsi con tutti gli URL dei server che potrebbero utilizzare nell'app e sul web per registrare le origini e gli attivatori di attribuzione. Sono supportati più URL di registrazione del server, ma è supportata solo un'origine report. Questa origine report deriva dal dominio di uno degli URL di registrazione del server.

Modifiche per le tecnologie pubblicitarie

Modifiche relative a registrazione e attribuzione

Quando registri un'origine di attribuzione, gli ad tech attualmente specificano un campo di destinazione che corrisponde al nome del pacchetto dell'app in cui si verifica l'evento di attivazione. Per attivare la misurazione dall'app al web, prevediamo di supportare un campo di destinazione dell'app (nome del pacchetto dell'app) e un campo di destinazione web (eTLD+1).

Durante la registrazione di attivatori o origini di attribuzione web, l'API non supporta i reindirizzamenti perché ogni app che ospita contenuti web potrebbe avere un proprio modello di autorizzazioni. Ogni app è responsabile dei seguenti reindirizzamenti (se supportati) e della chiamata delle API di contesto web per ogni hop di reindirizzamento.

Inoltre, questa integrazione consente alle tecnologie pubblicitarie di utilizzare una logica di attribuzione specifica per app nelle origini di attribuzione web. Ad esempio, ora puoi specificare finestre di attribuzione post-installazione su un'origine di attribuzione web.

Ricevi report web e app

L'API Android Attribution Reporting può inviare report sia sulle conversioni di app che sul web. Se gli ad tech non vogliono allineare i dati dei trigger e le coppie chiave-valore di aggregazione sulle piattaforme web e app, possono distinguere tra una conversione web e una conversione di app:

• Per i report a livello di evento, supportiamo un campo destinazione che specifica se l'attivatore è avvenuto sul web (la destinazione è un eTLD+1) o nell'app (la destinazione è il nome di un pacchetto dell'app)
• Per i report aggregati, la destinazione viene inviata in chiaro.

Implicazioni per la misurazione da web a web

Le app scelgono quando passare la registrazione all'API Attribution Reporting. A questo proposito, è necessario fare alcune considerazioni:

• L'API Attribution Reporting è disponibile su quel dispositivo? Mostreremo un nuovo indicatore alle app che ci comunica se l'API Attribution Reporting è disponibile su quel dispositivo. Per ulteriori dettagli su come le app possono passare la registrazione all'API Attribution Reporting, consulta la sezione Modifiche alle app.
• Quale parte delle origini e degli attivatori di attribuzione deve essere trasmessa all'API? Sarà una decisione presa da ciascuna app o dal ad tech, se l'app consente una scelta. Se l'app dispone di una soluzione di misurazione dedicata, ti consigliamo di utilizzare quella. In definitiva, il trasferimento di tutte le origini e delle registrazioni all'API Android Attribution Reporting, se disponibile, consente di ottenere l'attribuzione più accurata tra le app e il web.

L'esempio seguente mostra come le app del browser possono funzionare con l'API Attribution Reporting per fornire una misurazione accurata quando l'utente fa clic su un annuncio sia in un'app browser sia in un'app non correlata al browser:

Esempio di origine e attivazione della registrazione su un browser e in un'app

• Il 1° giorno, l'utente fa clic su un annuncio nell'app del browser.
  • L'app browser può scegliere di utilizzare la propria soluzione di misurazione o di trasferire la registrazione del clic sull'annuncio web all'API Attribution Reporting.
• Il secondo giorno l'utente fa clic su un annuncio in un'app non correlata al browser.
  • Il clic viene registrato come origine di attribuzione con l'API. L'app browser non ha visibilità su questo clic perché l'evento si è verificato all'interno di un'altra app.
• Il terzo giorno l'utente effettua la conversione nell'app browser.
  • Se l'app browser registra il clic e la conversione utilizzando la propria soluzione di misurazione e passa queste informazioni all'API Attribution Reporting, è improbabile che un'ad tech possa deduplicare i report sulle conversioni nelle varie soluzioni di misurazione. Inoltre, una tecnologia pubblicitaria potrebbe consumare sia i limiti di frequenza delle app del browser sia i limiti di frequenza dell'API Attribution Reporting. Di conseguenza, consigliamo che le app trasmettano tutti gli eventi relativi agli annunci e le conversioni in modo che vengano registrati nell'API, quando quest'ultima è disponibile.

Registra l'origine dell'attribuzione e l'attivatore da WebView

Nel caso in cui l'app utilizzi WebView per mostrare contenuti web anziché un annuncio Android nativo, l'app può richiedere l'inserimento nella lista consentita di registerWebSource() e fornire l'origine di primo livello del sito web da associare all'origine dell'attribuzione anziché al nome del pacchetto dell'app.

Analogamente ai browser, WebView supporta registerWebTrigger() per le registrazioni degli attivatori, che associano l'attivatore all'origine di primo livello. WebView non supporta la registrazione di un trigger di app; contattaci se hai un caso d'uso in merito. Per l'elenco completo delle combinazioni supportate da WebView, consulta Origine dell'attribuzione e registrazione dell'attivatore da WebView.

A differenza dei browser, WebView supporta la registrazione con il sistema operativo nell'intestazione Attribution-Reporting-Eligible solo se è disponibile l'API Attribution Reporting di Android. Se l'API Attribution Reporting di Android non è disponibile, WebView non imposta un'intestazione Attribution-Reporting-Eligible e non vengono effettuate registrazioni.

Per registrare un'origine o un attivatore di attribuzione utilizzando il sistema operativo:

• I tecnici pubblicitari devono rispondere alle registrazioni della sorgente utilizzando l'intestazione Attribution-Reporting-Register-OS-Source, che avvia una chiamata API secondaria da WebView a registerSource() o registerWebSource().
• I tecnici pubblicitari possono anche rispondere alle registrazioni di attivazione utilizzando l'intestazione Attribution-Reporting-Register-OS-Trigger, che avvia una chiamata API secondaria da WebView a registerWebTrigger() o registerTrigger().

Tieni presente che se la risposta non include le intestazioni precedenti o include anche le intestazioni Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger anche se il web non è supportato, l'intera registrazione non andrà a buon fine.

Per informazioni dettagliate sull'utilizzo di registerSource()/registerWebSource() e registerTrigger() / registerWebTrigger() da parte di WebView e su come modificare questo comportamento, consulta Origine dell'attribuzione e attiva la registrazione da WebView.

Report di debug di transizione

L'API Attribution Reporting supporta una funzionalità facoltativa chiamata report di debug transitorio, che consente ai tecnici pubblicitari di ottenere ulteriori informazioni sui report sull'attribuzione quando è disponibile un ID pubblicità. Esistono due tipi di report di debug: attribuzione-successo e dettagliato. Questi report sono supportati per l'attribuzione web e tra app ed entrambi i tipi di report contengono le stesse informazioni; l'unica differenza riguarda le autorizzazioni che impediscono quando vengono inviati i report di debug.

Per l'attribuzione web-web che si verifica all'interno di una singola app (ad esempio nella stessa app del browser), i report dettagliati e sull'esito positivo dell'attribuzione sono disponibili solo quando sono disponibili cookie di terze parti e non sono basati sulla disponibilità degli ID pubblicità.

Per l'attribuzione tra app tra app e web, web e web e tra app, sono disponibili report dettagliati e sull'attribuzione riuscita se l'ID pubblicità è disponibile sul lato app e se la tecnologia pubblicitaria è in grado di trasmettere lo stesso ID pubblicità (corretto) sul lato web. Di seguito è riportato un esempio dall'app al web in cui l'origine si verifica nell'app di un publisher, ma l'attivatore si verifica sul sito di un inserzionista all'interno di un'app del browser.

Per attivare un report di debug dell'attribuzione riuscita per l'app al web, devono essere soddisfatte tutte e tre le condizioni seguenti:

• L'utente non deve aver disattivato la personalizzazione utilizzando l'ID pubblicità
• L'app del publisher deve avere autorizzazioni dichiarate per l'ID pubblicità
• La tecnologia pubblicitaria deve passare il valore dell'ID pubblicità nella registrazione dell'attivatore (da un contesto web)

Per attivare report di debug dettagliati per l'app al web:

• I report dettagliati delle origini dipendono solo dalle autorizzazioni lato publisher. Per inviare i report dettagliati dell'origine, l'utente non deve aver disattivato la personalizzazione dell'ID pubblicità e l'app del publisher deve avere dichiarato le autorizzazioni per l'ID pubblicità.
• I report dettagliati per attivare i report dipendono solo dalle autorizzazioni lato trigger (in questo esempio web). I cookie di terze parti devono essere disponibili nel browser affinché vengano inviati report dettagliati per attivare l'attivazione.
• Per i report dettagliati dell'attivazione che possono includere facoltativamente un source_debug_key, source_debug_key viene incluso se l'ID pubblicità è disponibile per l'app del publisher.

Tieni presente che, in tutti i casi, la tecnologia pubblicitaria deve comunque attivare la ricezione di report di debug dettagliati tramite il campo del dizionario debug_reporting nell'origine e attivare le intestazioni di registrazione.

Nota: se supporti l'attribuzione web e cross-app utilizzando dati diversi da un ID pubblicità, contatta il tuo caso d'uso per presentare domanda di partecipazione al programma Trusted Tester. Il programma Trusted Tester supporta un modo alternativo per ricevere gli stessi report di debug transitori descritti in precedenza. Il programma Trusted Tester è riservato ai tecnici pubblicitari con necessità comprovata, nei casi in cui il caso d'uso sia supportato, ma la tecnologia pubblicitaria non è in grado di fornire un ID pubblicità in più fonti e attivare la registrazione.

Modifiche per le app

Supporteremo l'attribuzione su più piattaforme web e app consentendo alle app di trasferire la registrazione delle origini di attribuzione web e degli attivatori web all'API Attribution Reporting su Android tramite un nuovo insieme di chiamate API di contesto web.

Dopo aver completato i passaggi di registrazione nelle sezioni seguenti, le origini e gli attivatori di attribuzione di app e web vengono memorizzati sul dispositivo e l'API Attribution Reporting può eseguire l'attribuzione basata sull'ultimo touchpoint come priorità all'origine su piattaforme web e app.

Consulta la proposta di Privacy Sandbox per il web per un esempio di come i browser possono integrarsi con l'API Attribution Reporting di Android per consentire la misurazione su più app e web. Nella proposta, il browser aggiungerà le seguenti intestazioni di richiesta:

• Attribution-Reporting-Eligible comunica se è disponibile il supporto a livello di sistema operativo per l'attribuzione. In questo caso, l'intestazione indica se è disponibile l'API Attribution Reporting di Android.
• Se disponibili, gli ad tech possono facoltativamente rispondere utilizzando Attribution-Reporting-Register-OS-Source, che avvia una chiamata API secondaria dall'app del browser a registerWebSource().
• I tecnici pubblicitari possono anche rispondere alle registrazioni di attivazione utilizzando l'intestazione Attribution-Reporting-Register-OS-Trigger, che avvia una chiamata API secondaria dall'app browser a registerWebTrigger().

Registrazione dell'origine dell'attribuzione

Quando registri un'origine di attribuzione, le app possono chiamare registerWebSource(), che prevede i seguenti parametri:

• URI dell'origine dell'attribuzione: la piattaforma invia una richiesta a ogni URI in questo elenco per recuperare i metadati associati all'origine dell'attribuzione.
  
  Ogni URI deve accompagnare un flag booleano Debug per indicare se le chiavi di debug fornite dai tecnici devono essere incluse nel report.
• Evento di input: un oggetto InputEvent (per un evento di clic) o null (per un evento di visualizzazione)
• Origine della sorgente: l'origine in cui si è verificata l'origine (sito web del publisher).
• Destinazione sistema operativo: il nome del pacchetto dell'app in cui si verifica l'evento di trigger.
• Destinazione web: un eTLD+1 in cui si verifica l'evento di trigger.
• Destinazione verificata: l'intent del sistema operativo o dell'URI di destinazione web utilizzato per la navigazione al clic dell'utente.

Quando l'API invia una richiesta all'URI dell'origine di attribuzione, la tecnologia pubblicitaria deve rispondere con i metadati dell'origine di attribuzione in un'intestazione HTTP, Attribution-Reporting-Register-Source. Questa intestazione utilizza gli stessi campi della registrazione dell'origine dell'attribuzione app-to-app, con alcune modifiche:

• L'API convalida le destinazioni specificate dalla tecnologia pubblicitaria con le destinazioni specificate dall'app. Se le destinazioni sono diverse, l'API annulla la registrazione dell'origine dell'attribuzione.
  
  Le app devono convalidare le destinazioni web prima di chiamare l'API Webcontext. Per i clic, le app devono verificare che la destinazione specificata corrisponda a quella a cui viene indirizzato l'utente.
• L'API ignora eventuali URI di reindirizzamento forniti in Attribution-Reporting-Redirects. Le app devono seguire i reindirizzamenti autonomamente e chiamare registerWebSource() per ogni reindirizzamento, in modo da poter applicare i propri criteri di autorizzazione a seconda delle esigenze.

Le app devono essere inserite in una lista consentita per chiamare registerWebSource(). Compila questo modulo per iscriverti alla lista consentita. Lo scopo della lista consentita è attenuare le considerazioni sulla privacy per instaurare un rapporto di fiducia per il contesto web.

Registrazione attivatore (conversione)

Al momento della registrazione del trigger, le app possono chiamare registerWebTrigger(), che prevede i seguenti parametri:

• URI del trigger: la piattaforma invia una richiesta a ogni URI in questo elenco per recuperare i metadati associati al trigger
• Origine destinazione: l'origine in cui si è verificato l'attivatore (sito web dell'inserzionista)

Origine dell'attribuzione e attivazione della registrazione da WebView

Per impostazione predefinita, WebView utilizzerà registerSource() e registerWebTrigger(). In questo modo, quando si verifica l'attivatore, le origini vengono associate all'app e vengono attivate con l'origine di primo livello di WebView.

Se un'app richiede un comportamento diverso (ad esempio quelle che ospitano contenuti web in un componente WebView), sarà necessario utilizzare il metodo setAttributionRegistrationBehavior nella classe androidx.webkit.WebViewSettingsCompat. Questo metodo specificherà se WebView deve chiamare registerWebSource(), registerSource() e registerWebTrigger() o registerTrigger().

Le opzioni disponibili per setAttributionRegistrationBehavior sono di seguito:

Valore	Descrizione	Esempio di caso d'uso
APP_SOURCE_AND_WEB_TRIGGER (predefinito)	Consente alle app di registrare origini app (origini associate al nome del pacchetto dell'app) e trigger web (attivatori associati all'eTLD+1) da WebView.	App che utilizzano WebView per pubblicare annunci anziché abilitare la navigazione sul web
WEB_SOURCE_AND_WEB_TRIGGER	Consente alle app di registrare origini web e trigger web da WebView. Nota: per poter essere inserite nella lista consentita, le app che utilizzano questa opzione dovranno essere richieste per poter utilizzare registerWebSource().	App del browser basate su WebView, in cui le impressioni degli annunci e le conversioni possono verificarsi sui siti web in WebView.
APP_SOURCE_AND_APP_TRIGGER	Consente alle app di registrare origini app e attivatori di app da WebView.	App basate su WebView in cui le impressioni e le conversioni degli annunci devono essere sempre associate all'app anziché all'eTLD+1 di WebView.
DISABILITATA	Disattiva l'origine e la registrazione di attivazione da WebView. Tieni presente che la chiamata di rete iniziale agli URI dell'origine dell'attribuzione o dell'attivatore potrebbe comunque avvenire, ma qualsiasi risposta viene ignorata e non verrà memorizzato nulla sul dispositivo.

Nota: setAttributionRegistrationBehavior si applica a ogni implementazione di WebView di ogni app. Se la tua app supporta più componenti WebView, puoi impostare comportamenti diversi per ognuna. setAttributionRegistrationBehavior non impedisce o modifica l'origine né attiva la registrazione dall'app stessa o da qualsiasi altra app.

Considerazioni su privacy e sicurezza

Impatto sui meccanismi che tutelano la privacy applicati alle segnalazioni

Come descritto nella proposta di progettazione principale, l'API applica ai report limiti di frequenza incentrati sulla tutela della privacy. Alcuni limiti sono partizionati tra le app di origine e di destinazione. Quando vengono registrati un trigger o un'origine di attribuzione web, il limite di frequenza viene partizionato in base al sito di origine o di destinazione anziché all'app.

Se l'app mantiene limiti di frequenza separati, un utente malintenzionato potrebbe usufruire di limiti di frequenza specifici dell'app oltre ai limiti di frequenza dell'API. Per attenuare questo problema, le app devono garantire che una determinata origine di attribuzione non sia registrata sia nella soluzione di misurazione dell'app sia nell'API Android Attribution Reporting.

Crea fiducia nel contesto web

Nelle chiamate API contesto web, l'API ripone fiducia nell'app per rilevare e specificare le origini di origine e di destinazione. Questo può creare potenziali considerazioni sulla privacy e sulla sicurezza:

• Un avversario può affermare di ospitare siti web di sua proprietà nel tentativo di aggirare i limiti di frequenza relativi alla quantità di informazioni che qualsiasi fonte può trasferire.
• Più utenti malintenzionati possono unirsi a registrare origini di attribuzione separate, rivendicando lo stesso sito di origine. Di conseguenza, il sito di origine potrebbe raggiungere i limiti di frequenza della piattaforma di tecnologia pubblicitaria e impedire al sito di origine effettivo di registrare origini di attribuzione legittime.

Per limitare questo problema, limiteremo i browser o le app che possono chiamare registerWebSource() ai browser o alle app che attestano che il sito di origine utilizzato per la registrazione rappresenta il sito effettivamente mostrato all'utente. Compila questo modulo per iscriverti alla lista consentita di chiamate registerWebSource().

Qualsiasi app potrebbe chiamare registerWebTrigger() perché le considerazioni relative a privacy e sicurezza sul lato trigger non sono applicabili senza collusione lato origine.

Controlli utente

Le app possono continuare a supportare controlli utente o criteri di autorizzazione, purché possano essere definiti al momento della registrazione. Ad esempio, se le app consentono autorizzazioni a livello di sito o utente, deve valutarle e determinare se chiamare le API di contesto web.

Supportiamo inoltre una nuova chiamata API dalle app per eliminare origini di attribuzione, attivatori e report in attesa archiviati per l'app sul dispositivo. Ad esempio, se le app consentono all'utente di cancellare la cronologia di navigazione, può essere opportuno chiamare l'API per eliminare origini di attribuzione, attivatori e report in attesa archiviati per quell'app sul dispositivo dell'utente.

Considerazioni future e domande aperte

L'interoperabilità app-web per l'API Attribution Reporting è ancora in fase di sviluppo. Apprezziamo un feedback da parte della community su alcune idee:

1. Su un dispositivo Android Privacy Sandbox supportato, come utilizzerai le soluzioni di misurazione del browser con l'API Android Attribution Reporting? Preferiresti passare tutto ad Android?
2. Hai dubbi sulla ricezione potenzialmente di 2 ping per ogni origine e trigger di attribuzione, uno dal browser/app e uno dall'API Attribution Reporting?
3. Come possiamo aiutarti a semplificare il debug di diverse API?
4. La proposta non include la conferma dell'affiliazione di app e destinazioni web. In futuro, potremmo essere in grado di convalidare queste destinazioni controllando le associazioni tramite Digital Asset Links. Bloccherebbe alcuni dei tuoi casi d'uso? Ha senso utilizzare Digital Asset Links per eseguire questa convalida?
5. Quando registri un'origine di attribuzione, devi specificare una destinazione. Nel caso da web ad app, potresti voler specificare un link dell'app. Quali formati usi per specificare questo link dell'app?
6. Quando registri un'origine di attribuzione app-web, l'evento di origine deve essere registrato dall'app con l'API Android Attribution Reporting. Ad esempio, se l'utente fa clic su un annuncio e il clic viene aperto in un browser o in una scheda personalizzata del browser, il clic (evento di origine) deve essere registrato dall'app anziché nel contesto del browser. Non esitare a contattarci in caso di dubbi o se esistono altri casi d'uso che non rientrano nelle categorie trattate in questo problema che descrive i flussi supportati.