Was ist die Protected Audience API und welche Auswirkungen hat es auf das Remarketing?

Die bevorstehende Abschaffung von Google GAID in 2024 ist eine wichtige Ankündigung für Unternehmen und App-Marketers. Für diejenigen, die Remarketing als Hauptstrategie zur Retention und zum Engagement einsetzen – und das sind einige, wie Grafik A unten zeigt – ist es umso relevanter.  

Bevor Sie jedoch den Alarm auslösen, ist es wichtig zu betonen, dass die Privacy Sandbox auf den ersten Blick nicht wirklich zur Beunruhigung beiträgt. Die Marketers bleiben nicht auf dem Trockenen sitzen. Dieses disruptive Update wird von technologischen Innovationen begleitet, um sicherzustellen, dass es Lösungen gibt, die den Marketers helfen, ihre Ziele zu erreichen. 

Parallel zu dem Bestreben, die Abhängigkeit von Geräte-IDs zu verringern, werden neue Technologien zur Wahrung der Privatsphäre eingeführt. Bei AppsFlyer arbeiten wir eng mit Google und Partnern aus der Branche zusammen, um eine Lösung zu entwickeln, die den Datenschutz berücksichtigt und es Unternehmen gleichzeitig ermöglicht, ihre Nutzer:innen durch Remarketing zu vergrößern und zu binden. 

Die Protected Audience API (früher bekannt als FLEDGE) ist Googles Framework für ein datenschutzorientiertes, geräteinternes Remarketing ohne die Android-ID.

Aber verändert die Protected Audience API das Remarketing, wie wir es kennen? 

Und wie wird sich dieser neue Framework über die Marketingteams hinaus auf App-Developers und Werbepartner auswirken? 

Hier erfahren Sie alles, was Sie wissen müssen.

Protected Audience API im Überblick

Wie funktioniert also Remarketing im Zeitalter der Protected Audience API? Im Folgenden finden Sie eine vereinfachte Erklärung, in der das aktuelle, auf der Werbe-ID basierende Remarketing mit dem Remarketing unter Nutzung der Protected Audiences API verglichen wird. 

Remarketing mit GAID

Heute wird Remarketing durch die Google Advertising ID (GAID) ermöglicht – eine app-übergreifende Mobile Geräte-ID, die vom Android-Betriebssystem generiert und über Werbenetzwerke hinweg kommuniziert wird, um Marketers zu helfen, ihre Kampagnen wie folgt zu personalisieren:

• Individuelle Zielgruppensegmentierung: App-Nutzer:innen werden nach gemeinsamen Merkmalen oder der App-Nutzung in individuelle Zielgruppen gruppiert, wobei jede:r App-Nutzer:in durch die GAID repräsentiert wird. 

• Individuelle Kommunikation mit der Zielgruppe: GAID wird genutzt, um Werbepartnern (z. B. Werbenetzwerken und deren Publisher-Apps) die individuelle Zielgruppe eines App-Nutzers mitzuteilen.

• Individuelles Zielgruppen-Targeting: Ad-Plattformen können dann personalisierte Ads und Bids auf bestimmte GAIDs entsprechend ihrer individuellen Zielgruppen zuschneiden und die Ad schalten, sobald die GAID in einer Publisher-App verfügbar wird.  

• Individuelle Attribution und Messung von Zielgruppen: Das Engagement von Nutzer:innen mit Remarketing-Ads wird über GAID kommuniziert, das von MMPs für ihre Attributionsmodelle genutzt wird. Diese Informationen werden auch an Werbenetzwerke und Publisher-Apps weitergegeben, damit diese ihre Ad-Logik in Echtzeit weiter optimieren können.

Jetzt sind wir mit den Besonderheiten des Remarketings vertraut und wollen nun eingehen, wie es ohne GAID funktioniert. 

Remarketing mit der Protected Audience API

Mit der Protected Audience API wird das Android-Betriebssystem den Informationsaustausch zwischen den Apps von Werbetreibenden und Publishern und den entsprechenden Kauf- und Verkaufs-Adtech-Plattformen erleichtern. 

Anstatt sich wie heute auf eine gemeinsame Kennung zu verlassen, werden die Zielgruppen auf dem Gerät erstellt, um ein individuelles Targeting zu ermöglichen. Auf diese Weise werden alle Daten auf dem Gerät isoliert, ohne dass Dritte auf sie zugreifen können.  

Die Reihenfolge für das Remarketing innerhalb der Protected Audience API wird wie folgt ausgeführt:

• Individuelle Zielgruppensegmentierung: Nutzer:innen werden nach gemeinsamen Merkmalen oder der App-Nutzung in individuelle Zielgruppen eingeteilt. Jede:r Nutzer:in wird von der App des Werbetreibenden selbst über die Protected Audience API von Android zur Zielgruppe auf dem Gerät hinzugefügt. 

• Individuelle Kommunikation mit der Zielgruppe: Bei der Erstellung der Zielgruppe wird eine bestimmte Ad-Plattform (z. B. ein DSP ein Werbenetzwerk oder ein SRN, wie z. B. Meta) definiert, um dieser Zielgruppe Ads anzuzeigen. Da die Zielgruppe des Geräts nicht außerhalb des Geräts kommuniziert werden kann, werden die Prozesse der Ad-Schaltung, die traditionell auf dem Server der Werbeplattform stattfanden, nun auf dem Gerät selbst ausgeführt.

Um dies zu erreichen, muss die Werbe-App die folgenden Elemente der Zielgruppe vordefinieren:

• Ad Creatives: Die Ads, die sie der Zielgruppe auf anderen Apps liefern wollen 
• Bidding-Signale: Faktoren, die für die Bestimmung eines künftigen Bids wichtig sind, wie z. B. der Standort der Nutzer:innen, die Aktivität, das LTV usw. 
• Bidding-Logik: Die Logik zur Nutzung verschiedener Variablen, die von der individuellen Zielgruppe und der Publisher-App empfangen werden, um ein Bid in Echtzeit zu bestimmen. Da die Logik selbst nicht auf der Nutzerebene liegt und in Echtzeit aktualisiert wird, wird sie von einem vertrauenswürdigen Server auf der Seite der Ad-Plattform abgerufen.  
• Aktivierungs-/Ablaufzeit: Der Zeitpunkt, zu dem die individuelle Zielgruppe aktiviert werden soll, und der Zeitpunkt, zu dem sie ablaufen soll
• Beispiel: Eine Shopping-App möchte Nutzer:innen, die kürzlich etwas gekauft haben, erneut ansprechen, um sie zum nächsten Kauf zu animieren. 

Sobald „App-Nutzer:in A“ eine:n Kauf abgeschlossen hat, ruft die App die Protected Audience API von Android auf, um „App-Nutzer:in A“ der individuellen Zielgruppe „Gekauft in den letzten 7 Tagen“ hinzuzufügen. 

Die auf dem Gerät festgelegte individuelle Zielgruppe enthält den Namen des Werbenetzwerks, in dem die Shopping-App ihre Werbekampagne eingestellt hat, die in der Kampagne enthaltenen Ads, einen Aktivitäts-Score, um ein konkurrenzfähiges Bid zu erstellen, einen Pointer, um die Bidding-Logik des Werbenetzwerks in Echtzeit abzurufen, und eine Ablaufzeit, die auf 7 Tage ab dem Zeitpunkt des Kaufs festgelegt ist. 

• Individuelles Zielgruppen-Targeting: Sobald eine Publisher-App die Schaltung einer Ad anfordert, ruft sie die Protected Audience API auf, um eine gewinnende Ad und ein Bid zu erhalten, das von den auf dem Gerät eingestellten individuellen Zielgruppen abgeleitet ist. Auch hier werden die Elemente, die erforderlich sind, von der Publisher-App und ihrem Verkaufspartner kommuniziert, um eine gewinnende Ad zu bestimmen:
  • Verkäufer- und Werbe-Auktionssignale: Faktoren, die für die Bestimmung einer gewinnenden Ad und eines Bids wichtig sind, wie z. B. die Art der App oder die Ad-Platzierung und umfassende kontextbezogene Informationen. 
  • Entscheidungslogik: Die Logik für das Scoring einer Ad anhand der gemeinsamen Variablen der Kauf- und Verkaufsseite.
  • Ein Beispiel: Eine News-App möchte in ihrem Modebereich eine Ad schalten. Sobald „App-Nutzer:in A“ einen Artikel im Modebereich öffnet, ruft die News-App die Protected Audience API auf, um zu prüfen, ob es für diese:n App-Nutzer:in eine zielgruppenbasierte Werbung gibt. 

Diese „Ad-Auswahl“-Anfrage enthält das Ad-Netzwerk/SSP des Verkäufers, über das die Aktion durchgeführt wird, die anfragende App und die App-Vertikale, das Ad-Format und die Dimensionen, die Content-Kategorie und einen Pointer, um die Scoring-Logik des Verkäufers in Echtzeit abzurufen. Diese Informationen werden genutzt, um gegen andere zielgruppenbasierte Ads sowie gegen anderes Ad-Inventar zu bieten.

Erhalten Sie die neuesten Marketing-News und Experten-Insights direkt in Ihre Inbox

Die Protected Audience API antwortet mit einer gewinnenden Ad und einem Bid, das von der Publisher-App ausgeliefert wird

• Individuelle Attribution und Messung von Zielgruppen: Gewonnene Impressionen werden sowohl an die Käufer- als auch an die Verkäuferseite zu Mess- und Optimierungszwecken zurückgemeldet. Dieses Element befindet sich noch im Entwurfsstadium, und wir werden weitere Einzelheiten mitteilen, sobald es sich weiterentwickelt hat.

Wie wird sich die Protected Audience API auf mich auswirken? 

Starten wir mit den offensichtlichen Herausforderungen:

• Nutzer:innen können nur dann zu individuellen Zielgruppen hinzugefügt werden, wenn sie aktiv sind: Im Gegensatz zu GAID, wo Zielgruppen nachträglich erstellt werden können, muss die App bei der Protected Audience API aktiv sein (d. h. geöffnet, im Vordergrund des Geräts), um Nutzer:innen zu einer Zielgruppe hinzufügen zu können. Es erfordert von den App-Developern:

• Definition einer robusten Strategie für das individuelle Targeting während des gesamten Nutzerlebenszyklus, da viele der Zielgruppenstrategien nur im Voraus festgelegt werden können.

Wenn ein Werbetreibender beispielsweise beabsichtigt, dem/der Nutzer:in nach 7 Tagen Inaktivität eine Remarketing-Ad zu zeigen, sollte er diese Zielgruppe jedes Mal im Voraus festlegen, wenn der/die Nutzer:in die App startet (wobei der Aktivierungszeitpunkt in der Zukunft liegen sollte), und den/die Nutzer:in aus der Zielgruppe entfernen, wenn er die App vor dem 7-tägigen Inaktivitätszeitraum nutzt.

• Berechnen Sie zügig den Anteil der Zielgruppe: Da nur ein begrenzter Zeitraum zur Verfügung steht, um den/die Nutzer:in zu einer Zielgruppe hinzuzufügen, muss die Segmentierung der Zielgruppe schnell und flexibel erfolgen. 
• Die Details der Nutzerkontrolle müssen noch festgelegt werden: Android-Nutzer:innen können selbst bestimmen, welche Apps sie zu individuellen Zielgruppen hinzufügen dürfen. Android hat noch nicht alle Details dieses Designs bekannt gegeben, aber angesichts des Engagements für den Fortbestand des Ökosystems, das sich in allen Privacy Sandbox-Initiativen gezeigt hat, erwarten wir keine massiven Opt-out-Raten.
• Von Werbetreibenden erstellte individuelle Zielgruppen müssen ein SDK nutzen: Die BI- und CRM-Teams der Werbetreibenden sind traditionell in der Lage, eine individuelle Zielgruppensegmentierung auf ihrer Seite durchzuführen und dann individuelle Zielgruppen manuell über CSV-Datei-Uploads oder programmatisch über direkte API-Integrationen in die Werbeplattformen hochzuladen. 

Mit dem Wechsel zum On-Device Audience Management müssten Werbetreibende diese Fähigkeiten entweder direkt in die SDKs ihrer Apps implementieren oder spezielle Ad-Tech-Plattformen nutzen. Mit dem AppsFlyer SDK können Werbetreibende die AppsFlyer Audiences Plattform für ein individuelles Zielgruppen-Management auf die gleiche Art und Weise nutzen, wie sie heute genutzt wird.

Das Diagramm oben zeigt den vom Werbetreibenden generierten Flow

• Von der Ad-Plattform stammende individuelle Zielgruppen: GAID ermöglichte es Werbetreibenden, die Zielgruppensegmentierung an Werbeplattformen (z. B. DSPs oder Werbenetzwerke) zu delegieren, ohne dass sie spezielle mobile SDKs in ihren Apps implementieren mussten. Im Gegensatz dazu erfordert die Protected Audience API ein SDK, um Nutzer:innen zu individuellen Zielgruppen hinzuzufügen, was sowohl für Werbetreibende als auch für Werbeplattformen einen technischen und operativen Mehraufwand bedeuten kann. Um diese Lücke zu schließen, entwickelt AppsFlyer eine Partner-Integrationen, die auch von Partnern definierte individuelle Zielgruppen ermöglichen – siehe Grafik C für weitere Informationen. 

Gehen wir nun auf die einzigartigen Vorteile ein.

• Schützt die Privatsphäre der Nutzer:innen: Die Protected Audience API bietet einen großen Fortschritt in Bezug auf den Schutz der Privatsphäre der Nutzer:innen. Diese Lösung ermöglicht es Marken, die Kommunikation mit ihren Zielgruppen zu personalisieren, ohne Nutzerdaten an Dritte weiterzugeben. Es kann Remarketing für viele Unternehmen freischalten, die aus Befürchtung vor der Weitergabe von Nutzerdaten gezögert haben, dies zu tun. Über das Remarketing hinaus stellt die Protected Audience API einen bedeutenden Fortschritt für das App-Ökosystem dar und zeigt, wie man Technologie zum Schutz der Privatsphäre nutzen kann, ohne das User Experience oder die Werbeoptimierung zu beeinträchtigen.
• Filterung von Ads bei der App-Installation: Die Protected Audience API enthält ein spezielles Feature, die es App-Developern ermöglicht, Geräte für die Filterung von App-Installations-Ads zuzulassen. Mit dieser Filterlogik könnten Ad-Plattformen UA-Kampagnen so einstellen, dass bestehende App-Nutzer:innen bei der Ad-Auswahl ausgeschlossen werden, um so die Akquisitionskosten zu optimieren. 
• Bidding-Signale der Nutzer:innen: Die Protected Audience API ermöglicht Werbeplattformen eine granulare Bidding-Optimierung auf Geräteebene mithilfe von Nutzer-Bidding-Signalen, die zu jeder individuellen Zielgruppe hinzugefügt werden. Diese Funktion hilft Werbeplattformen, ihre Bidding-Logik zu optimieren, indem sie sie mit zusätzlichen Details auf datenschutzorientierte Weise anreichert. Beispielsweise können Apps jetzt ein wettbewerbsfähigeres Bid für eine:n Nutzer:in, der/die höhere Umsätze erzielt, vorgeben. 

Was soll ich als nächstes tun?

Die Protected Audience API und die Verringerung unserer Abhängigkeit von Geräte-IDs hat unterschiedliche Auswirkungen, je nachdem, auf welcher Seite man sitzt. Auch wenn wir festgestellt haben, dass Remarketing dank der Protected Audience API weiterhin erfolgreich sein wird, müssen Sie unterschiedliche Strategien entwickeln, je nachdem, ob Sie ein Marketer oder ein Werbepartner sind.

Den Hut eines Marketers aufsetzen

Die Protected Audience API bringt massive technologische Veränderungen für Android mit sich, und daher ist Bildung eine wichtige Komponente für eine erfolgreiche Vorbereitung. Dies ist für viele interne Stakeholder, einschließlich Marketing-, BI- und Dev-Teams, notwendig. Werbetreibende müssen ihre derzeitige Retargeting-Infrastruktur und -Strategien überprüfen und sicherstellen, dass sie mit dem neuen Flow übereinstimmen. Als Ihr Partner für Wachstum ist AppsFlyer hier, um Ihnen zu helfen, das Potenzial der Veränderungen, die die Protected Audience API bietet, zu verstehen und zu verwirklichen.

Neben den internen Teams müssen Marketers auch sicherstellen, dass ihre Werbe- und Technologieplattformen auf die Veränderungen vorbereitet sind. AppsFlyer entwickelt technologische Ressourcen und Partnerschaften im gesamten App-Ökosystem, um Ihr Wachstum innerhalb dieses neuen Rahmens zu fördern. 

Eine Meile in den Schuhen einer Werbeplattform gehen

Werbeplattformen sehen sich mit vielen neuen Anforderungen konfrontiert, an die sie sich anpassen müssen, mit einigen tektonischen Verschiebungen von serverseitigen Mechanismen zu gerätebasierten. Während Verkaufs-Seite-Einheiten wie SSPs und Monetarisierungs-SDKs bereits eine Präsenz auf dem Gerät voraussetzen, verlangen Kauf-Seite-Plattformen wie Ad-Networks und DSPs von ihren Werbetreibenden traditionell nicht, dass sie ein Mobile SDK für die Durchführung von Werbekampagnen implementieren. 

AppsFlyer arbeitet mit Werbeplattformen zusammen, um Custom Audience Targeting innerhalb des Protected Audience API Frameworks zu ermöglichen, indem das AppsFlyer SDK genutzt wird. Dadurch wird die Konnektivität zwischen Werbetreibenden und Werbepartnern, die für die Ausführung dieser kritischen Marketingströme erforderlich ist, optimiert.

Das Ökosystem vernetzen, um das Remarketing neu zu gestalten

Zusammenfassend lässt sich sagen, dass sich das Remarketing zwar verändert, aber keineswegs ausstirbt. Und nur durch Zusammenarbeit können wir den Erfolg dieser Strategie fördern und gleichzeitig sicherstellen, dass die Privatsphäre der Endnutzer:innen gewahrt bleibt. 

Diese Vision hat AppsFlyer dazu veranlasst, eng mit Google, unseren Kunden und unseren Werbepartnern zusammenzuarbeiten, um den Rahmen für die Nutzung der Protected Audience API zu schaffen. Ich hoffe, dass wir als Community weiter zusammenarbeiten können, damit wir unsere Datenschutzpraktiken im Einklang mit dem wachsenden Business Erfolg und der Retention weiterentwickeln können.