Wie du das Auswerten von Webanalysedaten standardisierst
Heute beschäftige ich mich beim Auswerten von Daten mit einem grundsätzlichen Thema. Was bei Unternehmen und Kollegen immer wieder zur Sprache kommt ist die Tatsache, dass es im Web Analytics-Tool an Struktur mangelt. Häufig werden für die Benennung von Seiten vorhandene Knotenpunkte im Content Management System (CMS) 1:1 in die Webanalyse gespiegelt. Leider ist die Struktur in den seltensten Fällen für den Anwender oder Empfänger von Reports verständlich (oder nachvollziehbar). Immer wieder höre ich die Frage, wie ich Seitenstrukturen in der Webanalyse aufbauen würde. Aus diesem Grund schreibe ich nun diesen ausführlichen Artikel!
Ich konzentriere mich heute vor Allem auf notwendige Parameter zur Seitenmessung. Tiefergehende, nutzerbezogene und produktbezogene Parameter lasse ich bewusst außen vor. Die behandle ich in Kürze in einem gesonderten Beitrag.
Dann mal hinein ins Vergnügen!
Grundsätzliche Anforderungen an eine Seitenanalyse
Zunächst müssen wir uns überlegen, warum wir überhaupt seitenbezogene Inhalte auswerten wollen. Wie ich ja schon in meinem Artikel Die Page Impression ist tot erläutert habe, werden Seiten nicht um der Seite wegen analysiert. Vielmehr geht es darum, wie ein Besucher (allgemein der Visitor) innerhalb einer (oder mehrerer) Besuche (auch Visits/Sessions genannt) mit den Seiten meiner Plattform interagiert.
Und um derartige Fragestellungen auswerten zu können, müssen gewisse strukturierte Inhalte an sämtlichen Seiten innerhalb der Plattform zu finden sein. Es geht konkret um eine möglichst feste Struktur, die standardisierte Analysen und Reports ermöglicht. Für eine einzelne Seite sollten also grundsätzliche Informationen immer erfasst werden.
Seitenbezogene Inhalte
Zentral für eine effektive Auswertung der Nutzerpfade auf der Website sind Informationen, die die Zugehörigkeit der einzelnen Seite, sowie deren “Zustand” beschreiben.
Portal, in dem die Seite eingehängt ist
Das Portal ist vor Allem für die Trennung unterschiedlicher Länder relevant, die in einen einzelnen Account einfließen. Dieser Account kann zum Beispiel die Datenansicht bei Google Analytics (View) sein, aber auch zum Beispiel ein Datenaccount bei Webtrekk, einem deutschen Anbieter eines Web Analytics-Tools. Ein anderes Szenarion könnte sein, dass es mehrere Unterportale gibt, die in einen Datentopf wandern und ich als Digital Analyst und auseinanderhalten soll.
Navigationsebene der Seite
Natürlich ist es wichtig zum Auswerten, in welcher Navigationsebene die betrachtete Seite eingehängt ist. Deshalb gilt, dass immer auch die Informationen aller Navigationsebenen einer einzelnen Seite erfasst werden. Wie genau eine Struktur hierfür aussieht, dazu komme ich weiter unten. Jede Navigationsebene muss mindestens eine eindeutige Namensgebung haben, die effizient auswertbar ist.
Beispiel:
– Erste Ebene: Kategorie Socken
– Zweite Ebene: Kategorie rote Socken
– Dritte Ebene: Produktdetailseite rote Socke mit Ringel
Seitentyp
Der nächste zentrale Punkt zum Auswerten des Nutzerverhaltens onsite ist die Fragestellung, welche Seitentypen relevant für welche Nutzergruppe sind. Der Vorteil von der Kategorisierung in Seitentypen ist es, dass die Seiten gruppiert und übersichtlich gegenübergestellt werden können. Auch dient diese Gruppierung als Segment für weiterführende Analysen.
Fragestellungen könnten zum Beispiel sein:
– Welche Produkte werden am meisten gekauft, wenn die Nutzer über die Startseite auf die Website gelangen?
– Wo springen die meisten Nutzer ab, die über unsere selbst erstellten Landingpages zu uns kommen?
– Nutzen Besucher von Suchergebnisseiten auch den FAQ-Bereich?
Das sind nur drei Beispiele für zahllose Segmentierungsmöglichkeiten. Hierbei ist der Fantasie prinzipiell keine Grenzen gesetzt.
Ich unterteile die Seiten im Normalfall in folgende Seitentypen:
– Startseite
– Kategorieseite
– Landingpage
– Produktdetailseite
– Bestellprozessseite + Dankeseite
– Suchergebnisseite
– Contentseite
– FAQ-Seite
– Kundenkontaktformularseite
– etc.
Login Status
Eine weitere, wichtige Information ist, wie viele Nutzer sich in ihrer Session wenigstens ein mal eingeloggen. Auch ist hier interessant, welche Seiten tatsächlich im eingeloggten Zustand gesehen wurden, und welche nicht. Achte aus diesem Grund auf bestimmte Schlüsselseiten. Sieht der Besucher auch tatsächlich die für ihn bestimmten Angebote? Nutzt eine Gruppe von Kunden verstärkt Hilfeseiten für die gekauften Produkte?
Bei der Betrachtung der eingeloggten Nutzer ist zwischen zwei Arten von Fragestellungen zu unterscheiden:
– Wie viele Nutzer waren eingeloggt?
– Welche Seiten wurden im eingeloggten Zustand betrachtet, welche nicht?
Hier erweist für die Übermittlung dieser Informationen ein zweigeteiltes Vorgehen. Es sollte einen Parameter geben, der pro Seitenaufruf mit dem aktuellen Login Status versendet wird. Also auch, wenn der Nutzer aktuell sich nicht eingeloggt. Der Parameter wird also bei 100% der Seitenaufrufe versendet. Ein zweiter Parameter sollte sich auf die Session des Nutzers fokussieren und dabei immer den “höchsten” Login Status innerhalb des Besuchs wiedergeben. Natürlich geht das auch mit der Segmentierung des seitenbezogenen Parameters. Jedoch je nach Web Analytics-Tool ist es sinnvoller diese zwei Anwendungsfälle auch unterschiedlich auszusteuern.
Mögliche Werte für die Parameter sind:
– logged_in
– not_logged_in
Titel der Seite
Die Relevanz des Titels/Namens einer betrachteten Seite betrifft vor Allem Content-Portale. Aber auch für klassische Onlineshops ist die Information, welche Seite der Besucher (im Klarnamen) gesehen hat, sehr wichtig. Gerade Reportings für andere Fachbereiche sind so deutlich lesbarer und einfacher zu verstehen. Als Wert für dieses Attribut hat sich die H1-Überschrift der Seite bewährt. Alternativ macht auch der Title Tag einer Seite Sinn. Hier musst du als Analyst darauf hören, was die relevanten Fachbereiche als lesbarer empfinden.
Veröffentlichungsdatum der Seite
Auch wieder vor Allem für Content- und Mediaplattformen ist vor Allem interessant, zu welchem Zeitpunkt der Artikel/die Einzelseite veröffentlicht wurde. Diese Information kann insbesonders dazu verwendet werden, Langzeitanalysen zum Traffic von Einzelseiten aufzusetzen. Werden bestimmte Seiten auch nach Monaten noch regelmäßig frequentiert? Welche “Artikel-Tage” sind die mit dem meisten Traffic?
Als Format schlage ich einen klassischen Standard vor:
– DDMMYYYY
Viewport
Meistens interessieren sich Entwickler und UX-Designer oft dafür, in welchen Viewports der Besucher die Seite betrachtet. Damit meint der Designer die Fragestellung, mit welcher Art von Endgeräten der Visitor die Seite hochkant (portrait) oder quer (landscape) anschaut. So kann er prüfen, ob die relevanten Inhalte je Endgeräte-Typ auch korrekt gesehen wurden. Ist eines der Endgeräte in den Analysen auffällig, so muss der zuständige Ansprechpartner die jeweiligen Breaking Points prüfen und gegebenenfalls nachbessern.
Ich empfehle als mögliche Werte folgende:
– desktop-landscape
– desktop-portrait
– mobile-landscape
– mobile-portrait
– tablet-landscape
– tablet-portrait
Customer ID
Mit Kundendaten muss der Webanalyst immer sehr sensibel umgehen. Auch sind die Datenschutzrichtlinien im jeweiligen Land zu beachten, um diese Daten rechtskonform zu erheben und zu verwenden. Im Normalfall kann beim Einstieg auf die Plattform noch keine konsistente CustomerId vergeben werden. Eine CustomerId bezeichnet immer einen auf eine Person eindeutigen Schlüssel, mit dem zum Beispiel in der Kundendatenbank des Unternehmens die Kaufhistorie erfasst wird. In einem Onlineshop wird eine derartige Id bereits bei der Erstellung eines Accounts oder bei der Registrierung für einen Newsletter vergeben. Aber achte darauf, dass diese Id über sämtliche Stufen der Wertschöpfungskette konsistent ist.
Übergibt man diese Id dann an das Web Analytics-Tool, so muss sie verschlüsselt werden. Es soll ein sogenanntes Hashing durchgeführt werden, damit ein Analyst im Tool keine Überleitung auf eine natürliche Person im Data Warehouse vornehmen kann. Die CustomerId übergibt das CMS ab dem erfolgreichen Login und dann auf jeder Folgeseite.
Fehlermeldungen
Vernachlässige niemals Fehlermeldungen, die der Besucher der Seite sieht. Auch diese sollte das System an die Webanalyse übergeben. Der Vorteil ist offensichtlich. Das ist der nächste Schritt zum Formulartracking. Werden die Fehlermeldungen übergeben, so kann pro Seite die Anzahl und die Art der Fehlermeldungen analysiert, segmentiert und ausgewertet werden. Je detaillierter die Informationen übergeben werden, desto gezielter kann der Webanalyst später auswerten.
Beispiele für Fehlermeldungen können sein:
– Passwort vergessen
– Feld nicht korrekt ausgefüllt
– Feld gar nicht ausgefüllt
– etc..
Individuelle Seitenbezeichnung
Am Ende steht immer eine individuelle Bezeichnung, um eine Seite eindeutig zu identifizieren. Als Standard wird meistens die URL verwendet. Sie scheint auf den ersten Blick eindeutig und ausreichend. Leider sind URLs oft nicht aussagekräftig genug, weil keine eindeutige, konsistente URL-Struktur gegeben ist. Navigationsebenen werden ausgelassen, (teilweise) für das System notwendige Parameter hängen an URL. Und das erfasst das Tool dann im Schluss auch noch.
Wie heisst es so schön: Hinten pupt die Ente. Am Ende eine Seite muss immer eine Eindeutigkeit hergestellt werden, die die aktuelle Seite von anderen Seiten unterscheidet. Diese Eindeutigkeit schafft man dadurch, dass am Ende des Bezeichners folgende Werte stehen. Natürlich nur auf passenden Seiten!
Beispiele für eindeutige Bezeichner:
– Produktbezeichnung (Produktname, oder noch besser, Artikelnummer)
– Homepage
– Registrierung
– Login
– Inhalt der Kategorieseite
– FAQ-Thema
– etc.
Eine zentrale Struktur hilft bei der Interpretation
Ich hoffe mit diesem ersten Teil meines Artikels konnte ich euch einen gewissen Eindruck vermitteln, worauf es mir bei der Strukturierung von Daten ankommt. Natürlich kannst du mit den meisten Seiten auch arbeiten, ohne eine derartige Struktur zu verwenden. Aber auf diese Weise ist es deutlich einfacher den Überblick zu behalten. Wie genau diese Inhalte dann zu einer wirkungsvollen Definition von eindeutigen Seitenbezeichnern verwenden kannst, erfährst du in Teil zwei dieses Artikels Auswerten von Webdaten strukturiert und gut gestalten – Teil 2.
