Vielen Dank!

Die Android Privacy Sandbox steht vor der Tür: Was müssen Marketers berücksichtigen?

Von Roy Yanai
Android Privacy Sandbox is coming. What should marketers do next_ OG

Im Februar 2022 kündigte Google seine Pläne zur Verbesserung des Datenschutzes auf Android an, und Marketers wurden hellhörig. Nach dem Schock über Apples App Tracking Transparency (ATT) war und ist die Frage, was genau Android vorhat und wie es sich auf Unternehmen auswirkt, in aller Munde. 

Die Aufregung ist groß, obwohl die Google Advertising ID (GAID) erst im Jahr 2024 abgeschafft werden soll.

Damit Sie sich auf die Privacy Sandbox vorbereiten können, haben wir einige der wichtigsten Änderungen zusammengefasst. Die hier dargestellten Informationen basieren auf einer engen Zusammenarbeit mit dem Google-Team, einer ausführlichen Prüfung der Dokumentation und praktischen Tests dieser Lösung. Dann tauchen wir mal ein.

GAID: Das Ende der Erkenntnisse auf Nutzerebene auf Android

Als Grundlage für die Privacy Sandbox gehen wir ein, wie die GAID heute hauptsächlich genutzt wird: 

  1. Attribution GAID hilft Marketers, die Effektivität ihrer Kampagnen zu messen und ihre User Journey zu verstehen.
  2. Management der Zielgruppen: GAID hilft Marketers, ihre Remarketing-Kampagnen zu personalisieren. 
  3. Gemeinsame Nutzung von 3rd-Party-Daten:  GAID hilft Werbenetzwerken bei der Erstellung von Persona-Graphen, um die besten Ads für jede Persona zuzuordnen.

Da wir nun wissen, wie GAID genutzt wird, wollen wir herausfinden, wer es in erster Linie einsetzt, damit wir feststellen können, was sich ändern muss, wenn GAID abgeschafft wird, und wie.

ZielErforderliche Maßnahmen
MeasurementMMPs, Marketers
RemarketingMarketers, Werbenetzwerke, MMP
TargetingWerbenetzwerke

Wenn wir den Einsatz von GAID betrachten, können wir aus der obigen Tabelle ersehen, dass Marketers in erster Linie von der Abschaffung der GAID in ihren aktuellen Mess- und Remarketingmaßnahmen betroffen sein werden. Wie können wir uns vorbereiten?

Measurement 

Wenn es um Messungen und Analysen geht, gibt es keinen Grund zur Panik. Die Abschaffung von GAID bedeutet nicht das Ende der Marketingmessung. 

Bisher hat Android noch keine Pläne zur Abschaffung von Google Play Install Referrer, einer der wichtigsten Attributionsmethoden auf Android, bekannt gegeben. Derzeit werden 29 % der AppsFlyer-Installationen auf Android über Google Play Referrer durchgeführt. 

Um sich auf die Privacy Sandbox vorzubereiten, empfehlen wir Ihnen, sich mit Ihren aktuellen Daten zu befassen. In den Rohdaten-Reports von AppsFlyer können Sie sehen, dass eines der Felder <match_type> heißt . Unter <match_type> können Sie feststellen, wie viele Ihrer aktuellen Installationen die Google Play Referrer-Attribution nutzen. Diese Datenabfrage kann dazu beitragen, Bedenken hinsichtlich erheblicher Änderungen bei der Attributions-Messung auszuräumen. 

Trotz der Bedeutung des Google Play Install Referrers lässt sich nicht leugnen, dass die GAID derzeit die Grundlage und der Eckpfeiler für einen großen Teil der Messaktivitäten ist. 

Um Marketers zu helfen, ihre Attributionsmaßnahmen ohne GAID fortzusetzen, führt Privacy Sandbox eine der Attribution API für neue Methoden zur Kampagnenmessung ein. Diese API bietet zwei Arten von Reports: Reports auf Event-Ebene und aggregierte Reports. Jeder Report bietet unterschiedliche Vorteile und Erkenntnisse:

Reports auf Event-Ebene

Während Reports auf Event-Ebene eine begrenzte Messung von Installations- und Post-Installations-Events bieten, erfolgt das Reporting auf Klick-ID-Ebene, was es Werbenetzwerken ermöglicht, genaue Signale für die geschaltete Ad zu erhalten. Zum Schutz der Privatsphäre der Endnutzer:innen werden die Reports jedoch um mindestens einen Tag für die View Through Attribution und zwei Tage für die Click Through Attribution verzögert, und es werden maximal drei Postbacks pro Quelle attribuiert. Oberflächlich betrachtet mag man die Postbacks, die Sandbox bietet, mit denen von SKAN vergleichen, doch ein tieferes Verständnis von Sandbox zeigt, dass diese Postbacks sowohl in ihrer Art als auch in ihrer Nutzung unterschiedlich sind. Bei der derzeitigen Lösung sind Reports auf Event-Ebene für Werbenetzwerke zur Optimierung am aussagekräftigsten und für Marketer weniger aufschlussreich.

Aggregierte Reports

Aggregierte Reports bieten Marketers umfassendere Einblicke, da sie detaillierte Kampagnendimensionen enthalten können, z. B. Kampagnenname, Datum, Adset, Geo und Creatives. Die Einzelheiten der Kampagnendimensionen, die in den aggregierten Reports enthalten sind, werden vom Netzwerk, dem MMP und dem Werbetreibenden selbst festgelegt. Die Postbacks, aus denen sich die aggregierten Reports zusammensetzen, werden noch am selben Tag versandt. Die aggregierten Reports liefern den LTV für die Installation und die Zeit nach der Installation, so dass Marketers verwertbare Erkenntnisse für ihre Kampagnen gewinnen können. 

Sowohl der aggregierte Report als auch der Report auf Event-Ebene bieten eine netzwerkübergreifende Attribution, wobei die Bestimmung der netzwerkübergreifenden Attribution des letzten Klicks ausschließlich dem MMP obliegt.
Marketer können Lookback-Fenster von bis zu 30 Tagen konfigurieren, aber bedenken Sie, dass sie für jedes Werbenetzwerk konfiguriert werden müssen – eine unglaublich mühsame Aufgabe, wenn sie von Marketers selbst durchgeführt wird. Die Konfiguration von Lookback-Fenstern wird durch den Einsatz eines MMP vereinfacht, da dieser sich direkt mit den Werbenetzwerken abstimmt und die Arbeit übernimmt. 

Das hört sich alles sehr gut an, hat aber auch seine Schattenseiten: Für Marketers wird es komplizierter als je zuvor, ihre Daten zu deduplizieren. Der Grund dafür ist, dass die Attribution-API aggregiert ist und keine Daten auf Werbetreibenden-Seite auf Nutzerebene bereitstellt, wodurch es unmöglich ist, diese Daten mit den von Google Play Install Referrer erhaltenen Analysen zusammenzuführen.  

Um diese Herausforderung zu meistern, beinhaltet AppsFlyer einen Single Source of Truth-Mechanismus, der die Attributionsdaten dedupliziert und die Daten mit Erkenntnissen anreichert.

Remarketing

Heutzutage stützt sich das Remarketing stark auf die Nutzung von GAIDs, da Marketer Zielgruppen nach Nutzerpräferenzen, Interessen und App-Nutzung definieren können, um eine Liste von GAIDs zur Aktivierung einer Remarketing-Kampagne zu erstellen. Angesichts der bevorstehenden Abschaffung von GAID hat Google FLEDGE eingeführt, eine datenschutzorientierte Lösung für das Management von Zielgruppen und Werbung auf dem Gerät (die Daten werden nicht an einen Server gesendet).

Für Marketers

Für Marketers können die Veränderungen, die FLEDGE mit sich bringt, in unterschiedlichem Maße spürbar sein. AppsFlyer-Kunden, die das Audiences-Tool nutzen, werden zum Beispiel keine wesentlichen Änderungen spüren. Die Erstellung von Audiences in AppsFlyer unterstützt die FLEDGE-Änderungen und ermöglicht es verschiedenen Werbenetzwerken, Ads auf der Grundlage der von jedem Marketers festgelegten Konfigurationen zu personalisieren.

Wenn Sie jedoch daran gewöhnt sind, Zielgruppen in Ihrem eigenen BI zu erstellen, müssen Sie möglicherweise einiges an Arbeit leisten. Die Erstellung von Nutzerlisten und deren Übermittlung an verschiedene Partner wird nicht mehr möglich sein. 

Wie können Sie sich also anpassen? Es gibt mehrere Möglichkeiten:

  1. Managen Sie FLEDGE. Mit FLEDGE können Sie immer noch Zielgruppen erstellen und sie als verfügbar für ein bestimmtes Werbenetzwerk kennzeichnen, aber Sie müssen diese Integration mit den verschiedenen Partnern kommunizieren. Wenn Sie z. B. eine Zielgruppe für „Add-to-cart-did-not-purchase“ erstellen und diese einem DSP zuweisen möchten, können Sie das zwar tun, aber es erfordert eine Integration mit diesem DSP (um Daten von ihm zu erhalten und weiterzugeben).
  2. Arbeiten Sie mit einem MMP. AppsFlyer baut bereits die Integrationen auf, um FLEDGE über verschiedene Partner zu ermöglichen, die das Audience Management in der Post-GAID-Ära unterstützen und personalisiertes Remarketing ermöglichen werden.

Für Werbenetzwerke

Zusätzlich zu den Änderungen, die Marketers spüren, bringt FLEDGE viele Änderungen für die Werbenetzwerke in zwei Hauptaspekten mit sich:

  1. Definition der Zielgruppen: In der derzeitigen Struktur von FLEDGE ist ein SDK, das mit FLEDGE kommunizieren kann, auf der App des Werbetreibenden erforderlich, um eine:n Nutzer:in zu einer Zielgruppe hinzuzufügen oder zu entfernen. Werbenetzwerke müssen mit Hilfe von MMPs Integrationen aufbauen, die Funktionen für den Aufbau von Zielgruppen ermöglichen. 
  1. Bidding-Strategien für Nutzer:innen, die zu einer Zielgruppe gehören: Neben dem Aufbau von Zielgruppen besteht ein wichtiger Teil von FLEDGE darin, Werbenetzwerke mit einer datenschutzorentierten Bidding-Lösung zu unterstützen. FLEDGE bietet einen geräteinternen Bidding-Exchange zwischen dem SSP und dem DSP. Die Werbenetzwerke werden ihre Bidding-Strategien und Lösungen anpassen müssen, um zu gewährleisten, dass die richtigen Ads den richtigen Nutzer:innen auf die kosteneffizienteste Weise angezeigt werden. 

Über die aktuelle AppsFlyer-Lösung hinaus unterstützen wir das Ökosystem, indem wir die Erstellung von Zielgruppen auf der Seite der Werbenetzwerke erleichtern. Wie bereits erwähnt, handelt es sich bei FLEDGE um eine On-Device-Lösung. Für die Erstellung von Zielgruppen ist eine On-Device-Präsenz (SDK) erforderlich. AppsFlyer erleichtert den Aufbau von Zielgruppen durch jedes beliebige Werbenetzwerk über spezielle Integrationen.

Targeting

Einer der wichtigsten Inputs für die Targeting-Funktionen von Werbenetzwerken sind die 3rd-Party-Daten. Das heißt, wenn app.game.com Nutzungsdaten von Nutzer123 an ein Werbenetzwerk sendet, können diese Daten genutzt werden, um Nutzer123 mit Werbung in einer anderen Gaming-App anzusprechen. 

Das Konzept des app-übergreifenden Targeting anhand von Daten auf Nutzerebene ist ein wesentlicher Teil dessen, was Google zu verhindern versucht. Wir werden in der Post-GAID-Ära wahrscheinlich erhebliche Auswirkungen auf die Targeting-Fähigkeiten der Werbenetzwerke erleben. Die gute Nachricht ist, dass es Lösungen gibt, die Werbenetzwerken helfen können, eine kontextbezogene Ad-Schaltung zu gewährleisten.

  1. Topics: Als eine der von Google vorgeschlagenen Lösungen helfen die Topics beim app-übergreifenden Marketing. Dabei handelt es sich um eine geräteinterne Lösung, die die Privatsphäre der Nutzer:innen schützt und gleichzeitig app-übergreifende Targeting-Signale ermöglicht. Verschiedene Werbenetzwerke werden Topics übernehmen und auf der Grundlage von Topics optimieren müssen.
  2. Attributions-API-Signale: Wie bereits erwähnt, ist eine der wichtigsten Funktionen der Attribution API das Reporting auf Event-Ebene, das eine begrenzte Anzahl von Postbacks auf der Grundlage von Daten auf Nutzerebene bietet. Ein Beispiel: Ein Werbenetzwerk wird wissen können, dass click-id123 einen Kauf in der beworbenen App getätigt hat, aber diese Reports werden verzögert, um die Privatsphäre der Endnutzer:innen zu schützen.

Die Privacy Sandbox wird kommen und das ist gut so!

Veränderungen sind zwar beängstigend – und die Privacy Sandbox bringt einiges mit sich –, aber die Veränderungen, die Android einführt, bewegen das Ökosystem in die richtige Richtung: Abschaffung der Datensucht auf Nutzerebene und hin zu datenschutzorientierten Ansätzen. 

Um sich schon heute auf die Abschaffung der GAID vorzubereiten, empfehlen wir Marketers, ihre Abhängigkeit von Daten auf Nutzerebene zu verringern und damit zu beginnen, aggregierte Erkenntnisse zu nutzen. 

Bereiten Sie sich vor, indem Sie mehr über dieses sich entwickelnde Framework erfahren. Google stellt eine umfangreiche Dokumentation zur Verfügung, und wie immer ist AppsFlyer hier, um alle Fragen zu beantworten und Ihnen bei der Navigation durch neue Änderungen zu helfen, bevor diese auftreten.

Roy Yanai

Roy Yanai ist der AVP of Product - Measurement bei AppsFlyer. In den letzten 5 Jahren hat Roy verschiedene Produktbereiche bei AppsFlyer geleitet, darunter Data Exchange, Analytics und Incrementality. Zurzeit leitet Roy die Produktentwicklung für AppsFlyers iOS-Lösungen. Bevor er zu AppsFlyer kam, war Roy als CEO & Head of Product bei Mego tätig - einem Startup, das darauf abzielt, die Schwierigkeiten bei E-Commerce-Lösungen zu beseitigen und gründete HackIDC - Israels größten Hackathon.
Background
Erhalten Sie die neuesten Marketing-Insights und Experten-Berichte direkt in Ihre Inbox