Aktuelle Informationen zu den Fortschritten bei der Privacy Sandbox für Android

Diese Fortschrittsberichte enthalten eine Zusammenfassung der neuen Entwicklungen und Updates zu den Designvorschlägen, wichtige Fragen und Feedback, das wir erhalten haben, sowie Updates zu den Entwicklervorschauversionen.

Neuveröffentlichungen

Veröffentlichung der Entwicklervorschau 7

Diese neue Version ist ein wichtiger Meilenstein, der die Grundlage für zukünftige Privacy Sandbox-Betaversionen bildet. Diese Version enthält zusätzliche Funktionen für die abfolgebasierte Vermittlung von Protected Audience-Kampagnen, Daisy-Chain-Weiterleitungen bei der Registrierung von Attributionsberichten und andere API-Änderungen.

Wir aktualisieren die Ressourcen für die Entwicklervorschau fortlaufend, sobald in den kommenden Monaten neue Funktionen veröffentlicht werden. Melden Sie sich an, um Neuigkeiten zur Initiative zu erhalten.

Betaversion vom März 2023 veröffentlicht

Diese Version steht für die Verfügbarkeit der Privacy Sandbox APIs auf öffentlichen Geräten und ist funktional mit der Entwicklervorschau 6 identisch. Entwickler können über das Extension SDK auf die APIs in Betaversionen zugreifen.

Aktualisierung der Zeitleiste für Releases der Entwicklervorschau

Alle Termine und Details können sich ändern.

Jede Entwicklervorschau und jeder Beta-Release werden mit ausführlichen Releasenotes und Anleitungen geliefert, in denen beschrieben wird, welche Funktionen mit den einzelnen Releases verfügbar sind und welche nicht.

Jetzt verfügbar:

  • Entwicklervorschau 7: Enthält Funktionen,mit denen Sie die Integration mithilfe relevanter APIs wie der SDK-Laufzeit, der Topics API, der Protected Audience API und der Attribution Reporting API entwerfen können.
  • Das Betaprogramm ist für eingeschränkte Produktionstests verfügbar. Die Betaversion vom März 2023 steht für die Verfügbarkeit der Privacy Sandbox APIs auf öffentlichen Geräten und ist funktional mit der Entwicklervorschau 6 identisch.

Anfang 2023:

  • Erste stabile API-Version der datenschutzfreundlichen APIs auf einem kleinen Prozentsatz von Android 13-Geräten.

Bis 2023:

  • Weitere Iterationen von Entwicklervorschauen und stabile API-Releases mit zusätzlichen Funktionen. Ausweitung auf mehr Nutzer und Android-Geräte.

Erinnerung:Als wir im Februar die Privacy Sandbox für Android ankündigten, haben wir betont, dass wir die bestehenden Funktionen der Werbeplattform mindestens zwei Jahre lang unterstützen werden, während wir diese neuen Lösungen entwerfen, entwickeln und testen. Alle künftigen Änderungen werden rechtzeitig angekündigt.

Aktualisierungen des Designvorschlags

In diesem Abschnitt werden mehrere spezifische Änderungen an den Designvorschlägen beschrieben.

Reflection APIs

In unserem ursprünglichen Designvorschlag für die SDK Runtime haben wir um Feedback zu unserem Vorschlag gebeten, den Zugriff auf die Reflection- und Invoke-APIs zu verhindern. Ziel war es, SDK-Entwicklern zu helfen, Manipulationen durch andere SDKs zu verhindern.

Wir haben wertvolles Feedback zu den betroffenen Anwendungsfällen erhalten. Nach einer weiteren Untersuchung der Nützlichkeit und der Risiken erlauben wir die Verwendung von Reflection und Invoke APIs innerhalb der SDK-Laufzeit. Wir haben unseren Designvorschlag entsprechend aktualisiert.

Ein SDK darf jedoch keine Reflection verwenden oder APIs in einem anderen runtimefähigen SDK aufrufen. Für die SDK-zu-SDK-Kommunikation in der SDK-Laufzeit entwerfen wir stattdessen separate APIs für die SDK-Erkennung. Diese werden in einem zukünftigen Update näher erläutert.

Wir suchen ständig nach Möglichkeiten, das Risiko von Manipulationen durch andere SDKs zu verringern. Daher empfehlen wir weiterhin, die Verwendung von JNI-Code in der SDK-Laufzeit zu verhindern. Wir prüfen auch aktiv andere APIs. Wir werden in einem zukünftigen Update einen vollständigen Vorschlag unzulässiger APIs veröffentlichen.

Attribution Reporting API

Topics API

  • Die Topics API gibt eine Liste mit bis zu drei Themen zurück, jeweils eines für die letzten drei Epochen (z. B. die letzten drei Wochen). Wir haben das technische Angebot der Topics API aktualisiert, um klarzustellen, dass die zurückgegebenen Themen den Interessen des Nutzers entsprechen und dass einige oder alle zurückgegebenen Themen für personalisierte Werbung verwendet werden können.

Zusammenfassung weiterer Fragen und erhaltenes Feedback

In diesem Abschnitt finden Sie einige der Fragen und das Feedback, die wir erhalten haben, sowie unsere Antworten.

Allgemeine Fragen

Wird die Privacy Sandbox für Android auf internetfähige Fernseher angewendet?
Unsere aktuellen Designvorschläge konzentrieren sich auf die Unterstützung von Anwendungsfällen für Mobilgeräte und Apps. Wir werden in Zukunft weitere Informationen zu anderen Android-Formfaktoren veröffentlichen.
Wie wird die Privacy Sandbox für Android auf Geräten für die Betaversion eingeführt?
Um Updates für Nutzer flexibel im Laufe der Zeit bereitzustellen, werden die Hauptkomponenten als Mainline-Module auf unterstützten Android-Mobilgeräten verteilt. Auf diese Weise können wir unterstützte Geräte jenseits des normalen Releasezyklus der Android-Plattform nahtlos verbessern.
Wie sieht Ihr Plan für den Kotlin-Support aus?
Wir arbeiten daran, das Design der Privacy Sandbox API zu überarbeiten und Entwicklern die Möglichkeit zu geben, idiomatischen Kotlin-Code zu schreiben. Entsprechende Entwicklerressourcen, z. B. Beispiel-Apps in der Entwicklervorschau, sind neben Java auch in Kotlin verfügbar.
Welche Einstellungen gibt es für die Privacy Sandbox auf Nutzerebene und wie lange wird es dauern, bis sie eingeführt werden?

Die endgültigen Designs befinden sich noch in der Entwicklung, aber während der Betaphase möchten wir Nutzern Steuerelemente in den Geräteeinstellungen zur Verfügung stellen, mit denen Sie:

  1. Privacy Sandbox-Lösungen verlassen oder wieder beitreten
  2. Bestimmte abgeleitete Themen aus der Topics API entfernen
Können auch andere App-Shop-Systeme als Google Play die Privacy Sandbox-Lösungen verwenden?

Alle Privacy Sandbox-Lösungen sind Teil des Android Open Source Project (AOSP) und können bei Bedarf auch von anderen App-Shops übernommen werden. Wenden Sie sich an die App-Shops, mit denen Sie zusammenarbeiten, um mehr über ihre Pläne zu erfahren.

SDK-Laufzeit

Wie werden SDK-Versionen gemäß diesen Vorschlägen verwaltet? Können Apps SDK-Versionen steuern, wenn Anbieter ihre SDKs unabhängig aktualisieren können?

Diese Funktion wird derzeit entwickelt. Ein Ansatz, der derzeit geprüft wird, besteht darin, dass SDK-Entwickler die major.minor.patch-Version eines SDKs angeben, das sie über einen App-Shop vertreiben möchten, der die SDK-Laufzeit unterstützt.

App-Entwickler können dann die major.minor-Version auswählen, auf die sie angewiesen sein möchten, indem sie sie in ihrem App-Manifest deklarieren. Der neueste Patchrelease für diese major.minor-Version wird installiert, bis der nächste Patch veröffentlicht wird (der selbst automatisch installiert wird) oder bis der App-Entwickler seine App neu erstellt und dabei eine andere major.minor-Version als Abhängigkeit angibt.

Für welche Arten von SDKs ist die SDK-Laufzeit gedacht?

Die erste Version der SDK Runtime soll Anwendungsfälle für werbebezogene SDKs unterstützen, einschließlich SDKs, die die Anzeigenbereitstellung, die Anzeigenmessung, die Erkennung von Anzeigenbetrug und Missbrauch ermöglichen.

Der Schwerpunkt liegt zwar auf werbebezogenen SDKs, aber auch Entwickler von nicht werbebezogenen SDKs, die für den Datenschutz eintreten und der Meinung sind, dass sie unter den oben genannten Bedingungen arbeiten können, können Feedback zu ihren SDKs geben, die in der SDK-Laufzeit ausgeführt werden.

Wir verwenden derzeit für unsere Anwendungsfälle Berechtigungen, die nicht im Vorschlag angegeben sind. Können wir weitere Berechtigungen anfordern?

Wir möchten mehr über werbebezogene Anwendungsfälle erfahren, für die spezielle Zugriffsberechtigungen erforderlich sind, die über die in unserem ursprünglichen Designvorschlag genannten hinausgehen.

Würden Sie durch das Verschieben von SDKs in den SDK-Laufzeitprozess Einsparungen bei der Downloadgröße oder am Speicherplatz erzielen?

Wenn mehrere Apps mit einzelnen runtimefähigen SDKs derselben Version integriert sind, wird die Downloadgröße und der Speicherplatz gespart.

Hängt die SDK-Berechtigung für den Zugriff auf die AAID (AD_ID) von den Berechtigungen der App ab?

Ob das RE SDK auf die AAID zugreifen kann, hängt davon ab, ob die Berechtigung sowohl in der App als auch im SDK im Manifest der App deklariert wurde. In einem zukünftigen Vorschlagsupdate werden wir die API beschreiben, mit der SDKs die AAID abrufen können, sofern sie die Berechtigung haben.

IP-Adressen, Betriebssystemversionen und alternative Daten: Sind diese für werbebezogene SDKs verfügbar?

Wir arbeiten derzeit an den Systemeigenschaften, auf die werbebezogene SDKs zugreifen können. Diese werden in einem zukünftigen Update des Designvorschlags veröffentlicht. Wir haben keine Richtlinien zur Verwendung dieser Properties veröffentlicht.

Ist die App-Set-ID, die unser SDK erfasst, für viele Apps identisch, auch wenn diese Apps zu verschiedenen Google Play-Entwicklerkonten gehören? Wie können wir betrügerische Nutzer in mehreren Apps ohne AAID blockieren?

Eine App oder eines ihrer SDKs darf nur auf den Wert App-Set-ID zugreifen, der mit dem Google Play-Entwicklerkonto der Host-App verknüpft ist. Die Privacy Sandbox für Android bietet keine Publisher-Kennung zu Betrugszwecken an. Bis dahin können Entwickler IP als etwas weniger konsistente Alternative verwenden.

Themen

Kann ich eine Liste aller möglichen Themen sehen, die von der API zurückgegeben werden können?
Zum Testen werden in der Entwicklervorschau 1 Themen aus dieser Taxonomie verwendet, die sich ändern kann. Anhand des Feedbacks aus dem Umfeld werden wir die Funktion im Laufe der Zeit weiterentwickeln.
Wenn sich die Topics-Taxonomie ändern kann, wie können wir diese Änderungen in nachgelagerten Buy-Side-Modellen berücksichtigen?
Die Topics API-Antwort enthält eine Versionsnummer für den Klassifikator und die Taxonomie.

Protected Audience auf Android-Geräten

Wird das ausschließende Targeting von Protected Audience unterstützt?

Das aktuelle Designvorschlag unterstützt kein negatives Targeting auf Grundlage einer benutzerdefinierten Zielgruppe in Protected Audience.

Bei App-Installationskampagnen bieten wir Anzeigentechnologie-Anbietern die Möglichkeit, mithilfe einer Filterfunktion bereits installierte Apps herauszufiltern. Außerdem untersuchen wir, wie die auf Frequency Capping basierenden Negativfilter auf Kampagnenebene unterstützt werden können. Weitere Informationen finden Sie in den nächsten Updates zum Designvorschlag.

Können benutzerdefinierte Zielgruppen von den Werbenetzwerken der Verkäufer erstellt werden? Oder sind sie auf die Werbenetzwerke des Käufers beschränkt?

Unser aktueller Vorschlag für benutzerdefinierte Zielgruppen konzentriert sich auf den Anwendungsfall auf der Buy-Side, da sie die Erstellung von Buy-Side-Geboten für den Anwendungsfall „Remarketing“ auf datenschutzfreundliche Weise unterstützen sollen.

Attributionsberichte

Funktionieren die Privacy Sandbox APIs zusammen, um Web-zu-App- und App-zu-Web-Anwendungsfälle zu unterstützen?
Wir erproben Anwendungsfälle, bei denen eine mobile Browser-App die Attribution Reporting API von Android aufruft, um die Attribution zwischen App und Web auf demselben Gerät zu ermöglichen. Wenn Sie die App-zu-Web-Funktion aktivieren, werden die Privacy Sandbox for Android APIs für die Speicherung und Attribution verwendet. Dabei werden doppelte Attributionen zwischen App und Web entfernt. Es kann jedoch sein, dass Sie von der API separate Berichte für App und Web erhalten, die kombiniert werden müssen.
Unterstützt die API neben dem letzten Klick noch weitere Attributionsmodelle?
Die API unterstützt ein quellenpriorisiertes Attributionsmodell vom Typ „Letzter Touch“. Außerdem unterstützt der Vorschlag eine optionale Attributionslogik, mit der Conversions nach der Installation dem Klick oder der Wiedergabe zugeordnet werden können, die zur Installation geführt haben.
Hat die Privacy Sandbox Auswirkungen auf den Play-Installations-Referrer?

Basierend auf dem aktuellen Design und den aktuellen Plänen haben die Privacy Sandbox APIs keine Auswirkungen auf die Funktionalität des Play Install Referrers.

Einige Entwickler haben Anzeigenformate entwickelt, bei denen Nutzer für das Ausführen bestimmter Ereignisse nach dem Klick „belohnt“ werden können. Ohne Attribution auf Nutzerebene wäre dies bei den aktuellen Vorschlägen eine Herausforderung.

Wir prüfen derzeit, welche Lösungen möglich sind. Wir bitten um zusätzliches Feedback für diesen Anwendungsfall und andere mögliche Anwendungsfälle.

Warum erfolgt die Attribution für jede Anzeigentechnologie-Plattform unabhängig?

Viele Werbetreibende sind der Meinung, dass es wichtig ist, eine netzwerkübergreifende deduplizierte Ansicht ihrer Conversion-Ereignisse zu erhalten. Daher wird in der Regel ein Partner für mobile Messungen (Mobile Measurement Partner, MMP) eingesetzt. Das ist mit den neuen APIs weiterhin ganz einfach möglich. Außerdem können einzelne Technologieplattformen oder Werbetreibende die Daten direkt erfassen, wenn sie das möchten.

Wenn Sie Weiterleitungen verwenden, ist kein SDK in jeder App erforderlich. Sie benötigen jedoch eine Beziehung zu den SDKs der Anzeigentechnologie, die am Weiterleitungsprozess beteiligt sind.

Ein wichtiger Vorteil dieses Ansatzes besteht darin, dass jeder Nutzer seine eigenen Metadaten und Aggregationsschlüssel für die eigene Geschäftslogik haben und eine eigene Priorität festlegen kann.

Werden Installationen aus dem Play Store überprüft?

Validierte Installationen werden nur für die optionale Attributionslogik von Conversions nach der Installation verwendet. Diese validierten Installationen werden nicht von der API gesendet. Die API sendet nur Berichte basierend auf den registrierten Conversions und gibt kein Signal dafür zurück, ob der Nutzer die App bereits installiert hat.

Führen Sie eine Validierung von Klicks oder Aufrufen durch? Gibt es für die Datenansichtsbestätigung eine Mindestdauer?

Der aktuelle API-Vorschlag unterstützt die grundlegende Klickvalidierung über InputEvent. Wir beschäftigen uns mit robusteren Formen der Klick- und Ansichtsprüfung. Wir freuen uns über zusätzliches Feedback zu diesen Anwendungsfällen, insbesondere dazu, welche Arten von Ansichtsdefinitionen für das System hilfreich wären.