[outdated] Google Universal Analytics: Darum hast du mehr User als Sessions in deinen Reports12 min Lesezeit

Nagst du gerade an einem “komischen“ User/Session Verhalten in deinen Google Analytics Reports? Deine Nutzer-Zahlen sind höher als deine Sitzungen – obwohl das gar nicht möglich ist? >> Hier erfährst du, wie es zu diesem Problem kommt und wie du es blitzschnell behebst.

🛑✋ACHTUNG UPDATE: Am 1. Juli 2024 wurde Universal Analytics (GA3) vollständig durch das neue Google Analytics 4 (GA4) ersetzt. Alles zur neuen Version von Google Analytics findest du hier: >> Google Analytics 4

In Google Analytics 4 gibt es dieses Problem zum Glück nicht mehr. Zumindest nicht in der Form, wie es bei Universal Analytics der Fall war. 

Dieser Blogartikel ist daher veraltet. 

Wichtig💡: Wenn du im großen WWW nach Infos zu Google Analytics suchst, ist es wichtig zu überprüfen, um welche Version es sich handelt: Universal Analytics (=alt), Google Analytics 4 (=neu).

First Things First: User vs. Sessions vs. Pageviews

Ein typischer Report in Google Analytics sieht wie folgt aus, hier am Beispiel des Audience-Overview Reports unter Zielgruppe → Übersicht:

• Die Pageviews (1.247) sind kontinuierlich höher, als die Sessions (1.034).
• Die Sessions (1.034) sind kontinuierlich höher, als die User (905).

Soweit so richtig.

Warum? Dazu ist es wichtig zu verstehen, wie sich User, Sessions und Pageviews in Google Analytics definieren.

Ein User (aus GA-Sicht ein Browser, der eine bestimmte Client-ID hat und anhand eines Cookies wiedererkannt wird) kann eine oder mehrere Sitzungen initiieren, weswegen es immer mehr Sitzungen als User geben muss.

Hinweis: Für alle Details zu User, Sessions, Pageviews sei auf diesen Blogartikel verwiesen, da ich hier sonst (wieder einmal) den Rahmen sprenge.

Das Problem: Mehr User als Sitzungen in GA

Komisch ist es jetzt, wenn deine Google Analytics Reports plötzlich mehr User als Sitzungen anzeigen, wie in folgendem Screenshot der Fall:

Denn das ist theoretisch gar nicht möglich: Wie sollen 1.455 User nur 1.034 Sitzungen initiiert haben?

Gab es User ohne Sitzung? 🤔

Gab es User mit einer halben Sitzung? 😵

Wie kommt es zu diesem “komischen” Verhalten? 🤯

Die Ursache: ni-Events vor Pageviews

In der Regel kommt es zu mehr Nutzer als Sitzungen in deinen Google Analytics Berichten, wenn Non-Interaction Events VOR dem Pageview gefeuert werden: 

Häh?

Schauen wir uns das im Detail an:

RICHTIG: Wie das Tracking sein sollte

Kommt ein User auf deine Website, wird in der Regel zuallererst der Seitenaufruf (Pageview) = Hit ausgelöst.

Der Seitenaufruf initiiert die Sitzung (Session) – den Container, dem alle weiteren Interaktionen (Hits) dieses Users innerhalb einer bestimmten Zeit zugeordnet werden.

Jetzt das Komplexe: Alle Hits (Seitenaufrufe, Events, Transaktionen) innerhalb einer Sitzung werden zwar in der Sitzung zusammengefasst, allerdings wird die Sitzung selbst nur dem allerersten Hit zugeordnet – in der Regel und richtigerweise dem allerersten Pageview, der Landingpage.

Grund dafür ist, dass die Sitzung mit dem allerersten Hit erhöht wird.

Würde die Sitzung auch am zweiten Hit hängen, würde diese nochmal erhöht werden – was aber nicht gewünscht ist, weil sie ja nur einmal pro Sitzung hochgezählt werden soll.

Das ist die Definition der Sitzung!

Mehr Details gewünscht? >> Siehe hier: Seiten-Report ohne Sitzungen? Fehler – oder was ist hier der Grund?  

Ist der erste Hit also ein Pageview, ist alles okay: Dein Tracking ist korrekt – deine Reports sind korrekt! ✔️

FALSCH: Was deine GA Reports verfälscht

Manchmal passiert es allerdings, dass die erste Interaktion mit der Website ein Event ist (und kein Pageview!), weil

• das Event schneller lädt als der Pageview,
• das Event bewusst als erstes geschickt wird,
• die Sitzung abgelaufen ist, der User die Website aber noch nicht verlassen hat und das Weiter-Surfen durch ein Event z.B. Scrolling oder Button-Klick ausgelöst wird.

Das ist per se noch kein großes Problem, WENN es sich bei dem Event um ein Event mit Interaktion handelt.

Event-Exkurs: Ereignisse (Events) sind Nutzerinteraktionen die zusätzlich und unabhängig vom Ladevorgang deiner Website erfasst werden z.B. ein Button Klick. >> Alle Details zu Events.

Manchmal will man aber, dass ein Event nicht als Interaktion gewertet wird z.B. wenn der User auf eine Landingpage kommt, auf der automatisch ein Video abgespielt wird.

Das automatische Abspielen soll dabei nicht als Interaktion gewertet werden, da ja tatsächlich keine User-Interaktion stattgefunden hat.

Für solche Fälle gibt es den non-interaction Parameter: Mit diesem kannst du angeben ob Ereignisse MIT oder OHNE Interaktion an Google Analytics gesendet werden.

Standardmäßig ist der ni-Parameter “false” gesetzt, d.h. es findet eine Interaktion statt (EVENT MIT INTERAKTION).

Hinweis: >> Alles zum non-interaction Event-Parameter und was er bedeutet erfährst du hier.

Das Problem im Detail

Zum Problem wird es dann, wenn der non-interaction Parameter auf “true” gesetzt wird, d.h. es sich um ein EVENT OHNE INTERAKTION handelt.

Besteht eine Sitzung nämlich NUR aus Events ohne Interaktion (ni = true), wird die Sitzungs-Metrik in Google Analytics NICHT ERHÖHT.

Das ist auch korrekt so: Es wurde Google Analytics mitgeteilt, dass KEINE Interaktion stattgefunden hat.

Wichtig: Eine Sitzung wird natürlich trotzdem initiiert, da es ein Event gab und eine Interaktion nicht Sitzungslos in GA rumschwirren kann. Nur wird die Anzahl der Sitzung eben nicht erhöht…

Achtung: Die User-Metrik wird aber sehr wohl erhöht! Das macht auch Sinn, denn Google Analytics erkennt, dass ein User auf der Website ist und erhöht automatisch die Anzahl der User – unabhängig von der Session.

Theoretisch mag das alles auch total richtig sein – nur bringt es dir in der Analyse leider gar nichts, weil dadurch deine Reports nur verfälscht werden.

Mehr User als Sessions in Google Analytics ist einfach ein quatsch!

Du kannst deinen Daten nicht mehr vertrauen.

Beispiele: Wie kann das passieren?

Ausgezeichnete Frage! 🤓

Das Events vor Pageviews gefeuert werden, passiert meistens dann, wenn der User nur sehr kurz auf der Website verweilt (Bouncer) oder nur sehr wenige Interaktionen auslöst, die allesamt ni=true sind.

Ein Beispiel: Bouncer! Ein User kommt auf deine Website und verlässt diese sofort wieder, weil er sich verlaufen hat: Ein typischer Bouncer.

Der User löst dabei ein Scrollevent mit ni=true oder auch ein Video-Event mit ni=true aus.

Dieses Event wird VOR dem Pageview gefeuert, welches zu einer Session mit nur einem einzigen ni=true Event führt.

Die User werden erhöht – die Sessions jedoch nicht: Und schon hast du den 🥗.

Ein weiteres Beispiel: Drittanbieter Tools! Manchmal werden zur Kontrolle von Drittanbieter Tools Events an Google Analytics gesendet: Beim Laden der Website wird das Event ausgelöst, dass bewusst so früh wie möglich gefeuert wird – es dient ja zur Kontrolle.

Das Event wird bewusst auf ni=true gesetzt, damit die Bouncerate nicht in Mitleidenschaft gezogen wird: Das ist aus Kontroll-Sicht auch gut gemeint, führt allerdings zu genau diesem “komischen” User/Session Verhalten!

Das Event wird gefeuert – der User springt jedoch ab und hinterlässt eine Sitzung mit nur einem ni=true Event.

Die User werden erhöht – die Sessions jedoch nicht: Und schon hast du den 🥗.

Fazit und Tracking Tipp

Bewusst oder unbewusst: Events sollten am besten GAR NICHT vor dem Pageview gefeuert werden – egal ob mit oder ohne Interaktion, wobei Events ohne Interaktion definitiv das größere Problem sind und deine Google Analytics Reports ordentlich versauen.

Und was ist jetzt die Lösung?

🔽🔽🔽

Lösung #1: ni-Event Parameter auf “false” lassen

Wenn du den schnellsten, einfachsten und unkompliziertesten Weg gehen möchtest, kannst du den ni-Parameter aller deiner Events auf die Standardeinstellung = false setzen – hier am Beispiel GTM:

Damit verhinderst du jedenfalls, dass es Sitzungen OHNE INTERAKTION gibt und die Sache ist gegessen.

Vermutlich hat es aber einen Grund, dass du Events auf ni=true gesetzt hast und somit ist Lösung 2 die sauberste:

Lösung #2: Quellcode anpassen

Wird das Event bewusst vor dem Pageview gesendet, weil sich Entwickler ganz, ganz sicher sein wollen, dass das Event auslöst und in Google Analytics erfasst wird, gibt es zwei Möglichkeiten:

1) Siehe Lösung 1.

Vorteil: Geht schnell!

Nachteil: Aus GA-Sicht macht es eigentlich keinen Sinn, Events vor dem Pageview zu feuern, da die Sitzung am ja am ersten Hit hängt. >> Dazu hier mehr.

Daher ist die zweite Lösung die eigentlich richtige und einzig empfehlenswerte:

2) Das Event sollte bewusst verzögert werden, indem die Entwickler den Quellcode anpassen und Events, die als erstes in den dataLayer gepusht werden, NACH dem Pageview senden.

Einzige Herausforderung: Die betreffenden Events finden!

Am besten führst du dafür eine Analyse durch, indem du dir anschaust SEIT WANN du mehr User als Sessions in GA verzeichnest und herausfindest, was damals geändert wurde:

Tipp: Dabei hilft dir die GTM History, falls du den GTM verwendest. In dieser kannst du nachsehen, was zu der Zeit gepublished wurde.

Zweiter Tipp: Auch die Google Analytics Vermerke (Annotations) helfen dir dabei mögliche Fehler zu finden, wenn du Änderungen, etc. brav in GA notierst.

Lösung #3: Tag Sequencing via GTM

Meistens ist es so, dass Events unbewusst vor dem Pageview gefeuert werden.

Das liegt daran, dass JavaScript Code asynchron geladen wird, d.h. als Programmierer hast du kaum die Möglichkeit Einfluss auf die Reihenfolge der ausgeführten Tags zu nehmen.

Hinweis: Die technischen Details dazu findest du im Blog von Simo Ahava.

Es kann also sehr schnell und unbeabsichtigt passieren, dass Events vor dem Pageview ausgeführt werden.

Was also tun?

▶ Tag Sequencing über den Google Tag Manager!

Mit Tag Sequencing kannst du die Reihenfolge deiner Tags im GTM festlegen, d.h. bestimmen welcher Tag unmittelbar VOR oder NACH einem gewünschten Tag ausgelöst werden soll.

Ein Beispiel: Mit Tag Sequencing kannst du z.B. den Scrolltracking-Tag anweisen, auf jeden Fall erst NACH dem Pageview zu feuern:

Die Einstellung zu Tag Sequencing findest du in deinem GTM Container unter Tags:

Wähle einen Tag z.B. den Scrolltracking Event-Tag und klicke diesen an, sodass du in den Bearbeitungs-Modus gelangst:

Unter Erweiterte Einstellungen → Tag Reihenfolge kannst du das Tag-Sequencing aktivieren:

Fire a tag before UA – Event – Scrolltracking fires bedeutet, dass der ausgewählte Setup-Tag z.B. Pageview erst erfolgreich ausgeführt werden muss, BEVOR der Event-Tag feuern darf. Genau das wollen wir! ✔️

Hier kannst du auch auswählen / anhakeln, dass der Event-Tag GAR NICHT feuern soll, sollten beim Setup-Tag z.B. Pageview Probleme aufgetreten sein.

Mit dieser Einstellung verhinderst du, dass Sitzungen erfasst werden, die nur aus EINEM Event-Tag bestehen.

Fire a tag after UA – Event – Scrolltracking fires ist in diesem Fall nicht sinnvoll, da du damit einen Tag auswählen kannst, der unmittelbar nach dem Event-Tag feuern soll. >> Weitere Details in der Tag Manager Hilfe.

Immer noch mehr User als Sessions?

Schlecht!

Wenn du alle technische Hürden beseitigen konntest, bleibt nämlich leider nur noch eines übrig: Eingeschlafene User! 😴

D.h. User, bei denen die Sitzung zwar abgelaufen ist, welche die Website aber noch nicht verlassen haben und beim Weiter-Surfen ein Event z.B. Scrolling oder Button-Klick auslösen.

Das sollte aber in der Regel nicht sehr häufig vorkommen und daher nicht ins Gewicht fallen.

Ist das bei dir dennoch der Fall, könntest du dir überlegen, ob die Standard-Sitzungsdauer von 30 Minuten für dich ideal eingestellt ist: Möglicherweise bietest du Content oder Produkte an, mit denen sich User wesentlich länger als 30 Minuten auseinandersetzen z.B. beim Kauf von einem Auto, die Anmeldung zu einer Universität, sehr langen Videos, etc.

In diesen Fällen kann es Sinn machen, die Standard-Sitzungsdauer von 30 auf z.B. 45 oder 60 Minuten anzuheben und nach ein bis zwei Wochen zu überprüfen, ob es immer noch mehr User als Sessions gibt – und ob die Veränderung der Standard-Einstellung zu anderen Konsequenzen geführt hat.

Meistens ergeben sich dadurch aber nur Vorteile und deine Google Analytics Daten werden noch genauer, eben weil es für deinen Anwendungs-Fall Sinn macht.

Call to Action

Du hast immer noch mehr User als Sessions in deinen Reports?

Du hast eine Frage zum Artikel?

👉 Schreibe sie einfach in die Kommentare. Ich helfe, wo ich kann.

💡 Happy Analyzing,

Deine Michaela