Auswerten durch die Kombination von Inhalten
Willkommen zurück zum zweiten Teil meines Artikels Webdaten strukturiert und gut gestalten – Teil 1. Und nun geht es auch endlich ans Zusammensetzen für effizientes Auswerten. Aber was meine ich damit? Die meisten im ersten Teil beschriebenen Datenpunkte musst du zu einem insgesamt strukturierten und standardisierten Seitennamen zusammenführen. Nur so stellst du sicher, dass du das Auswerten der Daten bestmöglich vereinheitlichst.
Alles in allem besteht eine komplette Struktur idealerweise aus folgenden Bestandteilen:
portal.navigationsebene1…..navigationsebene(n).seitentyp.eindeutiger seitenbezeichner
Seitenbezeichner in der Praxis
Aber wie kannst du das in der Praxis umsetzen? In den nachfolgenden Abschnitten findest du ein paar Beispiele, wie diese Struktur aufgebaut wird. Anhand konkreten Seitentypen formuliere ich die Struktur in den nachfolgenden Abschnitten.
Seitenbezeichner für eine Startseite
portal.homepage
Die Startseite solltest du schlicht und einfach halten. Es gibt keine unteren Ebenen, da die Startseite normalerweise den Ausgangspunkt einer Webplattform darstellt. Der zentrale Wert zur Identifikation der Seite ist hier der Begriff homepage.
Seitenbezeichner für Kategorieseiten
portal.navigationsebene1…..navigationsebene(n).categorypage.eindeutige seitenbezeichnung
Kategorieseiten können auf verschiedenen Navigationsebenen existieren. Das ist von den jeweiligen Strukturen im Content Management und der Komplexität des Geschäftsmodellen abhängig. Im Regelfall sollte eine Kategorieseite aber nicht tiefer als in der ersten oder zweiten Navigationsebene liegen. Du identifizierst die entsprechenden Seiten später im Web Analytics-Tool durch eine einheitliche und konsistente Namensgebung in den einzelnen Navigationsebenen. Die Ebenen sind im Endeffekt auch die Navigationspunkte, die der Nutzer sieht. Das sind Namen der Kategorieseite, aber auch andere eindeutige Informationen. Sie müssen nur klar ersichtlich zeigen, an welcher Position sich diese Seite innerhalb der Plattform befindet.
Damit die Seiten in Segmenten einfacher verwendet werden können, verwende grundsätzlich der Begriff categorypage, direkt vor der eindeutigen Seitenbezeichnung.
Seitenbezeichner für eine Produktdetailseite
portal.navigationsebene1…..navigationsebene(n).productpage.produktbezeichnung
Weiterführend zu den Kategorieseiten gibt es in Onlineshops natürlich Produktdetailseiten. Hier eignet sich der eindeutige Identifikator productpage als Gruppierungsmerkmal zum Auswerten. Bei Medienseiten macht es unter Umständen Sinn, anstatt dieses Begriffes einen Wert zu nehmen, wie zum Beispiel articlepage. Dahinter soll immer ein Produktname und/oder eine Artikelnummer (beziehungsweise ein Content-Artikelname) ergänzt werden. Schließlich will der geneigte Webanalyst auch auf unterster Ebene auswerten können 🙂
Seitenbezeichner für eine (virtuelle) Productview-Seite
portal.navigationsebene1…..navigationsebene(n).productview.produktbezeichnung
Ein Sonderfall zur Productview-Seite ist ein virtueller Seitenaufruf, der den Event Productview vom eigentlichen Seitenaufruf trennt. Das macht vor Allem Sinn in verschiedenen Arten der Seitenauswertung. Das hängt aber stark vom Use Case der Analyse ab.
Seitenbezeichner für eine (virtuelle) Add to Cart-Seite
portal.navigationsebene1…..navigationsebene(n).addtocart.produktbezeichnung
Analog zum virtuellen Productview wird auch immer häufiger der virtuelle Add to Cart zur Auswertung verwendet. Er vereinfacht vor Allem eine Auswertung der “Adds”. Oftmals verlinkt ein Add to Cart direkt zur Warenkorbseite, oder aber wieder zurück zur Produktseite. Diese Seitenaufrufe sollten nicht durch einen Add-Event verunreinigt werden.
Seitenbezeichner für eine Warenkorbseite
portal.navigationsebene1…..navigationsebene(n).shoppingcart
Wieder eine relevante Seite für Onlineshops. Die Warenkorbseite ist eines der zentralen Elemente eines Shops. Deshalb definiere sie auch mit besonderer Aufmerksamkeit für das Auswerten. Hier verwende ich gerne den Seitentyp shoppingcart. Er ist eindeutig und kann nicht verwechselt werden. Alternativ hängst du den Warenkorb auch in die Nomenklatur für die Bestellprozessseiten. Da dann mit dem Wert shoppingcart als individuellen Teil des Seitenbezeichners.
Seitenbezeichner für einen Bestellprozess
portal.navigationsebene1…..navigationsebene(n).orderprocess.payment
portal.navigationsebene1…..navigationsebene(n).orderprocess.shippingaddress
portal.navigationsebene1…..navigationsebene(n).orderprocess.lastcheck
portal.navigationsebene1…..navigationsebene(n).orderprocess.confirmation
Zum Auswerten ist der Bestellprozess der Bereich, auf den viele interne Entscheider ein besonderes Augenmerk legen. Hat der Besucher es schon in den Bestellprozess geschafft, dann soll der Vorgang auch reibungslos absolviert werden. Viele verwenden diese Seitenfolge sehr gerne als Conversion Funnel für eine Zielerreichung (zum Beispiel in Google Analytics). Gerade deshalb ist eine eindeutige Struktur hier umso wichtiger, als vielleicht bei anderen Seiten.
Als eindeutige Identifikationen verwende folgende Begriffe:
– payment
– shippingaddress
– lastcheck
– confirmation
Damit klappt es auch mit dem Bestellprozess! 🙂
Seitenbezeichner für einen Registrierungssprozess
portal.navigationsebene1…..navigationsebene(n).registration.registrationform
portal.navigationsebene1…..navigationsebene(n).registration.confirmation
Das nächste wichtige Einsatzgebiet für eindeutige Strukturen ist der Registrierungsprozess. Meistens ist der aber relativ kurz. Ein Registrierungsformular und eine Dankeseite sollten ausreichen. Um die Registrierung als Ziel zu messen, muss auf jeden Fall eine Dankeseite existieren. Diese kann allerdings auch als virtuelle Seite umgesetzt werden. Der Seitentyp ist in meinem Fall registration, die eindeutigen Bezeichner sind „registrationform“ und „confirmation“.
Seitenbezeichner für einen Login-Prozess
portal.navigationsebene1…..navigationsebene(n).login.loginform
portal.navigationsebene1…..navigationsebene(n).login.confirmation
Strukturiere den Login-Prozess ähnlich, wie den Registrierungsprozess. registration“ wird in diesem Fall durch login ersetzt. Die Seite confirmation kannst du auch als virtuelle Seite verschickt werden, wenn der Nutzer vom Login auf seine Account-Seiten geleitet wird.
Seitenbezeichner für Account-Seiten
portal.navigationsebene1…..navigationsebene(n).account.accountdetails
portal.navigationsebene1…..navigationsebene(n).account.profile
Nach dem Login folgt oftmals der Bereich mit den Account-Details. Hier gibt es oftmals viele verschiedene Unterseiten. Daher begrenze ich mich in diesem Artikel auf die accountdetails“ und „profile. Der Seitentyp ist mit account ebenfalls eindeutig abgrenzbar.
Seitenbezeichner für die internen Suche
portal.navigationsebene1…..navigationsebene(n).internalsearch.search
portal.navigationsebene1…..navigationsebene(n).internalsearch.results
Die interne Suche ist oftmals die Navigationsmöglichkeit für die Besucher, die sich mit der eigentlichen Navigation nicht zurechtfinden. Das sind tatsächlich mehr Besucher, als dem Portalbetreiber meistens lieb ist. Du glaubst mir nicht? Dann verwende den Seitentyp „internalsearch“ im Bezeichner und überprüfe es bei der nächsten Messung. Fröhliches Auswerten 😉
Seitenbezeichner für eine Landingpage
portal.navigationsebene1…..navigationsebene(n).landingpage.thema der landingpage
Über Landingpages könnte ich einen ganzen eigenen Bereich in diesem Blog füllen. Aber in diesem Artikel möchte ich nur auf die eindeutige Identifikation dieser konzentrieren. Wie in den anderen Strukturen auch, definiere einen eindeutigen Seitentypen, der dir die Auswertung ermöglicht. Ich verwende immer klassisch den Begriff landingpage, dem das Thema der Landingpage folgt. Achte darauf, dass das Thema der Landingpage nicht “Landingpage 1” lautet. Nutze hier eine klare und sprechende Beschreibung. Sie soll dir bei der Auswertung auch direkt sagen, was der Inhalt der Seite war.
Seitenbezeichner für eine Support-Seite
portal.navigationsebene1…..navigationsebene(n).support.support-thema
Für viele Portalbetreiber ist der Supportbereich, auch FAQ-Bereich, ein zentraler Bestandteil. Visitors können hier wichtige Infos finden oder technische Dokumente herunterladen. Aber welche Inhalte interessiert den Besucher? Das findest du am besten heraus, wenn du auch hier eindeutige Bezeichnungen nutzt. Ob du den Begriff Support oder FAQ nutzt, ist dabei tatsächlich egal. Nicht egal ist das Thema des Artikels. Er gibt dir Aufschluss über Themenschwerpunkte, mit denen der Nutzer nicht klarkommt oder über die er mehr wissen will. Unterschätze niemals die Notwendigkeit eines Supportbereiches! Ein guter und für den Kunden relevanter FAQ-Artikel erspart oft einen Anruf im Supportcenter. Damit spart das Unternehmen also bares Geld, weil die Anzahl der Anrufe zurückgeht!
Seitenbezeichner für die Kontaktseite
portal.navigationsebene1…..navigationsebene(n).contact.contactform
portal.navigationsebene1…..navigationsebene(n).contact.confirmation
Zu guter letzt kommt nun die Kontaktseite. Oft hängt diese im Supportbereich. Jedoch hängt die Wichtigkeit hier stark von der Rolle des Formulars ab. Wenn die Kontaktaufnahme wichtig für das Unternehmen ist, dann gib der Auswertung auch die angemessene Priorität. Verwende auch Formulartracking zur Analyse. Aber vor Allem achte auf eine Eindeutigkeit in der Bezeichnung der Unterseiten. Der Seitentyp ist “contact”, der eindeutige Bezeichner “contactform”, beziehungsweise “confirmation”.
Und jetzt direkt einbauen und umsetzen!
Ein fertiges Web Analytics-Tool fällt nicht vom Himmel! Auch wenn Google Analytics diesen Eindruck sehr gerne vermittelt. Klar kann das Auswerten direkt nach Einbau des Pixels erfolgen. Aber eine erfolgreiche und nachhaltige Implementierung sichert dir und deinem Unternehmen eine bestmögliche Analyse. Diese kannst du dann zielgerichtet und effektiv betreiben und deine Fachabteilungen mit guten und einfach verständlichen Auswertungen versorgen. Ich wünsche dir viel Spaß bei der Umsetzung. Ich habe ihn jedes mal wieder. Die Ergebnisse sprechen einfach für sich! 🙂
