Der Beitrag Webtrekk – Web Analytics-Anbieter stellen sich vor erschien zuerst auf digitalanalytics24.com.

Der Visitor ist tatsächlich noch oft ein Mysterium. Viele Firmen wissen zu wenig über die Website-Besucher. Meistens liegt es an mangelnder Kenntnis, was Firmen durch Web Analytics über den Visitor lernen können. Der folgende Artikel zeigt Potentiale und Möglichkeiten, die jeder nutzen sollte, wenn er dauerhaft am Markt bestehen will.

Wer kommt, wie kommt er, womit kommt er? Für viele Unternehmen ist zu wenig über den Visitor der eigenen Website bekannt. Machen Sie den Test und fragen einen bekannten Unternehmer folgendes:

Weisst du, wie der typische Besucher deiner Website aussieht?

Nur ein Bruchteil wird Ihnen eine Auskunft geben können. Da ich während meiner Arbeit immer wieder auf dieses Phänomen stoße, möchte ich versuchen, den Visitor (auch Uniqe Visitor genannt) anschaulich zu erklären.

Was ist der Visitor einer Website überhaupt?

Schauen wir uns zunächst den Begriff an. Was ist ein Visitor? Bei AT Internet wird der (Unique) Visitor wie folgt definiert:

Der Begriff Visitor bezeichnet einen Online-Nutzer, der innerhalb eines bestimmten Zeitraums eine Website besucht. Ein Unique Visitor ist ein Visitor, der innerhalb eines bestimmten Zeitraums eine Website mehrmals besucht, aber nur einmalig gezählt wird. Dies geschieht mit Hilfe eines Cookies.

Die Definition nimmt eine Abgrenzung zum Visit, also dem Besuch, vor. Was ist aber der Unterschied? Deutlich macht es das Beispiel einer farblich markierten Zeitachse:

Bei dem Schaubild erhalten wir in der Summe vier Besucher mit insgesamt sieben Besuchen. Deutlich wird, dass offensichtlich einige Besucher die Website öfter betreten. Diese Gruppe nennt sich wiederkehrende Besucher (oder auch Returning Visitors). Web Analytics-Tools, so wie andere verwandte Systeme, nutzen unterschiedliche Möglichkeiten, um Besucher erneut zu erkennen. Die derzeit am weitesten verbreitete Methode ist die Wiedererkennung über Cookies.

Eine andere Variante kann zum Beispiel das sogenannte Canvas Fingerprinting sein. Auf die genaue Funktionsweise möchte ich an dieser Stelle nicht eingehen. Wir merken uns nur, dass der Visitor relativ genau wiedererkannt werden kann.

Nun wissen wir,
– dass ein Besucher wiedererkannt werden kann
– dass ein Besucher mehrere Besuche innerhalb eines definierten Zeitraumes tätigen kann

Was können wir aber noch über den Visitor lernen? Im Folgenden gebe ich ein paar Beispiele.

Woher kommt der Besucher einer Website?

Die Frage, woher ein Besucher kommt, hat zwei unterschiedliche Aspekte, die interessante Informationen liefern:
– Aus welcher Region kommt er?
– Über welche Quelle/Kampagne kommt er?

Aus welcher Region kommt er?

Gerade wenn Unternehmen lokal/regional agieren, ist es wichtig, woher der Visitor kommt, der die Website besucht. Für einen Lebensmittellieferanten aus Bremen sind die Besucher relevant, die aus seiner Umgebung kommen. Besucher aus Berlin sind für ihn zwar schön, jedoch im Regelfall nicht relevant für den Geschäftserfolg. Kommen die Besucher von überall her, ausser aus Bremen, sollte der Lebensmittellieferant die Marketing-Maßnahmen überdenken.

Um die Frage des “woher” zu beantworten, nutzen Web Analytics-Tools die IP-Adresse des Besuchers. Gemäß des Bundesdatenschutzgesetzes (bzw. Telemediengesetz) wird die IP-Adresse nur für die sogenannte Geolokalisierung verwendet und anschließend wieder gelöscht. Der letzte Block der Adresse wird für die Geolokalisierung nicht benötigt und daher nicht erfasst. Somit ist auch keine genaue Identifikation der tatsächlichen Person möglich.

Über welche Quelle/Kampagne kommt er?

Eine der spannendsten Disziplinen der Webanalyse ist es, Kampagnen und Herkunftskanäle zu betrachten und Rückschlüsse daraus zu ziehen. War der Newsletter erfolgreich? Wird die Website bei Suchmaschinen gefunden? Lohnt sich Retargeting? Diese Fragen kann ein Analyst beantworten, wenn er sich anschaut, woher der Visitor kommt.

In Verbindung mit der Information, ob er das gewünschte Ziel erreicht hat, haben wir einen der wichtigsten Indikatoren für die Wirtschaftlichkeit von Kampagnen entdeckt:

Sollte ich in eine Kampagne weiter investieren, oder sie abschalten?

Ein Indikator für die Optimierung einer Kampagne ist zum Beispiel folgender:

Verlässt der Visitor nach dem Klick auf eine Kampagne direkt wieder die Website, hat er mit hoher Wahrscheinlichkeit nicht das gefunden, was er erwartet hat

Passiert das bei zu vielen Besuchern, wird eine Kampagne sehr schnell zum Budget-Grab der Online Marketing Abteilung

Diese Informationen können, bei richtiger Aussteuerung von Kampagnen-Codes, bis auf einzene Werbemittel heruntergebrochen werden. Eine gezielte Optimierung von Marketing-Maßnahmen auf Basis von Segmentierung des Visitors muss eine zentrale Rolle in jedem Unternehmen einnehmen, das langfristig ein Online-Business aufbauen will.

Langsam zeichnet sich ein Bild ab. Das ist aber noch nicht alles, was wir herausfinden können. Betrachten wir nun, welche technischen Informationen erfasst werden…

Womit kommt der Visitor auf die Website?

Es gibt eine Fülle von technischen Informationen, die über den Besucher gesammelt werden können. Die meisten gibt das Endgerät automatisch mit. Hierzu gehören zum Beispiel:

Über welche Endgerät kommt der Besucher?
Zum Beispiel:
– Desktop PC
– mobile Endgeräte, wie iPhone, Samsung Galaxy S,
– Tablets
– etc.

Welches Betriebssystem nutzt der Besucher?
Zum Beispiel:
– Windows 10, 7, 8, OS X, etc.
– iOS 7, Android 4, etc..

Welche weiteren technischen Merkmale kennzeichnen den Besucher?
Zum Beispiel:
– Browser
– Bildschirmauflösung
– JavaScript Ja/Nein
– Akzeptanz von Cookies
– Verbindungsgeschwindigkeit
– etc.

Alleine diese (unvollständige) Aufzählung verdeutlicht, welche Potentiale erschlossen werden können. Mit Hilfe dieser Daten ist es zum Beispiel möglich, Schwerpunkte für zukünftige Website-Gestaltung zu identifizieren.

Steigt der Anteil an Visitors über mobile Endgeräte, so muss ein Unternehmen reagieren und seine Website dafür optimieren. Je komplexer und größer die Website wird, desto langsamer ist sie auch. Nicht nur bei Zugriffen über mobile Endgeräte ist darauf zu achten, dass die Zielseite für den Visitor zu öffnen ist. Je länger die Ladezeit, desto mehr Besucher springen ab.

Kann ich erkennen, ob ein Visitor mehrere Geräte nutzt? Ist der Visitor auch ein Kunde von mir?

Eine der größten Schwierigkeiten ist die Identifikation des selben Visitors über unterschiedliche Endgeräte. Max Mustermann schaut sich in der Firma einen Newsletter an und gelangt hierüber auf das Angebot für eine Schrankwand. Nach der Arbeit schaut er sich das Angebot über sein Smartphone erneut an. Zuhause beim Abendessen bespricht er den Kauf mit seiner Frau. Anschließend schließt er den Kauf über sein Tablet auf dem Sofa ab. Für das Web Analytics-Tool sieht der Besuch allerdings zunächst wie folgt aus:

Was fehlt, ist ein Identifikator. Unternehmen nutzen hierfür oft eine eindeutige ID. Diese kann nur vergeben werden, wenn sich der Visitor ein Konto erstellt. Sei es beim Kauf eines Produktes, oder bereits davor. Bei der Erstellung wird eine eindeutige ID vergeben, die bei LogIn an das Web Analytics-Tool übertragen werden kann. Dieses funktioniert auf allen Endgeräten gleichermaßen. Durch diese ID verändert sich das Bild:

Zwar erwischt man hierdurch nur diejenigen, die sich mindestens einmal eingeloggt haben, jedoch lässt dies wichtige Schlüsse über das Verhalten der interessierten Visitors zu. Ein Ziel könnte es also sein, dass sich der Visitor ein Konto anlegt. Zwar hilft das Konto an sich nicht direkt, jedoch werden so wertvolle Informationen gewonnen.

Ich weiß nun, wer der Visitor ist. Und jetzt?

Die einzelnen Punkt dieses Artikels machen es deutlich: Es gibt viele Informationen, die gesammelt werden können. Die Kunst ist es, diese Informationen sinnvoll zu kategorisieren, zu priorisieren und die Erkenntnisse gezielt für eine Optimierung zu nutzen. Schauen Sie sich ihre Daten genau an. Können Sie bestimmte Gruppen von Visitors auf Ihrer Website ausmachen? Welche Gruppen sind wirtschaftlich gesehen für Sie interessant? Welche nicht? Wenn Sie diese Fragen beantworten können, dann haben Sie einen ersten Schritt in die richtige Richtung getan.

Der Beitrag Definition Visitor erschien zuerst auf digitalanalytics24.com.

Der Beitrag Definition Absprungrate erschien zuerst auf digitalanalytics24.com.

Der Beitrag Definition Bounce Rate erschien zuerst auf digitalanalytics24.com.

Tag Management ist in aller Munde. Soll ich als Unternehmen Tag Management einsetzen? Was spricht dafür, was spricht dagegen? Zu diesem spannenden Thema habe ich mich mit Justus Blümer zu einem Interview getroffen.

Justus hat in seiner Laufbahn in der Webentwicklung besondere Erfahrung mit Datenbanken und Programmierung. Deswegen liegt sein Fokus in Sachen Webanalyse auch in der Implementierung und Tag Management. Sein Faible für JavaScript / node.js macht ihn zum Experten für Crawling, Datenerhebung und Automatisierung, was bei der Optimierung insbesondere bei großen Portalen mit vielen hunderttausenden Seiten hilft. Mit denen hat er als Consultant bei Wingmen Online Marketing (Zur Website der Wingmen) mit Fokus auf SEO und Webanalyse täglich zu tun.

Hallo Justus! Es ist mir wieder mal eine Ehre! Bitte stelle dich für die Leser einmal ganz kurz vor. Wer bist du, was machst du, welchen Bezug hast du zu Web Analytics/Digital Analytics?

Ich beschäftige mich als Online Marketing Berater vor allem mit Suchmaschinenoptimierung und Webanalyse. Von der Entwickler-Seite bin ich damals in den Marketingbereich und zu SEO gewechselt, weil ich damit mein Faible für Technik mit wirtschaftlichen Themen kombinieren konnte. SEO ist und bleibt zumindest für die meisten Unternehmen der spannendste Kanal im Online Marketing. Fast alle SEO-motivierten Maßnahmen haben einen positiven Impact auf größere Aspekte und andere Disziplinen: Relevanterer Text auf Landingpages beispielsweise hilft richtig umgesetzt nicht nur dem Suchmaschinen-Ranking, sondern auch der Conversion Rate, sorgt für höhere AdWords-Qualityscores, niedrigere CPCs und so weiter.

Irgendwann muss man sich aber immer der Bewertung der eigenen SEO-Arbeit stellen und die Frage beantworten, wie viel der akquirierte Traffic überhaupt wert ist und wie er sich in harte Euros umrechnen lässt.
– Welche Seiten funktionieren so wie sie sollen?
– Welche Position hat der Kanal SEO im Lauf der Customer Journey?
– Wann haben sich die Kosten für meine 1000 eingekauften Texte durch positive Trafficeffekte amortisiert?

Solche Fragen muss man beantworten können, sonst arbeitet man im Blindflug und das bedeutet Ressourcenverschwendung, Optimierung unwichtiger Problemstellen oder der Konzentration auf falsche KPIs, z. B. wie in deinem Artikel über Page Impressions als KPI.

Du bist als Consultant viel bei Unternehmen vor Ort tätig. Für welche Art von Aufgaben wirst du geholt?

Mit einer 5-Minuten-Implementierung des Google Analytics Pixels ist es (…) leider nicht getan (…)

Dieser Blindflug findet noch in viel zu vielen Unternehmen statt. Mit einer 5-Minuten-Implementierung des Google Analytics Pixels ist es bei den meisten Geschäftsmodellen leider nicht getan, um wirklich nutzbare Daten zu generieren. Das ist meine Hauptrolle im Bereich Web Analytics: Die Anforderungen an die Datenerhebung aufzusetzen, die Umsetzung zusammen mit den Entwicklern erledigen und die Folgen und neuen Möglichkeiten in den einzelnen Teams zu kommunizieren.

Welche Situation findest du häufig vor, wenn du mit dem Projekt startest?

Meistens gibt es bereits einen, manchmal auch mehrere Verantwortliche, die mit dem Thema Webanalyse bereits recht intensiv beschäftigt sind, das sind aber sehr selten diejenigen, die auch die Implementierung verantworten. Das bringt einige Fallstricke mit sich.

Erstens: Oft ist nicht 100% klar, wie technische Gegebenheiten Einfluss auf bestimmte Metriken nehmen, weil das Knowhow für die Überprüfung der Datenerhebung fehlt. Interne Nutzung von Kampagnenparametern oder mehrfach eingebaute Trackingcodes, die zu mehreren getrackten Seitenaufrufen führen sind Beispiele von den kleineren Fehlern, die große Auswirkung auf die eigentliche Bedeutung von Zahlen und ihre Interpretation haben können.

Webanalyse wird bei der Entwicklung und Konzeption des Projekts nicht mitbedacht.

Zweitens: Webanalyse wird bei der Entwicklung und Konzeption des Projekts nicht mitbedacht. Es ist ein beliebter Irrglaube, man könne Webanalyse jederzeit und einfach über ein Projekt stülpen und dann funktioniert das Tracking so wie es soll. Das ist durchaus auch Resultat der gefährlichen Heilsversprechen der Tag-Management- und Toolanbieter. Dabei ist das Gegenteil der Fall: In der Webanalyse können wir nur mit den Daten arbeiten, die wir von der der Website bekommen und dafür ist die Zuarbeit und die enge Kooperation zwischen Analyse und Entwicklung unabdingbar.

Drittens: Es fehlen einfach die nötigen Ressourcen und Unterstützung wird dringend gebraucht.

Harter Einbau von Tags/Pixeln auf der Website versus Tag Management. Was ist besser und warum?

Tag Management ist fast immer die bessere Lösung

Tag Management ist fast immer die bessere Lösung, denn es entkoppelt das Tracking von der Plattform ähnlich wie ein Content Management System die Technik einer Website vom Inhalt trennt. So wie das CMS dem Redakteur die Möglichkeit gibt, einen Websiteinhalt ohne ständigen IT-Support zu bearbeiten, hat der Analyst oder Marketer die Möglichkeit, selbst zu implementieren. Das reduziert – wenn man es richtig macht – die Aufwände der IT-Abteilung und hält den Code der Plattform freier von Logik, die eigentlich nichts mit dem Produkt selbst zu tun hat.

Welche Vor- und welche Nachteile hat dieser Weg der Implementierung?

Der größte Vorteil von Tag Management für Analyse und Marketing ist mehr Selbstbestimmtheit. Man kann an den bestehenden Prozessen vorbei selbst Implementierungen vornehmen, auf die man sonst Wochen oder Monate gewartet hätte. Mit der eingebauten Versionierung hat man stets den Überblick wann was live gegangen ist und kann das Tracking vor der Veröffentlichung selbst vorher in Ruhe testen anstatt das einem Entwickler zu überlassen, der in den einzelnen über den Tag Manager angebundenen Tools und ihren Anforderungen weniger erfahren ist.

Der größte Vorteil von Tag Management für Analyse und Marketing ist mehr Selbstbestimmtheit.

*Diese Freiheit ist gleichzeitig auch der größte, systemimmanente Nachteil. Geht man ohne Plan und Struktur vor, hat man schnell riesige Tag Manager Container mit hundert Implementierungen in kryptischen Bezeichnungen von 5 verschiedenen Mitgliedern aus unterschiedlichen Teams und am Ende ist jede Wartbarkeit verloren.

Wer Zugang zum Tag Management hat, hat Vollzugriff auf die Website (…)

Wer Zugang zum Tag Management hat, hat Vollzugriff auf die Website und kann mit einem Klick alles lahmlegen und befindet sich außerhalb sonstiger Kontrollmechanismen wie Unit Tests, die in der IT-Abteilung sicherstellen, dass nur voll funktionsfähige Versionen livegestellt werden können.

Welche (größten) Fehler machen Unternehmen aus deiner Sicht, wenn es um Web Analytics, Online Marketing und insbesondere Tag Management geht?

Der größte Fehler ist meistens, Webanalyse zu vernachlässigen und das daraus resultierende Fehlen von echten internen Experten in dem Bereich. Zu oft wird das Thema dem Falschen aufgedrückt und mündet in einer lieblosen Google Analytics Standardimplementierung, aus der ein insightfreies monatliches Reporting mit irgendwelchen hoffentlich steigenden Kurven generiert wird.

Natürlich ist ein Webanalyst oder ein ganzes Team dafür teuer, aber die positiven Auswirkungen können erheblich sein, wenn der- oder diejenige zum unternehmensweiten Ansprechpartner mit ausgeprägter Produktdenke wird und Fragen aus Produktmanagement, Technik und Marketing zahlenbasiert beantworten kann.

Das gleiche gilt auch für Tag Management mit dem Unterschied, dass falsche Implementierung hier schnell Schaden verursachen kann. Falsche Daten fallen in der Regel nicht sofort auf, können auch nur begrenzt über automatisiertes Testing verhindert werden und lassen sich kaum nachträglich korrigieren.

Mit welchen Abteilungen bist du am häufigsten in Kontakt, wenn du vor Ort bist?

Nach Häufigkeit absteigend sortiert:
1. Webanalyse (sofern es sie gibt)
2. Produktmanagement
3. (Online-)marketing
4. IT

Und sind das tatsächlich alle relevanten Stakeholder? Oder welche Abteilungen fehlen regelmäßig in der Anforderungsaufnahme? Woran liegt es aus deiner Sicht, dass diese Abteilungen gerne vergessen werden?

Ich denke es ist seltener der Fall, dass bestimmte Abteilungen vergessen werden. Häufiger sehe ich eher den Fall, dass es gar keine richtige Anforderungsaufnahme gibt, sondern stattdessen viel Kleinstarbeit an einzelnen Fragestellungen. Oft wäre es aber sinnvoller, für jedes Team die Anforderungen zuerst komplett aufzunehmen und dann passende Reports oder Dashboards aufzusetzen, bei deren Weiterentwicklung automatisch alle profitieren.

Bei wachsenden Unternehmen wird es ohnehin nicht möglich sein, jede Frage durch den Webanalysten selbst beantworten zu lassen. Die meisten kleineren Analysen lassen sich aber auch mit entsprechendem Grundlagenwissen im self-service durchführen, was einerseits für mehr Geschwindigkeit sorgt und andererseits dem Webanalysten die Möglichkeit gibt, seine Ressourcen für die Weiterentwicklung des ganzen Systems zu nutzen.

Justus, vielen Dank für das sehr spannende Interview!

Der Beitrag Warum Tag Management wichtig ist – Interview mit Justus Blümer erschien zuerst auf digitalanalytics24.com.

“Die Webanalyse gehört in meinen Bereich!” höre ich bei meinen Einsätzen in Unternehmen sehr häufig. Ich höre es vom Online Marketing, von der IT (ok, von dort eher seltener ), ich höre es vom Controlling. Und wisst ihr was? Sie alle liegen falsch. Und warum, das möchte ich euch in diesem Artikel näherbringen. Nur um das klarzustellen: Analysen müssen in allen Fachbereichen gemacht werden können. Und sie muss für alle Fachbereiche verfügbar und umsetzbar sein. Mir geht es um die fachliche Verantwortung, den strategischen Aufbau und die Sicherstellung von Qualität und Output innerhalb des Systems.

Ich wünsche euch viel Spaß beim Lesen!

Die Säulen einer guten Webanalyse

Um abzustecken, wo die Webanalyse am besten eingehängt wird, möchte ich noch mal darauf zu sprechen kommen, worauf es bei einer qualitativ guten Webanalyse ankommt. Aus den Erfahrungen vieler Projekte kann ich sagen, es kommt vor Allem auf drei Merkmale an:

1. Gute Bedienbarkeit/Effizienz
2. Bestmögliche Datenqualität
3. Zielgerichtete Implementierung

Wenn diese drei Komponenten funktionieren, dann habe ich sehr gute Chancen!

Als Schaubild hier noch mal verdeutlicht:

In den folgenden Abschnitten gehe ich näher auf die Bedeutung der drei Bereiche ein.

Ein effizientes Web Analytics-Tool lässt sich einfach bedienen

Niemand mag komplizierte Frontends von Systemen. Nur leider werden diese Tools (gerade professionelle Tools, die Geld kosten) teilweise so kompliziert aufgebaut, dass niemand mehr einen Überblick hat. Genau das schreckt viele Anwender ab. Zu komplex, unverständlich und keiner weiß, wie gut die Datenqualität ist. Deshalb ist notwendig, dass das Tool der Wahl für die Webanalyse sinnvoll aufgebaut und einfach verständlich ist. Wenn ich ein System nicht verstehe, dann verwende ich es nicht. Und das geht mit Sicherheit einem Großteil deiner Arbeitskollegen genau so.

Die Datenqualität muss so gut wir irgend möglich sein

Ein großer Problemfaktor in Unternehmen ist das Vertrauen in die Webanalyse-Daten. Eben durch eine hohe Komplexität und (leider oft) mangelnde Qualitätskontrolle des zuständigen Implementierers, schleicht sich der eine oder andere Fehler ein. Je tiefergehende die Fragen der Fachbereiche sind, desto eher kommen diese Fehler dann ans Licht der Öffentlichkeit. Und wie sagt der Volksmund:

Ist der Ruf erst ruiniert…

Es gibt eine Vielzahl von möglichen Fehlerquellen. Es kann die Implementierung sein, aber auch externe Faktoren. AdBlocker unterbinden das Tracking, der böse Nutzer löscht ständig seine Cookies. Dennoch ist es möglich, die Differenz in (zum Beispiel) den Bestellungen eines E-Commerce-Shops niedrig zu halten. Bei einem Vergleich vom Data Warehouse und dem Web Analytics-Tool ist es definitiv möglich, die Verschieber auf deutlich unter 10% zu bringen.

Implementierung aus der Hölle muss vermieden werden

Bei dem Thema Implementierung wird es immer spannend. Oft starten Webanalyse-Projekte damit, dass eine JS-Bibliothek eingebunden wird, mit der das Tracking erst mal läuft. Dann kommt eine neue Anforderung. Diese baut der Implementierer ein, teilweise als Sonderlösung. Dann kommt die nächste Anforderung, die wird pragmatisch eingebaut. Und so weiter, und so weiter… und ehe du dich versiehst, hast du ein riesiges, großes Hexenhaus. Keiner weiß mehr, woher welche Daten kommen, wie sie hergeleitet sind, welche Definitionen dahinter stecken. Ich habe schon Projekte gesehen, wo vier (4!) unterschiedliche Versionen einer Web Analytics-Lösung in die Website eingebunden wurden. Das selbe System, der gleiche Hersteller. Aber anstatt eine Aktualisierung der Bibliotheken durchzuführen, wurde einfach eine neue hinzugefügt. Das kommt durch unterschiedliche verantwortliche Entwickler, durch Zeitdruck, oder durch mangelnde Sorgfalt. Hier haben wir natürlich eine direkte Auswirkung auf die Datenqualität. Da hilft dann nur noch einreißen und neu aufbauen…

Webanalyse im Online Marketing-Team eingehängt? Niemals!

Historisch bedingt liegt die Verantwortung für die Webanalyse oft im Online Marketing. Das kommt hauptsächlich daher, dass dort ein direkter Bedarf für die Daten liegt. Die (meisten) Online-Kampagnen werden dort gesteuert. Die Anforderungen an das Web Analytics-Tool gehen hauptsächlich in die Richtung, diese Kampagnen analysieren zu können und die Daten mit denen der Dienstleister zu vergleichen (oder auch anzureichern). Das berühmte händlerische Agieren zwingt die Abteilung dazu, pragmatisch an die Analyse heranzugehen. Die Daten sind schnell verfügbar, schieben sich quasi von alleine zusammen. Jedoch ist hier die Sorgfalt oft ein Problem. Die Systeme liefern schnell Daten. Das verleitet gerne dazu, dass diese Daten niemand hinterfragt. Sie stehen schwarz auf weiß geschrieben. Also müssen sie doch stimmen!

Leider weit daneben. In den meisten Online Marketing-Abteilungen sind die Maßgaben schlicht anders als notwendig. Hier gibt es (häufig, nicht immer) nicht den Anspruch, Daten so konsistent und genau wie möglich zu halten, solange es nicht dem Auftrag der Abteilung nutzt. Auch gibt es in den meisten Teams nicht das technische Know how oder die erforderlichen Freigaben, um am Code tatsächlich etwas anzupassen. Am häufigsten fehlt es aber an beidem.

Somit sind zwei der drei Säulen schon mal gestrichen, nämlich “Bestmögliche Datenqualität” und “Zielgerichtete Implementierung”. Und nun? Kann die Aufgabe der Webanalyse beim Controlling liegen?

Die Aufgabe im Controlling – damit tut sich keiner einen Gefallen

Kommen wir nun zum krassen Gegenteil vom Online Marketing: Das Controlling. Das (gefühlte) Stiefkind des Unternehmens hat eine große Verantwortung, die aber eigentlich niemand mag. Die gesammelten und dort auftauchenden Daten müssen konsistent, nachvollziehbar und vor Allem valide sein. Natürlich ist es für das Unternehmen entscheidend, dass die betriebswirtschaftlichen Ergebnisse stimmen und steuerrechtlichen sicher aufgesetzt sind. Die Bestelldaten aus dem Content Management System müssen für die Auftragsbearbeitung zu 100% stimmen, da darf es keine Ausnahmen geben.

Dieser Anspruch ist absolut berechtigt, jedoch in der Webanalyse unrealistisch. Über mögliche Unschärfen habe ich weiter oben ja bereits referiert. Alleine dieses Thema kann einen eigenen Blog für mehrere Jahre auslasten. Klar, die Daten in der Webanalyse müssen so genau, wie irgendwie möglich sein. Aber die Aufgabe eines solchen Systems ist schlicht eine andere, als zu 100% saubere Daten zu liefern. Es liefert Hinweise, wo auf der Plattform es Auffälligkeiten innerhalb der Plattform gibt. Es liefert Hinweise darauf, welche Kampagnen welchen Effekt im Onlineshop erzielen. Und es liefert Informationen, welche Nutzer sich wie auf der Plattform verhalten.

Zusätzlich fällt bei einer Controlling-Denkweise zu 90% aller Fälle der Pragmatismus weg Der ist in der Analyse von Webdaten aber zwingend notwendig. Analysten heben situativ und iterativ Datenschätze für Fachbereiche. Sie zeigen Potentiale auf und erstellen Hypothesen zu A/B-Tests auf Basis der Webanalyse-Daten. Und dafür ist die Fragestellung, ob der Umsatz € 258.765,67 beträgt, oder € 258.763,17 nicht relevant. Hierfür benötigst du einen Webcontroller. Keinen Webanalysten.

Und nebenbei: Kein Controller will Code programmieren, der sich nicht um die Statistik dreht. Keiner Auch hier fallen also zwei der notwendigen drei Säulen aus, nämlich “Bedienbarkeit/Effizienz” und “Implementierung”.

Uns bleibt also nur noch eine Hoffnung… oder?

Der Entwickler ist der Tod einer strategisch aufgesetzten Webanalyse

Eine gewagte Aussage, das weiß ich. Aber in 99,99% der Fälle ist es harte Realität. Und warum, das erläutere ich sehr gerne. Entwickler machen vor Allem eines: Sie programmieren Code. HTML, CSS, JavaScript und wie sie alle heißen. Sie verbinden Data Warehouses mit Content Management Systemen und programmieren Schnittstellen.

Aber: Ein Entwickler kennt im Normalfall nicht die inhaltliche Bedeutung der Daten. Nur weil Daten einlaufen heisst es nicht, dass sie auch korrekt sind, oder gar ihrer Bestimmung entsprechend ins Tool einfließen. Es ist notwendig, dass die Fachanforderungen aus Online Marketing und Controlling nicht nur technisch “irgendwie” umgesetzt werden. Sie müssen inhaltlich stimmen, aber sie müssen auch so in die Webanalyse fließen, dass die richtigen Auswertungen daraus entstehen. Es kommt darauf an, in welche Felder/Parameter diese Informationen kommen. Und wie sie von der Struktur her aussehen. So muss zum Beispiel die Struktur der Seitenbezeichnungen passen und so über alle Seiten konstant bleiben. Hierzu habe ich einen wunderbaren Zweiteiler geschrieben: Auswerten von Webdaten – Teil 1.

Es ist also immer notwendig, dass Entwickler und Fachanforderer gemeinsam eine Lösung für die Datenströme entwickeln. Liegt das Tool aber in der IT, findet genau dieser Austausch nicht statt. Wenn doch, dann ist er häufig zu oberflächlich oder ungenau. Du ahnst es sicherlich. Liegt die Webanalyse in der IT, dann fallen somit die beiden Säulen “Bedienbarkeit/Effizienz” und “Bestmögliche Datenqualität” aus. Auch die Säule “Zielgerichtete Implementierung” erfüllt diese Konstellation bestenfalls nur teilweise.

Und nun? Die Abteilungen gehen uns langsam aus… Wie also sieht die Lösung aus?

Die Lösung ist weder A, noch B, noch C, sondern etwas ganz anderes

Das Dilemma ist offensichtlich. Keine der alteingesessenen Abteilungen kann die Aufgabe der Webanalyse wirklich alleine ausfüllen. Nun gibt es mehrere Möglichkeiten.

1. Ich mache ein fachübergreifendes Projekt daraus

Eine Option ist mehrere Teammitglieder aus den unterschiedlichen Fachbereichen in eine Projektstruktur zu bringen. So sind im besten Fall sämtliche Disziplinen abgedeckt und das Team kann gemeinsam die Anforderungen erfüllen. Dieses Vorgehen hat allerdings entscheidende Nachteile:
– Ein Projekt hat immer einen Anfang und ein Ende
– Ein Projekt hat (normalerweise) nur begrenzte fachliche Ressourcen
– Ein Projekt hat nie die Akzeptanz wie eine Fachabteilung

Für einen Pilot-Versuch ist eine projektartige Struktur sinnvoll. So kann das Unternehmen testen, ob das Verhältnis zwischen Input und Output passt.

2. Ich installiere eine neue Abteilung, die unabhängig agieren kann

Der aus meiner Sicht nachhaltige Weg ist die Schaffung einer neuen Abteilung. Diese Abteilung muss zwingend unabhängig von anderen Fachbereichen handlungsfähig sein. Sie koordiniert die fachlichen Anforderungen. Sie definiert die notwendigen Parameter zur technischen Umsetzung oder setzt sie sogar selbst um. Und sie führt die dringend notwendigen Maßnahmen zur Qualitätssicherung durch.

Eine weitere wichtige Aufgabe für die Abteilung: Sie muss den anderen Fachabteilungen das Tool beibringen und mit Rat und Tat zur Seite stehen:
– Welche Kennzahlen muss ich für welche Frage verwenden?
– Wie sind die Daten zu lesen, die das System mir gibt?
– Was sagen mir die gezeigten Daten?
– Kann ich den Daten vertrauen?
– Wie baue ich eine gute Analyse auf?

Diese Aufgaben kann das Team nur bewältigen, wenn fundiertes Wissen aus allen zentralen Fachbereichen vereint wird.

Wir brauchen also in dieser Abteilung mindestens einen Mitarbeiter aus den folgenden Fachrichtungen:

1. Online Marketing-Experte für Performance-Kanäle
2. Experte für technisches SEO und ggf. Content-Erstellung
3. Frontend-Entwickler mit entsprechenden Kenntnissen
4. Controller, der Qualität und Konsistenz der Daten bewerten kann
5. Webanalyst, der das Web Analytics-Tool kennt, die Daten analysieren und Potentiale aus den Daten erkennen kann

Optional sollten in der selben Fachabteilungen Mitarbeiter für folgende Aufgaben dazustoßen:

1. Statistiker
2. Datenbankprogrammierer
3. Experte für A/B-Tests
4. Marktforscher

Mit einem Team, dass diese Fachbereiche abdeckt, ist dein Unternehmen auf einem guten Weg.

Viel Spaß beim nachbauen!

Der Beitrag Webanalyse im Organigramm – wem gehört sie eigentlich? erschien zuerst auf digitalanalytics24.com.

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!

Der Beitrag Auswerten von Webdaten strukturiert und gut gestalten – Teil 2 erschien zuerst auf digitalanalytics24.com.

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.

Der Beitrag Auswerten von Webdaten strukturiert und gut gestalten – Teil 1 erschien zuerst auf digitalanalytics24.com.

Viele Unternehmen hüten die Page Impression (oder auch Pageviews bzw. Seitenaufrufe genannt) in ihrem Web Analytics-Tool wie einen Schatz. Je mehr Page Impressions das Unternehmen hat, desto besser. Vor Allem in großen Medienhäusern werden diese als Währung für den Verkauf von Werbemaßnahmen verwendet. Und das wird dann als Preisschild potentielle potentielle Werbende an die Website gehängt.

Was ist eine Page Impression denn nun?

Schauen wir uns einmal an, was die Page Impression tatsächlich ist. Laut verschiedenen Web Analytics-Quellen gibt es auch unterschiedliche Definitionen.

Marco Hassler definiert die Page Impression in seinem Buch Digital und Web Analytics (4. Auflage, 2016) wie folgt:

Als Seitenaufruf wird jede von einem Besucher nachgefragte Seite bezeichnet.

Es geht hier also darum, welche Seiten der Nutzer innerhalb seiner Customer Journey (onsite) sieht.

Die Seo-Küche definiert eine Page Impression wiederum wie folgt Definition der SEO-Küche

Page Impressions, auch als Page View bezeichnet, beziehen sich auf die Anzahl der Aufrufe einer Webseite und bilden somit eine Kennzahl für die Aktivität der Benutzer auf dieser Seite. Eine hohe Page Impression dient als Beleg für die Relevanz einer Webseite und die Attraktivität ihres Inhalts.

Direkt im nächsten Satz relativiert der Autor seine Aussage mit folgender Ergänzung:

Bessere Aussagen zur Qualität einer Website liefern allerdings Vergleiche mit den Unique Visitors der Seite, denn allein genommen lassen Page Impressions keine quantitativen Aussagen zu.

Ich bin sehr froh, dass die geschätzten Kollegen das Thema angesprochen haben. Warum? Das werde ich dir gerne im folgenden Absatz erklären

Die Page Impression wird zweckentfremdet

Zugegeben, bei klassisch aufgebauten Websites macht auch die Messung der Page Impression im Web Analytics-Tool (meistens) Sinn. Wenn jeder neue Inhalt beim Klick auf eine Interaktion auch einen tatsächlichen Aufruf einer neuen Seite zur Folge hat.

Im Zeitalter von Single Page Applications (SPA), Ajax-basierten Features und hochkomplexen Webanwendungen ist dieser Ansatz zur Messung nahezu ohne jede Aussagekraft. Eine Page Impression ist mittlerweile nicht mehr ein tatsächlicher Seitenaufruf, sondern wird aus technischen Gründen dazu verwendet, um die Anforderungen des Managements an eine vermeintliche Messbarkeit von Features und Prozessen herzustellen.

Beispiele für dieses Verhalten der Page Impression:

Der Nutzer überspringt im Bestellprozess durch vorherige Anmeldung die Schritte „Lieferadresse“ und „Zahlart“. Jedoch wird für jeden einzelnen Schritt eine Page Impression an das Web Analytics-Tool ausgespielt.

Google Analytics (und auch andere Tools) ermöglicht es, Events als Seitenaufrufe zu erfassen, um sie technisch besser verarbeiten zu können. Oder um sie als Website-Ziel mit einem Conversion-Funnel abbilden zu können.

„Virtuelle“ Page Impressions werden erzeugt, um Views und Add to carts vom eigentlichen Klickpfad des Besuchers zu trennen und diese gezielter ausgewertet.

Änderst du im Warenkorb die Anzahl der Produkte, löschst ein Produkt, oder gibst einen Gutschein ein, wird der Warenkorb erneut geladen.

Und genau das erfordert einen inflationären Anstieg von (technischen) Seitenaufrufen, die nichts mit der tatsächlichen Sicht von Inhalten durch einen Besucher zu tun haben. Mittlerweile stellen sie nicht mehr den tatsächlichen Interaktionsgrad mit der eigenen Plattform dar, sondern sind ein reines Hilfsmittel um andere Dinge ausführen und auch messen zu können.

Medienhäuser und Publisher stehen auf Page Impressions

Warum aber hält sich die Page Impression in der Disziplin Digital Analytics so hartnäckig? Mit ein Grund sind auf jeden Fall die großen Medienhäuser. Bei ihnen steht vor Allem der Verkauf von Werbeplätzen an oberster Stelle. Damit wird ein Großteil der Einnahmen generiert.

Und womit kann ich als Plattform den Gewinn maximieren? Vor Allem, indem ich an Interessenten eine möglichst hohe Reichweite kommunizieren kann. Je mehr Reichweite, desto höhere Preise kann ich als Anbieter für Werbefläche verlangen. Und da Hits/Events hier als Messgröße nicht dienen können, gewinnt klar die Page Impression den Preis der zu kommunizierenden Zahl.

Schade ist nur, dass die Zahl einem Unternehmen nichts nützt, welches Werbung auf der Plattform schalten möchte.

Der Nutzer im Fokus, anstatt die Page Impression

Wie so oft wird der Nutzer, also der Mensch hinter den Zahlen oft vergessen. Dabei ist der Mensch die tatsächlich relevante Zielgröße, auf die es im Web Analytics-Tool ankommen muss:
– Wie viele Nutzer haben meine Werbung gesehen und darauf geklickt?
– Und welche Visitors davon haben meine Website tatsächlich erreicht?
– Welcher Anteil davon hat eine Conversion erzielt?

Die Page Impression als Hilfsgröße nutzen

So leid es mir tut, aber die Page Impression als Kennzahl an sich ist genauso nutzlos, wie das reine Messen von Hits/Events. Ohne den Kontext hinter dem Seitenaufruf (oder dem Hit) zu kennen, ist die Information nicht zu gebrauchen.

Daher sollte jeder Webanalyst sich darauf einstellen, zukünftig die betrachteten Seiten immer im Nutzerkontext auszuwerten und zu analysieren.

Der Beitrag Die Page Impression ist tot. Wirklich. Ganz ehrlich. erschien zuerst auf digitalanalytics24.com.

Web Analytics (bzw. Digital Analytics) und zentrales Controlling in einem Unternehmen prallen oft aufeinander. Und zugegebenermaßen wird die Diskussion zu Key Performance Indicator(s), also den zentralen Messgrößen eines Unternehmens, immer anstrengender. Für das Controlling werden die Daten aus dem Web Analytics-Tool erfreulicherweise immer wichtiger. Darüber bin ich sehr glücklich, da die Disziplin endlich in einem großen Teil der Firmen angekommen zu sein scheint.

Aber: Während es vor ein paar Jahren noch so war, dass ein Unternehmen online praktisch keine spezifischen Web Analytics-Messgrößen definiert hatte, gibt es nun eine unfassbare Inflation eben dieser KPI’s. Jede Messgröße, die irgendwie in Systemen angezeigt wird, steigt sofort zum KPI empor.

Welche Kriterien ich für Key Performance Indicators anwende

Fassen wir noch mal zusammen, welche Kriterien einen Key Performance Indicator ausmachen. Hierfür nutze ich auch in der Disziplin Web Analytics gerne das Schema nach SMART. Diese Schema erkläre ich dir nun, so wie ich es verwende.

“S” für Specific

S steht für „Specific“. Für die Kennzahl muss eine Zielgröße im Web Analytics-Tool definierbar sein, die das Geschäftsziel/die Geschäftsziele unterstützt. Was meine ich damit aber nun? Wie der Name Zielgröße schon sagt, muss es für die gewünschte Kennzahl ein Ziel geben.

Beispiel für ein Web Analytics-KPI:

Anzahl Bestellungen, die um 10% erhöht werden sollen.

Es muss konkrete Vorgaben/Planungen für diese Kennzahl geben. Aber vor Allem müssen Maßnahmen eingeleitet werden, um dieses Ziel zu erreichen.

“M” für Measurable

Das „M“ steht für „Measureable“, also muss eine Messbarkeit da sein. Ein Key Performance Indicator für das Web Analytics-Tool zu definieren macht nur Sinn, wenn sie auch tatsächlich gemessen werden kann. Kann sie (noch) nicht gemessen werden, so muss eine Messbarkeit hergestellt werden. Auch hier hängt es aber von der Wichtigkeit der Kennzahl ab. Nur wenn auf Basis dieser Messgröße konkrete Maßnahmen für die Website abgeleitet werden soll, ist sie tatsächlich ein KPI.

“A” für Achievable

A bedeutet „Achievable“, also erreichbar. Dieses bezieht sich vor Allem darauf, dass bei der Definition der Zielsetzung realistische Ziele definiert werden. Es hilft nichts, wenn das Team Online Marketing die Sales um 50% erhöhen will/soll, aber ohne die erforderlichen Mittel handeln muss. Hohe Ziele erfordern immer auch genug Budget. Sonst bleibt das Vorhaben reine Utopie.

Natürlich muss immer eine bestmögliche Performance die Maßgabe sein… aber zu hoch gesetzte Zielwerte führen sehr schnell zu Demotivierung auf allen Seiten. Die Geschäftsführung ist negativ gestimmt, weil die Ziele nicht erreicht wurden. Das Online Marketing Team ist unter einem permanenten Druck, um jeden Preis die Ziele erreichen zu müssen. Das führt oft dazu, dass die eigentlich nachhaltig geplante Strategie für das Online Marketing einer kurzfristigen Taktik zur Zielerreichung weichen muss. Kurzfristig mag das einen gewissen Erfolg für die Sales generieren. Jedoch mittelfristig hinterlässt es bei den potentiellen Kunden verbrannte Erde, die von zu aggressiven Werbemaßnahmen schnell Abstand nehmen werden.

R für Result Oriented

R ist das Synonym für „Result Oriented“. Ein Key Performance Indicator im Rahmen von Web Analytics/Digital Analytics unterstützt immer direkt die Unternehmensziele. Hat eine Messgröße keinen direkten Einfluss auf diese, so ist es kein KPI, sondern maximal eine Hilfsgröße. That’ it!

Aber wie erkenne ich, ob eine Kennzahl zielorientiert ist? Für diesen Fall kannst du das “ujujuj”-Prinzip verwenden.

Lass’ mich dir das an einem Beispiel erklären:

Nehmen wir die Kennzahl “Anzahl Visitors mit Kauf” als Beispiel. Wir stellen in unserem Web Analytics-Tool fest, dass es einen Einbruch in der Kennzahl gegenüber der Vorwoche gibt:

• Wir haben erkannt, dass wir deutlich weniger Visitors mit Kauf, als in der letzten Woche haben. Und jetzt?
• Wenn wir keine Maßnahmen einleiten, dann werden wir die Zielvorgaben von der Geschäftsführung für diesen Monat nicht erreichen. Und jetzt?
• Wir müssen gemeinsam mit dem Online Marketing und den Budgetverantwortlichen Kampagnen für die Kundenakquise organisiert bekommen Und jetzt?
• Die Maßnahmen sind so wichtig, dass die Geschäftsführung das Budget bewilligt hat und die Kampagne sofort starten kann.

Wenn du die “Visitors mit Sales” durch deine Messgröße, die Probleme macht, austauschst und nicht mindestens zum zweiten Und jetzt kommst – dann vergiss diese und konzentriere dich auf die wesentlichen Dinge!

T für Time Bound

Das „T“ steht für „Time Bound“, also für zeitgebunden. Wenn ich eine Messgröße optimieren will, muss ich einen Rahmen dafür definieren. Zu wann soll die Zielerreichung vollzogen sein? Dieses natürlich unter der Voraussetzungen, dass die entsprechend notwendigen Mittel bereitgestellt wurden.

Der Digital Analytics Consultant ist in der Pflicht zu handeln

Wie sich aus diesen Leitplanken für KPI in der Web Analytics (bzw. Digital Analytics) schnell herauslesen lässt, ist ein Key Performance Indicator keine reine Messgröße. Er ist vielmehr ein Faktor der Website, den ich durch Optimierungsmaßnahmen gezielt verändern kann. Alleine aus diesem Umstand leitet sich schon automatisch ab, dass ich nicht mehr als eine Handvoll KPI im Unternehmen haben sollte, um zielgerichtetes Arbeiten zu ermöglichen.

Wer mehr über die Definitionen von SMART im Projektmanagement lesen möchte, kann das über folgenden Link tun: www.projektmagazin.de

Natürlich erst am Ende deines Besuches auf dieser Plattform

Der Beitrag Web Analytics im Datenchaos – Warum 345 KPIs keine Lösung sind erschien zuerst auf digitalanalytics24.com.