⑥ Matching der Informationen
Anschließend sammelt das Adjust SDK Geräteinformationen inklusive der Advertising ID (IDFA), des Device Fingerprints und/oder IP-Location und übermittelt diese an das Adjust Ad Network. Im Adjust Ad Network findet nun ein Matching anhand des jeweiligen Identifiers statt, wodurch die Interaktion mit der Anzeige auf dem Marketingkanal mit der erfolgreichen Installation der App in Verbindung gebracht werden kann.

① Klick auf eine Werbeanzeige
Der Nutzer sieht in einem sozialen Netzwerk oder auf einer Werbeplattform die Anzeige zu einer App, welche zum Download, in den App Store führt und klickt auf den Call-to-Action.

Ab diesem Punkt besteht ein Unterschied in der Anwendbarkeit der zuvor beschriebenen Attributions-Logik für Geräte, auf denen bereits iOS 15.0 oder eine neuere Version installiert wurde. Seit der mit iOS 15 eingeführten iCloud Private Relay-Funktion greift nun auch nicht mehr der von Adjust entwickelte Attribution Fallback.

Die Funktion verschlüsselt hierbei DNS-Einträge und erzeugt eine temporäre IP-Adresse für den gesamten unverschlüsselten HTTP-Traffic zwischen Gerät und der aufgerufenen Webseite im Safari-Browser. Zwar hat Apple angedeutet, dass nur HTTP-Traffic innerhalb von Apps durch Private Relay geleitet wird und es somit das App-to-App-Fingerprinting nicht behindert, dies jedoch nicht die Datenkommunikation an Third Party-Anbietern wie Adjust oder Appsflyer mit einschließt. Eine gerätespezifische Attribution wird somit unmöglich, falls kein Opt-In für die Nutzung der IDFA im ATT SDK registriert wurde. Als Alternative für die Messung von Kampagnen ohne Zugriff auf die IDFA wurde bereits 2018 mit der Einführung von iOS 14 das sog. SKAdNetwork (StoreKit Ad Network) von Apple vorgestellt. Das SKAdNetwork kann hierbei parallel als auch bei Verweigerung des Zugriffs auf die IDFA für die Attribution von Installationen genutzt werden.

Attribution ohne IDFA-Zugriff

②b SKAd Network
Bei Ablehnung der Erfassung der Advertising ID (IDFA) durch das ATT SDK, kann auf das SKAdNetwork zurückgegriffen werden. Dieses ersetzt im Wesentlichen die Funktionalität der MMP, indem es die gerätebasierte Attribution in eine datenschutzkonforme Attribution anhand aggregierter Conversion Daten (Installationen) übersetzt. Dem Werbenetzwerk bleibt es somit weiterhin möglich, Rückschlüsse darüber zu treffen, ob eine bestimmte Kampagne zu einer Installation führte, jedoch nicht, welcher spezifische Nutzer diese Installation durchgeführt hat. Nach dem Klick auf die Werbeanzeige wird der Nutzer auf die App-Detailseite des App Stores weitergeleitet.

③b Start des 24h-Timers
Wurde eine über das SKAdNetwork registrierte App erfolgreich installiert, wird beim initialen Öffnen der App mit einem Call an die SKAdNetwork-API ein 24h-Timer in der App gestartet, welcher nach Ablauf des Zeitfensters die Conversion erfolgreich verifiziert. Wird innerhalb des gesetzten Zeitfensters eine weitere Conversion erfasst, wird der Conversion-Value mit einem weiteren Call an die SKAdNetwork API geupdated und der bestehende 24h-Timer zurückgesetzt.

④b Download der App
Nach Ablauf des 24h-Timers kommuniziert die App den endgültigen Conversion-Value an das SKAdNetwork (API), welches die Conversion Daten in einem Conversion Postback an das zugewiesene Werbenetzwerk sendet.

⑤ Übermittlung der Conversion Daten zu Adjust
Adjust erhält von dem jeweiligen Ad Network anschließend eine Kopie des Conversion Postbacks mit dem aktuellsten Conversion-Value.

Attribution mit IDFA-Zugriff

②a ATT Consent
Liegt der Consent für die Erfassung der Advertising ID (IDFA) vor, wird diese vom Ad Network in der Adjust Tracker URL ergänzt und an Adjust übergeben.

③a Adjust Network
Im Adjust Network werden die Informationen über die Anzeigen-Interaktion und die Advertising ID (IDFA) erfasst, miteinander verknüpft und gespeichert. In einem Bruchteil von Sekunden wird der Nutzer automatisch an den App Store zum Download weitergeleitet.

④a Download der App
Der Nutzer lädt die App aus dem App Store herunter. Die App wird erfolgreich auf dem Gerät installiert.

⑤a Initiale Öffnen der App (Adjust SDK)
Sobald der Nutzer die App initial öffnet (Event: First Open), wird das in der App integrierte Adjust SDK getriggert.

⑥ Matching der Informationen
Anschließend sammelt das Adjust SDK Geräteinformationen inklusive der Advertising ID (IDFA) und übermittelt diese an das Adjust Ad Network. Im Adjust Ad Network findet nun ein Matching anhand der Advertising ID (IDFA) statt, wodurch die Interaktion mit der Anzeige auf dem Marketingkanal mit der erfolgreichen Installation der App in Verbindung gebracht werden kann.

① Klick auf eine Werbeanzeige
Der Nutzer sieht in einem sozialen Netzwerk oder auf einer Werbeplattform die Anzeige zu einer App, welche zum Download, in den App Store führt und klickt auf den Call-to-Action.

Ab diesem Punkt – wird wie bei iOS-Geräten auch – eine Validierung vorhandener Identifier für die Identifizierung des Gerätes durch das Ad Network ausgelöst. Adjust bezeichnet diesen Fallback-Mechanismus als “Attribution Waterfall“. Hierbei wird die Verfügbarkeit der Identifier in der Reihenfolge ihrer Reliabilität für die Attribution geprüft und angewendet.

Attribution mit reftag

②a Play Store Referrer
Erkennt Adjust einen Play Store Referrer-Link, wird dem Referrer ein sogenanntes reftag hinzugefügt, welches Play Store Referrer zur Identifizierung der Interaktion dient. Anschließend wird der Nutzer an den Google Play Store weitergeleitet.

②b Google Advertising ID (GAID)
Die Google Advertising ID (GAID) ist in Android das Pendant zu dem Identifier for Apps (IDFA) von iOS. Stehen dem Adjust Ad Network keine Informationen zu einem Play Store Referrer zur Verfügung, wird die Google Advertising ID (GAID) für die Identifizierung des Gerätes genutzt.

②c Device Fingerprinting
Besteht kein Zugriff auf die Google Advertising ID (GAID) wird versucht, ein Device Fingerprint des Gerätes als Identifier zu erstellen. Dieser enthält Informationen aus dem User Agent und der IP-Adresse des Klicks, welcher mit den Daten der Installation abgeglichen wird.

③ Google Play Store
Im Playstore wird der mit dem reftag deklarierte Play Store Referrer temporär gespeichert. Kommt es anschließend zum Download, werden die Informationen mit der Installation in die App weitergegeben.

④ Adjust SDK
Mit der Installation der App wird auch das in der App installierte Adjust SDK ausgeführt, welches über einen Broadcast Receiver verfügt. Dieser untersucht empfangene Messages laufend nach Referral-Informationen.

⑤ Matching der Informationen
Der aus dem Play Store übermittelte reftag wird vom Broadcast Receiver erkannt. Daraufhin wird die Information über den erfolgreichen Install an Adjust übermittelt und anhand des reftag mit dem initialen Klick auf die Werbeanzeige in Verbindung gebracht. Wurde zu diesem Zeitpunkt für die Attributions-Logik bspw. die Google Advertising (ID) oder ein Device Fingerprinting gewählt, da keine Play Store Referrer-Informationen verfügbar waren, werden diese Informationen vom Adjust SDK im Gerät abgefragt und nach Übermittlung an das Adjust Ad Network mit dort vorhandenen Informationen abgeglichen, um die Attribution zuzuordnen.

Ein sogenannter Deep Link beschreibt die Ziel-URL in einer Anzeige, mit der man auf eine bestimmte Seite oder einen bestimmten Inhalt in einer App weitergeleitet wird. Oftmals treten jedoch Problematiken in der Übergabe der Deep Link-Parameter auf, wenn die App vom Nutzer bisher noch nicht installiert wurde. Link-Parameter gehen zwischen Interaktion mit der Anzeige und Installation der App verloren. Es entsteht ein Bruch in der Attribution, wodurch die Maßnahme nicht mehr zielführend mit dem Download verknüpft wird.

Google Firebase hat für dieses Problem das Dynamic Links SDK entwickelt. Deep Links lassen sich somit mithilfe der Firebase-Konsole, einer REST-API, iOS- oder Android-Builder-API oder mittels einer URL erstellen, indem dynamische Link-Parameter zu einer für die App spezifischen Domain hinzugefügt werden. Wenn der Nutzer nun einen Dynamic Link öffnet, die App jedoch noch nicht installiert ist, wird der Nutzer an den Play- oder App Store gesendet, um die App zu installieren. Anschließend wird der initial an die App übergebenen Dynamic-Link beim Öffnen vom Dynamic Links SDK abgefragt und der Nutzer auf den spezifischen Inhalt weitergeleitet.

In dem Umgang mit Dynamic Links existieren zwischen den Betriebssystemen iOS und Android jedoch einige Unterschiede. Anhand der folgenden Schaubilder wird deshalb der technische Ablauf der Attribution von Dynamic Links detailliert für beide Betriebssysteme dargestellt.

① Klick auf eine Werbeanzeige
Der Nutzer sieht in einem sozialen Netzwerk oder auf einer Werbeplattform die Anzeige zu einer App, welche einen Deep Link enthält, der auf spezifische Inhalte in der App verlinkt. An dieser Stelle findet eine Prüfung statt. Ist die App bereits installiert, wird der Nutzer zu dem ausgewiesenen Inhalt weitergeleitet. Ist die App dem Gerät nicht bekannt, wird der Nutzer zum Download in den App Store weitergeleitet.

②a URL Handler
Ist die App bei Klick auf die Anzeige bereits auf dem Gerät installiert, wird der Dynamic Link über einen URL Handler (handleUniversalLink) im Dynamic Links SDK als normaler Universal Link behandelt.

③a Attribution des Dynamic Links
Der URL Handler ruft eine Funktion im Firebase SDK der App auf, welche die Deep Link URL aus der Dynamic Links URL extrahiert und mit der Firebase Instance-ID als Identifier verknüpft.

Deep Linking bei ausstehender Installation

②b Mobile Preview der Inhalte
Ist die App noch nicht auf dem Gerät installiert, wird nach dem Klick auf den Dynamic Link automatisch der mobile Browser des Gerätes geöffnet. Dort wird dem Nutzer eine Vorschau der spezifischen App-Inhalte mit einem Call-to-Action zum Download präsentiert.

③b Download und Installation der App
Während der Nutzer über den Download Link in der Vorschau zum App Store weitergeleitet wird, speichert der Browser die Dynamic Link-URL in der Zwischenablage des mobilen Browsers ab. Anschließend installiert der Nutzer die App auf dem Gerät.

④b Initiale Öffnen und Aufruf des URL Handlers
Wird die App nach erfolgreicher Installation initial geöffnet, erstellt das in der App implementierte Firebase SDK einen Dynamic Link nach dem App-spezifischen Schema, welches es aus der Dynamic Link URL des Browser Storage extrahiert und ruft anschließend den URL Handler auf.

⑤b Attribution des Dynamic Links
Der URL Handler ruft eine Funktion im Firebase SDK der App auf, welche die Deep Link URL aus der Dynamic Links URL extrahiert und mit der Firebase Instance-ID als Identifier verknüpft.

① Klick auf eine Werbeanzeige
Der Nutzer sieht in einem sozialen Netzwerk oder auf einer Werbeplattform die Anzeige zu einer App, welche einen Deep Link enthält, der auf spezifische Inhalte in der App verlinkt. Klickt der Nutzer nun auf die Anzeige, findet eine Prüfung statt.

Deep Linking bei abgeschlossener Installation

②a Weiterleitung in der App
Ist die App bereits erfolgreich auf dem Gerät des Nutzers installiert und der Link zur App ist in Dynamic Links registriert, wird die App geöffnet und der Nutzer auf den ausgewiesenen Inhalt weitergeleitet.

③a Initiale Öffnen und Aufruf des Intent Handlers
Beim Öffnen der App wird der Intent Handler getriggert und nach der für die App hinterlegten Dynamic Link URL abgefragt.

④a Attribution des Dynamic Links
Der Intent Handler ruft anschließend eine Firebase Funktion auf, um die Deep-Link URL aus dem Handler zu extrahieren und mit der Firebase Instance-ID zu verknüpfen.

Deep Linking bei ausstehender Installation

②b Aufruf des Intent Handlers
Ist die für den Dynamic Link registrierte App noch nicht auf dem Gerät installiert, öffnet das Betriebssystem automatisch den Standard-Webbrowser des Nutzers über den Dynamic Link aus der Anzeige. Die durch Dynamic Links automatisch generierte Website leitet den Nutzer direkt zu einer Android Intent URL, wodurch ein Intent Handler aufgerufen wird.

③b Handling des Deep Links
Der Intent Handler prüft, wie viele Apps sich auf dem Gerät befinden, die bereits für Dynamic Links registriert sind und die spezifische Deep Link-URL händeln können. Das Prüfungsschema des Handlers sieht dabei folgende drei Szenarien vor:

Keine registrierte App:
Befindet sich keine App auf dem Gerät, die für den Deep-Link registriert ist, leitet der Intent Handler den Nutzer automatisch in den Play Store zum Download weiter.

Eine registrierte App:
Ist bereits eine App auf dem Gerät installiert, welche über Dynamic Links registriert wurde, um den Deep-Link zu händeln, wird diese automatisch geöffnet.

Mehr als zwei registrierte Apps:
Sind mehrere Apps auf dem Gerät installiert, die für Dynamic Links registriert sind, wird dem Nutzer ein Pop-up ausgeliefert, welches in einem Dialog zur Auswahl der gewünschten App auffordert. Wählt der Nutzer die gewünschte App aus, wird diese vom Intent Handler anschließend geöffnet.

④b Aufruf des Intent Handlers
Das in der App implementierte Firebase SDK und Dynamic Links SDK wird geladen und stellt eine Abfrage für die Deep Link URL an den Intent Handler. Der Handler ruft anschließend eine Firebase Function auf, um die Deep Link-URL aus dem Intent zu extrahieren.

Im Gegensatz zu Google Analytics, verfügt die Firebase Analytics Console nicht über ein Default Channel Grouping für Traffic Quellen. Stattdessen werden die Werte für Quelle, Medium und Kampagne gespeichert und direkt in den Firebase Conversion-Berichten angezeigt. Standardmäßig gruppiert Firebase Analytics Traffic Quellen wie folgt:

Direct None:
Stehen keine Informationen zu einer Kampagne (Bspw. Link-Parameter) zur Verfügung, wird der Traffic von Firebase Analytics als Direct/None klassifiziert. Dies kann der Fall sein, wenn der Nutzer auf die App zugreift, aber von einer Quelle kommt, die von Firebase Analytics nicht erkannt wurde oder Firebase Analytics nicht in der Lage war, die Informationen über die Quelle abzurufen. Einige Beispiele hierfür sind organische Apple Search-Links, Google Ads iOS Search App-Install Kampagnen und andere nicht deklarierte Kampagnen. Die Klassifizierung als Direct/None kann auch erfolgen, falls der Nutzer über einen Link zum Play Store weitergeleitet wurde, der keine UTM-Parameter enthält.

google-play/referral
Diese Klassifizierung erfolgt, wenn der Nutzer über einen Link, der einen Referrer enthält, auf die Play Store-Liste geleitet wird oder die App organisch durch eine Suche im Google Play Store gefunden wurde.

Apple/Search
Eine App wurde als Ergebnis eines Klicks auf eine Apple Search Ad installiert.

(not set)
Wenn einer der Werte für das Quellmedium, die Kampagne, den Typ des Werbenetzwerkes oder das Werbemittel fehlt, klassifiziert Firebase Analytics den Traffic als (not set).

Firebase kann automatisch den Traffic von einer begrenzten Anzahl von Quellen erfassen. Bei anderen Plattformen wird die Kampagnenquelle als direct eingestuft. Für die Analyse gibt es jedoch einen Workaround, mit dem Daten korrekt der Kampagnenquelle zugeordnet werden können. Dazu müssen wir zwei Schritte befolgen:

① UTM-Kennzeichnung der Deep-Links
Um Traffic toolseitig klassifizieren zu können, muss sichergestellt werden, dass alle Links mit UTM-Parametern gekennzeichnet sind. Hierfür bietet Google Play den sogenannten Google Play URL Builder an, um das nötige Schema einzuhalten.

② Fetching und Übermittlung der UTM Parameter an Firebase Analytics
Je nach verwendetem Betriebssystem unterscheidet sich die Vorgehensweise punktuell. Der grundlegende technische Vorgang bleibt jedoch relativ gleich. Folgend wird die Vorgehensweise zur Übermittlung der UTM Parameter zu Firebase Analytics am Beispiel des Android Betriebssystem erläutert:

A. Hinzufügen der Dynamic Links Library im Code der App
implementation ‚com.google.firebase:firebase-dynamic-links-ktx:19.1.0‘

implementation ‚com.google.firebase:firebase-analytics:17.3.0‘

B. Akzeptieren der Nutzungsbedingungen
Nach Hinzufügen der Dynamic Links Library im Code der App muss im jeweiligen Firebase-Projekt über den Abschnitt dynamische Links in der Firebase-Console den Nutzungsbedingungen von Dynamic Links zugestimmt werden.

C. Hinzufügen eines Intent-Filters in der AndroidManifest.xml