Warum Scrolltracking selten der richtige Weg zur Antwort ist

Scrolltracking ist ein - leider - sehr beliebtes Feature. Nicht nur, aber auch in Google Analytics. Eine der "besten" Eigenschaften von Google Analytics ist es, dieses Event nur einmal bei 90 Prozent auszulösen und nicht in Zehn- oder 25-Prozent-Schritten.

Warum wollen wir überhaupt Scrolltracking? Dieser Beitrag befasst sich mit den typischen Fragen, die hinter dem Wunsch nach Scrolltracking stehen, den besseren Wegen zu Antworten und den Problemen, die damit zusammenhängen, wenn man diese Antworten dennoch in Scroll-Ereignissen sucht.

Warum Scrolltracking so beliebt ist

Vor jeder technischen Diskussion lohnt der Blick auf die eigentliche Frage: Was soll mit den Scrolldaten überhaupt beantwortet werden? In den meisten Fällen sind es Varianten dieser drei Themen:

• "Wird mein Inhalt überhaupt gesehen?" - die Sorge, dass der mühsam geschriebene Text nach drei Absätzen abgebrochen wird.
• "Wo brechen Leute ab?" - die Vorstellung, aus Scrollpunkten den "kritischen Bereich" einer Seite ableiten zu können, an dem das Interesse wegbricht.
• "Engagement messen" - die diffuse Hoffnung, dass tieferes Scrollen mit höherem Interesse korreliert und sich daraus eine Qualitätsaussage ableiten lässt.

Das sind alles nachvollziehbare Bedürfnisse. Sie haben nur wenig damit zu tun, wie weit jemand nach unten gescrollt hat - sondern damit, ob ein bestimmter Inhalt wirklich konsumiert oder ein bestimmtes Element wahrgenommen wurde. Diese Fragen lassen sich meistens deutlich besser mit anderen Mitteln beantworten als mit der reinen Scrollposition.

Warum genau 90%?

In Tools wie Matomo und Piwik PRO werden vorgegebene Scrollmarken gerne in 25er-Schritten gesetzt: 25%, 50%, 75%, 100%. Das fühlt sich nach Vollständigkeit an und passt gut in Reports. Mit Enhanced Measurement liefert GA4 hingegen genau ein scroll-Event pro Sitzung und Seite - bei 90%. Das ist zwar immer noch Tracking mit der Brechstange und auf allen Seitentypen, aber wenigstens sparsamer. Warum aber genau dieser Wert? Weil selbst Google davon ausgeht, dass die Marke "100% Sichtbarkeit" auf modernen Websites praktisch nicht mehr erreicht wird. Footer, Sticky-Header, Cookie-Banner, Newsletter-Boxen, "Verwandte Artikel"-Listen und WhatsApp-Buttons stehlen so viel Platz unten, dass das logische Ende des Inhalts oft schon bei 70-80% des scrollHeight liegt.

GA4 setzt also pragmatisch auf 90% als Näherung, weil man mit 100% kaum noch Daten bekäme. Das ist ehrlich - gleichzeitig aber die Bestätigung, dass Scrolltracking nicht das misst, was man eigentlich wissen will. Wenn der Wert "wir haben das Ende erreicht" so schwer zu fassen ist, dass selbst der Toolanbieter ihn als Schätzung ausliefert, ist die Aussagekraft des einzelnen Datenpunkts begrenzt.

Bessere Annäherung: Content Engagement

Wer wirklich wissen will, ob der eigene Inhalt konsumiert wurde, sollte nicht den Viewport vermessen, sondern den Hauptinhalt selbst. Praktisch heißt das: Der Container des eigentlichen Artikels (in der Regel über einen CSS-Selektor wie #main-content, article oder .entry-content ansprechbar) wird als Bezugspunkt definiert. Innerhalb dieses Containers werden unsichtbare Markerlinien per JavaScript eingefügt - z. B. alle 25% der Container-Höhe. Auf diese Markerlinien lässt sich anschließend ein Element-Sichtbarkeits-Trigger im Tag Manager ansetzen, der ein Event feuert, sobald der jeweilige Marker tatsächlich im Viewport landet.

Der Vorteil dieser Methode: Die Messung ist unabhängig von Theme, Footer-Höhe, Sticky-Elementen und Bildschirmgröße. Sie misst genau das, was sie messen soll - "wieviel vom Hauptinhalt war für den Besucher tatsächlich sichtbar?". Ein passendes Custom HTML Tag für GTM, das die Marker beim Laden in den Container einfügt, habe ich als Gist auf GitHub abgelegt. Bei dieser Methode werden zwar wieder Prozentschritte verwendet, aber hier bedeutet 50% tatsächlich "die Hälfte". Egal wie breit oder schmal der Viewport ist: Die Einheit des Hauptinhalts wird (von Werbung ggf. abgesehen) selten von Blöcken unterbrochen, die etwas mit der Breite des Browsers zu tun haben.

Noch aussagekräftiger wird die Auswertung, wenn man sie mit der geschätzten Lesezeit kombiniert. Die berechnet sich überschlägig aus der Wortanzahl im Container (ca. 300 Wörter pro Minute als "Scan-Geschwindigkeit" sind eine gute Annäherung). Auch dafür gibt es ein kleines Helfer-Snippet als JavaScript-Variable. Die Kombination "Marker bei 100% sichtbar und mindestens X Sekunden auf der Seite" beantwortet die ursprüngliche Frage ("wurde der Content wirklich konsumiert?") deutlich verlässlicher als jede Scrolltiefe. Man weiß immer noch nicht, ob wirklich gelesen wurde, aber es bestand wenigstens die faire Chance, wenn genug Zeit auf der Seite verbracht und bis zum sichtbaren Ende des Hauptinhalts gescrollt wurde.

Wer das ganze Konzept im Zusammenhang sehen will: Ich habe das in einem Workshop-Video einmal komplett durchgespielt. Das Beispiel ist noch in Universal Analytics gezeigt, das Konzept ist aber tool-agnostisch und funktioniert genauso mit GA4, Matomo, Piwik PRO oder allem anderen, was Events entgegennimmt.

Bitte nicht auf allen Seiten

Auch "schlauere" Lösungen wie diese sind selten auf allen Seiten einer Domain erforderlich. Es lohnt sich fast immer, einen Trigger - oder die Anbringung der unsichtbaren Content-Marker - auf bestimmte Seitentypen zu beschränken. Wo niemand wissen will, ob Content gelesen wird, muss man es nicht vermessen. Datenschutzhinweise und Impressum sind demnach nicht der richtige Platz. Ein Blog, ein Glossar oder Produkt- und Leistungsbeschreibungen schon. Ebenso Case Studies oder andere "Long Form" Inhalte, die eine Redaktion der Inhalte a) möglich und bei Erkenntnissen b) wahrscheinlich machen. Wie immer gilt: Insights, die nicht zu Optimierung führen können, sind bestenfalls interessant. Meistens aber eher eine Verschwendung von Zeit und Ressourcen.

Element-Sichtbarkeit für gezielte Fragen

Wenn die eigentliche Frage nicht "wurde der Text gelesen?" lautet, sondern "wurde dieses bestimmte Element wahrgenommen?", ist die Antwort noch direkter: Element-Sichtbarkeits-Trigger im GTM, gezielt auf den Selektor des Elements gesetzt - fertig. CTAs, Banner, Newsletter-Boxen, "Mehr lesen"-Bereiche oder ein eingebettetes Video - alles, was eine konkrete Funktion hat, lässt sich präzise messen. Das spart die Umleitung über Scrollpunkte und liefert eine belastbare Antwort auf die eigentliche Frage. Pro Element ein Trigger, pro Trigger ein Event - das skaliert besser, als zehn verschiedene Scrolltiefen abzugreifen und danach irgendwie zu interpretieren. Nicht umsonst gibt es dazu im Google Tag Manager (und anderen) vorgefertigte Trigger, die auch erlauben zu definieren, wie viel von einem Element in den Viewport kommen muss und / oder wie lange es sichtbar sein muss, um auszulösen. Auch walkerOS bietet durch Anbringen von data-elb-Attributen eingebaute Optionen zur Vermessung von Sichtbarkeit, ohne dass dazu spezieller Code erforderlich ist (siehe walkerOS Dokumentation).

Größte Schwäche: kurze Seiten

Eine spezifische Schwäche der klassischen Scrolltracking-Implementierung wird gerne übersehen: Auf kurzen Seiten sind 10%, 25%, manchmal sogar 50% schon beim Pageview sofort im sichtbaren Bereich - vor allem, aber nicht nur auf dem Desktop. Bei einem 600 Pixel hohen Inhalt und einem 900 Pixel hohen Viewport ist die ganze Seite sofort sichtbar - Scroll-Events feuern dann praktisch unmittelbar nach dem Pageview im Dauerfeuer, ohne dass jemals jemand wirklich gescrollt hätte. Über viele Pageviews hinweg explodiert das Hit-Volumen, ohne dass auch nur ein einziges nützliches Datum entsteht. Wer pro Pageview drei oder vier Scroll-Events pflegt, verdoppelt oder vervierfacht damit das Hit-Volumen seiner Property - mit Daten, die im besten Fall ignoriert und im schlechtesten Fall fehlinterpretiert werden. Wenn in Analytics mehr "scroll" als "page_view" zu sehen ist, hat man den Großteil seines Event-Volumens für eher nutzlose Messungen verschwendet. Leider kein untypisches Bild.

Kollateralschaden: Zombie-Sessions in GA4

Es kommt aber noch besser. In GA4 trägt ein scroll-Event - wie auch ein user_engagement oder bestimmte click-Events - potenziell einen neuen Sitzungsstart-Marker. Wenn ein solches Event nach Ablauf des Session-Timeouts versendet wird (z. B. durch einen Browser, der einen lange offenen Tab beim Schließen noch schnell die letzten Engagement-Events rauspustet), startet GA4 daraufhin eine völlig neue Sitzung. Scrollereignisse sind dabei auch möglich, selbst ohne dass die Seite wirklich "bewegt" wird, speziell bei mobilen Browsern. Die neue Session besteht dann aus genau einem Event, hat mangels Seitenaufruf keine Landingpage und gehört eigentlich zu einer längst beendeten Vorgänger-Session. Was dabei am Ende herauskommt, habe ich im Beitrag zu (not set)-Landingpages und Zombie-Sessions in GA4 ausführlich beschrieben.

Das Fiese daran: Scrolltracking erzeugt so nicht nur nutzloses Hit-Volumen - es trägt aktiv dazu bei, die Sitzungs-Statistik zu verfälschen. Mehr Sessions ohne Landingpage, mehr Sitzungen ohne erkennbares Engagement, dennoch kein echter Einfluss auf die Engagement-Quote in Google Analytics, weil diese auf solche Scroll Events gar nicht angewiesen ist. Wer auf ohnehin überschätzte Scrolldaten setzt und gleichzeitig versucht, in den GA4-Standardberichten ein sauberes Bild der Sitzungen zu bekommen, streut sich in gewisser Weise selbst Sand in die Augen.

Visuelle Fragen verdienen visuelle Antworten

Selbst wenn man sich entschließt, Scrolldaten trotz allem zu erheben: Die Auswertung in tabellarischer Form ist meistens frustrierend. Aus einer Liste von Events mit Werten wie "10", "25", "50", "75" und "90" macht man entweder einen mühsam zusammengeklickten Funnel in Looker Studio (BTW: Looker Studio heißt seit gestern wieder Data Studio. Kein Scherz!) oder eine Tabelle mit Anteilen, die ohne kontextuelles Wissen über die jeweilige Seite kaum zu interpretieren ist.

Die eigentliche Frage hinter Scrolltracking - "wo verlieren wir die Leute auf welcher Art von Seite?" - ist im Kern eine visuelle Frage. Und visuelle Fragen beantwortet man am besten mit visuellen Tools. Microsoft Clarity z. B. liefert aggregierte Scroll-Maps, Click-Maps und Attention-Maps direkt aus Session-Aufzeichnungen - ohne mühsame Interpretation einzelner Datenpunkte und mit der zusätzlichen Möglichkeit, sich konkrete Sessions im Zweifel auch im Original anzusehen, wenn etwas auffällt. Ich habe Clarity vor einigen Jahren in einem eigenen Beitrag vorgestellt - der ist zwar inzwischen in die Jahre gekommen, aber als Einstieg immer noch brauchbar. Das Tool ist seither nicht schlechter geworden, sondern gehört zu den Analytics Werkzeugen mit einer der höchsten Innovationsraten in den letzten zwei Jahren.

Empfehlungen

Wer das Thema Scrolltracking ernsthaft angehen will, findet bessere Antworten auf verschiedenen Wegen:

• Hauptcontent vermessen + Lesezeit prüfen: Die Kombination aus Element-Sichtbarkeits-Triggern auf Markerlinien im Hauptinhalt und einer Lesezeit-Variable ist die saubere Antwort auf "wurde der Content wirklich konsumiert?". Details und ein Beispiel im Workshop-Video.
• Element-Sichtbarkeit gezielt einsetzen: Für CTAs, Banner, Newsletter-Boxen und besondere Inhaltsblöcke ist der direkte Element-Sichtbarkeits-Trigger im GTM präziser, sparsamer und einfacher zu interpretieren als jedes Scroll-Event-Geflecht.
• Visuelle Tools für visuelle Fragen: Sobald die Frage in Richtung "wie sieht eine Seite eigentlich aus, wenn jemand sie benutzt?" geht, sind Heatmap- und Attention-Tools wie Clarity haushoch überlegen. Eine Map aus 1.000 zusammengeführten Sessions sagt mehr als jede Tabelle aus 50.000 Events.
• Tool-unabhängig: Alle drei Empfehlungen funktionieren genauso mit GA4, Piwik PRO, Matomo oder sonstwas. Es geht nicht um das Tracking-Tool, sondern um die Frage, was man vom Tool eigentlich erwartet.

Scrolltracking ist nicht böse. Es beantwortet nur fast nie die Frage, die wirklich gestellt wird - und im Fall von GA4 zahlt man für die Mühe gleich doppelt, weil die Events die Sitzungs-Statistik gleich miterledigen. Bevor das nächste Scroll-Event in den GTM einzieht, lohnt also der Blick auf die Frage dahinter: Will ich wissen, ob mein Content gelesen wird, ob ein bestimmtes Element gesehen wird... oder will ich wissen, wie eine Seite "lebt"? Das entscheidet, welches Werkzeug die richtige Antwort liefert. Plattes Scrolltracking über alle Seiten hinweg ist aber faktisch nie die richtige Wahl.