App Tracking und App Analytics wird gerne von vielen Unternehmen etwas vernachlässigt (zumindest meiner eigenen Erfahrung nach). Mit der Einführung von Google Analytics 4, wo Web- und App-Daten innerhalb einer Property gesammelt werden können, bekommt das Thema etwas Aufwind. Dennoch ist die Implementierung eines App Tracking-Setups nicht immer einfach umzusetzen, wie es zunächst scheint. Hilfreich sind einige Basics, die man im Hinterkopf bei der Implementierung behalten sollte. In diesem Artikel gebe ich eine grobe Einführung in das Thema des App Trackings. Nach einer kurzen Definition und Funktionsweise, gehe ich auf mögliche technische Setups ein und behandle zum Schluss noch weitere Themen wie Nutzer-Identifizierung und Attribution. Der Beitrag wird jedoch wachsen und ich werde auch noch Themen wie Attribution, Analyse und Co. ergänzen.

• App Tracking Definition und Funktionsweise
• Technisches App Tracking Setup
• Nutzer-Identifizierung in Apps
• Attribution

App Tracking Definition und Funktionsweise

Mit App Tracking bezeichnet man die Datenerfassung in mobilen Apps. Dies wird in der Regel durch entsprechende SDKs (Software Development Kits) ermöglicht. Bei einer SDK handelt es sich um eine Sammlung von verschiedenen Tools und Programmen, um Apps für die jeweiligen Plattformen (iOS und Android) zu erstellen. Mit SDKs müssen bestimmte Aufgaben nicht von Grund auf entwickelt werden, sondern es können vordefinierte Prozesse und Funktionen in die Anwendung integriert werden. Beim App Tracking spielen Analytics SDKs und Tag Management SDKs eine entscheidende Rolle (bei Google Analytics alternativ auch das Measurement Protocol). Durch deren Integration in die App wird die Grundfunktionalität zum Erfassen von Nutzer-Events zur Verfügung gestellt. Zudem werden einige Nutzerinteraktionen automatisch durch Analytics SDKs erfasst. Beispiele sind Screenview-Events. Jedes Mal wenn der Nutzer einen Screen öffnet oder wechselt, feuert ein entsprechendes Event und erfasst diese Informationen. Wird dafür “nur” eine Analytics SDK integriert, dann schickt die SDK das Event direkt an die entsprechende Analytics-Plattform.

Wird jedoch eine Tag Management SDK integriert, kann das selbe Event auch vom Tag Manager registriert und weiterverarbeitet werden. Vorteil mit einem Tag Manager ist, dass auf das selbe Event mehrfach reagiert werden kann: Durch entsprechende Tags kann die Info an mehrere Analytics-Plattformen geschickt werden.

Während also im Webtracking…

• …JavaScript-Pixel (= grundlegende Tracking-Funktionalität)…
• …und Cookies (für die Nutzererkennung)…

…den Kern des Trackings bilden, sind es im App Tracking…

• …die Analytics SDKs (= grundlegende Tracking-Funktionalität)…
• …und entsprechende IDs (für die Nutzererkennung, siehe Details weiter unten).

In der Regel wird je nach App-Plattform eine eigene Analytics SDK benötigt. SDKs wie Firebase stellen bspw. jeweils SDKs für iOS und Android zur Verfügung. Da aber auch Flutter und React Native immer beliebter werden, gibt es auch hierfür eigene Analytics SDKs. Hier geht es zum Flutter-Setup. Für React kann die Firebase JavaScript-SDK genutzt werden.

Technisches App Tracking Setup

Entscheidend für ein korrektes App Tracking Setup ist die zugrundeliegende Technologie. Grundsätzlich gibt es verschiedene Arten von Apps:

• Native App: Bei nativen Apps handelt es sich um Apps, die für ein bestimmtes Betriebssystem entwickelt werden und über den jeweiligen Marktplatz installiert werden können. Im Grunde gibt es native iOS-Apps (für Apple-Geräte) und native Android-Apps (für Android-Geräte).
• Web App: Eine Web App wird über einen Browser aufgerufen und funktionieren deshalb plattformübergreifend (müssen nicht über den App Store installiert werden). Die Entwicklung läuft in der Regel über JS, CSS und HTML5 ab – also nicht über typische App-Sprachen wie Kotlin oder Swift. Da zudem Web Apps auf dem Client-Server-Modell basieren, können Komponenten des Webtrackings eingesetzt werden, um ein App Tracking zu implementieren. Eine Web App ist ähnlich wie eine mobile Website mit dem Unterschied, dass in der Web App diverse dynamische Interaktionen implementiert werden. Deshalb fühlt sich eine Web App auch eher an wie eine Native App.
• Hybride App: Eine hybride App ist zunächst einmal eine native App, die installiert werden muss. Die Ansichten innerhalb der App (oder auch nur Teile davon) basieren jedoch auf HTML, CSS und JavaScript – also typischen Webtechniken. Diese Ansichten laufen dabei über den sogenannten Webview-Container, der viele API und Techniken wie herkömmliche Webbrowser bereitstellt. Eine hybride App ist im Grunde eine Mischung von nativer App und Web App.
• Progressive Web Apps (PWA): Ein PWA ist ein Art Erweiterung der Web App. Die größte Unterscheidung liegt darin, dass sich die PWA über die Add-to-Homescreen-Funktion auf dem Endgerät ablegen lässt. Zusätzlich kommt ein Service Worker hinzu, der die PWA auch offline nutzbar macht.
• Cross Plattform App: Wenn man eine App entwickeln möchte, dann muss man eigentlich 2 Apps entwickeln. Eine für Android und Eine für iOS in jeweils unterschiedlichen Sprachen. Es gibt jedoch neue Technologien und Frameworks wie React Native (von Facebook) und Flutter (von Google), um Cross-Plattform-Applikationen zu entwickeln. Damit muss nur eine App entwickelt werden, die dann im Play Store und App Store veröffentlicht werden kann. Außerdem können damit auch Websites und Desktop-Applikationen erstellt werden.

Je nach App Art kommt ein anderes Setup für das App Tracking zum Einsatz (eine sehr gute Übersicht inkl. Grafiken ist auch im Blog von Mohr & Stade zu finden):

• Native App: Bei nativen Apps wird das entsprechende SDK implementiert. Wird ein Analytics SDK direkt implementiert, dann erkennt dieses bestimmte Nutzer-Aktionen (z.B. Screenviews) automatisch und sendet es als Event an die Analytics Plattform. Es können auch eigene Events implementiert werden. Kommt ein Tag Management System zum Einsatz, dann werden die Events über den Tag Manager an die gewünschten Analytics Plattformen geschickt. Mit einem Tag Management System hat man den Vorteil, dass dieser als Schicht zwischen App und Analytics Plattform dient und dadurch die Events mit zusätzlichen Informationen versehen werden können, bevor sie ihren Endpunkt erreichen. Zudem kann über ein Tag Management System das Event an mehrere Endpunkte – ohne großen zusätzlichen Entwicklungsaufwand – geschickt werden. Damit die Daten an die jeweilige Analytics Plattform angepasst sind, können diese bis zu einem gewissen Grad im Tag Manager transformiert werden. Jedoch macht eine Tag Management SDK nicht immer Sinn. Sollen die Events z.B. nur an Firebase Analytics a/k/a GA4 gehen, dann reicht es in der Regel aus, wenn nur die Analytics SDK eingesetzt wird. Der GTM wäre dafür in den meisten Fällen eine unnötige Zwischenschicht.
• Web App: Da in der Web App die Webressourcen wie auf der mobilen Website geladen werden, müssen hier die Events und Daten in ein App-Daten-Format umgewandelt werden. Standardmäßig werden innerhalb der Web App die Webressourcen wie z.B. der Web-Container eines Tag Management Systems geladen, der dann Pageviews an die Endpunkte schickt. Damit die Daten aber als App-Events (also statt Pageview dann Screenview) verschickt werden können, gibt es 2 Möglichkeiten. Der eingesetzte Tag Manager transformiert die Daten in ein App-Format und schickt sie ab. Oder – wenn kein Tag Manager zum Einsatz kommt – muss ein entsprechendes JavaScript SDK implementiert werden. Bei Firebase gibt es z.B. das Firebase JS SDK, welches die Daten im richtigen Format zu Google Analytics bzw. Firebase schickt.
• Hybride App: Hier ist das Tracking-Setup etwas komplexer. Neben dem nativen Teil läuft in hybriden Apps auch ein Web App-Teil mit. Entsprechend kommen im nativen Teil die SDKs wie die Google Tag Manager SDK oder Firebase SDK zum Einsatz. Hinsichtlich Tag Management-Setup läuft dann in der Webview der Web GTM-Container, der die Events standardmäßig im Web-Format feuert. Damit diese im App-Format verschickt werden können, muss der Web-GTM die Events an den nativen Teil kommunizieren (dazu gleich mehr), woraufhin die native SDK die App-Daten verschickt. Gleichzeitig muss man dafür Sorge tragen, dass die Webevents unterbunden werden, da man sonst ein Doppeltracking hat. Kommt kein GTM zum Einsatz, sondern hat man direkt die Analytics SDK implementiert, so muss die Webview mit dem nativen Teil kommunizieren. Werden in der Webview Events registriert, gehen diese nicht direkt zur Analytics-Plattform, sondern werden mittels eines JavaScript-Handlers an den nativen Teil weiterschickt. Im nativen Teil wartet dann ebenfalls ein Message-Handler, der die Anfragen entgegennimmt und weiterverarbeitet.
• Progressive Web Apps (PWA): Hinsichtlich App Tracking muss hier zunächst das gleiche beachtet werden wie bei der herkömmlichen Web App. Der größte Unterschied im technischen Setup liegt darin, dass man sich bei PWAs auch Gedanken zum Offline-Tracking machen muss. Ruft der Nutzer die PWA im Offline-Modus auf, muss sichergestellt werden, dass die Events dennoch gesammelt und später nachgeschickt werden können. In der Regel geschieht das über die IndexedDB.
• Cross Plattform App: Für das App Tracking auf Cross Plattform-Technologien können auf Basis des Google Tag Manager die App-Container genutzt werden. Soll ein direktes App Tracking über Firebase ermöglicht werden, so gibt es bspw. das Analytics SDK auch für Flutter.

Nutzer-Identifizierung in Apps

Da in nativen Apps keine Cookies zum Einsatz kommen, erfolgt die Nutzer-Identifizierung über andere Wege und ist etwas komplexer als wie im Web.

• Cookies
• Device ID
• Open Device Identification Number
• Neue Device ID aka Advertising ID
• Instance ID

Cookies

Um den Nutzer innerhalb einer App zu identifizieren, können auch Cookies zum Einsatz kommen, jedoch nur im begrenzten Rahmen innerhalb einer Webview, wenn diese in der App geladen wird. Es handelt sich jedoch um eine Art Sandbox, da diese Cookies nicht über verschiedene Apps hinweg geteilt werden können. Bei Apps mit rein Webviews, können diese Cookies zur Nutzer-Identifizierung für statistische Zwecke genutzt werden, jedoch nicht für Marketing.

Device ID

Vor 2012/2013 gab es noch die klassische Device ID, die man auch nutzen konnte, um Nutzer über verschiedene Apps hinweg zu identifizieren. Eine Device ID ist dabei eine eindeutige, anonymisierte Zeichenfolge bestehend aus Nummern und Buchstaben, um jedes Smartphone und Tablet individuell identifizieren zu können. Bei Android-Geräten war es die Android ID, bei iOS der Universal Device Identifier (UDID). Auch konnte man über die MAC-Adresse (Media Access Control) eine eindeutige ID des Nutzer generieren. Aufgrund von rechtlichen Regulierungen und Bedenken seitens der Nutzer wurde diese Form der Identifizierung irgendwann in 2012 und 2013 durch Google und Apple verhindert. Auf die Android ID und UDID konnte somit nicht mehr zugegriffen werden.

Open Device Identification Number (ODIN)

Daraufhin haben sich diverse Mobile-Ads-Anbieter zusammengetan und die Open Device Identification Number (ODIN) als eindeutigen Identifier für Apps entwickelt. Diese Lösung konnte sich nicht ganz durchsetzen und wurde schnell durch die von Google und Apple neuen Identifier abgelöst.

Neue Device ID aka Advertising ID

Die neuen Device IDs zur Nutzer-Identifizierung werden nun Advertising IDs genannt, von denen es verschiedene gibt:

• Android Advertising ID (AAID) von Google (manchmal auch Google Advertising ID (GAID) genannt)
• Identifier For Advertisers (IDFA) von Apple

Für Marketing sind diese IDs besonders wichtig, da darüber verfolgt werden kann, welche Ad gesehen und geklickt wurde und ob die Kampagnen erfolgreich zu einer App-Installation oder einem Kauf geführt hat (zumindest in der Theorie). Die Advertising IDs können als Art Third-Party-Cookies in der Appwelt gesehen werden. Falls diese ID zur Verfügung steht, kann damit folgendes erreicht werden:

• Nutzer können über Apps hinweg identifiziert werden.
• Retargeting von Nutzern.
• Attribution – z.B. Klick auf eine Anzeige in einer App, wobei der Klick zu einer anderen App führt, wo dann eine Conversion stattfindet. Die App, auf der die Conversion stattfand, kann nachvollziehen worüber der Nutzer kam und die Conversion attribuieren. Die ist vor allem wichtig, wenn man Installationskampagnen korrekt auswerten möchte.

Android Advertising ID (AAID) von Google
Die AAID besteht zunächst aus 8 Zeichen, gefolgt von einem Bindestrich, gefolgt von weiteren drei Blöcken jedoch mit je 4 Zeichen – getrennt mit einem Bindestrich. Und zum Schluss nochmal 12 Zeichen. Alles im Lowercase:

8t65214e-456e-sdf5-fde8-12dfertaser1

Als Nutzer kann man seine AAID in den System-Einstellungen von Android unter “Google” -> “Anzeigen” einsehen.

Dort lässt sich die ID zurücksetzen oder auch komplett löschen. Mit der Löschung der AAID setzt man automatisch auch eine Art “Opt-out” für personalisierte Werbeanzeigen. Seit Android 12 wird die AAID beim Löschen komplett genullt. Man bekommt dann:

00000000-0000-0000-0000-000000000000

Identifier For Advertisers (IDFA) von Apple
Die IDFA besteht zunächst aus 8 Zeichen, gefolgt von einem Bindestrich, gefolgt von weiteren drei Blöcken mit je 4 Zeichen – getrennt mittels Bindestrich. Alles im Uppercase:

UIDS456E-EE1O-78FD-4588

Mit der Einführung von LAT (Limited Ad Tracking) in 2016 konnten Nutzer die Nutzung der IDFA einschränken. Mit der Aktivierung der LAT-Funktion wurde die IDFA genullt. Jedoch musste der Nutzer diese Funktion aktiv selbst in den Einstellungen suchen und setzen. Seit den iOS-Versionen 14.5 (iOS 14.5, iPadOs 14.5 und tvOS 14.5) können Nutzer der Weitergabe der IDFA zustimmen oder die Weitergabe auch komplett über ein Pop-Up, welches beim initialen Start der App nach der Installation erscheint, ablehnen. Entwickler müssen dabei das ATT (App Tracking Transparency) Framework nutzen, um diese Zustimmung zu holen (ATT ist eine Art nativer Cookie-Consent-Banner innerhalb iOS-Apps). Erst dann ist die IDFA für Entwickler und Add-Tech-Plattformen verfügbar. Da die Zustimmungsraten niedrig sind, bringt das unter anderem für Attribution von Marketing-Kampagnen Herausforderungen mit sich. Etwas Abhilfe schafft da die SKAdNetwork-Technik von Apple. Darüber können bei Apple registrierte Werbenetzwerke nachvollziehen, über welche Apps und Kampagnen App-Installationen durchgeführt worden sind. Die bereitgestellten Daten sind jedoch sehr limitiert.

Für das Tracking ist relevant, dass durch ATT zunächst einmal alle Techniken betroffen sind, die Daten in der App sammeln und mit Drittanbieter Plattformen und SDKs teilen. Heißt: Nutzt man Firebase Analytics nicht nur für statistische Zwecke, sondern auch um Zielgruppen damit zu bauen und sie mit anderen Tools zu teilen, dann ist das App Tracking Transparency zwingend erforderlich, damit auf die IDFA zugegriffen werden kann.

ATT muss nicht eingesetzt werden, wenn Daten im First-Party-Kontext für analytische Zwecke gesammelt werden. Sprich: Firebase Analytics (also GA4) kann auch ohne ATT eingesetzt werden. Zwar steht dann die Advertising ID nicht zur Verfügung, was im Grunde für die Datensammlung im First-Party-Kontext nicht relevant ist, da man sich hier auf andere Identifier beziehen kann: Instance ID.

Instance ID

Für die First-Party-Messung stehen die sogenannten (App) Instance IDs zur Verfügung, die eine Art First-Party-Cookies im App-Kontext sind. Mit dieser ID kann man den Nutzer zwar nicht App-übergreifend identifizieren (weil nur die App selbst darauf zugreifen kann), aber sie erfüllt andere Zwecke:

• Mit der Instance ID kann ein Nutzer (genauer gesagt eine Appinstallation!) identifiziert werden.
• Verschiedene App Sessions können einem Nutzer zugeordnet werden.

Gleichzeitig muss man mit einigen Einschränkungen rechnen:

• Die Instance ID wird gelöscht, wenn bspw. der App-Cache geleert wird.
• Wenn der Nutzer die App deinstalliert wird die Instance ID ebenfalls gelöscht und bei einer späteren nochmaligen Installation wird eine neue ID vergeben.

Wenn es um das Setzen der Instance ID geht, dann übernehmen das in der Regel die Tools selbst. Ähnlich wie Google Analytics beim _ga-Cookie im Web, setzt z.B. standardmäßig die Firebase Analytics SDK selbstständig eine eigene ID. Aber es kann auch alternativ eine eigene ID gesetzt werden. Bei Firebase Analytics ist es die Firebase-Installations-ID (FID), die gleichzeitig die Client ID – also das Feld user_pseudo_id in den Rohdaten – darstellt. Man muss bei der FID jedoch berücksichtigen, dass sie…

• …bei einer Deinstallation der App ebenfalls gelöscht wird und…
• …dass sie auch beim Leeren des App-Caches (und Geräte-Caches) gelöscht wird und…
• …dass die FID ebenfalls nach 270 Tagen Inaktivität des Nutzer gelöscht wird.

Auch andere Tools haben ihre Instance ID. Bei AppsFlyer ist es z.B. die AppFlyer ID, bei Adjust der Adjust Device Identifier. Über diese App Instance IDs können also Nutzer wiedererkannt werden und die einzelnen Events können einem Nutzer (bzw. einer App-Installation) zugewiesen werden.

Für Marketing bleibt aber die Frage offen, wie Attribution im App Tracking-Bereich funktioniert? Hier kommen Deep Links, UTM-Parameter und Mobile Measurement Partner (MMP) ins Gespräch.

Attribution

Attribution in der mobilen App-Welt ist nicht einfach. Die Verknüpfung verschiedener Referrer und IDs, um eine kanalübergreifende Attribution zu ermöglichen, ist im App-Kontext deutlich komplizierter als im Web. Die Standardmethoden aus dem Web wie Cookies oder Bildpixel funktionieren im App-Kontext nicht. Zudem kommt hinzu, dass man für Android und iOS jeweils eigene technische Methoden braucht. In diesem Bereich geht es um die technischen Möglichkeiten im Bereich der Attribution:

• Deep Links mit UTM-Parametern
• Mobile Measurement Partner (MMP)

Deep Links mit UTM-Parametern

Bei einem Deep Link handelt es sich um eine URI bzw. einem Link, der einen Nutzer direkt auf einen Screen der App weiterleitet. Klickt bspw. der Nutzer auf eine Produkt-Anzeige im mobilen Browser und soll dabei direkt auf die Produktseite innerhalb der App weitergeleitet werden, dann stellt dies der Deep Link sicher. Zudem kann der Deep Link so eingestellt werden, dass a) wenn Nutzer die App bereits installiert haben, direkt auf die Produktseite landen oder b) wenn Nutzer die App nicht installiert haben, zunächst zum App Store oder Play Store geleitet werden, um die App herunterzuladen und dann auf die Produkt-Seite geleitet zu werden.

Leider gibt es bei Deep Links keinen Standard, sodass Android und iOS dies etwas unterschiedlich handhaben. Hinzu kommt, dass größere Plattformen wie Facebook auch eigene Standards haben, die wiederum von anderen Plattformen abweichen können. Vom Grundprinzip arbeiten sie ähnlich. Dennoch muss die technische Implementierung je Plattform durchgeführt werden:

• Bei iOS heißen die Deep Links “Universal Links”.
• Bei Android heißen sie tatsächlich Deep Links (wobei manchmal auch von “Android App Links” gesprochen wird, was jedoch leicht was anderes ist). Mehr Infos dazu auf der entsprechenden Android-Developer-Seite

Zusätzlich gibt es noch die Dynamic Links von Firebase. Dazu gleich mehr. Wir bleiben zunächst bei den klassischen Deep Links, denn davon gibt es wieder verschiedene Arten (Quelle Adjust), die unterschiedlich arbeiten und diverse Zwecke erfüllen:

• Direkte Deep Links: Bei diesem Link wird der Nutzer direkt auf die gewünschte Stelle der App geführt, sofern die App installiert ist.
• Indirekte Deep Links: Im Prinzip landet auch hier der Nutzer direkt auf die gewünschte Stelle in der App, jedoch dass der Deep Links zunächst auf eine andere URI leitet und diese dann den Nutzer zur App bringt. Man kann sich das wie einen Klick-Tracker vorstellen.
• Deferred Deep Link: Dabei handelt es sich – wie der Name schon sagt – um einen “verzögerten” Link. Dieser Deep Link umgeht den Nachteil der direkten Deep Links. Bei direkten Deep Links landet der Nutzer im Nirvana, falls die App noch nicht installiert ist. Bei einem Deferred Deep Link wird zunächst abgefragt, ob die App installiert ist. Falls ja, dann wird der Nutzer direkt auf die gewünschte Stelle geleitet. Falls nein, dann wird der Nutzer zunächst in den Play Store bzw. App Store geleitet, um die App zu installieren. Im Anschluss – nach der Installation – wird der Nutzer auf die gewünschte Stelle der App geleitet.
• Fallback Deep Links: Mit einem Fallback Deep Link kann man den Nutzer zu einer beliebigen Stellen leiten, falls die App noch nicht installiert ist. Statt also einen Deferred Deep Link zu nutzen, um den Nutzer zuerst zur Installationsseite der App zu leiten, kann man mit dem Fallback (der meist bei direkten Deep Links zum Einsatz kommt) den Nutzer z.B. zur mobile Website leiten, falls die App noch nicht installiert ist.

Wie beschrieben müssen Deep Links je Plattform aufgesetzt werden (Universal Links bei Apple, Deep Links bei Android). Um eine plattformübergreifende Technik zu ermöglichen, gibt es die Firebase Dynamic Links. Diese haben verschiedene Vorteile:

• Hat der Nutzer die iOS- oder Android-App bereits installiert, wird der Nutzer direkt auf den gewünschten Inhalt nach dem Klick auf den Dynamic Link geleitet
• Falls der Nutzer die App noch nicht installiert hat, wird der Nutzer auf den richtigen Store (Play oder App) geleitet.
• Öffnet der Nutzer denselben Link auf dem Desktop, dann kann der Nutzer auf einen entsprechenden Inhalt auf der Website geleitet werden.

Wenn es nun um Attribution geht ist der entscheidende Punkt, dass man an Deep Links (bzw. Dynamic Links) wie im Web Tracking-Parameter (z.B. UTMs) setzen kann. Ob die Attribution aber auch klappt hängt von diversen Faktoren ab und vom Use Case: Hat der Nutzer die App schon installiert oder noch nicht?

Attribution, wenn der Nutzer die App schon installiert hat
Stößt ein Nutzer auf eine Anzeige im Web, klickt auf die Anzeigen und hat dabei die App schon installiert, dann kommt der Direct Deep Link zum Einsatz. Damit wird der Nutzer direkt auf den gewünschten Screen in der App geleitet. Für die Attribution und das Tracking ist es wichtig, dass UTM-Parameter am Deep Link dran sind. Diese kann dann bspw. die Firebase Analytics SDK verarbeiten.

Attribution, wenn der Nutzer die App noch nicht installiert hat
Hat der Nutzer die App noch nicht installiert, dann ist Attribution herausfordernd. Hier müssen folgende Use Cases beachtet werden:

• Der Nutzer klickt auf den Link, hat aber die App noch nicht installiert
• Übergabe und Weitergabe der Tracking-Parameter muss sichergestellt werden, wenn der Nutzer zunächst in den App- oder Play-Store geleitet wird

Um diese Use Cases bestmöglich abzudecken, kommt eine bestimmte Art von Deep Links zum Einsatz: Deferred Deep Links. Wie oben schon beschrieben sind das “verzögerte” Deep Links. Dieser Link prüft zuerst, ob die App schon installiert ist. Wenn ja, dann wird der Nutzer direkt zum gewünschten Screen weitergeleitet. Wenn nein, wird zunächst auf die Download-Seite geleitet (App- oder Play-Store), damit der Nutzer die App installieren kann. Nach erfolgreicher Installation wird der Nutzer auf den gewünschten Screen geleitet. Für den ersten Fall – wo der Nutzer ohne Umwege auf die App geleitet wird – können Tracking-Parameter wie UTMs direkt ausgelesen werden und gehen nicht verloren. Beim zweiten Fall ist die Sache etwas schwieriger. Wie kann also der Klick (wo die Kampagnen-Information enthalten sind) mit dem ersten Öffnen der App (first_open-Event z.B.) verknüpft werden, um Attribution zu ermöglichen?

Theoretisch gäbe es einige Möglichkeiten den Klick und das First-Open-Event nach der App-Installation miteinander zu verknüpfen, jedoch mit Limitierungen:

• Über den IDFA oder GAID könnte dieses Linking stattfinden. Sprich: Der Nutzer, der auf eine bestimmte Kampagne geklickt hat und nicht direkt auf die App kam, da nicht installiert, kann später nach der Installation darüber identifiziert werden. Auf diesem Wege kann der initial geklickte Deep Link inkl. UTM-Parametern beim ersten Öffnen der App wieder abgerufen werden. Diese Methode ist jedoch aufgrund Consent beschränkt. Bei iOS zudem noch stärker seit Version 14.5. Über die Beschränkungen habe ich weiter oben schon geschrieben.
• Alternativ könnte man über Fingerprinting gehen, was jedoch nicht so genau wäre wie IDFA oder GAID bzw. ebenfalls aus Datenschutz-Gründen limitiert ist

Was bliebt also noch? Im Falle von Android hilft die Install Referrer API, um die Kampagneninformationen weiterzugeben. Für iOS gibt es diese Möglichkeit leider nicht. Deshalb kann alternativ (auch für Android) das Auswerten von Kampagnen-Informationen im App- oder Play-Store selbst erfolgen. Diese bieten nämlich auch ein eigenes Analytics-Dashboard an. Dies ist zwar limitiert und nicht so umfangreich wie Firebase Analytics bzw. GA4, aber immerhin können dadurch auf Basis von UTMs Kampagnen ausgewertet werden und welche davon für die meisten Installationen geführt haben. Damit das Reporting und die Attribution funktionieren ist es wichtig, die Deep Links mit den richtigen Tracking-Parametern zu versehen. Auch hier gibt es Unterschiede zwischen den Plattformen:

• Für den Android Play Store können UTMs genutzt werden (nutze diesen Play-Kampagnen-URL-Builder). Hat den Vorteil, dass diese dann über die Install Referrer API weiter zu Firebase Analytics übergeben werden, damit in Firebase Analytics die Attribution erfolgen kann.
• Der App Store von Apple versteht hingegen nur die Parameter “pt” (für den Provider) und “ct” (für den Kampagnencode). Siehe hier unter “Use your campaign and provider tokens”.

Als letzte Alternative für iOS wäre da noch das SKAdNetwork, welches jedoch nur bestimmte Daten in aggregierter Form liefert. Jedoch sind diese Alternativen nicht wirklich hilfreich, da man im App-Bereich nicht nur wissen möchte, über welche Kampagne die meisten App-Downloads und -Installationen durchgeführt worden sind, sondern man möchte auch wissen, welche Kampagnen die meisten Transaktionen gebracht haben. Wie erwähnt ist das für Android mit der Install Referrer API besser nachvollziehbarer als für iOS-Geräte. Um hier, aber auch bei Android, mögliche Lücken zu schließen kommen Mobile Measurement Partner zum Einsatz.

Mobile Measurement Partner (MMP)

Um Aktivitäten des Nutzers über verschiedene Plattformen hinweg zu verknüpfen, kommen meist MMP’s (oder Universal SDKs) zum Einsatz. In der Regel muss man verschiedene SDKs für unterschiedliche Zwecke wie Ads-Ausspielung oder Tracking einsetzen. Mit einer Universal SDK (bekannte Anbieter sind Adjust oder AppsFlyer) wird hingegen einmalig die Universal SDK implementiert und durch die zahlreichen Partnerschaften lassen sich weitere SDKs wie Facebook, Twitter und Co. darüber anbinden. Gleichzeitig stellt der Mobile Measurement Partner sicher, dass man ein übergreifendes Bild von seinen Nutzern hat. Während der Einsatz einzelner SDKs die Conversion-Messung auf sich selbst beschränkt, hilft eine Universal SDK die Messung plattformübergreifend zu ermöglichen.

Die Attribution wird bei MMPs auf Basis von verschiedenen Identifiern ermöglicht. Grob läuft dies wie nachfolgend ab. Bitte beachte, dass sich das Handling je nach MMP im Detail unterscheiden kann.

1. Tracker nimmt Klick auf

MMPs bieten Tracker-URLs an, die als Anzeigen-Ziel-URL verwendet werden. Klickt der Nutzer auf eine Werbeanzeige innerhalb einer App, dann erfolgt zunächst der Aufruf dieser Tracker-URL. Diese hat diverse Parameter mit zusätzlichen Informationen über die Kampagne. Durch den Aufruf der Tracker-URL bekommt das MMP schon diverse Informationen mit. Im zweiten Schritt kann diese Tracker-URL auch das Gerät des Nutzers identifizieren, um den Nutzer später in den richtigen App-Marktplatz weiterzuleiten (Play Store bei Android oder App Store bei iOS). Man spricht dabei auch von Multi-Plattform-Tracker-URLs. Je nachdem, ob der Nutzer als Android- oder iOS-Nutzer identifiziert wurde, hängt davon der weitere Verlauf ab.

2. Plattform-Handling

Android bzw. Play Store
Hat der Tracker erkannt, dass es sich um einen Android-Nutzer handelt, dann wird mithilfe folgender Methoden versucht ein Matching zwischen Klick und Erstöffnen der App hinzubekommen:

1. Android Install Referrer: Nach dem Klick auf die Anzeige leitet die Tracker-URL den Nutzer in den Play Store inkl. allen Tracking-Parametern. Zusätzlich wird ein weiterer Parameter der MMP angehangen für die spätere Identifikation (falls Install Referrer verfügbar). Installiert der Nutzer nun die App und öffnet sie, wird der selbe Link inkl. Tracking-Parameter vom Play Store über die Install Referrer API an die App übergeben, wo wiederum die MMP diese Daten und Parameter wieder an die eigenen Server für das Matching senden kann.
2. Google Advertising ID (GAID): Ist kein Install Referrer vorhanden, wird versucht auf die GAID zuzugreifen.
3. Fingerprinting: Falls auch keine GAID verfügbar ist, versucht das MMP in der Regel nochmal per Fingerprinting ein späteres Matching hinzubekommen.

Schlagen alle Methoden fehl, dann läuft der Traffic in Organic oder anderswo rein (je nach MMP unterschiedlich). Nachdem eine Identifizierungsmethode vorhanden ist, landet der Nutzer im Play Store, um die App herunterzuladen. Nach der Installation und dem Öffnen der App wird auch gleichzeitig das SDK des MMPs gestartet, welches wieder einen Request zum MMP-Server inkl. den Identifier schickt, damit dies später abgeglichen werden kann.

iOS bzw. App Store
Hat der Tracker erkannt, dass es sich um einen iOS-Nutzer handelt, dann wird mithilfe folgender Methoden versucht ein Matching zwischen Klick und Erstöffnen der App hinzubekommen:

1. Identifier for Apps (IDFA): Das MMP versucht zunächst auf den IDFA zuzugreifen. Für Geräte ab iOS 14.5 ist es dabei notwendig, dass das App Tracking Transparency (ATT) Framework implementiert ist. Ist die IDFA verfügbar wird diese an den MMP-Klick-Tracker-Request angehangen (für das spätere Matching).
2. Fingerprinting: Falls keine IDFA verfügbar ist, versucht das MMP in der Regel nochmal per Fingerprinting ein späteres Matching hinzubekommen.
3. IP-Adresse: Als letzten Ausweg kann die MMP versuchen, noch auf die IP-Adresse zuzugreifen. Dies ist jedoch nur für iOS-Geräte vor Version 15 möglich. Ab Version 15 hat iOS diverse Privacy-Features implementiert. Darunter die IP-Verschleierung. Entsprechend muss bei Geräten ab Version 15 als Fallback das SKAdNetwork genutzt werden.

Auch hier gilt: Schlagen alle Methoden fehl, dann läuft der Traffic in Organic oder anderswo rein (je nach MMP unterschiedlich). Nachdem eine Identifizierungsmethode vorhanden ist, landet der Nutzer im App Store, um die App herunterzuladen. Nach der Installation und dem Öffnen der App wird auch gleichzeitig das SDK des MMPs gestartet, welches wieder einen Request zum MMP-Server inkl. dem gewählten Identifier (z.B. IDFA) schickt, damit dies später abgeglichen werden kann.