Markus Baersch

Berichte zu Seitenaufrufen in GA4 zeigen per Standard Seitentitel als Dimension statt der aus dem Vorgänger bekannten URLs bzw. Seitenpfade. Das hat verschiedene Vorteile und Auswirkungen und viele Anwender stellen den Standardbericht in GA4 um, damit wieder Pfade (mit oder ohne Parameter) zu sehen sind.

Ist das eigentlich die beste Option? Und welche Folgen hat es, wenn künftig mit Titeln statt Pfaden gearbeitet wird?

Warum überhaupt Seitentitel nutzen?

Schon in Universal und den Vorversionen konnte man als primäre Dimension den Seitentitel statt des Pfades verwenden. Je nach Struktur einer Website oder der Gestaltung der URLs ist das gelegentlich der einzige Weg, um bestimmte Seiten wiederzufinden. Produktdetailseiten anhand des Produktnamens im Titel statt einer ID in der URL zu identifizieren, fällt in solchen Szenarien leichter.

Evtl. lassen sich mit Hilfe des Titels sogar einzelne Seitentypen identifizieren, ohne dass es eine passende Gruppierung nach Content gibt. Suchergebnisse, Kategorieseiten, Seiten des Checkouts oder Fehlerseiten beinhalten oft eindeutige Kennungen im Titel, die eine Gruppierung oder Filterung vereinfachen.

Ein großer Unterschied liegt in der Tatsache, dass der Seitentitel nicht so anfällig ist gegen Fragmentierung von Daten zur gleichen Seite auf Basis unterschiedlicher URL Parameter sind. Nicht nur, aber vor allem externe Identifier wie die fbclid von Meta, Affiliate-Ids u. A. sorgen normalerweise dafür, dass eine Seite unter mehreren URLs in Berichten zu finden ist. Üblicherweise konzentriert sich eine Analyse von vollständigen URLs oder Pfaden inkl. Parametern auf die “normale” und dominierende Version, so dass der Rest nicht in's Gewicht fällt. Dass es je nach Fragestellung ein Problem werden kann, wenn z. B. sämtlicher aus Facebook stammender Traffic ignoriert wird, ist sicher leicht nachvollziehbar.

Hier sieht man ein Beispiel aus den GA4 Daten des Google Merchandise Store, bei dem für einen Seitentitel in einer gefilterten Liste alle entsprechenden URLs zu sehen sind.

In diesem Fall sind es verschiedene Parameter in gleichen Pfaden des ewig gleichen Artikels. Es finden sich weitere Beispiele von Titeln in diesen Daten, deren zugehörige URLs vollkommen unterschiedlich sind, weil diese z. B. aus der Suche heraus anders verlinkt sind als in der Navigation oder in verschiedenen Kategorien angeboten werden.

Durch die Nutzung von Titeln statt URLs umgeht man in GA4 dieses Problem. Schaut man in den Bericht unter “Berichte -> Engagement -> Seiten und Bildschirme”, werden die Metriken nach Titeln gruppiert dargestellt.

Umstellen auf “Seitenpfad” nicht immer sinnvoll

Die Ansicht kann zwar umgestellt werden, so dass hier stattdessen der Seitenpfad zu sehen ist, aber das ist nur dann eine Lösung, wenn es keine Parameter gibt, die relevant für den Inhalt sind. Meint: eine Pfad wie /index.php?id=12345 in der Adresse einer bestimmten Seite würde mit allen anderen IDs in diesem Report unter /index.php zusammengefasst. Eine Ansicht inkl. Parametern ist ebenso herzustellen (siehe unten), aber nicht in den normalen Vorgaben auswählbar. Das mag damit zusammenhängen, dass es in GA4 (nach akt. Stand) keine Optionen zum Ausschluss oder Filtern von URL Parametern gibt.

Während man in Standardberichten also mit Titeln oder reinen Pfaden arbeiten wird, kann spätestens im “Erkunden”-Bereich statt des reinen Pfads auch der “Pfad und Abfragestring” als Dimension genutzt werden.

Feind der Konsolidierung per Titel: Sprachvarianten und Übersetzung im Browser

Die Überschrift sagt im Prinzip schon alles aus: Ein Seitentitel muss nicht immer eindeutig sein. Geht es z. B. um ein Produkt in einem mehrsprachigen Shop, kann es durchaus sein, dass dieser unter einer “sprachneutralen” URL im Browser aufgerufen werden kann, obschon die “canonical” URL der Variante anders lautet und eine Kennung für die Sprache beinhaltet.

Viel wahrscheinlicher ist es, dass die Website von Besuchern im Browser in deren Muttersprache übersetzt wird. Internationale Zielgruppen begünstigen dies zwar, sind aber keine Voraussetzung - auch auf kleineren und einen Sprachraum konzentrierten Websites kommt dies vor. Ist die Menge der so entstehenden unterschiedlichen Titel zu groß oder die Verteilung z, B, auf DE und EN so groß, dass ein nennenswerter Anteil potenziell ignoriert wird, ist der Titel nicht immer die optimale Lösung. Das entsprechende Beispiel aus dem Merchandise Store zeigt die verschiedenen Titel der gleichen Seite / URL:

Was nutzen?

Die Antwort auf die Frage, welche Variante - spätestens in individuellen Berichten - besser ist und wie man die Standardberichte in GA4 konfigurieren sollte, hängt vom Grad der Fragmentierung beider Optionen ab. In einem Google Data Studio Dashboard ist schnell zu ermitteln, wie nach aktuellem Stand die Verteilung von Titeln auf unterschiedliche Pfade und der Pfade / URLs auf Titel aussieht. Hier ist eine entsprechende Vorlage zu finden. Darin steckt keine Rocket Science - der Report ist mit wenigen Klicks auch selbst erstellt.

Sind Seitentitel aus o. a. Grund nicht ideal, können reine Pfade als Standard-Dimension dienen…solange nicht einige Parameter für das Erkennen des Inhalts erforderlich sind und man daher mit dem Pfad allein nicht arbeiten kann. Werden Parameter benötigt, kann man die passende Dimension für Berichte selbst aktivieren.

Reports umstellen

Sind Pfade ohne Parameter eindeutig genug für die Identifizierung von Seiten, möchte man diese Ansicht ggf. zum Normalzustand für den o. a. Bericht zu “Seiten und Bildschirmen” machen. Auch für den Fall, dass auf Parameter nicht verzichtet werden kann und Titel nicht den eigenen Wünschen entsprechen, ist eine Anpassung der Standardansicht oder die Erstellung einer Report-Variante möglich.

Klickt man dazu oben rechts auf das Stift-Symbol (“Bericht anpassen”), wird ein - wenngleich sehr eingeschränkter - Editor eingeblendet. Neben der individuellen Zusammenstellung der Info-Karten kann oben über “Abmessungen” (ja, toll übersetzt) die Standard-Dimension auf den “Seitenpfad und Bildschirmnamen” umgestellt werden. Möchte man lieber eine Ansicht inkl. Parametern, fügt man die Dimension “Seitenname und Abfragestring” vorher hinzu und macht diese dann zum neuen Standard (über das Drei-Punkte-Menü beim Eintrag).

Beim Speichern (über einen Klick auf - nochmal “Seufz” - “Wird gespeichert…”) kann gewählt werden, den Standardbericht anzupassen oder einen neuen Report anzulegen, der dann über die “Mediathek” in das Menü aufgenommen werden kann.

Den Titel zur eindeutigen Kennung machen

Damit Titel nicht unter dem Problem der Übersetzung im Browser “leiden”, gibt es nur eine vernünftige Option: Die Konservierung des Ursprungstitels einer Seite im dataLayer oder einer anderen Variable, um diese Fassung dann im Tracking zu nutzen statt der zum Zeitpunkt des Trackings ggf. durch Übersetzung veränderten Version.

Titel per Script in dataLayer sichern

Da die Übersetzung einer Seite im Browser wie Chrome und anderen typischerweise erst dann startet, wenn die Seite “fertig” ist, kann an beliebiger Stelle im Quellcode eine Konservierung erfolgen. Ob dies also weit oben im Quelltext passiert oder ganz am Ende ist irrelevant, solange man es nicht in einem asynchron nachgeladenen Script versucht, wie es beim Tag Manager der Fall ist, denn da ist es meistens schon zu spät.

Im einfachsten Fall passt man also z. B. den Integrationscode des Tag Managers an und erledigt die Aufgabe des “Konservierens” direkt dort. Oder bei der Initialisierung des dataLayers - wie auch immer.  Wird der dataLayer verwendet, ist es sinnvoll, ein Event beizufügen, so dass man dieses ggf. in Triggern nutzen kann… vor allem dann, wenn der Push erst relativ spät stattfindet und die Gefahr besteht, sonst auf eine noch nicht belegte dataLayer Variable im Tag Manager zuzugreifen. Das kann z. B. so aussehen:

Im Fall von WordPress bietet es sich als Alternative an, ohnehin bestehende Plugins zu nutzen, die der Anreicherung der Datenschicht dienen. Ein zurecht oft genutztes Plugin ist GTM4WP. Hier kann die Ausgabe des “Post title” einfach aktiviert werden.

Kleiner Schönheitsfehler: Die Ausgabe entspricht nicht unbedingt dem, was das Theme daraus als tatsächlichen Titel macht. Die folgende Abbildung zeigt den dataLayer mit dem Titel, wie er…

• von GTM4WP eingetragen wird (Push 1)
• von einem weiteren Plugin (Push 2) ausgelesen und konserviert wurde und
• wie der Titel nach dem Laden der Seite unter document.title zurückgeliefert wird (unten), nachdem die Seite im Browser beim Laden automatisch übersetzt wurde

Beim Plugin der zweiten Fassung, die mit dem tatsächlichen Titel übereinstimmt, handelt es sich um mein eigenes (nur manuell installierbares) Plugin “WP Post Infos”, das ich nach Jahren der Inaktivität gerade um den Seitentitel ergänzt habe. Eine weitere Möglichkeit ist ein beliebiges Plugin zum Ergänzen von Scriptcode wie z. B.
WPCode. Damit kann der o. A. Code einfach der Seite im Head der Seite oder unten im Quellcode hinzugefügt werden.

Auch in anderen Systemen sollte eine entsprechende Anpassung des Codes bzw. Templates kein Problem darstellen und sogar ein synchron geladenes externes Script kann die Aufgabe im Bedarfsfall übernehmen.

JavaScript Variable statt dataLayer?

Wenn Timing wichtig ist oder nicht (nur) via Tag Manager auf den Titel zugegriffen werden soll, ist die Nutzung der Datenschicht nicht die ideale Lösung - jedenfalls nicht exklusiv. In solchen Fällen ist eine einfache Variable der bessere Platz, um den akt. Wert von document.title vor evtl. Veränderungen als Kopie zu sichern. Zum Beispiel als global verfügbare window Eigenschaft unter einem möglichst eindeutigen Namen ohne Konfliktpotenzial wie z. B. _orgPagePath o. Ä. Also mit dem folgenden hochkomplexen Code an beliebiger Stelle zum Beispiel:

Bereinigung

Beides kann freilich kombiniert werden und es ist denkbar und ggf. sinnvoll, hierbei bereits Bereinigungen vorzunehmen, die die Lesbarkeit der Titel verbessern wie z. B. Entfernen von Sonderzeichen o Ä., so dass bereits ein “sauberer” Seitentitel für das Tracking als Variable und / oder dataLayer Key bereitgestellt wird.

Ein weiterer guter Streichkandidat sind konstante Ergänzungen der Seitentitel mit dem Namen des Unternehmens oder der Domain… vor allem dann, wenn diese am Anfang des Titels stehen und so die Lesbarkeit der Reports erschweren.

Nicht jeder mag zudem die beliebten UTF8 Icons, mit denen Seitentitel in der Hoffnung auf bessere Rankings als Opfergaben für den SEO Gott dekoriert werden, unbedingt in der Webanalyse wiederfinden. Mit JavaScript ist man diese schnell los, indem man den Titel bei der Zuweisung zu einer Variable oder Ablage in der Datenschicht anpasst. Das kann z. B. mit der folgenden Anweisung geschehen:

Nutzung im Google Tag Manager

Im GTM wird der Wunschtitel in Form einer JavaScript Variable (nicht “Benutzerdefiniertes JavaScript”) unter dem entsprechenden Namen wie “window._orgPagePath” ausgelesen, wenn diese Methode gewählt wurde - ansonsten nutzt man eine Datenschicht-Variable mit dem jeweiligen Schlüssel wie “pageTitle” (GTM4WP), “wp_title” (WP Post Infos) oder wie immer man die dataLayer Variable selbst benannt hat.

Im GA4 Konfigurations-Tag wird für den ggf. damit ausgelösten Seitenaufruf und alle folgenden Events der Titel der Seite mit dieser Variable belegt.

Auf diese Weise wird das Übersetzungsproblem umgangen und eine möglichst vollständige Sicht auf die Seiten per Titel ermöglicht.

Mehr als ein “Bonus”: Bereinigung von URL Parametern

Wenngleich ohne Anpassungen ohnehin keine Pfade inkl. Parametern in Standard-Reports auftauchen, ist die Kontrolle der Anzahl von URLs eine sinnvolle Übung, um z B. in eigenen Erkundungen, um Dimensionen inkl. Parametern ergänzte Standard-Reports oder dem Data Studio mit sauberen vollständigen Seiten-Adressen zu arbeiten. Solange es zudem noch ein potenzielles Risiko (Stichwort “Kardinalität”) für alle Reports ist, wenn viele URLs die Auswertungsgrundlagen bilden (selbst wenn die URL nicht Teil des Reports ist - verrückt), will man die Anzahl ohnehin möglichst gering halten.

Weder in den Property-Einstellungen (als Pendant zu den Datenansichten in Universal) noch in Form von Filtern kann man Kontrolle darüber ausüben, was in GA4 als Parameter in URLs landet. Daher ist eine Anpassung der für das Tracking genutzten URLs direkt im Browser die einzige Option… wenn nicht ein eigener Tracking Endpunkt in Form eines server-side GTM o. Ä. im Einsatz ist, wo als letzte Möglichkeit vor dem Versand an GA4 noch Korrekturen vorgenommen werden können.

Parameter und deren Impact bestimmen

Wenn eine Bereinigung vorhandener Parameter geplant wird, braucht man nicht nur eine Übersicht aller vorhandenen Parameter, sondern auch eine Metrik, nach der diese gewichtet werden können. Nur so kann man die irrelevanten Parameter finden, die in den meisten URLs vorkommen und damit für die größte Streuung sorgen. Bei Analytrix findet sich dazu der GA4 Parameter-Check, der eine Liste von gefundenen Parametern, der Anzahl der URLs und einen Beispieltreffer liefert, so dass auf einen Blick erkannt werden kann, ob hier z. B. kritische Daten oder potentiell einmalige Werte enthalten sind, die für eine große Streuung sorgen.

Hiermit kann geplant werden, welche Parameter ausgeschlossen oder je nach Verhältnis und Anzahl auch mit Hilfe einer Whitelist beim Streichen aller anderen Parameter erhalten werden sollen.

Parameter-Kontrolle via Google Tag Manager

Davon ausgehend, dass der Google Tag Manager entweder im Browser oder als Tracking-Endpunkt im Einsatz ist, gibt es neben Custom JavaScript (im Browser) zahlreiche Lösungen in der Template Gallery - darunter der “URL Cleaner” (hier für den client-side GTM und als Variante für server-side GTM derzeit nur zur manuellen Installation bei GitHub).

Damit können sowohl über eine Whitelist nur bestimmte Parameter durchgelassen oder per Blacklist explizit aus URLs entfernt werden. Zusätzlich stehen für die verbleibenden Parameter Anpassungsfunktionen bereit, mit denen die URL auf einheitliche Kleinschreibung gebracht oder z. B. Mail-Adressen oder andere Daten aus Parameterwerten entfernt werden können.

Im GA4 Konfigurations-Tag kann das Ergebnis dieser Variable zum Überschreiben der page_location dienen, um hierüber alle Angaben in GA4 (Landingpage, vollständige URL, Pfad und Pfad nebst Suchanfrage) zu kontrollieren.

Wer ihn zu Auswertungszwecken benötigt, kann die vollständige URL als weiteren Ereignis-Parameter übertragen.

Auf dem exakt gleichen Weg ist dieser Vorgang mit Hilfe des serverseitigen URL Cleaners im ssGTM zu erledigen, wo die “page_location” aus den Ereignisdaten ausgelesen, angepasst und beim Tag wieder als Feld zugewiesen wird.

Mit dieser Methode kann die Auswertungsqualität in GA4 je nach “Parameter-Vielfalt” deutlich verbessert werden.

Titel oder Pfad: Was soll es sein?

Mit den obigen Hinweisen sind beide Optionen so gut wie derzeit möglich in GA4 einsetzbar. Wesentlich ist, dass man sich im Fall von GA4 durch fehlende Kontrolle per Filter & Co. bei einigen Feldern schon beim Tracking Gedanken darüber machen sollte, wie man Daten bereinigen und Report-Einträge konsolidieren kann. Das betrifft nicht nur Titel und URL vermessener Seiten: Auch in anderen Dimensionen wie z. B. Produktnamen und an anderen Stellen lauern Inkonsistenzen, denen man (natürlich nicht nur bei GA4) mit Anpassungen im Tracking begegnen kann. Räumst Du schon Felder im Client oder am Server vor dem Senden an GA4 auf - und wenn ja, in welchen anderen Feldern und wie? Ich freue mich über jede Rückmeldung per Mail, Twitter oder sonstwo.