Ein allgemein bekanntes Phänomen ist, dass Mobile-Traffic schlechter konvertiert als Desktop-Traffic. Im Netz gibt es dazu dutzende Artikel (oder auch hier) und umfangreiche Studien.
Der Unterschied wird oft damit erklärt, dass der Bildschirm zu klein und die Navigation schwierig ist. Der User informiert sich zwar gerne Mobil, wechselt dann aber zum Desktop-Device und tätigt dort den Einkauf. Dies ist das sogenannte “Cross-Device-Problem”. In diesem Artikel möchte ich nicht nur auf dieses Problem, sondern vor allem auf das eher unterschätzte “Cross-Browser-Problem” eingehen.
Dem Problem auf den Grund gehen – Schritt für Schritt
Die Meisten aus unserer Branche haben vermutlich von dem “Cross-Device-Problem” schon gehört – aber was da ganz genau passiert und welche Seiteneffekte das hat, ist vermutlich den Wenigsten bewusst. Ich möchte das Problem daher anhand eines Beispiels darstellen:
- Ein User sieht auf seinem Smartphone eine Display-Anzeige für Sneaker
- Er klickt auf die Anzeige und wird zum Shop weitergeleitet – der Shop nutzt UTM-Parameter, um die Kampagne besser zu messen.
- Google Analytics erfasst den Aufruf und weist ihn dem Display-Kanal zu.
- Der User navigiert innerhalb des Shops und ruft ein Produkt auf.
- Er fällt seine Kaufentscheidung – den Kauf möchte er aber nicht auf dem Smartphone tätigen, sondern auf seinem Laptop.
- Also fährt er seinen Laptop hoch, öffnet den Browser und…
…ab hier kommt das große Fragezeichen. Die wenigsten User synchronisieren ihre Browser, so dass besuchte oder aufgerufene Browser-Tabs auch auf dem Desktop-Device erscheinen. Wie kommt der User also zum Shop und zu dem Produkt, dass er kaufen möchte? Es gibt mehrere Möglichkeiten:
- Er gibt im Desktop-Browser direkt die URL des Shop ein und sucht erneut nach dem Produkt.
- Er “googelt” nach dem Shopname (evtl. zusätzlich noch nach dem Produkt)
- Er schickt sich selbst den Link zum Produkt (z.B. via E-Mail, Notiz-Sync etc.)
- Er versucht die Display-Anzeige erneut zu finden über die er zum Shop gelangte (m.E. unrealistisch)
Eines haben alle gemeinsam – beim erneuten Besuch des Users (diesmal via Desktop), ist er für GA ein neuer User mit einer neuen Session. Und welchem Kanal wird dieser zugeordnet? Nun, das hängt davon ab welche der Optionen er nutzt – meines Erachtens sind Variante 1 und 2 am realistischsten, also Direct oder Search. In jedem Fall ist es nicht der Display-Kanal. Wenn der User nun seinen Einkauf tätigt, wird also erneut ein anderer Kanal “gestärkt”, während der eigentliche Kanal in der Conversion geschwächt wird (Impression ja, Sale nein).
Dieser Effekt verstärkt sich, je höher der Mobile-Anteil eines Unternehmens ist! Im Umkehrschluss schwächt man also subjektiv betrachtet seine Paid-Kanäle je mehr man Mobile Traffic einkauft.
Zugegeben, es ist sehr kompliziert und technisch extrem herausfordernd das “Cross-Device-Problem” zu lösen. Von den großen Anbietern (Facebook & Google) gibt es mit dem sogenannten“Cross-Device-Tracking” Ansätze. Diese basieren darauf, dass der User auf beiden Devices, also bei Facebook oder Google, eingeloggt ist und dadurch identifizierbar ist. Das kann helfen, führt aber zwangsläufig zu Streuverlusten, da nicht jeder User immer überall eingeloggt ist.
Darüber hinaus stellt sich die Frage wie Google Cross-Device-Besuche handhabt die nach dem Device-Wechsel eine Google-Suche ausführen um zum Shop zu gelangen. Bleibt es bei “Display” oder zählt Google den Cross-Device-User dann als “Organic Search”? Und was wenn der User statt auf den organischen Treffer auf eine AdWords-Anzeige des Shops klickt? Wird er dann als “Paid Search” gehandhabt? Leider konnte ich zu diesem Thema bei meinen Recherchen nichts finden.
Das unterschätzte Problem: InApp-Browser
Im Zuge meiner Recherchen bin ich auch auf ein wenig bekanntes Problem gestoßen – und zwar bei den sogenannten InApp- bzw. Webview-Browsern in iOS und Android, siehe “In-App Browsers: What You Need to Know” bzw. “The Facebook browser – the biggest browser that you ignore”.
Bei einem InApp-Browser handelt es sich um ein Browser-Framework, das Mobile-Apps nutzen können, um externe Seiten direkt aus der App heraus aufzurufen ohne die App zu verlassen. Apps nutzen diese Funktion gerne, da der User quasi in der App bleibt und sie so die Kontrolle über den User und sein Surfverhalten behalten (zumal sie damit erweiterte Tracking-Möglichkeiten nativ in der App nutzen können).
Zu den bekanntesten Apps die diese Funktion nutzen, zählen ohne Zweifel Facebook, Twitter und Instagram. Aber auch viele andere populäre Apps wie Telegram, LinkedIn, Xing u.v.a. nutzen InApp-Browser.
Warum sind InApp-Browser für den User schlecht?
Leider haben InApp-Browser einige negative Eigenschaften für den User, darunter:
- Es gibt keine Tabs – alles spielt sich in einem Browser-Fenster ab.
- Die URL-Leiste kann vom App-Anbieter deaktiviert werden, der User kann also nicht einfach eine andere URL eingeben und weitersurfen. Er kann nur mit Links auf der geöffneten Seite navigieren.
- Man kann nicht auf Favoriten zugreifen, also weder welche speichern, noch welche abrufen
- Es funktionieren i.d.R. keine Browser-Plugins (z.B. Passwortmanager wie 1Password)
- Sie besitzen ein eigenes Cookie-Storage (dazu später mehr)
All dies sorgt dafür, dass InApp-Browser bei Usern eher unbeliebt sind. Die Folge: Die User nutzen die angebotene Funktion “in Safari/Chrome öffnen”, um in den Standard-Browser des Smartphones zu wechseln. Leider gehen dabei aber wichtige Informationen für die Attribution verloren und es besteht das Risiko, dass der User doppelt gezählt wird (siehe auch “Unique Visitors In A Multi-Device World“).
InApp-Browser führen zu einem “Cross-Browser”-Problem
Wie bereits erwähnt besitzen InApp-Browser ein eigenes Cookie-Storage – sprich Cookies die im Standard-Browser bereits gesetzt sind, sind im InApp-Browser nicht verfügbar! Umgekehrt sind auch Cookies die InApp gesetzt werden, im Standardbrowser nicht abrufbar. Darüber hinaus ist jeder InApp-Browser quasi komplett voneinander abgekoppelt – sprich, Cookies die im Facebook InApp-Browser gesetzt werden, sind in anderen InApp-Browsern (z.B. Twitter) ebenfalls nicht verfügbar. Damit ergibt sich, angelehnt zu “Cross-Device”, ein “Cross-Browser”-Problem.
Und genau das sorgt für einige Probleme bei der Attribution! Stellen wir uns folgendes Szenario vor:
Ein Shop schaltet eine Produktanzeige auf Facebook. Ein User sieht die Anzeige in der Facebook-App, klickt darauf und wird im InApp-Browser zum Shop weitergeleitet. Die Weiterleitung erfolgt über einen AdServer inkl. einer Cookie-Weiche. Der User erhält also ein Cookie von Facebook, vom Tracking-Provider des Shops und vom Shop selbst. Auf der Landingpage wurden UTM-Parameter verwendet, weshalb der User auch in Google Analytics korrekt erfasst wurde. Soweit ist alles in Ordnung – wenn der Kunde seinen Einkauf auch im InApp-Browser abschließt gibt es gar keine Probleme.
SZENARIO 1: Kunde springt direkt raus
Problematisch wird es aber, wenn der Kunde sich dazu entscheidet, aus dem InApp-Browser in den Standard-Browser zu wechseln. Tut er dies, wird die zuletzt geöffnete URL aufgerufen – im obigen Beispiel also inkl. der UTM-Parameter. Ab hier wird es kompliziert: Beim “herausspringen” gehen alle Cookies verloren – sie können ja vom Standard-Browser nicht gelesen werden. Das Cookie von Facebook und auch das Cookie vom Tracking-Provider, der die Cookie-Weiche steuert, wurden ja nur InApp ausgelöst. Für den Shop und auch für Google Analytics handelt es sich somit um einen neuen User – ergo wird ein neues Cookie erstellt und in GA eine neue Session gestartet. Zwar trackt GA aufgrund der übernommenen UTM-Parameter die korrekte Herkunft, aber derselbe Nutzer wurde somit doppelt erfasst. Schließt der Kunde nun seinen Einkauf ab, löst der Shop das Tracking-Pixel des Tracking-Providers aus – sofern er den Tracking-Container basierend auf der Cookie-Weiche von diesem nutzt. Dessen Cookie ist aber im Standard-Browser nicht mehr vorhanden (es wurde ja nur InApp ausgelöst) – sprich das Conversion-Tracking-Pixel von Facebook und auch alle anderen möglichen Tracking-Pixel in dem Tracking-Container werden nicht aufgerufen!
Szenario 2: Noch schlimmer – Kunde navigiert zunächst im shop
Stellen wir uns vor der Kunde, der die Anzeige angeklickt hat und InApp im Produktdetail landet springt nicht sofort raus. Er navigiert zunächst InApp innerhalb des Shops – er besucht z.B. ein Cross-Selling-Produkt oder führt eine Suche aus oder legt etwas in den Warenkorb und ruft diesen auf. Erst danach wählt er die Funktion “In Safari/Chrome öffnen”. In diesem Szenario gehen nämlich auch die UTM-Parameter verloren – diese hängen i.d.R. ja nur an der Landingpage-URL, werden aber nicht bei der weiteren Navigation mit übernommen. Ergebnis: Neben Facebook und dem Tracking-Provider verliert auch der Shop und GA die Herkunftsinformation des Users! In GA wird der Kunde also im Direct-Kanal erfasst (sofern GA keinen Referer im Fallback-Fall erkennen kann).
Aber wie oft kommt das vor?
Leider lässt sich nicht ermitteln wie groß das InApp-Problem ist. Ich konnte keine Angaben dazu finden wie viele User die Funktion “In Safari/Chrome öffnen” nutzen. Aber bei einer kleinen Befragung unter den everysize-Mitarbeitern und in meinem Bekanntenkreis nutzen diese Funktion überraschend viele. 9 von 20 gaben an, dass sie das “auch häufig” oder gar “immer” so machen. Sicherlich ist diese Zahl nicht repräsentativ – aber selbst wenn nur 10% der User aus den InApp-Browsern herausspringen, würde dies bedeuten, dass die Paid-Attribution um 10% abweicht!
Wie lässt sich das Problem lösen?
Leider gibt es weder zum Cross-Device- noch zum Cross-Browser-Problem eine einfache Lösung. Mit dem Cross-Device-Tracking gibt es basierend auf Logins zumindest einen Ansatz. Hierbei muss der User jeweils auf seinem Mobile- als auch Desktop-Gerät eingeloggt sein. Die bekanntesten Logins sind ohne Zweifel Google und Facebook – demnächst vermutlich auch Apple. Darüber hinaus gibt es sogenannte Login-Allianzen wie netID oder Verimi. Der Erfolg steht und fällt jedoch damit ob man es schafft, den Kunden dazu zu motivieren sich auf beiden Geräten einzuloggen.
Beim Cross-Browser-Problem ist es aber leider noch etwas komplizierter. Da jeder InApp-Browser einen eigenes Cookie-Storage besitzt, muss sich der User auch in jeder App innerhalb des InApp-Browsers erneut einloggen (allerdings nur einmal pro InApp-Browser). Es ist jedoch fraglich ob der User motiviert genug ist, dass auch dauerhaft zu tun – zumal InApp-Browser stets wie eine Art “temporärer Browser” wirken. Ich selbst gehe davon aus, dass das eher selten der Fall ist und wenn dann maximal für Facebook, Google und amazon. Eher springt der User aus der InApp raus und ab da ist die Wiedererkennung – ohne Login – schwierig bis unmöglich.
Bei meinen Tests stellte ich z.B. fest, dass InApp-Browser i.d.R. einen eigenen, leicht modifizierten User-Agent verwenden der auf die entsprechende App hinweist.
Bei Facebook ist dies beispielsweise:
Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_5 like Mac OS X) AppleWebKit/604.5.6 (KHTML, like Gecko) Mobile/15D60 [FBAN/FBIOS;FBAV/157.0.0.42.96;FBBV/90008621;FBDV/iPhone9,1;FBMD/iPhone;FBSN/iOS;FBSV/11.2.5;FBSS/2;FBCR/Verizon;FBID/phone;FBLC/en_US;FBOP/5;FBRV/0]
und bei Instagram:
Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_5 like Mac OS X) AppleWebKit/604.5.6 (KHTML, like Gecko) Mobile/15D60 Instagram 31.0.0.14.97 (iPhone9,1; iOS 11_2_5; en_US; en-US; scale=2.00; gamut=wide; 750×1334)
Damit (und wegen anderer Unterschiede in der Browser-Engine) ist auch ein Fingerprinting-Tracking nicht möglich – wer dies selber testen möchte kann die Seite amiunique.org einmal in seinem Standard-Browser und einmal in einem InApp-Browser aufrufen:
Somit fallen für die Attribution sowohl Cookies als auch Fingerprinting aus. Damit bliebe nur noch die IP, die aber zu Zeiten von Shared-IPs definitiv kein eindeutiges Identifikationsmerkmal darstellt und somit nicht für die Attribution geeignet ist.
Nachtrag: Abweichung größer als gedacht
Zwischen dem initialen Schreiben dieses Artikels und der Veröffentlichung liegen 4 Wochen. In dieser Zeit habe ich gemeinsam mit zwei everysize-Händlern versucht festzustellen wie viele Conversions durch das “Cross-Browser-Problem” verloren gehen. Da wir auf everysize einen sehr hohen Mobile-Anteil haben und uns verschiedener Paid-Kanäle bedienen, lag meine Schätzung bei 10-15% (sprich: Conversions die nicht everysize zugewiesen wurden, sondern im “Direct”-Kanal landeten).
Gemeinsam mit den Händlern führte ich daher verschiedene Abgleiche durch – anschließend rechneten wir das Ergebnis statistisch hoch. Das Ergebnis: 25 bzw. 30% der Conversions die durch den Kanal everysize zu Stande kamen, landeten in “Direct”!
Selbstverständlich ist mir bewusst, dass es sich nur um eine Hochrechnung handelt und die Werte nicht 100% korrekt sind. Es gibt schlicht zu viele Variablen die die Statistik beeinflussen (Touchpoints in der Customer-Journey, andere Faktoren die ein fehlerhaftes Tracking beeinflussen etc.). Dass InApp-Browser aber einen negativen Einfluss auf die Attribution haben, ist meiner Meinung nach unstrittig.