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 viste. 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 di SDK Runtime. Questa proposta di progettazione mira a ottenere il supporto delle Misurazione e servizi di misurazione simili. Le soluzioni discusse qui potrebbero essere applicabili anche alle API Attribution Reporting. Ti invitiamo a fornirci il tuo feedback su questa proposta.

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 come interagiscono i componenti della visibilità SDK Runtime
Panoramica della visibilità di SDK Runtime
.
  • viewport [Rect]: rappresenta lo schermo del dispositivo o la finestra dell'app. la geometria, a seconda delle capacità 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 di onScreenGeometry che sono ostruiti da eventuali visualizzazioni nella gerarchia dell'applicazione. Include un Rect per ogni occlusione, corrispondente a zero, una o più viste di app che si intersecano con SandboxedSdkView onScreenGeometry

Requisiti

  • Valori per uiContainerGeometry, onScreenGeometry e occludedGeometry sono espresse nello spazio di coordinate di 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 UI. L'osservatore riceverà informazioni sulla visibilità ogni volta che vengono rilevati eventi pertinenti che modificano i tipi di dati nella sezione Funzionalità. SDK di misurazione nel runtime dell'SDK (implementazioni OMID e MRAID) possono collegare questo osservatore alla sessione UI, in modo che queste informazioni possano essere inviate . 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.

Flusso di controllo 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 è stata modificata in che potrebbe influire sulla misurazione della visibilità, la libreria client controlla quando l'ultima notifica è stata inviata all'osservatore. Se l'ultimo aggiornamento è una data successiva della latenza consentita (configurabile dall'SDK, fino a un minimo di 200 ms su dispositivo mobile), viene creato un nuovo oggetto AdContainerInfo e viene visualizzata una notifica inviato all'osservatore. Questo modello basato su 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 capabilites sopra. I valori restituiti da questi getter corrispondono, se possibile, ai valori restituiti pacchettizzabili da quelli esistenti. getter su View e sulle relative sottoclassi. Se il contenitore dell'annuncio è stato creato utilizzando Jetpack Compose, espone le proprietà semantiche del container. Questo può essere utilizzata per calcolare eventi MRAID e OMID relativi alla visibilità.
  • SessionObserverotifyAdContainerChanged(): utilizzato per inviare una notifica 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 il SDK per ridimensionare l'annuncio. Inoltre, SessionObserver.notifyAdContainerChanged() lo è chiamato quando accade.
  • SessionObserverotifySessionClosed(): informa l'osservatore che la sessione è stata chiusa.

Miglioramenti futuri

Qualsiasi codice in esecuzione nel processo dell'applicazione, incluso il codice privacysandbox.ui.client, può essere modificata se l'applicazione viene è stato compromesso. Di conseguenza, qualsiasi logica di raccolta degli indicatori eseguita nell'applicazione è soggetta a manomissione del codice dell'applicazione. Questo vale anche per il codice SDK il cui deployment viene eseguito prima della disponibilità di Privacy Sandbox in esecuzione procedura di richiesta di adesione. Di conseguenza, la raccolta di indicatori da parte della libreria peggiorano la situazione della sicurezza.

Inoltre, il codice nel runtime dell'SDK può utilizzare un'API della piattaforma denominata setTrustedPresentationCallback che può dargli maggiori garanzie da il quadro di riferimento della 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, ad esempio la percentuale di pixel visibili, il tempo sullo schermo o la scala. Questi dati possono essere vengono verificati con i dati sulla visibilità forniti dalla libreria client dell'interfaccia utente, come spiegato in alto. 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 il listener ha fornito setTrustedPresentationCallback viene richiamato con una notifica che indica che nessun pixel dell'interfaccia utente dell'annuncio, mentre la libreria dell'interfaccia utente client mostra diverso da zero, i dati di quest'ultimo possono essere scartati.

Domande aperte

Invitiamo i nostri feedback sui seguenti punti:

  1. Quali indicatori di visibilità ti interessano che non sono menzionati in questo articolo esplicativo?
  2. La proposta attuale è aggiornare la visibilità non meno di ogni 200 millisecondi, a condizione che ci sia una modifica pertinente nell'interfaccia utente. È questo accettabile per te? In caso contrario, quale frequenza preferisci?
  3. Preferisci analizzare le informazioni di setTrustedPresentationCallback oppure fare in modo che la libreria dell'interfaccia utente del provider trasmetta i dati dall'interfaccia utente client libreria, se i dati di setTrustedPresentationCallback non corrispondono?
  4. Come consumi gli indicatori di visibilità? Aiutaci a comprendere i tuoi casi d'uso inviando un feedback che risponda a queste domande.