Markus Baersch

Am Anfang stand die harmlose Frage eines Kunden nach den Gründen dafür, warum die Absprungrate im Bericht “Alle Seiten” in Google Analytics für einzelne Seiten eine Absprungrate von über 100% - also z. B. 150%, 200% oder auch andere Werte - ausweist.

Schon aus Routine habe ich die üblichen “bekannten Gründe” abgeklopft und den verbleibenden Rest als Antwort gegeben: Es liegt an Sitzungen, die “eingeschlafen” sind und daher mit Events statt Seitenaufrufen neu anfangen. Das stimmt glücklicherweise auch. Aber wie genau ist der Ablauf, der zu diesem Effekt führt? Kann man das nachstellen - und so ggf. auch vermeiden? Wie ist mit solchen Zahlen umzugehen? Ich habe es mir genauer angesehen.

Das Problem: Über 100% Absprungrate

Die Abbildung eines realen Beispiels zeigt es: Mitunter sind die Absprungraten im Bericht unter “Verhalten - Websitecontent - Alle Seiten” offensichtlich falsch. Das zeigt sich spätestens dann, wenn man die gleiche Seite im Report zu “Landingpages” statt “Alle Seiten” untersucht: Dort sollte sich eine andere und vor allem glaubhaftere Zahl finden.

Da ein Absprung nur dann stattfinden kann, wenn man auf der gleichen Seite aussteigt, auf der man auch eingestiegen ist (und streng genommen auch keine Ereignisse sendet, die als Interaktion definiert sind, aber dazu weiter unten mehr), müssten die Zahlen in beiden Berichten bei gleichem Zeitraum eigentlich deckungsgleich sein. Das stimmt auch für die drei Einstiege auf der ersten Abbildung, auf denen die Absprungrate ja basieren muss. Nur ist eben die ausgewiesene Absprungrate im ersten Fall unsinnig hoch. Wie kann das passieren?

Übliche Erklärungen

Es gibt bei der Recherche nach Ursachen verschiedenste Aussagen. Die einen scheinen auf den ersten Blick schon unsinnig, andere aber hingegen erst einmal schlüssig. So schlüssig, dass ich beim Versuch des Nachstellens eine ganze Zeit auf dem Holzweg war 😉 Hier eine Übersicht, die alle auf der (richtigen) Annahme basieren, dass man einen Ausstieg messen muss, ohne den Einstieg mitbekommen zu haben.

• Filter: Wenn man den Anfang einer Session nicht in die Datenansicht bekommt, weil Filter im Spiel sind, bleibt nur der Absprung übrig und führt zu diesem Problem. Ob das stimmt? Ich kann es mir zwar vorstellen, aber nicht bestätigen, weil im konkreten Fall eine Rohdatenansicht ohne Filter die auffälligen Absprungraten aufwies und somit Filter als Grund ausgefallen sind. Wer es mal nachstellen möchte: Viel Spaß dabei 😉
• Beenden der Sitzung beim Tageswechsel: Auch das Überschreiten der Datumsgrenze kann eine Sitzung beenden und eine neue starten. Reicht das aber, um “vereinzelte Events” zu erzeugen, die zu diesem Effekt führen? Laut meiner Tests ist das nicht so. Solange die Sitzung nicht zwischendurch eingeschlafen ist, “verwaisen” auch die Events nicht auf die (unten beschriebene) erforderliche Weise.
• Initialisierung des Trackingcodes ohne Seitenaufruf: Angeblich soll das Initialisieren eines Trackers, der dann durch ein Opt Out oder aus sonstigen Gründen dann keine Daten senden darf, eine Sitzung ohne Hits erzeugen und auf magische Weise zu diesem Effekt führen. Dass Sitzungen entstehen, ohne dass Hits gesendet werden - nur durch die Initialisierung des Trackers von Analytics - ist freilich ein Märchen. Deshalb ist diese Erklärung barer Unsinn. Natürlich habe ich es aber dennoch getestet, weil es ja schnell geht 🙂
• Events, die vor dem Seitenaufruf gesendet werden: Das ist die häufigste Erklärung. Unterschiedlich genau formuliert besagt sie, dass Events dafür verantwortlich sind, die vor einem Seitenaufruf gesendet werden. Das stimmt auch, wie man unten sehen wird. Allerdings nicht auf die Weise, auf die es meistens gemeint ist: Wer zuerst Events und erst dann einen Seitenaufruf sendet, wird dieses Problem nicht forcieren können. Dabei ist es auch egal, ob es sich im Interactive Events oder Non-Interactive Events handelt. Für GTM-Nutzer: Es geht dabei um die Einstellung “Treffer ohne Interaktion” bei Event-Tags. Grundsätzlich ist es aber falsch anzunehmen, dass die Einbau- oder Tracking-Reihenfolge auf einer einzelnen Seite einen Einfluss auf die Absprungrate hat. Hier bleibt es dabei: Werden Interaktive Events und Seitenaufrufe gesendet, ist die Absprungrate 0. Egal in welcher Reihenfolge diese gesendet werden. Hier sei - auch wenn es dort in einem anderen Kontext und anderer Absicht getestet wurde - auf den Beitrag von Simo Ahava verwiesen, der dieses Reihenfolge-Thema explizit vermessen hat.

Aber Non-Interaction Events können unter den richtigen Umständen tatsächlich dafür sorgen, dass die oben gezeigten falschen Absprungraten entstehen. Sie müssen nur am Anfang einer Sitzung stehen und einer “andere Seite” gehören als der ersten echten Seite der Sitzung. Ich habe sie daher in meinen Tests und im folgenden Text “Rogue Events” getauft 😉 Hier das Ergebnis eines solchen Tests:

Wie kommt´s? Ursachen nachgestellt mit “Rogue Events”

Das erforderliche Szenario basiert darauf, dass Non-Interaction Events nicht nur vor einem Seitenaufruf stattfinden, sondern dies auch als allererstes Signal einer Sitzung schaffen.

Das ist z. B. dann der Fall, wenn mit Scrolltracking gearbeitet wird oder die Sichtbarkeit von Elementen genutzt wird, um Events zu versenden. Denn diese Messpunkte - korrekterweise als Non-Interaction Event gestaltet - können auch dann auftreten, wenn zwischendurch die Sitzung eingeschlafen ist.

Meint: Ein Besucher betritt Seite A, liest dort ein wenig herum und öffnet dann z. B. einen zweiten Tab, um seine Recherche dort fortzusetzen. Nach Ablauf der Sitzung (im Standard also nach 30 Minuten ohne Signal) kommt er zum Tab mit Seite A zurück, scrollt etwas nach unten, löst dabei ein Event aus und klickt dann irgendwo auf einen Link zu Seite B. Dort macht er nichts mehr, was einen Interaction Hit oder weiteren Seitenaufruf auslöst und ist damit abgesprungen. Als Schaubild sieht das in etwa so aus:

Und tatsächlich sorgt so ein Non-Interaction-Event von Seite A am Anfang der zweiten Sitzung dafür, dass Seite B eine Absprungrate von über 100% erhält. Zumindest im Report über “Alle Seiten” (und nur dort, siehe Handlungsempfehlungen unten). Der Ausstieg gehört also Seite B, während der Einstieg dem Event zugeordnet wird, welches aber keine Sitzung aufmachen kann. Damit geht der Einstieg für die nach dem Timeout gestartete Sitzung 2 "verloren".

Weitere Ergebnisse

Auf dem Weg zu dieser Antwort und einem nachvollziehbaren Szenario sind mir ein paar andere Dinge aufgefallen:

“Echte Absprünge” müssen vorhanden sein

Damit man die gewünschten Ergebnisse von mehr als 100% bei der Absprungrate in Reports sehen kann, müssen auch tatsächlich andere Absprünge stattgefunden haben, denn sonst zeigen sich die falschen Werte nicht. Sie verfälschen also nur bestehende Zahlen, können aber keine “eigenen” generieren.

Ich habe daher zur “Aktivierung” einzelner URLs, die ich in meinen Tests verwendet habe, Sitzungen generiert, die nur einen einzigen Seitenaufruf dieser URLs beinhaltet haben, um sie (mit dem Wert von 100% Absprungrate) in den Report zu bekommen. Es handelt sich bei allen Tests um virtuelle und eindeutige Adressen, die ich als Parameter bei Events und Seitenaufrufen übergeben habe, damit ich diese leichter den verschiedenen Tests zuordnen und wiederfinden kann. Jede verwendete URL wurde also in den abschließenden Tests mit einer Absprungrate von 100% “initialisiert”, nachdem ich diese Voraussetzung aus vorherigen Tests abgeleitet habe.

Fehler abhängig von der Anzahl echter Absprünge

Damit man also einen Wert von über 100% für Seite B aus dem o. a. Szenario sehen kann, muss diese Seite auch weitere “echte” Absprünge im Auswertungszeitraum aufweisen. Denn sonst sehen die Daten anders aus:

Das ist zwar auch ganz offenkundig falsch, denn wenn 100% der (1) Besucher ausgestiegen und auch alle (1) dort eingestiegen sind, müsste hier 100% und nicht 0% Absprungrate stehen. Erst nach einem weiteren “Absprunghit” ist das Ergebnis von 200% zu sehen, das weiter oben für eine andere Test-URL abgebildet ist.

Ebenso sinkt die Rate, wenn auch die Anzahl der sonstigen Absprünge ansteigt. So zeigt diese Abbildung das Ergebnis, wenn man einem “Absprung einer Seite B nach Event Seite A” nicht nur einen, sondern vier “Aktivierungsabsprünge” in separaten Sitzungen verpasst:

Wer also Werte über 200% sieht, hat eine Differenz von mehr als nur einem “falschen” Absprung durch Rogue Events als echte Absprünge gemessen. Die Zahl ist also auch nach oben “skalierbar”. Hier ein Beispiel mit mehreren (10)  Absprüngen mit Rogue Events und einem echten, so dass 1.100% Absprungrate entsteht:

Auch die “event-liefernde” Seite ist betroffen

Schaut man sich Absprungraten der Seiten an, auf denen die Events am Anfang einer neu aufgenommenen Sitzung ausgelöst wurden, so ist auch deren Absprungrate betroffen - nur eben in die andere Richtung.

Die Abbildung zeigt auf seine eigene Weise für “Seite A” (hier als “eventurl” zu sehen) ebenso unsinnige Zahlen wie für Seite B: Es gab nur einen Aufruf der Seite, ebenso einen Einstieg (der einzige Aufruf war also der Einstieg), angeblich 100% Ausstiege (letzte Spalte), aber nur 50% Absprungrate. Zauberei!

Mit weiteren Events kann man die Rate weiter verringern, ohne dass sich die Anzahl der Aufrufe oder Einstiege oder die Rate der Ausstiege ändert - nur die Absprungrate ist mehr oder weniger beliebig veränderbar.

Solche Hits zeigen zwar die erwarteten Spuren im Ereignis-Report, aber nur dort ist dann die URL zu finden, wenn es sonst keine Absprünge im Auswertungszeitraum für diese Seite gab.

Daraus kann und darf man schließen, dass man mit Sitzungen, die nur einzelne Non-Interaction Event-Hits einer Seite und sonst nichts enthalten, die Absprungrate in diesem Bericht künstlich nach unten “korrigieren” kann. Ausgleichende Gerechtigkeit, wenn man nicht wie hier diese Sitzungen künstlich erzeugt, denn so gleichen sich die falschen Werte in Summe für beide Seiten wenigstens wieder aus.

Absprungraten über 100% selbst erzeugen

Wer es nachstellen möchte, muss also eigentlich nur zwei Hits in einer Sitzung nacheinander absenden:

• Ein Non-Interaction-Event für eine Seite A und
• einen anschließenden Seitenaufruf für Seite B

Und dann nichts mehr. So entsteht ein Absprung für Seite B ohne einen “eigenen Einstieg” und deren Absprungrate steigt dann auch über 100%. Der Seite A fehlt hingegen der Ausstieg und die Rate sinkt dort.

Wie schon beschrieben, müssen aber sowohl Seite A als auch Seite B echte Absprünge im Auswertungszeitraum aufweisen, damit diese Werte “sichtbar” werden. Verwendet man also “erfundene” URLs, um die Ergebnisse einfacher finden zu können, müssen sowohl für Seite A als auch Seite B jeweils eine Sitzung mit nur einem einzelnen Aufruf der Seite generiert werden. Will man nur die zu hohe Absprungrate von Seite B “sichtbar machen”, reicht es, eine solche “Absprungsitzung” für Seite B zu generieren. Je mehr Sitzungen man mit den Sequenzen inkl. Rogue Events generiert, desto höher wird die Zahl. Sie sinkt hingegen mit der Anzahl der echten “Absprungsitzungen”.

Wie? Falsche Zahlen in Analytics? Ja!

Wie man nun unschwer nachvollziehen kann, stimmen die Zahlen ganz offensichtlich nicht. Selbst dann, wenn es einen gewissen “Ausgleich” zwischen den Absprungraten der Seiten A und B aus dem Beispiel gibt. Schließlich sollte so ein Non-Interaction-Event ohne einen Seitenaufruf davor oder dahinter kaum vorkommen. Ein Szenario wäre die oben angegebene Sequenz von Seitenaufruf, Timeout und dann nur noch ein Event, ohne dass eine weitere Seite aufgerufen wurde. Ein solcher Besuch würde nur die Absprungrate von Seite A verringern und mangels Seite B (weil ja nach dem Timeout keine Seite mehr aufgerufen wurde) keinen Ausgleich finden. Beide Fälle sind eher Ausnahmen und auf einen Timeout der Sitzung angewiesen.

Eine andere denkbare Möglichkeit für eine Verringerung der Rate bei einer Seite ohne passende Erhöhung bei einer anderen: Schließt ein Besucher nach einem Einstieg und Betrachtung einer einzelnen Seite nach mehr als 30 Minuten ohne sonstigen Messpunkt den Tab und es wird kurz vorher noch ein “Exit Intent” als Non-Interaction Event vermessen, ist dieser Messpunkt “allein” und verringert nur die Absprungrate der einzigen beteiligten Seite, ohne an anderer Stelle die Rate zu erhöhen.

So oder so gilt aber: Falsch, falsch, falsch. Alles, was an Absprungraten in diesem Bericht zu sehen ist, ist potentiell unrichtig, wenn Events vermessen werden. Genauer gesagt Non-Interaction-Events, die jederzeit auch nach einem Timeout auftreten können. Wie eben z. B. beim Scrolltracking.

Man weiß leider auch nicht, welche Seiten in welchem Umfang davon betroffen sind. Nur bei denen, wo die Rate über 100% liegt, ist der Fehler offensichtlich - aber auch andere Werte können wie gezeigt verfälscht worden sein. Es ist aber zu erwarten, dass der Großteil der Absprünge im echten Leben nicht unter diesem Problem leidet. Wenn man sich also auf Daten konzentriert, die eine angemessene Menge an Stichproben (in diesem Fall also Einstiege) enthalten, sollte der Fehler nur geringe Auswirkungen zeigen - falsche Entscheidungen sind demnach eher nicht zu erwarten.

Handlungsempfehlung

Prinzipiell ist es natürlich möglich, solche “Rogue Events” zu vermeiden, indem man z. B. den Zeitpunkt des zuletzt gesendeten Hits speichert (in einem Session Cookie, im localStorage oder sonstwo) und dann vor dem Senden von Non-Interaction-Events prüft, ob der letzte Hit schon zu lange her ist, um noch innerhalb der Sitzung zu sein. In diesem Fall sendet man den Hit dann nicht, was über einen blockierenden Trigger im GTM leicht umsetzbar ist.

Aber: Muss man das wirklich tun? Natürlich sind offensichtlich falsche Daten in Reports schlecht. Aber deshalb ist das verbaute Tracking nicht falsch, sondern diese Zahlen entstehen dadurch, dass es das Konstrukt der Sitzungen geben muss und die Interpretation der Hits durch Analytics in diesem Fall… naja… ungeschickt ist. Verzichten auf Event-Tracking oder Umstellen aller Events auf “Interaction” sind freilich keine Lösung. Auch das Verlängern der Sitzungsdauer würde das Problem bestenfalls verringern und dafür neue Herausforderungen bringen. Insofern: Wer hier unbedingt technisch ansetzen will oder muss, sollte auf die o. a. Lösung setzen und Event-Hits blockieren, wenn die Session “zu alt” ist. Wer dabei keine Cookies nutzen mag, kann im GTM auch die Zeitangaben aus dem dataLayer nutzen - im einfachsten Fall sendet man schon nach dem ersten Laden der Seite plus 30 Minuten keine Non-Interaction Events mehr raus (wenngleich das natürlich "zu früh" sein kann, weil je nach Trackingumfang noch deutlich spätere Hits nach dem Laden ausgelöst werden können). Es braucht für diese einfache Variante nur eine Berechnung der Zeit auf der Seite (in Sekunden) seit dem Laden des Tag Managers...

... und einen darauf basierenden Trigger, der nach 1800 Sekunden (bei Standardtimeout von 30 Minuten) genutzt wird, um Tags mit Non-Interactive Events zu blockieren.

Auch Rohdaten betroffen?

Für den Fall, dass das Problem nur in einer gefilterten Datenansicht auftritt, aber nicht in den Rohdaten, kann man sich natürlich auch mit der Gestaltung seiner Filter befassen und versuchen, eine Arbeitsdatenansicht zu generieren, die das Problem nicht mehr aufweist, falls Filter tatsächlich für das Abschneiden von Seitenaufrufen, aber ggf. nicht deren Events verantwortlich ist.

Mit passenden Reports und ausreichenden Datenmengen arbeiten

Besser ist es aber m. E., die Werte hier zu ignorieren (da wir sie nicht ausblenden können) und bei allem, was mit der Absprungrate auf Seitenebene zu tun hat - denn nur hier ist das Problem zu sehen - lieber mit dem Report der Landeseiten zu arbeiten. Auch andere Übersichten wie Akquisitionsberichte und weitere Reports, in denen nach anderen Dimensionen als Seiten gruppiert wird, entsteht das Problem nicht. Ich habe dazu erkennbare Einstiege mit einem eindeutigen Quellmedium wie beschrieben manipuliert und konnte in den Seiten eine zu hohe Absprungrate sehen, während dies in anderen Berichten (auch bei Verwendung eines Segments für dieses Quellmedium) nicht der Fall war, sondern die erwarteten 100% zu sehen waren.

Daher kann man dieses Phänomen auch behandeln, indem man dem Report über “Alle Seiten” eine sekundäre Dimension hinzufügt, so dass es für die betreffende Seite mehr als einen Eintrag in der Liste gibt. Fügt man also z. B. Browser, Quelle oder sonstige i. d. R. mit mehreren Werten belegte Dimensionen hinzu, werden die (neu berechneten) Werte mit dem Bericht zu Landingpages übereinstimmen.

Merke: Auch in diesen Fällen sollten aber genug Einstiege vorhanden sein, um aus der Absprungrate Rückschlüsse ziehen zu können. Wenn überhaupt, denn die Absprungrate ist auch ansonsten eine sehr fragile Metrik mit viel Spielraum für Fehlinterpretation Das gilt übrigens auch dann, wenn man gar keine Events misst, die das hier beschriebene Problem ermöglichen könnten 😉

Fazit

Ja - es ist doof, dass Google hier falsche Werte ausweist. Jetzt wissen wir aber wenigstens, wie genau das Problem entsteht und können schlauer mit den Daten umgehen. Wer wirklich ein größeres Problem bei den eigenen Daten feststellt und die Absprungrate nicht nur auf drei oder vier Einstiegen besteht, kann sich mit den oben angesprochenen blockierenden Triggern behelfen. Da eine Absprungrate auf Basis weniger Fallzahlen aber ohnehin nicht ernst genommen werden sollte und mit steigender Fallzahlen auch der Einfluss dieses eher exotischen und i. d. R. auf Timeouts basierenden Problems sinkt, können wir wohl weiter getrost mit Google Analytics arbeiten.