Vorschlag zum Design der SDK-Laufzeitsichtbarkeit

Anzeigen-SDKs in der SDK-Laufzeit 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, die außerhalb der SDK-Laufzeit verwendet werden, um zu bestimmen, ob die Anzeige für den Nutzer sichtbar ist, da der Anzeigen-View nicht am Fenster der Anwendung angehängt ist. Dazu gehören auch Android-View APIs wie getLocationOnScreen, getLocationInWindow oder getVisibility, die nicht die erwarteten Werte zurückgeben.

Die Unterstützung der Messung der Sichtbarkeit von Anzeigen ist eine grundlegende Anforderung der SDK-Laufzeit. Mit diesem Designvorschlag soll Open Measurement und ähnlichen Analysediensten die Unterstützung ermöglicht werden. Die hier beschriebenen Lösungen können auch für die Attribution Reporting APIs gelten.

Leistungsspektrum

Mit diesem Design sollen Anzeigen-SDKs oder Analysepartner die folgenden Sichtbarkeitsdaten berechnen können (die Namen sind vorläufig und können sich ändern):

Abbildung, die die Interaktion der Komponenten der SDK-Laufzeit für die Sichtbarkeit zeigt
Übersicht über die Sichtbarkeit bei der SDK-Laufzeit
  • viewport [Rect]: Stellt je nach den Funktionen der Plattform den Bildschirm des Geräts oder die Geometrie des App-Fensters dar.
  • uiContainerGeometry [Rect]: Die Geometrie des gerenderten SandboxedSdkView.
  • alpha [float]: Die Deckkraft des gerenderten SandboxedSdkView.
  • onScreenGeometry [Rect]: Die Teilmenge von uiContainerGeometry, die nicht von übergeordneten Ansichten zugeschnitten wird, bis einschließlich der viewport.
  • occludedGeometry [Rect]: Die Teile des onScreenGeometry, die von Ansichten in der Hierarchie der Anwendung verdeckt werden. Enthält eine Rect für jede Okklusion, die null, eine oder mehrere App-Ansichten entspricht, die sich mit der SandboxedSdkView onScreenGeometry überschneiden.

Voraussetzungen

  • Die Werte für uiContainerGeometry, onScreenGeometry und occludedGeometry werden im Koordinatenraum des viewport ausgedrückt.
  • Berichte zu Sichtbarkeitsänderungen werden mit minimaler Latenz erstellt.
  • Die Sichtbarkeit kann über den gesamten Lebenszyklus der Anzeigenfläche gemessen werden, vom ersten bis zum letzten Anzeigenaufruf.

Designvorschlag

Dieser Vorschlag basiert auf der Funktionsweise der UI-Darstellung mithilfe der UI-Bibliotheken von Kunden und Anbietern. Wir werden die UI-Bibliotheken erweitern, damit das SDK einen oder mehrere Beobachter der UI-Sitzung registrieren kann. Der Beobachter erhält Informationen zur Sichtbarkeit, wenn relevante Ereignisse erkannt werden, die die Datentypen im Abschnitt capabilities ändern. Analyse-SDKs in der SDK-Laufzeit (OMID- und MRAID-Implementierungen) können diesen Beobachter an die UI-Sitzung anhängen, damit diese Informationen direkt an sie gesendet werden können. Anbieter von Analysetools können Informationen aus UI-Bibliotheken mit Daten zu bereits verfügbaren Inhalten kombinieren (z. B. bei der Verwendung von Analysescripts, die in das Creative eingefügt werden), um JavaScript-Ereignisse zur Sichtbarkeit zu generieren.

Ablauf für die Sichtbarkeit steuern
Kontrollfluss für die Sichtbarkeit.

Die Clientbibliothek überwacht über Ereignislistener wie ViewTreeObserver Änderungen an der Anzeigen-Benutzeroberfläche. Wenn festgestellt wird, dass sich die Anzeigenoberfläche so geändert hat, dass sich dies auf die Sichtbarkeitsmessung auswirken könnte, prüft die Clientbibliothek, wann die letzte Benachrichtigung an den Beobachter gesendet wurde. Wenn die letzte Aktualisierung länger als die zulässige Latenz ist (über das SDK konfigurierbar, bis zu einem Minimum von 200 ms auf Mobilgeräten), wird ein neues AdContainerInfo-Objekt erstellt und eine Benachrichtigung an den Beobachter gesendet. Dieses ereignisbasierte Modell ist für die Systemintegrität besser als die Abfragen, die bei den meisten OMID-Implementierungen unter Android derzeit durchgeführt werden.

API

Der Bibliothek „privacysandbox.ui.core“ werden die folgenden Elemente hinzugefügt:

  • SessionObserver: Wird in der Regel vom Measurement SDK implementiert und an die Sitzung angehängt, die vom SDK über die privacysandbox.ui zurückgegeben wird. Über diese Benutzeroberfläche können Sie auch bestimmte Kategorien von Sichtbarkeitssignalen für das Analyse-SDK aktivieren. Dadurch kann die UI-Clientbibliothek nur Signale erfassen, an denen der Beobachter interessiert ist. Das ist insgesamt besser für die Systemgesundheit.
  • registerObserver(): Diese Methode wurde der Klasse Session hinzugefügt und ermöglicht es allen Personen mit Zugriff auf die Sitzung, einen Beobachter zu registrieren. Wenn der Beobachter nach dem Öffnen der UI-Sitzung registriert wird, wird ihm sofort die im Cache gespeicherte AdContainerInfo gesendet. Wenn sie vor Beginn der Sitzung registriert werden, werden sie beim Öffnen der Sitzung an AdContainerInfo gesendet.
  • AdContainerInfo: Eine Klasse mit Gettern, über die der Beobachter schreibgeschützte Anzeigencontainerinformationen für die Datentypen abrufen kann, die oben im Abschnitt Funktionen aufgeführt sind. Die Rückgabewerte dieser Getter entsprechen nach Möglichkeit den teilbaren Rückgabewerten vorhandener Getter von View und seinen Unterklassen. Wenn der Anzeigencontainer mit Jetpack Compose erstellt wurde, werden die semantischen Eigenschaften des Containers freigegeben. Mit dieser Klasse können MRAID- und OMID-Ereignisse im Zusammenhang mit der Sichtbarkeit berechnet werden.
  • SessionObserverotifyAdContainerChanged(): Damit wird der Beobachter benachrichtigt, wenn sich die Sichtbarkeit ändert. Es wird ein AdContainerInfo-Objekt übergeben. Diese Funktion wird aufgerufen, wenn Ereignisse erkannt werden, die sich auf Datentypen auswirken, die im Abschnitt „Funktionen“ aufgeführt sind. Hinweis: Diese Methode kann zusätzlich zu Methoden auf „Sitzung“ aufgerufen werden. Wenn beispielsweise Session.notifyResized() aufgerufen wird, um das SDK aufzufordern, die Größe der Anzeige zu ändern, wird auch SessionObserver.notifyAdContainerChanged() aufgerufen.
  • SessionObserverotifySessionClosed(): Benachrichtigt den Beobachter darüber, 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 Signalerfassung, 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 Anwendungsvorgang ausgeführt wird. Die Signalerfassung durch die UI-Bibliothek verschlechtert die Sicherheitssituation daher 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 bietet. setTrustedPresentationCallback wird auf Surface-Ebene verwendet und kann helfen, Aussagen über die Oberfläche zu treffen, die die Anzeigen-UI enthält, indem Mindestgrenzwerte für die Präsentation 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 UI-Clientbibliothek bereitgestellt werden (siehe oben). Da die vom Framework bereitgestellten Daten zuverlässiger sind, können alle Ereignisse aus der UI-Bibliothek, deren Daten nicht mit den Daten aus dem Framework übereinstimmen, verworfen werden. Wenn beispielsweise der für setTrustedPresentationCallback bereitgestellte Listener mit einer Benachrichtigung aufgerufen wird, dass keine Pixel der Anzeigen-UI auf dem Bildschirm angezeigt werden, und die Client-UI-Bibliothek eine nicht nullwertige Anzahl von Pixeln auf dem Bildschirm anzeigt, können Daten aus letzterer verworfen werden.

Offene Fragen

  1. Welche Signale zur Sichtbarkeit interessieren Sie, die in diesem Hilfeartikel nicht erwähnt werden?
  2. Derzeit wird vorgeschlagen, die Sichtbarkeit mindestens alle 200 Millisekunden zu aktualisieren, sofern es eine relevante Änderung an der Benutzeroberfläche gibt. Ist diese Häufigkeit für Sie akzeptabel? Falls nicht, wie oft würden Sie es bevorzugen?
  3. Möchten Sie Informationen aus setTrustedPresentationCallback selbst analysieren oder sollen Daten aus der Client-UI-Bibliothek von der Anbieter-UI-Bibliothek gelöscht 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, in dem Sie diese Fragen beantworten.