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

Aggiornamenti recenti

Percorsi di trigger

Come descritto nella proposta di progettazione dell'API Attribution Reporting, l'API consente l'attribuzione dei seguenti percorsi di trigger su un singolo dispositivo Android. Qui definiamo Web come: (1) un browser autonomo in esecuzione su Android (ad es. Chrome) o (2) una WebView in esecuzione all'interno di un'app per Android.

  • App-to-app::l'utente vede un annuncio in un'app e poi effettua una conversione in quell'app o in un'altra app installata.
  • App-to-web: l'utente vede un annuncio in un'app e poi effettua una conversione sul web.
  • Web-to-app: l'utente vede un annuncio sul web e poi genera una conversione in un'app.
  • Web-to-web::l'utente vede un annuncio sul web e poi genera una conversione sul web.

I percorsi dei trigger precedenti si traducono nei seguenti requisiti:

  • Per le tecnologie pubblicitarie: aggiornamenti alle chiamate API e ai report per attivare i percorsi da app a web.
  • Per app e browser: possibilità di trasferire la registrazione delle origini di attribuzione web e dei trigger web ad Android.

Questo documento spiega come l'API Attribution Reporting viene estesa per supportare i percorsi di attivazione da app a web, da web ad app e da web a web. Descrive inoltre le modifiche che le tecnologie pubblicitarie e le app devono apportare per soddisfare i requisiti di supporto di questi percorsi di attivazione.

Ottenere l'accesso alle API Attribution Reporting

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

Una volta completata la procedura di registrazione, l'API ignorerà la registrazione se viene ricevuta una chiamata di registrazione annullata.

Al momento della registrazione, le piattaforme pubblicitarie devono assicurarsi di registrarsi con tutti gli URL dei server che potrebbero utilizzare su app e web per registrare le origini e i trigger dell'attribuzione. Sono supportati più URL di registrazione del server, ma solo un'origine di reporting. Questa origine report deriva dal dominio di uno degli URL di registrazione del server.

Modifiche per le tecnologie pubblicitarie

Questa sezione illustra le modifiche per le tecnologie pubblicitarie che utilizzano l'API Attribution Reporting.

Modifiche alla registrazione e all'attribuzione

Quando registrano una sorgente di attribuzione, le tecnologie pubblicitarie specificano un campo di destinazione che è il nome del pacchetto dell'app in cui si verifica l'evento attivatore. Per abilitare la misurazione da app a web, prevediamo di supportare un campo di destinazione app (nome del pacchetto app) e un campo di destinazione web (eTLD+1).

Quando registri origini o trigger di attribuzione web, l'API non supporta i reindirizzamenti perché ogni app che ospita contenuti web potrebbe avere il proprio modello di autorizzazioni. Ogni app è responsabile del follow-up dei reindirizzamenti (se supportati) e della chiamata alle API di contesto web per ogni hop di reindirizzamento.

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

Ricevere report su app e web

L'API Attribution Reporting di Android può inviare report per le conversioni da app e web. Se le tecnologie pubblicitarie non vogliono allineare i dati di attivazione e i valori chiave di aggregazione tra le superfici web e app, possono distinguere tra una conversione web e una conversione app:

  • Per i report a livello di evento, supporteremo un campo di destinazione che specifica se l'attivazione è avvenuta sul web (la destinazione è un eTLD+1) o nell'app (la destinazione è un nome di pacchetto app)
  • Per i report aggregabili, la destinazione viene inviata in testo non criptato.

Implicazioni della misurazione da web a web

Le app scelgono quando trasmettere la registrazione all'API Attribution Reporting. Ci sono diverse considerazioni da fare:

  • L'API Attribution Reporting è disponibile su questo dispositivo? Esporremo un nuovo indicatore alle app che restituisce se l'API Attribution Reporting è disponibile su quel dispositivo. Consulta la sezione relativa alle modifiche alle app per ulteriori dettagli su come le app possono superare la registrazione all'API Attribution Reporting.
  • Quale parte delle origini e dei trigger di attribuzione deve essere trasmessa all'API? Questa sarà una decisione presa da ogni app o dalla tecnologia pubblicitaria se l'app consente una scelta. Se l'app ha una propria soluzione di misurazione, potrebbe essere preferibile utilizzarla. In definitiva, il trasferimento di tutte le registrazioni di origine e trigger all'API Android Attribution Reporting, quando disponibile, consente l'attribuzione più accurata su app e web.

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

Esempi di clic e conversioni degli utenti in un periodo di 3 giorni.
Esempio di registrazione di origine e attivatore in un browser e un'app
  • Il giorno 1, l'utente fa clic su un annuncio nell'app browser.
    • L'app browser può scegliere di utilizzare la propria soluzione di misurazione o di passare la registrazione del clic sull'annuncio web all'API Attribution Reporting.
  • Il giorno 2, l'utente fa clic su un annuncio in un'app non browser.
    • Il clic viene registrato come origine 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 una conversione nell'app del browser.
    • Se l'app browser registra sia il clic che la conversione utilizzando la propria soluzione di misurazione e trasmette queste informazioni all'API Attribution Reporting, è improbabile che una tecnologia pubblicitaria possa deduplicare i report sulle conversioni tra le soluzioni di misurazione. Inoltre, una tecnologia pubblicitaria potrebbe utilizzare sia i limiti di frequenza delle richieste dell'app browser sia quelli dell'API Attribution Reporting. Pertanto, consigliamo alle app di trasmettere tutti gli eventi annuncio e le conversioni da registrare nell'API, quando questa è disponibile.

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

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

Analogamente ai browser, WebView supporta registerWebTrigger() per le registrazioni dei trigger, che associa il trigger all'origine di primo livello. Non è previsto il supporto di WebView per registrare un trigger dell'app. Contattaci se hai un caso d'uso per questa funzionalità. Per l'elenco completo delle combinazioni supportate da WebView, consulta Registrazione di trigger e sorgenti di attribuzione da WebView.

A differenza dei browser, WebView supporta la registrazione con il sistema operativo all'interno dell'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 / un trigger di attribuzione utilizzando il sistema operativo:

  • Le tecnologie pubblicitarie devono rispondere alle registrazioni delle origini utilizzando l'intestazione Attribution-Reporting-Register-OS-Source, che avvia una chiamata API secondaria dalla WebView a registerSource() o registerWebSource().
  • Le tecnologie pubblicitarie possono anche rispondere alle registrazioni di trigger 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 su se WebView utilizzerà registerSource()/registerWebSource() e registerTrigger() / registerWebTrigger() (e su come modificare questo comportamento), consulta Registrazione dell'origine dell'attribuzione e del trigger da WebView.

Report di debug transitorio

L'API Attribution Reporting supporta una funzionalità facoltativa chiamata report di debug transizionali, che consente alle tecnologie pubblicitarie di ottenere maggiori informazioni sui report sull'attribuzione quando è disponibile un ID pubblicità. Esistono due tipi di report di debug: attribution-success e verbose. Questi report sono supportati per l'attribuzione cross-app e cross-web ed entrambi i tipi di report contengono le stesse informazioni; l'unica differenza riguarda le autorizzazioni che controllano l'invio dei report di debug.

Per l'attribuzione da web a web che avviene all'interno di una singola app (ad esempio, all'interno della stessa app browser), i report dettagliati e di attribuzione riuscita sono disponibili solo quando sono disponibili cookie di terze parti e non si basano sulla disponibilità dell'ID pubblicità.

Per l'attribuzione cross-app da app a web, da web ad app e da web a web, i report dettagliati e di attribuzione riuscita sono disponibili se l'ID pubblicità è disponibile sul lato app e la tecnologia pubblicitaria può trasmettere lo stesso ID pubblicità (corretto) sul lato web.

In un esempio successivo da app a web, l'origine si verifica in un'app publisher, ma il trigger si verifica su un sito dell'inserzionista all'interno di un'app browser.

Per attivare un report di debug dell'attribuzione riuscita per il percorso app-to-web, devono essere soddisfatte le seguenti condizioni:

  • L'utente non deve aver disattivato la personalizzazione tramite l'ID pubblicità
  • L'app editore deve aver dichiarato le autorizzazioni per l'ID pubblicità
  • La tecnologia pubblicitaria deve trasmettere il valore AdID nella registrazione del trigger (da un contesto web)

Per attivare i report di debug dettagliati per app-to-web:

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

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

Modifiche per le app

Supporteremo l'attribuzione su app e web consentendo alle app di trasferire la registrazione delle origini di attribuzione web e dei trigger web all'API Attribution Reporting su Android utilizzando un nuovo insieme di chiamate API di contesto web.

Dopo aver completato i passaggi di registrazione nelle sezioni seguenti, le origini e i trigger dell'attribuzione web e app vengono memorizzati sul dispositivo e l'API Attribution Reporting può eseguire l'attribuzione last-touch con priorità dell'origine su tutte le superfici 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 attivare la misurazione cross-app e cross-web. Nella proposta, il browser aggiungerà le seguenti intestazioni della richiesta:

  • Attribution-Reporting-Eligible trasmette se è disponibile il supporto a livello di sistema operativo per l'attribuzione. In questo caso, l'intestazione indica se l'API Attribution Reporting di Android è disponibile.
  • Se disponibili, le tecnologie pubblicitarie possono rispondere facoltativamente utilizzando Attribution-Reporting-Register-OS-Source, che avvia una chiamata API secondaria dall'app browser a registerWebSource().
  • Le tecnologie pubblicitarie possono anche rispondere alle registrazioni dei trigger utilizzando l'intestazione Attribution-Reporting-Register-OS-Trigger, che avvia una chiamata API secondaria dall'app browser a registerWebTrigger().

Registrazione dell'origine attribuzione

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

  • URI di origine dell'attribuzione: la piattaforma invia una richiesta a ogni URI di questo elenco per recuperare i metadati associati all'origine dell'attribuzione.

    Ogni URI deve essere accompagnato da 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 la sorgente (sito web del publisher).
  • Destinazione OS: il nome del pacchetto dell'app in cui si verifica l'evento trigger.
  • Destinazione web: un eTLD+1 in cui si verifica l'evento trigger.
  • Destinazione verificata: intent URI di destinazione web o del sistema operativo utilizzato per la navigazione al clic dell'utente.

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 un'intestazione HTTP, Attribution-Reporting-Register-Source. Questa intestazione utilizza gli stessi campi della registrazione dell'origine dell'attribuzione da app ad app, con alcune modifiche:

  • L'API convalida le destinazioni specificate dalla tecnologia pubblicitaria con quelle specificate dall'app. Se le destinazioni sono diverse, l'API ignora la registrazione dell'origine dell'attribuzione.

    Le app devono convalidare le destinazioni web prima di chiamare l'API contesto web. Per i clic, le app devono verificare che la destinazione specificata corrisponda alla destinazione verso cui si sta spostando l'utente.
  • L'API ignora tutti gli 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 le proprie norme sulle autorizzazioni in base alle esigenze.

Le app devono essere aggiunte a una lista consentita per chiamare registerWebSource(). Compila questo modulo per entrare nella lista consentita. Lo scopo della lista consentita è quello di mitigare le considerazioni sulla privacy in merito alla creazione di fiducia per il contesto web.

Registrazione dell'attivazione (conversione)

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

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

Registrazione dell'origine attribuzione e dell'attivatore da WebView

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

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

Le opzioni disponibili per setAttributionRegistrationBehavior sono le seguenti:

Valore Descrizione Caso d'uso di esempio
APP_SOURCE_AND_WEB_TRIGGER (valore predefinito) Consente alle app di registrare origini app (origini associate al nome del pacchetto dell'app) e trigger web (trigger associati all'eTLD+1) da WebView. App che utilizzano WebView per pubblicare annunci anziché attivare la navigazione web
WEB_SOURCE_AND_WEB_TRIGGER Consente alle app di registrare origini web e trigger web da WebView.
Nota: le app che utilizzano questa opzione dovranno richiedere l'inserimento nella lista consentita per utilizzare registerWebSource().		 App browser basate su WebView, in cui le impressioni e le conversioni degli annunci potrebbero verificarsi entrambe sui siti web in WebView.
APP_SOURCE_AND_APP_TRIGGER Consente alle app di registrare origini e trigger delle app da WebView. App basate su WebView in cui le impressioni e le conversioni degli annunci devono sempre essere associate all'app anziché all'eTLD+1 di WebView.
DISATTIVATO Disattiva la registrazione di origini e trigger da WebView.
Tieni presente che la chiamata di rete iniziale agli URI di origine o trigger dell'attribuzione potrebbe comunque essere eseguita, ma qualsiasi risposta viene ignorata e non viene memorizzato nulla sul dispositivo.

Considerazioni su privacy e sicurezza

Questa sezione illustra le considerazioni sulla privacy e la sicurezza per le app che utilizzano l'API Attribution Reporting.

Impatto sui meccanismi di tutela della privacy applicati ai report

Come descritto nella proposta di progettazione principale, l'API applica limiti di frequenza che preservano la privacy ai report. Alcuni limiti sono partizionati tra le app di origine e di destinazione. Quando viene registrata un'origine o un trigger 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 malintenzionato potrebbe consumare i limiti di frequenza specifici dell'app oltre a quelli dell'API. Per mitigare questo problema, le app devono verificare che una determinata origine attribuzione non sia registrata sia nella soluzione di misurazione dell'app sia nell'API Android Attribution Reporting.

Stabilire l'attendibilità per il contesto web

Nelle chiamate API nel contesto web, l'API si affida all'app per rilevare e specificare le origini di origine e destinazione. Ciò può comportare potenziali considerazioni in termini di privacy e sicurezza:

  • Un malintenzionato può dichiarare di ospitare siti web di sua proprietà nel tentativo di aggirare i limiti di frequenza relativi alla quantità di informazioni che qualsiasi origine può trasferire.
  • Più malintenzionati possono colludere per registrare origini di attribuzione separate, rivendicando lo stesso sito di origine. Ciò potrebbe causare il raggiungimento dei limiti di frequenza della piattaforma di tecnologia pubblicitaria da parte del sito di origine e impedire a quest'ultimo di registrare fonti di attribuzione legittime.

Per mitigare 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 nella registrazione rappresenta il sito effettivo mostrato all'utente. Compila il modulo di registrazione per i report sull'attribuzione da web ad app per entrare nella lista consentita per chiamare registerWebSource().

Qualsiasi app potrebbe chiamare registerWebTrigger() perché le considerazioni sulla privacy e sulla sicurezza sul lato del trigger non sono applicabili senza la collusione lato sorgente.

Controlli utente

Le app possono continuare a supportare i controlli utente o le norme relative alle autorizzazioni, a condizione che possano essere definiti al momento della registrazione. Ad esempio, se le app consentono autorizzazioni a livello di sito o utente, l'app deve valutarle e determinare se chiamare le API di contesto web.

Inoltre, supporteremo una nuova chiamata API dalle app per eliminare eventuali origini di attribuzione, trigger e report in attesa archiviati per l'app sul dispositivo. Ad esempio, se le app consentono all'utente di cancellare la cronologia di navigazione, potrebbe essere necessario chiamare l'API per eliminare le origini dell'attribuzione, i trigger e i report in attesa archiviati per l'app sul dispositivo dell'utente.

Considerazioni future e domande aperte

L'interoperabilità app-web per l'API Attribution Reporting è in fase di sviluppo. Vorremmo ricevere un feedback dalla community su alcune idee:

  1. Su un dispositivo supportato da Privacy Sandbox per Android, in che modo utilizzerai le soluzioni di misurazione del browser con l'API Attribution Reporting di Android? Preferisci trasferire tutto ad Android?
  2. Esistono problemi con la potenziale ricezione di due ping per ogni origine e trigger di attribuzione, uno dal browser o dall'app e uno dall'API Attribution Reporting?
  3. Come possiamo semplificare il debug di diverse API?
  4. La proposta non include la convalida dell'affiliazione tra le destinazioni web e app. In futuro, potremmo essere in grado di convalidare queste destinazioni controllando le associazioni utilizzando Digital Asset Links. In questo modo, bloccheresti qualcuno dei tuoi casi d'uso? Ha senso utilizzare Digital Asset Links per eseguire questa convalida?
  5. Quando registri un'origine dell'attribuzione, devi specificare una destinazione. Nel caso del collegamento dal web all'app, potresti voler specificare un link per app. Quali formati utilizzi per specificare questo link all'app?
  6. Quando registri un'origine di attribuzione da app a 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 origine) deve essere registrato dall'app anziché nel contesto del browser. Contattaci se hai dubbi in merito o se esistono altri casi d'uso che non rientrano nelle categorie trattate in questo problema che descrive i flussi supportati.