Wie man Google Discover Traffic in Google Analytics trackt

Was genau ist eigentlich Google Discover?

Wer bisher noch nicht mit Discover in Kontakt gekommen ist, für den hier einmal kurz eine Zusammenfassung: Auf Google Discover werden individuell für den Nutzer personalisierte Webinhalte angeteasert. Es findet sich in der Google App, beim „Nach rechts“-Wischen auf dem Android Home Screen oder auf dem Startbildschirm der Chrome App. In den meisten Fällen sind das Beiträge von Online Magazinen / Online Zeitungen – es gibt jedoch auch Fälle, wo Inhalte, Online Shops oder andere Websites im Discover Feed entdeckt wurden.

Google Discover ist also eine Sammlung von Zusatzinhalten auf den Google App Startseiten, die sonst nur das Google Suchfeld (oder Lesezeichen) enthalten.

Im erweiterten Kreis könnte man noch die Google News App zählen, da auch hier ohne aktives Suchen Artikel bereits vorgeschlagen werden und auch die News App wohl ausschließlich geöffnet wird, um Nachrichteninhalte zu konsumieren. Im weiteren Verlauf des Artikels werden wir Google News jedoch vernachlässigen.

Google App mit Discover (die Blitz-Icons zeigen AMP Seiten an)

Chrome App mit Discover (hier gab es zur Aufnahme dieses Screens kein AMP Blitz Icon, mittlerweile gibt es wieder Blitz Icons)

Google News App mit Artikeln

Wie wird Discover Traffic standardmäßig in Analytics getrackt?

Wo man in Analytics standardmäßig den ganzen Discovertraffic findet, ist gar nicht so einfach zu sagen.

Wenn Sie hauptsächlich über AMP Seiten Discover Traffic bekommen, wird sich der Traffic hauptsächlich auf google/organic und ein wenig auf googleapis/referral verteilen – bei einem Beispiel hatten wir  für einen Artikel 85% google/organic aus der Google App und 15% googleapis/referral von Chrome.

Wenn Sie jedoch kein AMP benutzen, dann sehen Sie den Google App Traffic zu einem großen Teil als direct / (none), zu einem Teil verteilt über alle Medien (organic, cpc, referral, social usw.) und den Chrome Traffic weiter unter googleapis/referral. Wenn Sie sowohl AMP als auch Nicht-AMP Seiten in Discover haben, vermischt es sich logischerweise.

Der Grund für dieses Verhalten sind die unterschiedlichen Referrer Informationen, die in verschiedenen Szenarien von Discover Traffic übergeben werden. Dies wird in der ausführlichen Version dieses Abschnitts detaillierter beschrieben.

Ausführlich: Wie wird Discover Traffic standardmäßig in Analytics getrackt?
Klickt man auf einen Artikel bei Google Discover, öffnet sich die entsprechende Website und somit auch (sofern vorhanden) das Google Analytics Tracking. Aber welchem Kanal ordnet Analytics das zu? Es gibt auf die Frage: „In welchem Kanal ist der Discover Traffic?“ drei Antworten im Netz:

1. Es ist alles organischer Traffic mit Quelle „Google“
2. Man findet es zusammen mit dem direkten Traffic und kann zwischen „echtem“ direkten Traffic und Discover nicht unterscheiden.
3. Unter Referral mit der Quelle googleapis.com

Man könnte sagen: alle drei Antworten stimmen. Traffic über Google Discover kann unter verschiedenen Voraussetzungen in all diese Kanäle laufen. Es kommt dabei vor allem darauf an, über welche App der Traffic entsteht und ob es eine AMP Seite ist oder nicht.

Es gibt verschiedene Arten von Discover Traffic.

Discover Traffic kann im groben vier verschiedene Ausprägungen haben. Traffic über die Google App auf AMP Seiten, Traffic über die Google App auf „Nicht-AMP“ /“normale“ Seiten, Traffic über die Chrome App auf AMP Seiten und auf Nicht-AMP Seiten. Entsprechend gibt es drei verschiedene Szenarien, wohin der Traffic in Analytics getrackt wird.

Szenario 1: AMP + Google App

Traffic auf AMP Seiten über die Google App wird standardmäßig in google / organic gespeichert. In der Referrer Information, die der Browser an Analytics weitergibt, steht „https://www.google.com“. Man beachte, dass das Slash (/) am Ende fehlt, was bei sämtlichen anderen Referrern von Google vorhanden ist (Google Suche und Co.). Wir können den Traffic aktuell nur anhand dieses Merkmals vom restlichen organischen Traffic trennen.

Szenario 2: Chrome App

Traffic über die Chrome App wird – egal ob auf AMP Seite oder normaler Seite – in googleapis/referral gespeichert und befindet sich somit im Verweistraffic. Hier können wir über eine Channelgruppierung googleapis.com zu einem Discover Channel hinzufügen.

Szenario 3: „Normale“ Websites + Google App

Traffic auf Nicht-AMP Seiten über die Google App wird als direkter Traffic gewertet. Es wird aber ein Referrer an Google Analytics übertragen. Jedoch passiert dann etwas merkwürdiges. Als Referrer übergibt der Browser bzw. die Google App an Analytics „android-app://com.google.android.googlequicksearchbox/https/www.google.com“.  Mit dem „android-app“ anstatt „https“ oder „http“ kommt Google Analytics überhaupt nicht zurecht. Als Verweis kommt es noch korrekt in Analytics an, aber die Zuordnung zu Quelle und Medium funktioniert gar nicht. Beim Abspeichern der Sitzung speichert Analytics dann keine Quelle, kein Medium und keinen Verweis. Damit ist die Sitzung direkt.

Ist der Traffic aus Szenario 3 jetzt komplett im direkten Kanal? Nein: aufgrund der Analytics Attributionslogik wird direkter Traffic dem letzten indirekten Kanal zugewiesen. Das bedeutet, sollte ein Besucher schon einmal über Google/cpc auf der Seite gewesen sein, wird auch der Discover Click eine Google / cpc Sitzung. Neue Nutzer  bzw. Nutzer ohne indirekte Quelle werden dagegen dem direkten Traffic zugeordnet. Das macht es unmöglich, in einem Standard-Setup exakt zu sagen, ob und und wieviel Discover Traffic in Analytics einfließt.

Bitte nochmal ausführlich!

Discover Traffic über einen Kampagnenquellen Filter sichtbar machen?

Valentin Pletzer hat sich bereits sehr intensiv mit dem Thema beschäftigt und einen Filter für Analytics entwickelt, der Discover Traffic separiert. Der Filter funktioniert soweit sehr gut, ist aber in seiner Art sehr radikal. Bitte benutzen Sie den Filter daher nur in einer separaten (Test)-Datenansicht, wenn Sie ihn ausprobieren möchten.

In der ausführlichen Version dieses Abschnittes erkläre ich seine Lösung genauer und erläutere meine Bedenken an diesem Verfahren.

Ausführlich: Discover Traffic über einen Kampagnenquellen Filter sichtbar machen? Zur Untersuchung, wie Discover Traffic in Google Analytics getrackt wird, konnte ich im Netz bis heute (Januar 2020) nur einen guten Artikel finden. Valentin Pletzer hat die Referrer ausgiebig analysiert und schlägt einen Filter für die Google Analytics Datenansicht vor, der die Kampagnenquelle aus dem Verweisfeld herausextrahiert, dabei zwischen „mit Slash am Ende“ und „ohne Slash am Ende“ unterscheidet und die Domain aus dem „android-app-Protokoll“ Traffic herauszieht, bevor Google Analytics „verwirrt“ wird.

Mit dem Kampagnenquellen Filter können wir die Discoverquellen so sehen, wie sie an Analytics geschickt werden. Der Google.com Traffic ohne Slash am Ende ist von dem „normalen“ Google Traffic getrennt und wir sehen auch „com.google.android.googlequicksearchbox“ als Quelle. Dieser Filter funktioniert zwar, hat allerdings mehrere größere Nachteile, die man abwägen sollte, bevor man ihn einbaut:

1. Er verändert nur die Kampagnenquelle und nicht das Medium bzw. die Kanalzuordnung

Die veränderten Kampagnenquellen bewirken, dass unter „Quelle / Medium“ dann „com.google.android.googlequicksearchbox / (none)“ sehr häufig zu finden ist. Aber auch „com.google.android.googlequicksearchbox / organic“, „com.google.android.googlequicksearchbox / cpc“ oder „com.google.android.googlequicksearchbox / referral“ sind möglich. So richtig sauber ist der Filter allein also nicht ganz.

2. Er verändert nicht nur Discover Traffic, sondern den gesamten Traffic

Der Filter soll nur den Discover Traffic sichtbar machen, er verändert aber alle Quellen. Und das ist sehr problematisch. Zum Beispiel wird die automatische Quellengruppierung in Analytics verhindert und aus Quelle „Google“ werden „google.de“, „google.com“, „google.at“ usw.

Außerdem wird die Kampagnenquelle auch gesetzt bei Domains, die eigentlich in der Verweisausschlussliste stehen und man könnte dann in E-Commerce Shops Traffic mit Quelle / Medium „paypal.com / (none)“ bzw. „paypal.com / organic“ erhalten. Saubere Daten sehen anders aus.

Außerdem wird dann auch z.B. zwischen „paypal.com“ und „www.paypal.com“ unterschieden – die Kardinalität im Quelle/Medium Bericht leidet also deutlich.

Daher sagt Valentin selbst in seinem Artikel, dass man den Filter nur auf eine Extra-Datenansicht anwenden sollte.

3. Ich mag diese Kampagnen-Filter nicht 🙂

Zugegeben kein objektives Argument: Ich habe persönlich noch keine guten Erfahrungen mit Kampagnen-Filtern gemacht, die Quelle oder Medium umgeschrieben haben.

Früher war das die Best Practice, um Suchmaschinen wie Ecosia und Duckduckgo auf Medium „organic“ zu schreiben, aber ich bekam in allen Anwendungen die Sitzungen auf „duckduckgo / referral“ nie ganz weg. Kurios ist, dass die Duckduckgo Umsätze in den meisten Fällen auf „referral“ liefen. Den Fehler daran konnte ich nie finden. Ich habe von den Kampagnen-Filtern daher eher Abstand genommen – zumindest solange bis ich dieses Kuriosum verstanden habe (Wer es weiß, möge mich aufklären).

Valentins Lösung noch einmal ausführlich

In welchem Kanal/Quelle/Medium sollte man Discover Traffic erfassen?

Sollte Discover Traffic nun organisch, direkt oder referral sein?

Die für mich plausibelste Antwort ist, dass zumindest in der Ansicht / Auswertung, mit der man in der Webanalyse arbeitet, Discover als eigenständiger Kanal neben Organic Search, Verweistraffic, PPC und Co. stehen sollte, WENN hinreichend viel Traffic über Discover auf die Seite kommt. Bei Seiten ohne Discover Traffic würde ich aber zumindest die Voraussetzung schaffen, dass man prinzipiell erkennen kann, ob Discover Traffic auftritt. Da ich kein Freund davon bin, die Dimension „Medium“ mit neuen Werten zu bespielen, würde ich den Discover Traffic wahrscheinlich eher als „referral“ eingliedern und über die Quelle einen eindeutigen Wert vergeben, den ich dann im Channel-Grouping nutzen kann.

Das ist nur meine Einschätzung und kann in Ihrem Setup natürlich komplett anders gehandhabt werden.

Lösungsvorschlag für Seiten ohne AMP: Custom Task im Tag Manager

Seitdem es den Custom Task im Tag Manager gibt, hat er sich zur Allzweckwaffe für Eingriffe ins Analytics Tracking entwickelt. Es liegt daher nah, uns auch in diesem Case die Referrer passend zu scripten, bevor sie an Analytics gesendet werden. Damit ist ein Filter in Analytics gar nicht nötig und die Daten kommen in allen Datenansichten gleich an. Wir können also anders als bei der Lösung mit dem Kampagnenquellen Filter unsere Masteransicht für die Analyse weiter nutzen.

Custom Task für Websites ohne AMP

function() {
  //Converter für Android-App-Referrer by Thomas Langnau
  //Referrer als Integrierte Variable aktivieren und hier auslesen
  var r = {{Referrer}};
  return function(model) {
  //Protokoll für android app Referrer
  var appsrch = "android-app://"
  //Referrer mit Suchmuster vergleichen
  if (r.startsWith(appsrch)) {
    //ersetze android-app durch https
    var newref= r.replace("android-app://","https://android.")
    // neuen Referrer setzen
     model.set('referrer', newref);
  }
 }
}

Dieser Code funktioniert ganz einfach: er tauscht das „android-app“-Protokoll, das Analytics nicht versteht, durch ein https-Protokoll aus. Dazu setzt es künstlich eine „android.“ Subdomain, damit wir den Traffic in Analytics später wiederfinden, falls die Domain gleich einer Webdomain ist, von der wir ebenfalls Traffic bekommen.

Mehr Informationen zu Custom Task und wie man ihn einbaut gibt es bei Simo Ahava.

Damit wirkt sich dieser Filter nicht nur auf Google Discover aus, sondern auf sämtlichen Traffic, der von Android Apps zu unserer Website kommt und einen „android-app“-Referrer übergibt.

Folgende neue Android-App-Referrer-Quellen habe ich so bisher in Google Analytics „neu“ entdeckt:

• de.idealo.android
• com.google.android.gm
• org.telegram.messenger
• m.facebook.com
• com.twitter.android
• com.noinnion.android.greader.readerpro
• com.Slack
• com.xing.android
• org.fox.ttrss

Will man die Funktion nur auf Google Discover Traffic beschränken und die anderen Apps im direkten Traffic belassen, kann man die Zeile <<var appsrch = „android-app://“>> ersetzen durch <<var appsrch = „android-app://com.google.android.googlequicksearchbox“>>. Damit funktioniert das Skript nur für den Discover Referrer der Google App.

Lösungsvorschlag für Seiten mit AMP #1: Eintrag in die Quellen der organischen Suche

Die Liste der „Quellen der organischen Suche“ hat in den meisten Fällen den Nutzen, dass man zusätzliche kleinere Suchmaschinen eintragen kann. Jedoch gibt es noch einen weiteren Nutzen. Man kann mit der Liste die automatische Gruppierung der Quelle „google“ aufsplitten und z.B. zwischen „google.de“ und „google.com“ unterscheiden.

In diesem Fall wollen wir zwischen „www.google.com“ und „www.google.com/“ unterscheiden. Dafür müssen wir das Feld „Pfad enthält“ mit „/“ füllen, um die Abfrage nach einem Pfad zu tätigen. Die Einträge sollten so aussehen:

1.Eintrag

Name der Suchmaschine: google

Domainname enthält: www.google.

Suchparameter: q

Pfad enthält: /

2.Eintrag

Name der Suchmaschine: Google ohne Slash

Domainname enthält: www.google.com

Suchparameter: q

Pfad enthält:

Essentiell wichtig ist die Reihenfolge – denn nur in der hier aufgeführten Order funktioniert es.

Ergebnis ist, dass der Traffic aufgeteilt wird in „Google / organic“ und „Google Discover / organic“. Mit Anpassung der Standard Channelgruppierung kann man dann noch den Chrome-Discover Traffic zu einer Discover Gruppe hinzufügen.

Update Juni 2020: Das Problem bei dieser Lösung:

Wir können den Traffic von Google mit und ohne Slash mit diesem Verfahren aufsplitten. Es zeigte sich jedoch, das Traffic auf AMP Seiten auch aus der „normalen“ Suche aus der Google App heraus mit Google ohne Slash getrackt werden. Somit ist der Traffic der Quelle „Google ohne Slash“ eher eine Mischung aus Discover und Suchtraffic der Google App. Zudem wissen wir nicht genau, ob nicht noch weitere Technologien zu einem Traffic ohne Slash führen.

Lösungsvorschlag für Seiten mit AMP #2: Referrer in einer Dimension

Achtung: folgenden Vorschlag habe ich bisher noch nicht Live testen können. Daher kann ich nicht versprechen, dass er reibungslos funktioniert. 

Bei AMP Seiten kann man keinen Custom Task in das Analytics Tracking einbauen – zumindest nicht via Google Tag Manager AMP Container. Auch ein eigenes Javascript ist in einem AMP-Container nicht möglich, genau wie das manuelle Umbauen des Referrers oder von utm-Parametern in der URL.

Die einzige Möglichkeit, die uns im Tag Manager bei AMP Seiten bleibt, ist das Setzen einer benutzerdefinierten Dimension. Wir können also den Referrer in eine Dimension schreiben.

Im Google Analytics Pageview setzt man die ausgewählte benutzerdefinierte Dimension mit dem Document Referrer. So kann man später in Analytics filtern auf die AMP Discover Quellen „https://www.google.com“ (OHNE Slash am Ende) und auf „https://www.googleapis.com/“. Die Dimension sollte in Google Analytics mit dem Umfang „Sitzung“ angelegt werden.

Leider ist es mit dieser Methodik nicht möglich, ein Channelgrouping in Google Analytics direkt zu konfigurieren. Die finale Gruppierung müsste also in einem Datenvisualisierungstool oder über Datenexporte errechnet werden. Für AMP Websites bietet es sich an, im Web-Container trotzdem den Custom Task einzubauen, damit auch der Nicht-AMP Traffic gefiltert werden kann. Im Vergleich zu einem Kampagnenfilter bietet dies immerhin noch den Vorteil, dass man weiter in seiner Master-Datenansicht arbeiten kann.

Fazit 1: Discover Traffic ist ein Traffic-Biest, das man zähmen kann?

Für Nachrichtenportale kann Discover ein unglaublich starker Traffic-Bringer sein. Für die Webanalyse-Tools ist Discover Traffic aber nicht so einfach zu greifen. Hier sollte man die verschiedenen Arten von Discover Traffic zuerst isolieren und dann in einem Channelgrouping gruppieren. Das gilt nicht nur für Google Analytics, sondern für jedes andere Webanalyse Tool genauso. Für Google Analytics können Sie den hier beschriebenen Custom Task gerne nutzen.

Wer keine Nachrichten oder Artikel publiziert, kann selbst überlegen, ob es sinnvoll ist, Discover in seine Channelgruppierung aufzunehmen. Man hat zumindest schon von Produktseiten im Discover-Feed gehört. Spätestens, wenn in der Search Console der Menüpunkt „Discover“ auftaucht, sollte man es in Erwägung ziehen. Bei AMP Seiten ist die aktuelle Trackingsituation jedoch recht schwierig, da wir Discover nicht zu 100% vom Google Organic Traffic lösen können.

Fazit 2: Ein möglicher Bug in Analytics, der in jedes Setup gehört?

Traffic aus Android Apps haben einen Referrer und Google Analytics erkennt den nicht? Bitte was? Es war schon seit langem eine der Erklärungen für direkten Traffic, dass Klicks aus Apps im direkten Traffic zu finden sind. Nun kann man das zumindest für Android Apps ändern. iOS Apps hingegen bleiben weiterhin unsichtbar, weil sie keinen Referrer übergeben.

Man kann also über den Custom Task (auch ohne Discover Traffic) einen Teil des direkten Traffics wieder sichtbar machen, der bisher im direkten Kanal verschwindet. Und das ist doch für jeden Webanalysten ein erstrebenswertes Ziel 🙂

Zusätzliche Anmerkungen

Im Sommer 2019 kam bei einer Google Analytics Schulung bei einem Nachrichtenportal die Frage auf, warum auf einzelne Artikel mehrere Tausend direkte Sitzungen stattfinden.
Nach einem kurzen Blick in Analytics konnte ich erst einmal nur feststellen, dass es kein Bot-Traffic / Spam Traffic sein sollte. Als dann der Search Console – Zugriff kam, konnte ich in den Discover Berichten sehen, dass ein paar Artikel vergleichbar hohe Klick-Zahlen in Discover hatten. Die drei stärksten Artikel hatten am gleichen Tag genau so viele direkte Sitzungen wie Discover Clicks (+-10%). Damit war die Sache vorerst geklärt und Discover als direkter Kanal angesehen. Im August sprachen Jens Fauldraht und Stefan Keil in ihrem Podcast „SEO House“ über Discover und dass es ja in Google Analytics im organischen Traffic zu finden sei. Nach einer Rückfrage, ob sich die beiden sicher seien, wurde in der nächsten Episode noch mal bekräftigt, dass es organisch getrackt wird und ich auf den besprochenen Artikel von Valentin Pletzer verwiesen. Dieser Artikel ist auch nach längerer Recherche zum Thema Tracking von Discover der derzeit einzige wirklich gute Artikel. Valentin schlägt ein Verfahren vor mit einem Filter, der die Kampagnenquelle neu setzt. Da aber Informationen zu AMP bei ihm etwas kurz kamen und mein Forschergeist geweckt war, habe ich mir das Thema selbst noch mal vorgenommen. Später konnte ich mit Valentin selbst noch einmal über das Thema schreiben und seine Sicht auf das Thema erfahren.

Zusatz 1: Die Geschichte hinter diesem Artikel

Zusatz 2: Wie ich Google Discover Traffic untersucht habe

Da ich kein gelernter Programmierer bin, kann ich nur wie ein Webanalyst den Traffic untersuchen – nämlich Handy zücken, nachstellen, Traffic simulieren und testen.

Um zu sehen, welche Quelle in Analytics getrackt wird, schaut man sich normalerweise den Google Analytics Hit in den Devtools oder einer Debug-Plugin an und kann sehen, welcher Document Referrer im Parameter „dr“ des Analytics Collect Requests übergeben wird. In den Google Analytics live Berichten sieht man dann, in welchem Kanal der Traffic jeweils in der Datenquelle zugeordnet wird.

Bei der Analyse von Discover Traffic gab es 2 Herausforderungen zu lösen: Einmal ist die Website des Kunden gar nicht oder nur selten in meinem Discover Feed. Zum anderen gibt es auf dem Handy keine Devtools oder Debug-Plugins, mit denen eine Analyse des Analytics Hits möglich wäre.

Das Problem mit den fehlenden Devtools konnte gelöst werden, da es bei Chrome eine Möglichkeit gibt, Handy mit PC zu verbinden und dann per USB Debugging die Devtools der Handytabs auf dem Desktop zu sehen. So sieht man den Hit, der an Google Analytics gesendet wird. Wer das auch machen will, der findet hier eine Beschreibung, wie man USB Debugging für Chrome einrichtet.

Da die Website des eigenen Kunden nicht in meinem Discover Feed voller Top-News, NFL und Nerd-News zu finden war, konnte ich zuerst nicht wie gewohnt debuggen, sondern musste die Google Analytics Hits der Seiten in meinem Feed nehmen und die Tracking ID (UA-12345678) tauschen, um den Traffic zu sehen. Nach einigen Tagen hatte ich aber dann auch einen Artikel vom Kunden im Feed, sodass ich ausschließen konnte, dass es nur an dieser einen Seite bzw. diesem einen Analytics Account liegt.