Schaut man in den Akquisitionsberichten in Google Analytics nach, wird man immer einen Anteil an Direct Traffic wiederfinden. Die Verteilung der Channels ist bei jeder Webseite anders, aber der Direct Traffic ist bei allen da:
Zu diesem Thema möchte in diesen Artikel auf folgende Punkte eingehen:
- Was wird alles als Direct Traffic von Google Analytics gezählt?
- Wie kann man die Datenqualität des Direct Traffics erhöhen?
- Warum geben Nutzer eine URL direkt in die Browser-Adresszeile ein?
Was wird alles als Direct Traffic von Google Analytics gezählt?
Grundsätzlich lässt Google Analytics alle Traffic-Quellen in Direct Traffic fließen, die unbekannt sind. Nimmt man die Bezeichnung “Direct Traffic” wortwörtlich so scheint es als ob hier nur Traffic reinfließt, wo Nutzer direkt auf die Seite gelangt sind – z.B. durch Eingabe der URL in die Adresszeile des Browsers. Oder der Nutzer ruft ein Bookmark auf und landet so auf die Webseite. Es gibt jedoch noch viele weitere Quellen, die in den Direct-Traffic-Bereich reinfließen, die auch die Interpretation dieses Channels schwierig machen. In folgenden Fällen fließen die Daten als Direct Traffic rein:
- Nutzer gibt URL direkt in die Adresszeile ein
- Nutzer ruft ein gespeichertes Bookmark auf und kommt auf die Seite
- Cross-Device-Aufrufe
- Nutzer gelangt von einer HTTPS- zu einer HTTP-Seite
- Nutzer kommt von Unterseite A zu Unterseite B, wobei auf Unterseite B der Google Analytics Tracking-Code fehlt
- Bei komplizierten Weiterleitungen wie JavaScript-basierten Weiterleitungen oder Weiterleitungsketten können Referrer-Informationen verloren gehen
- Nutzer ruft ein PDF auf und klickt dort auf einen Link, um auf die Webseite zu gelangen
- Traffic aus Dark Social
- Sprung von Offline zu Online
- Die Cookie-Consent-Lösung verliert die Traffic-Quelle bei Bestätigung seitens dem Nutzer
- Fehlerhafte UTM-Parameter
- Einsatz von URL-Shortener
- Fake-Traffic
- Traffic über Backlinks, wobei diese das Attribut “noreferrer” enthalten.
Bevor jedoch Google Analytics den Traffic in den Direct-Topf wirft, werden mehrere Schritte zur Identifikation der Traffic-Quellen durchlaufen:
- Sind die Parameter gclid oder gclsrc gesetzt?
- Ist der Parameter campaignSource gesetzt?
- Sind UTM-Parameter gesetzt?
- Gibt es einen documentReferrer?
- Kampagnendaten für Client- oder User-ID vorhanden?
Wenn alles mit “Nein” beantwortet wird, fließt der Traffic als Direct rein. Eine ausführliche und visuelle Beschreibung dieses Prozesses gibt es hier.
Wie kann man die Datenqualität des Direct Traffics erhöhen?
Die ersten zwei Punkte von oben – Direkteingabe der URL in die Adresszeile sowie Bookmarkaufrufe – sind klassische Szenarien für Direct Traffic. Problematisch für die Datenqualität können die restlichen Punkte sein, die wir uns nun im Detail näher anschauen.
Cross-Device-Aufrufe
Ein klassisches Szenario heutzutage: Der Nutzer liegt vor dem Fernseher, sieht eine Werbung und ruft über sein Handy die Domain auf (Direct). Später ruft er die Domain nochmal über Desktop auf (Direct) und kauft was. Will man hier eine bessere Zuordnung erreichen, sollte man sich Gedanken über ein Cross-Device-Tracking machen.
Nutzer gelangt von einer HTTPS- zu einer HTTP-Seite
Kommt ein Nutzer von einer HTTPS- auf eine HTTP-Seite, werden keine Referrer-Daten übertragen. Dadurch fließt der Traffic in Direct rein. Aufgrund der Datenverschlüsselung ist dies ein normales Verhalten. Auf der anderen Seite werden Referrer-Daten übertragen bei Wechsel von HTTP zu HTTP, HTTPS zu HTTPS und bei HTTP zu HTTPS.
Lösung: Auf HTTPS umstellen. Dadurch werden Referrer-Daten übertragen und der Traffic taucht wieder als “Referral Traffic” auf.
Beachten sollte man hier, dass dies nicht nur die eigenen Daten betrifft. Läuft die eigene Seite auf HTTPS und verlinkt man auf eine HTTP-Seite, so läuft bei der HTTP-Seite der Traffic in Direct rein. Um das zu verhindern (z.B. für Werbezwecke oder bei Partnerwebseiten) kann man den Meta Referrer Tag einsetzen:
<meta name="referrer" content="origin">
Damit wird die Domain inkl. Protokoll und Port als Referrer gesendet. Den Meta Referrer Tag beschreibe ich nochmal im Detail in einem eigenen Beitrag.
Nutzer kommt von Unterseite A zu Unterseite B, wobei auf Unterseite B der Google Analytics Tracking-Code fehlt
Gehen wir vom folgenden Szenario aus:
- Nutzer landet auf einer Seite ohne Tracking-Code
- Nutzer klickt auf einen internen Link
- Nutzer gelangt auf eine Seite mit Tracking-Code
Im ersten Schritt werden keine Analytics-Daten aufgrund des fehlenden Tracking-Codes gesammelt. Klickt der Nutzer auf einen internen Link und gelangt dann auf eine Unterseite der gleichen Domain mit Tracking-Code ist der 2. Seitenaufruf für Google Analytics der 1. Seitenaufruf. Das heißt, dass der Referrer als Self-Referral in Google Analytics eingeht (da der Nutzer von der gleichen Domain kommt). Da aber die eigene Domain standardmäßig in den Google Analytics Einstellungen in der Verweis-Ausschlussliste eingetragen ist, fließt der Traffic in Direct rein.
Tracking-Codes können aus unterschiedlichen Gründen fehlen. Oft kommt dies vor, wenn eine Landingpage auf Basis eines eigenen Templates, welches unabhängig vom Rest der Seite ist, erstellt wurde. Wenn vergessen wird, den Tracking-Code mitzuübernehmen, kann das genannte Problem auftreten. Aus diesem Grund sollte man immer wieder die Webseite dahingehend prüfen.
Bei komplizierten Weiterleitungen wie JavaScript-basierten Weiterleitungen oder Weiterleitungsketten können Referrer-Informationen verloren gehen
Server-seitige Redirects wie 301 sind in Ordnung. Meta-Refreshes, JavaScript-Weiterleitungen und Weiterleitungsketten können dazu führen, dass Referrer-Informationen verloren gehen und nicht korrekt in Google Analytics einfließen. Daher sollte man immer wieder einen Blick auf die Weiterleitungen werfen. Vor allem nach mehreren Relaunches und vielen Backlinks sollte man darauf achten, dass man Weiterleitungsketten wieder löst und direkt auf die Zielseite leitet.
Nutzer ruft ein PDF auf und klickt dort auf einen Link, um auf die Webseite zu gelangen
Ruft ein Nutzer eins eurer PDFs auf und klickt dort auf einen internen Links, so werden keine Referrer-Informationen an Google Analytics übergeben. In diesem Fall landet der Traffic ebenfalls in den Direct-Topf. Für Nicht-HTML-Dokumente wie PDFs oder Word-Dateien sollte man UTM-Parameter einsetzen, um den Traffic identifizieren zu können.
Traffic aus Dark Social
Ein großes Problem für die Webanalyse ist zudem der Traffic aus dem Dark Social-Bereich. Damit ist der Traffic gemeint, der über private Kanäle wie Whatsapp, Viber, etc. generiert wird. Heutzutage findet das Teilen von Inhalten vermehrt auf diesen Kanälen statt. Es gibt auch schon Tools, die sich darauf spezialisiert haben. Um hier aus Google Analytics-Sicht entgegenzuwirken sollte man auch hier bei Kampagnen mit UTM-Parameter arbeiten, um den Traffic besser abzubilden.
Sprung von Offline zu Online
Sehen die Nutzer Offline eine Plakatwerbung und rufen die Webseite auf, so ist dieser (korrekterweise) ein Direct-Aufruf. Um auch Offline-Kampagnen richtig zuzuordnen, können Offline z.B. andere, kürzere Domains verwendet werden, die auf die eigentliche Domain oder URL inkl. UTM-Parameter weiterleiten. Dadurch ist die Herkunft besser erkennbar.
Warum geben Nutzer eine URL direkt in die Browser-Adresszeile ein?
Würden wir davon ausgehen, dass der Direct Traffic in Google Analytics tatsächlich nur der Traffic ist, der durch die Eingabe der URL in die Browser-Adresszeile generiert wird, dann stellt sich die Frage warum Nutzer eine URL direkt aufrufen? Die Beantwortung dieser Frage hilft für eine besseres Verständnis des “echten” Direct Traffics. Gründe könnten sein:
- Markenbekanntheit: Die Domain oder URL ist bei Nutzern aufgrund der Bekanntheit der Marke bekannt.
- Mundpropaganda: Die Domain wurde weiterempfohlen, wodurch der Empfänger der Empfehlung die URL direkt aufruft.
- Bestandskunden und -nutzer: Bestehende Kunden und Nutzer kennen die Domain und rufen diese direkt auf.
- Eigene Leute: Mitarbeiter, Freunde, Bekannte, etc. rufen die Domain direkt auf, um sich Informationen zu holen.
