Proposta di progettazione della visibilità di SDK Runtime

Gli SDK per gli annunci in SDK Runtime non sono in grado di accedere alla gerarchia delle visualizzazioni di un publisher. Gli SDK nel runtime hanno invece le proprie visualizzazioni. L'SDK non può utilizzare le stesse API View utilizzate al di fuori del runtime dell'SDK per determinare se l'annuncio è visibile all'utente, perché la visualizzazione dell'annuncio non è collegata alla finestra dell'applicazione. Sono incluse le API View per Android come getLocationOnScreen, getLocationInWindow o getVisibility, che non restituiscono i valori previsti.

Il supporto della misurazione della visibilità degli annunci è un requisito fondamentale del runtime dell'SDK. Questa proposta di progettazione mira a ottenere il supporto di Open Measurement e di servizi di misurazione simili. Le soluzioni discusse qui potrebbero essere applicabili anche alle API Attribution Reporting.

Funzionalità

Questo design ha lo scopo di supportare gli SDK pubblicitari o i partner di misurazione per calcolare i seguenti dati sulla visibilità (i nomi sono provvisori e soggetti a modifiche):

Illustrazione che mostra l'interazione tra i componenti della visibilità in fase di runtime dell'SDK
Panoramica della visibilità di SDK Runtime
.
  • viewport [Rect]: rappresenta la geometria della schermata del dispositivo o della finestra dell'app, a seconda delle funzionalità della piattaforma.
  • uiContainerGeometry [Rect]: la geometria del SandboxedSdkView visualizzato.
  • alpha [float]: l'opacità del SandboxedSdkView visualizzato.
  • onScreenGeometry [Rect]: il sottoinsieme di uiContainerGeometry che non viene tagliato dalle visualizzazioni principali, fino al viewport incluso.
  • occludedGeometry [Rect]: le parti del onScreenGeometry che sono bloccate da eventuali visualizzazioni nella gerarchia dell'applicazione. Include un Rect per ogni occlusione, corrispondente a zero, una o più visualizzazioni di app che si intersecano con il SandboxedSdkView onScreenGeometry

Requisiti

  • I valori di uiContainerGeometry, onScreenGeometry e occludedGeometry vengono espressi nello spazio delle coordinate del viewport.
  • La generazione di report sulle variazioni di visibilità avviene con una latenza minima.
  • La visibilità è misurabile per l'intero ciclo di vita della visualizzazione dell'annuncio, dalla prima apparizione all'ultima.

Proposta di design

Questa proposta si basa sul funzionamento della presentazione dell'interfaccia utente utilizzando le librerie UI del client e del fornitore. Estenderemo le librerie UI per consentire all'SDK di registrare uno o più osservatori della sessione dell'interfaccia utente. L'osservatore riceverà informazioni sulla visibilità ogni volta che vengono rilevati eventi pertinenti che modificano i tipi di dati nella sezione capabilities. Gli SDK di misurazione nel runtime dell'SDK (implementazioni di OMID e MRAID) possono collegare questo osservatore alla sessione dell'interfaccia utente, in modo che queste informazioni possano essere inviate direttamente a loro. I partner di misurazione possono combinare le informazioni ottenute dalle librerie UI con i dati sui contenuti già disponibili (ad esempio quando si utilizzano script di misurazione iniettati nella creatività dell'annuncio) per generare eventi di visibilità JavaScript.

Controlla il flusso per la visibilità.
Flusso di controllo per la visibilità.

La libreria client ascolta le modifiche all'interfaccia utente dell'annuncio tramite ascoltatori di eventi come ViewTreeObserver. Ogni volta che determina che l'interfaccia utente dell'annuncio è cambiata in modo da poter influire sulla misurazione della visibilità, la libreria client controlla quando è stata inviata l'ultima notifica all'osservatore. Se l'ultimo aggiornamento è superiore alla latenza consentita (configurabile dall'SDK, fino a un minimo di 200 ms su dispositivi mobili), viene creato un nuovo oggetto AdContainerInfo e viene inviata una notifica all'osservatore. Questo modello basato sugli eventi è migliore per l'integrità del sistema rispetto al polling eseguito dalla maggior parte delle implementazioni di OMID su Android al momento.

API

Alla libreria privacysandbox.ui.core verrà aggiunto quanto segue:

  • SessionObserver: in genere implementato dall'SDK di misurazione, associato alla sessione restituita dall'SDK tramite privacysandbox.ui. Questa interfaccia consentirà inoltre all'SDK di misurazione di attivare determinate categorie di indicatori di visibilità. Ciò consente alla libreria client dell'interfaccia utente di raccogliere solo gli indicatori di interesse dell'osservatore, il che è meglio per la salute complessiva del sistema.
  • registerObserver(): aggiunto alla classe Session, questo metodo consente a chiunque abbia accesso alla sessione di registrare un osservatore. Se l'osservatore viene registrato dopo l'apertura della sessione dell'interfaccia utente, riceverà immediatamente il valore AdContainerInfo memorizzato nella cache. Se registrati prima dell'apertura della sessione, verranno inviati AdContainerInfo quando la sessione viene aperta.
  • AdContainerInfo: una classe con getter che consente all'osservatore di ottenere informazioni di sola lettura sui contenitori degli annunci per i tipi di dati elencati nella sezione funzionalità sopra. I valori restituiti da questi getter corrisponderanno, ove possibile, ai valori restituiti parcellabili dei getter esistenti su View e sulle sue sottoclassi. Se il contenitore dell'annuncio è stato creato utilizzando Jetpack Compose, vengono esposte le proprietà semantiche del contenitore. Questa classe può essere utilizzata per calcolare gli eventi MRAID e OMID relativi alla visibilità.
  • SessionObserverotifyAdContainerChanged(): utilizzato per notificare all'osservatore ogni volta che la visibilità cambia. Passa un oggetto AdContainerInfo. Viene chiamato ogni volta che vengono rilevati eventi che interessano i tipi di dati elencati nella sezione Funzionalità. Nota: questo metodo potrebbe essere chiamato in aggiunta ai metodi su Session. Ad esempio, Session.notifyResized() viene chiamato per richiedere all'SDK di ridimensionare l'annuncio e viene chiamato anche SessionObserver.notifyAdContainerChanged().
  • SessionObserverotifySessionClosed(): informa l'osservatore che la sessione è stata chiusa.

Miglioramenti futuri

Qualsiasi codice in esecuzione nel processo di applicazione, incluso il codice della libreria privacysandbox.ui.client, può essere modificato se l'applicazione è compromessa. Pertanto, qualsiasi logica di raccolta degli indicatori eseguita nel processo dell'applicazione è soggetta a manomissioni da parte del codice dell'applicazione. Questo vale anche per il codice SDK impiegato prima della disponibilità di Privacy Sandbox ed eseguito nella procedura di applicazione. Di conseguenza, la raccolta degli indicatori da parte della libreria UI non peggiora la situazione di sicurezza.

Inoltre, il codice in SDK Runtime può utilizzare un'API di piattaforma chiamata setTrustedPresentationCallback che può fornire maggiori garanzie da parte del framework sulla presentazione dell'interfaccia utente dell'annuncio. setTrustedPresentationCallback funziona a livello di piattaforma e può aiutarti a fare affermazioni sulla piattaforma contenente l'interfaccia utente dell'annuncio specificando soglie minime per la presentazione, come la percentuale di pixel visibili, il tempo sullo schermo o la scala. Questi dati possono essere controllati in base ai dati sulla visibilità forniti dalla libreria client dell'interfaccia utente, descritti sopra. Poiché i dati forniti dal framework sono più affidabili, tutti gli eventi della raccolta UI i cui dati non sono in linea con quelli del framework possono essere ignorati. Ad esempio, se l'ascoltatore fornito a setTrustedPresentationCallback viene invocato con una notifica che indica che nessun pixel dell'interfaccia utente dell'annuncio viene visualizzato sullo schermo e la libreria dell'interfaccia utente del client mostra un numero di pixel sullo schermo diverso da zero, i dati di quest'ultima possono essere ignorati.

Domande aperte

  1. Quali indicatori di visibilità ti interessano e non sono menzionati in questa spiegazione?
  2. La proposta attuale è aggiornare la visibilità non meno di ogni 200 millisecondi, a condizione che ci sia una modifica pertinente nell'interfaccia utente. Questa frequenza è accettabile per te? In caso contrario, quale frequenza preferisci?
  3. Preferisci analizzare autonomamente le informazioni di setTrustedPresentationCallback o che la libreria UI del fornitore elimini i dati dalla libreria UI del client quando non corrispondono ai dati di setTrustedPresentationCallback?
  4. Come consumi gli indicatori di visibilità? Aiutaci a comprendere i tuoi casi d'uso inviando un feedback che risponda a queste domande.