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

Aggiornamenti recenti

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

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

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

I percorsi di attivazione precedenti si traducono nei seguenti requisiti:

  • Per le tecnologie pubblicitarie: aggiornamenti alle chiamate API e ai report per abilitare i percorsi da app a web
  • Per app e browser: possibilità di trasmettere ad Android la registrazione delle origini di attribuzione web e degli attivatori web

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 app e le tecnologie pubblicitarie devono apportare per soddisfare i requisiti per supportare questi percorsi di attivazione.

Accedere alle API Attribution Reporting

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

Una volta completata la procedura di registrazione, l'API la eliminerà se viene ricevuta una chiamata di registrazione non registrata.

Al momento della registrazione, le piattaforme di ad tech devono assicurarsi di eseguire la registrazione con tutti gli URL dei server che potrebbero utilizzare su app e web per registrare gli attivatori e le sorgenti di attribuzione. Sono supportati più URL di registrazione del server, ma solo un'origine report. Questa origine report è ricavata dal dominio di uno degli URL di registrazione del server.

Modifiche per le tecnologie pubblicitarie

Questa sezione illustra le modifiche per le ad tech che utilizzano l'API Attribution Reporting.

Modifiche alla registrazione e all'attribuzione

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

Quando registri gli attivatori o le origini 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 monitoraggio 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 app nelle origini di attribuzione web. Ad esempio, ora puoi specificare le finestre di attribuzione post-installazione in un'origine di attribuzione web.

Ricevere report su app e web

L'API Attribution Reporting per Android può inviare report sia per le conversioni di app sia per quelle web. Se le tecnologie pubblicitarie non vogliono allineare i dati sugli attivatori e le chiavi di aggregazione sulle piattaforme web e per app, possono distinguere tra una conversione web e una in-app:

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

Implicazioni della misurazione da web a web

Le app scelgono quando passare la registrazione all'API Attribution Reporting. Qui esistono diverse considerazioni:

  • L'API Attribution Reporting è disponibile sul dispositivo? Mostreremo alle app un nuovo indicatore che restituisce se l'API Attribution Reporting è disponibile sul dispositivo. Consulta la sezione relativa alle modifiche all'app per ulteriori dettagli su come le app possono trasmettere la registrazione all'API Attribution Reporting.
  • Quale parte delle origini e degli attivatori di attribuzione deve essere passata all'API? Si tratta di 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 consigliabile utilizzarla. In definitiva, se disponibile, il passaggio di tutte le registrazioni di origine e attivatori all'API Attribution Reporting di Android consente di ottenere l'attribuzione più accurata su app e web.

Il seguente esempio 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 sia in un'app browser sia 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 primo giorno, l'utente fa clic su un annuncio nell'app del browser.
    • L'app del browser può scegliere di utilizzare la propria soluzione di misurazione o passare 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 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 del browser registra sia il clic sia 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, un fornitore di tecnologia pubblicitaria potrebbe consumare sia i limiti di frequenza delle app browser sia i limiti di frequenza dell'API Attribution Reporting. Pertanto, consigliamo alle app di trasmettere tutte le conversioni e gli eventi annuncio da registrare nell'API, quando è disponibile.

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

Se l'app utilizza WebView per mostrare contenuti web anziché un annuncio per Android, può richiedere di essere inserita nella lista consentita per registerWebSource() e fornire l'origine di primo livello del sito web da essere associata all'origine dell'attribuzione anziché al nome del pacchetto dell'app.

Come i browser, WebView supporta registerWebTrigger() per le registrazioni degli attivatori, che associano l'attivatore all'origine di primo livello. Non è supportato il salvataggio di un attivatore dell'app in WebView. Contattaci se hai un caso d'uso in tal senso. Per l'elenco completo delle combinazioni supportate da WebView, consulta Registrazione dell'origine e dell'attivatore dell'attribuzione da WebView.

A differenza dei browser, WebView supporta la registrazione con il sistema operativo nell'Attribution-Reporting-Eligible header 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 degli attivatori 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() (nonché su come modificare questo comportamento), consulta Origine dell'attribuzione e attivazione della registrazione da WebView.

Report di debug di transizione

L'API Attribution Reporting supporta una funzionalità facoltativa chiamata report di debug di transizione, che consente agli esperti di pubblicità di saperne di più 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 su più app e web e contengono entrambi le stesse informazioni. L'unica differenza riguarda le autorizzazioni che vengono applicate quando vengono inviati i report di debug.

Per l'attribuzione web-to-web che avviene all'interno di un'unica app (ad es. all'interno della stessa app del browser), i report dettagliati e di attribuzione riuscita sono disponibili solo se 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, sono disponibili i report di attribuzione riuscita e dettagliati se AdID è disponibile sul lato dell'app e la tecnologia pubblicitaria può trasmettere lo stesso AdID (corretto) sul lato web.

In un esempio successivo di app-to-web, l'origine si verifica in un'app del publisher, ma l'attivazione avviene sul sito di un inserzionista all'interno di un'app di browser.

Per attivare un report di debug relativo al buon esito dell'attribuzione per la campagna da app a web, devono essere soddisfatte le seguenti condizioni:

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

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

  • I report dettagliati delle origini dipendono solo dalle autorizzazioni del publisher. Affinché i report dettagliati sulle sorgenti vengano inviati, l'utente non deve aver disattivato la personalizzazione dell'AdID e l'app publisher deve aver dichiarato le autorizzazioni AdID.
  • I report dettagliati degli attivatori dipendono solo dalle autorizzazioni sul lato dell'attivatore (in questo esempio, web). Affinché i report dettagliati vengano inviati, i cookie di terze parti devono essere disponibili nel browser.
  • Per attivare report dettagliati 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 utilizzando il campo del dizionario debug_reporting nelle intestazioni di registrazione di origine e di attivazione.

Modifiche per le app

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

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

  • Attribution-Reporting-Eligible indica se è disponibile il supporto per l'attribuzione a livello di sistema operativo. In questo caso, l'intestazione indica se l'API Attribution Reporting di Android è disponibile.
  • Se disponibile, gli esperti di tecnologia pubblicitaria possono facoltativamente rispondere utilizzando Attribution-Reporting-Register-OS-Source, che avvia una chiamata API secondaria dall'app del browser a registerWebSource().
  • Gli esperti di tecnologia pubblicitaria possono anche rispondere alle registrazioni degli attivatori utilizzando l'Attribution-Reporting-Register-OS-Trigger header, che avvia una chiamata API secondaria dall'app del browser a registerWebTrigger().

Registrazione dell'origine dell'attribuzione

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

  • URI delle origini di attribuzione: la piattaforma invia una richiesta a ogni URI in questo elenco per recuperare i metadati associati all'origine di 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 di un pacchetto dell'app in cui si verifica l'evento di attivazione.
  • Destinazione web: un eTLD+1 in cui si verifica l'evento di attivazione.
  • Destinazione verificata: intent URI di destinazione web o del sistema operativo utilizzato per la navigazione al clic dell'utente.

Quando l'API invia una richiesta all'URI dell'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 di attribuzione app-to-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 web contenuto. Per i clic, le app devono verificare che la destinazione specificata corrisponde a quella a cui sta navigando l'utente.
  • L'API ignora 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 relative alle autorizzazioni in base alle esigenze.

Le app devono essere inserite in una lista consentita per chiamare registerWebSource(). Compila questo modulo per inserire la tua app nella lista consentita. Lo scopo della lista consentita è attenuare le considerazioni sulla privacy relative all'ottenimento della fiducia per il contesto web.

Registrazione dell'attivatore (conversione)

Al momento della registrazione dell'attivatore, le app possono chiamare registerWebTrigger(), che prevede i seguenti parametri:

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

Origine attribuzione e registrazione dell'attivatore da WebView

Per impostazione predefinita, WebView utilizzerà registerSource() e registerWebTrigger(). In questo modo, associa le origini all'app e si attiva con l'origine di primo livello del 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 della 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 Esempio di caso d'uso
APP_SOURCE_AND_WEB_TRIGGER (valore predefinito) Consente alle app di registrare origini app (origini associate al nome del pacchetto dell'app) e attivatori web (attivatori associati all'eTLD+1) da WebView. App che utilizzano WebView per pubblicare annunci anziché per consentire la navigazione web
WEB_SOURCE_AND_WEB_TRIGGER Consente alle app di registrare origini web e attivatori web da WebView.
Nota: le app che utilizzano questa opzione dovranno richiedere di essere inserite nella lista consentita per poter utilizzare registerWebSource().		 App browser basate su WebView, in cui le impressioni degli annunci e le conversioni potrebbero verificarsi sui siti web in WebView.
APP_SOURCE_AND_APP_TRIGGER Consente alle app di registrare origini e attivatori da WebView. App basate su WebView in cui le impressioni degli annunci e le conversioni devono sempre essere associate all'app anziché all'eTLD+1 del componente WebView.
DISATTIVATO Disattiva la registrazione dell'origine e dell'attivatore da WebView.
Tieni presente che la chiamata di rete iniziale agli URI di origine o di attivazione dell'attribuzione potrebbe comunque avvenire, ma qualsiasi risposta viene ignorata e non verrà memorizzato nulla sul dispositivo.

Considerazioni su privacy e sicurezza

Questa sezione illustra i fattori di privacy e 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 ai report limiti di frequenza che tutelano la privacy. Alcuni limiti sono suddivisi tra le app di origine e di destinazione. Quando viene registrato un attivatore o un'origine di attribuzione web, il limite di frequenza viene suddiviso in base al sito di origine o di destinazione anziché all'app.

Se l'app gestisce limiti di frequenza separati, un avversario potrebbe consumare i limiti di frequenza specifici dell'app oltre a quelli dell'API. Per attenuare questo problema, le app devono assicurarsi che una determinata origine di attribuzione non sia registrata sia nella soluzione di misurazione dell'app sia nell'API Android Attribution Reporting.

Stabilire la fiducia 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 materia di privacy e sicurezza:

  • Un avversario 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ù avversari possono colludere per registrare origini di attribuzione distinte, dichiarando lo stesso sito di origine. Ciò potrebbe causare il raggiungimento dei limiti di frequenza della piattaforma di tecnologia pubblicitaria e impedire al sito di origine effettivo di registrare fonti di attribuzione legittime.

Per mitigare questo problema, limiteremo i browser o le app che possono chiamareregisterWebSource() 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 inserire la tua app nella lista consentita per chiamare registerWebSource().

Qualsiasi app potrebbe chiamare registerWebTrigger() perché le considerazioni sulla privacy e sulla sicurezza sul lato dell'attivatore non sono applicabili senza collusione sul lato dell'origine.

Controlli utente

Le app possono continuare a supportare i controlli utente o i criteri di autorizzazione, a condizione che possano essere definiti al momento della registrazione. Ad esempio, se le app consentono qualsiasi autorizzazione 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, attivatori e report in attesa di attribuzione memorizzati per l'app sul dispositivo. Ad esempio, se le app consentono all'utente di cancellare la cronologia di navigazione, l'utente potrebbe voler chiamare l'API per eliminare le origini di attribuzione, gli attivatori e i report in attesa memorizzati per l'app sul suo dispositivo.

Considerazioni future e domande aperte

L'interoperabilità da app a web per l'API Attribution Reporting è in fase di sviluppo. Vorremmo chiedere alla community un feedback su alcune idee:

  1. Su un dispositivo Android supportato da Privacy Sandbox, come utilizzerai le soluzioni di misurazione del browser con l'API Attribution Reporting per Android? Preferisci trasferire tutto su Android?
  2. Esistono problemi con la potenziale ricezione di due ping per ogni trigger e origine attribuzione, uno dal browser o dall'app e uno dall'API Attribution Reporting?
  3. Come possiamo aiutarti a semplificare il debug in più API?
  4. La proposta non include la convalida dell'affiliazione delle destinazioni web e dell'app. In futuro, potremmo essere in grado di convalidare queste destinazioni controllando le associazioni utilizzando i link agli asset digitali. Questo bloccherebbe qualcuno dei tuoi casi d'uso? Ha senso utilizzare Digital Asset Links per eseguire questa convalida?
  5. Quando registri un'origine attribuzione, devi specificare una destinazione. Nel caso di transizione da web ad app, ti consigliamo di specificare un link all'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 Attribution Reporting per Android. Ad esempio, se l'utente fa clic su un annuncio e il clic viene aperto in un browser o nella scheda personalizzata di un browser, questo clic (evento di 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 coperte da questo problema che descrive i flussi supportati.