Markus Baersch

So sperrig, wie der Titel es vermuten lässt, ist das Thema diesmal wirklich. Mir ist aufgefallen, dass ich die Anleitung zur Messung eines Teils der vielzitierten "User Signals" aus "Sicht" der Google Suchergebnisse bisher noch nicht verbloggt habe, sondern diese nur in Form der Session - Folien zur CAMPIXX 2018 (ab Folie 31) zu haben ist. Da hier die fehlende Tonspur eine eigene Umsetzung nicht wirklich einfach macht, liefere ich diese hier für alle nach, die das erweiterte Rezept zur Messung der SERP Bounce Time von Simo Ahava selbst implementieren wollen. 

Unterschiede zum "Original"

Generell stimmt sowohl der Code als auch der Implementierungsansatz weitestgehend mit dem o. a. Blogbeitrag überein. Auch hier wird also die History des Browsers genutzt, um über einen künstlich erzeugten Eintrag beim Eingang aus den Google Suchergebnissen einen Messpunkt zu setzen (URL der Zielseite mit Anker "#gref"). Anders als beim Original sollen aber alle Besuche vermessen werden; unabhängig von deren "Besuchstiefe".

Während die Ursprungs-Lösung also nur Besucher erfasst, die nach Ansicht der ersten Seite direkt wieder zu den Suchergebnissen zurückkehren, soll hier auch nach dem Aufruf weiterer Seiten eine Messung der Gesamtzeit erfolgen. Außerdem wird über Events beim Eintritt aus den SERPs - und ggf. erfolgenden späteren Austritt per "Zurück"-Taste zu den Suchergebnissen - die Messung der SERP-Rücksprungrate (SERP Bounce Rate / SERP Return Rate / wie auch immer) ermöglicht. Dazu dienen Hilfs-Ziele auf Basis der Events und ein benutzerdefinierter Messwert.

Umsetzung im Google Tag Manager

Für eine Messung werden insgesamt 5 integrierte und 5 eigene Variablen, 3 Tags und 3 Trigger benötigt. Klingt nach viel Arbeit - lohnt sich aber 😉

Variablen

Folgende im GTM integrierte Variablen werden benötigt und müssen ggf. aktiviert werden, wenn diese bisher nicht im Einsatz sind (die ersten beiden sind aber üblicherweise schon aktiv):

• Page URL
• Event
• History Source
• New History Fragment
• Old History Fragment

Diese können im GTM unter "Variablen - Integrierte Variablen - Konfigurieren" per Klick aktiviert werden. Zusätzlich werden folgende Benutzerdefinierte Variablen benötigt:

• Eine Datenschichtvariable für Serp Ein- und Austritte, die als "serpTrckEvent" vom Script-Tag (siehe unten) in den dataLayer geschrieben werden. Hier im Beispiel heißt diese Variable {{serpTrckEvent}}
  
• Eine Datenschichtvariable für den standardmäßig im dataLayer zu findenden "GTM Start". Hier: {{dlGtmStart}}
  
• Eine Datenschichtvariable für das Ende des Besuchs, wenn ein Rücksprung zu den SERPs erfolgt. Auch diese Angabe wird vom Script als "timeToSerp" in die Datenschicht geschrieben.  Hier: {{dlSrpReturnTime}
  
• Damit die Besuchsdauer auch über die erste Seite hinaus gemessen werden kann, ist die Messung gegen einen "Eintrittszeitstempel" statt des GTM-Initialisierungszeitpunkts wie im Orgiginalscript erforderlich. Dazu muss der Zeitstempel als Session Cookie (oder auch per localStorage) gesichert werden. Hier dient dazu eine Cookie-Variable für Serp-Eintritt {{cSrpEnter}}.
  

Der Wert dafür wird wiederum im zentralen Script-Tag gesetzt; als Fallback bleibt der GTM-Startzeitstempel der ersten aufgerufenen Seite.

Trigger erzeugen

Die drei Trigger, die für die danach folgenden Tags benötigt werden, können danach angelegt werden.

• Der erste Trigger entspricht der Original-Lösung. Über einen Verlaufsänderungstrigger histChangePopstate wird später das zentrale "Mess-Script" angestoßen.
  
• Das Script löst via dataLayer ein Event "enterFromSerp" aus, wenn ein Eintritt erfolgt. Damit dadurch ein Event ausgelöst werden kann, wird der Trigger serpEnterTrigger  benötigt.
  
• Passend dazu gibt es auch einen auf das dataLayer-Event horchenden "returnToSerp" Trigger für den "Ausgang" zurück zu den Suchergebnissen, wenn dieser denn erfolgt. Hierüber kann wiederum ein Event ausgelöst und - wie in der Originallösung - die Messung der Besuchsdauer ausgelöst werden. Dazu dient der Trigger serpReturnTrigger .
  
  Um zu verhindern, dass durch die Messung des Ausgangs ggf. eine neue Sitzung erzeugt wird (was die Messung ohnehin sinnlos machen würde), wird hier als Bedingung zusätzlich angegeben, dass die gemessene Verweildauer nicht größer ist als 30 Minuten (1800000 Sekunden). Dieser Wert ist ggf. anzupassen, wenn man mit einer anderen Sessiondauer arbeitet.

Tags anlegen

Nach dieser Vorbereitung können nun die Tags angelegt werden, die die Messung der Events und des Timings übernehmen.

• Zur Erfassung der Ein- und Austritte dient ein Analytics-Tag vom Typ "Ereignis".
  
  Als Kategorie wurde hier "SerpEvents" gewählt, die Aktion stammt aus der zuvor angelegten Variable {{serpTrckEvent}}, die entweder einen Ein- oder Austritt verzeichnet. Folgerichtig ist dieses Tag dann zu feuern, wenn ein Ein- oder Ausgang erfolgt. Dazu werden also sowohl der serpEnterTrigger  als auch der serpReturnTrigger  als Auslöser zugeordnet. Damit die Zielseite direkt den Events zugeordnet ist, kann das Label mit der entsprechenden integrierten Variable für deren URL belegt werden.
• Zusätzlich soll bei einer Rückkehr zu den SERPs eine Messung der vergangenen Zeit seit dem Eintritt erfolgen. Mit dem serpReturnTrigger kann also ein weiteres Analytics-Tag ausgelöst werden, diesmal vom Typ "Timing".
  
  Als Variable dient hier wiederum die URL der Seite, um deren Timings in den Berichten in Analytics ablesen zu können. Die Kategorie kann beliebig benannt werden, besser als das "Bounce2Serp" aus der Abbildung ist vielleicht "Return2Serp" - Geschmachssache. Wichtig ist der Wert aus der Variablen dlSrpReturnTime, die zuvor angelegt wurde.
• Ganz zum Schluss folgt das Herzstück der ganzen Übung, ein Benutzerdefiniertes HTML-Tag, in dem das zentrale Script ausgespielt wird. Dieses besteht aus einem ergänzten Script der Originallösung und erledigt mehrere Aufgaben: Es markiert den Eingang in der History, speichert die Eingangszeit in einem Cookie, feuert das Eingangsevent und ggf. auch ein Ausgangsevent für die Erzeugung der Messpunkte in Analytics und bestimmt zuvor die Verweildauer, um sie in den dataLayer zu schreiben.
  
  Das Script als Inhalt des HTML-Tags kann per Copy & Paste unter bit.ly/bouncetracker übernommen werden. Als Trigger dienen sowohl der Standardtrigger "All Pages" oder "Alle Seitenaufrufe" als auch der zuvor angelegte Trigger histChangePopstate, so dass es bei jedem Seitenaufruf und jedem Klick auf die Zurück-Taste des Browsers ausgelöst werden kann.

Damit ist die Vorbereitung im Tag Manager abgeschlossen. Ich verzichte hier mal angesichts der Länge des Beitrags auf die ausführlichere Hinweise zur Wichtigkeit von Vorschau und Testing. Trotzdem ist es wichtig 😉

Report zur Besuchsdauer in Google Analytics

Als erstes Ergebnis können nun die gemessenen Timings der Dauer aller Besuche, der bei Google angefangen haben und wieder durch Rückkehr dorthin beendet wurden, auf Seitenebene in Google Analytics betrachtet werden. Dazu findet sich ein Eintrag zur gewünschten Kategorie (also hier: "Bounce2Serp") unter "Verhalten - Websitegeschwindigkeit - Nutzer-Timings". Klickt man diesen an, erhält man eine Auflistung der gemessenen Zeiten nach Seiten.

Hier Ausreißer identifizieren, Segmente bilden und die gemessenen Werte mit den eigenen Erwartungen abzugleichen, ist zwar nicht ganz trivial, kann aber in Kombination mit den Daten zu Keywords auf Seitenebene aus der Google Search Console durchaus zu Erkenntnissen führen, die in realen Verbesserungen des Contents münden... was die ganze Übung tatsächlich mit einem tieferen Zweck versieht.

Ziele anlegen

Um nun auch etwas Sinnvolles aus den gemessenen Events aller Ein- und Austritten zu machen, werden für beide Events jeweils Ziele angelegt. Diese basieren auf den Events der im obigen Tag verwendeten Kategorie "serpEvents". Die jeweilige Aktion der Ein- und Ausgänge lautet entsprechend "enter" bzw. "exit". Mit diesen Zielen kann nun unter "Verwaltung - Datenansicht - Berechnete Messwerte" eine neue Metrik angelegt werden, die die "SERP Bounce Rate" anhand der gerade angelegten Ziele (hier: "Serp Ausgang" und "Serp Eingang" benannt) errechnet.

Diesen Messwert kann man nun in einem benutzerdefinierten Report mit passenden Standardmesswerten kombiniert werden. Hier ein Beispiel, in dem die Ziele und die daraus resultierende Absprungrate zu sehen sind:

Ein solcher Report steht unter goo.gl/brQA2u als Benutzerdefinierter Bericht zum Import bereit; mit Sicherheit müssen aber die dort zumindest die Slots der verwendeten Ziele angepasst werden.

Was tun mit den Zahlen?

Auch hier gilt: Die Auswertung der Daten ist ähnlich wie bei den gemessenen Zeiten zur Verweildauer i. d. R. nur dann sinnvoll, wenn der konkrete Seitentyp und die traffic-bringenden Keywords mit in die Betrachtung aufgenommen werden. Pauschale Aussagen wie "alles unter 30 Sekunden Verweildauer oder mit mehr als xx Prozent Serp Bounce Rate ist schlecht für SEO" sind auf keinen Fall das Ziel dieser umfangreichen Messung.

Vielmehr geht es - wie so oft - darum, sich auf Seiten mit möglichst viel Impact zu konzentrieren und dort unter Berücksichtigung des o. a. Kontext die gemessenen Zahlen zu hinterfragen. Hat man z. B. einen recht umfangreichen Beitrag zu einem konkreten Problem geschrieben, passen die Suchanfragen zur dort beschriebenen Lösung und steigen die Besucher dennoch in Scharen und schnell wieder aus, indem sie zu Google zurückkehren, kann man dies nun besser erfassen, als es vorher anhand der Standard-Absprungrate und Verweildauer möglich ist.

Nützlich wird es aber nur, wenn man dies für konkrete Veränderungen nutzt. Und da man keine Ahnung hat, was vor dem Besuch passiert ist und wie das Verhalten nach der Rückkehr zu den SERPs ausfällt, kann man damit auch nur wenig SEO-Zauber veranstalten. Dieses Wissen bleibt Google vorenthalten... und allen Plugin-Herstellern, die uns allen beim Verwenden der Suche täglich über die Schulter schauen 😉