Vorschlag zum Design der SDK-Laufzeitsichtbarkeit

Anzeigen-SDKs in der SDK Runtime können nicht auf die Ansichtshierarchie eines Publishers zugreifen. Stattdessen haben SDKs in der Laufzeit eigene Ansichten. Das SDK kann nicht dieselben View-APIs verwenden wie außerhalb der SDK-Laufzeit, um festzustellen, ob die Anzeige für den Nutzer sichtbar ist, da die Anzeigenansicht nicht mit dem Fenster der Anwendung verknüpft ist. Dazu gehören Android View APIs wie getLocationOnScreen, getLocationInWindow oder getVisibility, die nicht die erwarteten Werte zurückgeben.

Die Unterstützung der Sichtbarkeitsmessung von Anzeigen ist eine grundlegende Anforderung der SDK-Laufzeit. Mit diesem Designvorschlag soll die Unterstützung für Open Measurement und ähnliche Analysedienste erreicht werden. Die hier beschriebenen Lösungen können auch für die Attribution Reporting APIs gelten.

Leistungsspektrum

Dieses Design soll es ermöglichen, dass Anzeigen-SDKs oder Analysepartner die folgenden Sichtbarkeitsdaten berechnen können (Namen sind vorläufig und können sich ändern):

Abbildung, die zeigt, wie die Komponenten der SDK-Laufzeit für Sichtbarkeit zusammenarbeiten
Übersicht über die Sichtbarkeit der SDK-Laufzeit.
  • viewport [Rect]: Stellt die Geometrie des Gerätebildschirms oder des App-Fensters dar, je nach den Funktionen der Plattform.
  • uiContainerGeometry [Rect]: Die Geometrie des gerenderten SandboxedSdkView.
  • alpha [float]: Die Deckkraft des gerenderten SandboxedSdkView.
  • onScreenGeometry [Rect]: Die Teilmenge von uiContainerGeometry, die nicht durch übergeordnete Ansichten abgeschnitten wird, bis einschließlich viewport.
  • occludedGeometry [Rect]: Die Teile von onScreenGeometry, die durch Ansichten in der Hierarchie der Anwendung verdeckt werden. Enthält ein Rect für jede Verdeckung, das null, einer oder mehreren App-Ansichten entspricht, die sich mit dem SandboxedSdkView onScreenGeometry überschneiden.

Voraussetzungen

  • Die Werte für uiContainerGeometry, onScreenGeometry und occludedGeometry werden im Koordinatensystem des viewport ausgedrückt.
  • Berichte zu Änderungen der Sichtbarkeit werden mit minimaler Latenz erstellt.
  • Die Sichtbarkeit ist für den gesamten Lebenszyklus der Anzeigenansicht messbar, von der ersten bis zur letzten Einblendung.

Designvorschlag

Dieser Vorschlag basiert auf der UI-Darstellung mit den Client- und Provider-UI-Bibliotheken. Wir werden die UI-Bibliotheken erweitern, damit das SDK einen oder mehrere Beobachter der UI-Sitzung registrieren kann. Der Observer erhält Informationen zur Sichtbarkeit, wenn relevante Ereignisse erkannt werden, die die Datentypen im Abschnitt capabilities ändern. Measurement-SDKs in der SDK-Laufzeit (OMID- und MRAID-Implementierungen) können diesen Observer an die UI-Sitzung anhängen, damit diese Informationen direkt an sie gesendet werden können. Measurement-Partner können Informationen aus UI-Bibliotheken mit bereits verfügbaren Inhaltsdaten kombinieren, z. B. wenn im Anzeigen-Creative Measurement-Scripts eingefügt werden, um JavaScript-Sichtbarkeitsereignisse zu generieren.

Kontrollgruppe für Sichtbarkeit.
Kontrollfluss für die Sichtbarkeit.

Die Clientbibliothek reagiert auf Änderungen in der Anzeigen-UI über Event-Listener wie ViewTreeObserver. Wenn die Clientbibliothek feststellt, dass sich die Benutzeroberfläche der Anzeige so geändert hat, dass sich dies auf die Messung der Sichtbarkeit auswirken könnte, wird geprüft, wann die letzte Benachrichtigung an den Observer gesendet wurde. Wenn das letzte Update die zulässige Latenz überschreitet (konfigurierbar über das SDK, mindestens 200 ms auf Mobilgeräten), wird ein neues AdContainerInfo-Objekt erstellt und eine Benachrichtigung an den Observer gesendet. Dieses ereignisbasierte Modell ist besser für die Systemintegrität als das Polling, das von den meisten OMID-Implementierungen auf Android verwendet wird.

API

Der privacysandbox.ui.core-Bibliothek wird Folgendes hinzugefügt:

  • SessionObserver: Wird in der Regel vom Measurement SDK implementiert und an die Sitzung angehängt, die vom SDK über privacysandbox.ui zurückgegeben wird. Über diese Schnittstelle kann das Measurement SDK auch bestimmte Kategorien von Sichtbarkeitssignalen aktivieren. Dadurch kann die UI-Clientbibliothek nur Signale erfassen, die für den Beobachter von Interesse sind, was sich insgesamt positiv auf die Systemleistung auswirkt.
  • registerObserver(): Diese Methode wird der Session-Klasse hinzugefügt und ermöglicht es jedem mit Zugriff auf die Sitzung, einen Beobachter zu registrieren. Wenn sich der Beobachter registriert, nachdem die UI-Sitzung geöffnet wurde, wird ihm das zwischengespeicherte AdContainerInfo sofort gesendet. Wenn sie vor dem Öffnen der Sitzung registriert wurden, wird ihnen AdContainerInfo gesendet, wenn die Sitzung geöffnet wird.
  • AdContainerInfo: Eine Klasse mit Gettern, mit denen der Observer schreibgeschützte Informationen zum Anzeigencontainer für die oben im Abschnitt Funktionen aufgeführten Datentypen abrufen kann. Die Rückgabewerte dieser Getter entsprechen, sofern möglich, den parcelable-Rückgabewerten der vorhandenen Getter für View und seine Unterklassen. Wenn der Anzeigencontainer mit Jetpack Compose erstellt wurde, werden die semantischen Eigenschaften des Containers verfügbar gemacht. Mit dieser Klasse können MRAID- und OMID-Ereignisse im Zusammenhang mit der Sichtbarkeit berechnet werden.
  • SessionObserverotifyAdContainerChanged(): Wird verwendet, um den Beobachter zu benachrichtigen, wenn sich die Sichtbarkeit ändert. Es wird ein AdContainerInfo-Objekt übergeben. Diese Methode wird immer dann aufgerufen, wenn Ereignisse erkannt werden, die sich auf die im Abschnitt „Funktionen“ aufgeführten Datentypen auswirken. Hinweis: Diese Methode wird möglicherweise zusätzlich zu Methoden für die Sitzung aufgerufen. Beispiel: Session.notifyResized() wird aufgerufen, um das SDK aufzufordern, die Größe der Anzeige zu ändern, und SessionObserver.notifyAdContainerChanged() wird ebenfalls aufgerufen, wenn dies geschieht.
  • SessionObserverotifySessionClosed(): Benachrichtigt den Beobachter, dass die Sitzung geschlossen wurde.

Zukünftige Verbesserungen

Jeder Code, der im Anwendungsprozess ausgeführt wird, einschließlich des Codes aus der Bibliothek „privacysandbox.ui.client“, kann geändert werden, wenn die Anwendung manipuliert wird. Daher ist jede Logik zur Erfassung von Signalen, die im Anwendungsprozess ausgeführt wird, anfällig für Manipulationen durch Anwendungscode. Dies gilt auch für SDK-Code, der vor der Verfügbarkeit der Privacy Sandbox bereitgestellt wurde und im Anwendungsprozess ausgeführt wird. Daher verschlechtert die Signalerfassung durch die UI-Bibliothek die Sicherheitslage nicht.

Außerdem kann Code in der SDK-Laufzeit eine Plattform-API namens setTrustedPresentationCallback verwenden, die dem Framework stärkere Garantien für die Darstellung der Anzeigen-UI gibt. setTrustedPresentationCallback funktioniert auf der Surface-Ebene und kann helfen, Behauptungen über die Surface mit der Anzeigen-UI aufzustellen, indem Mindestschwellenwerte für die Darstellung angegeben werden, z. B. der Prozentsatz der sichtbaren Pixel, die Zeit auf dem Bildschirm oder die Skalierung. Diese Daten können mit den Daten zur Sichtbarkeit verglichen werden, die von der oben beschriebenen UI-Clientbibliothek bereitgestellt werden. Da die vom Framework bereitgestellten Daten zuverlässiger sind, können alle Ereignisse aus der UI-Bibliothek verworfen werden, deren Daten nicht mit den Daten aus dem Framework übereinstimmen. Wenn der für setTrustedPresentationCallback bereitgestellte Listener beispielsweise mit einer Benachrichtigung aufgerufen wird, dass keine Pixel der Anzeigen-UI auf dem Bildschirm angezeigt werden, und die Client-UI-Bibliothek eine Anzahl von Pixeln ungleich null auf dem Bildschirm anzeigt, können die Daten aus der Client-UI-Bibliothek verworfen werden.

Offene Fragen

  1. Welche Signale zur Sichtbarkeit interessieren Sie, die in dieser Erläuterung nicht erwähnt werden?
  2. Der aktuelle Vorschlag sieht vor, die Sichtbarkeit mindestens alle 200 Millisekunden zu aktualisieren, sofern es eine relevante Änderung auf der Benutzeroberfläche gibt. Ist diese Häufigkeit für Sie akzeptabel? Wenn nicht, wie oft möchten Sie die Reinigung durchführen lassen?
  3. Möchten Sie Informationen aus setTrustedPresentationCallback selbst analysieren oder sollen Daten aus der Client-UI-Bibliothek von der Anbieter-UI-Bibliothek verworfen werden, wenn sie nicht mit setTrustedPresentationCallback-Daten übereinstimmen?
  4. Wie werden Sichtbarkeitssignale verwendet? Helfen Sie uns, Ihre Anwendungsfälle besser zu verstehen, indem Sie Feedback geben und diese Fragen beantworten.