Back to Basics – Page Code, Teil 1

Von | 11. September 2012

Oops: Andreas Dierl hat mich (zum Glück) darauf hingewiesen, daß ich mich beim Code vertan habe. Der Call is natürlich s.t(), nicht s.tl()! Repariert.

Es ist immer gut, ab und zu mal zu den Grundlagen zurückzukehren. Das hilft Einsteigern beim Verstehen, Fortgeschrittenen beim Festigen und alten Hasen beim Erinnern.

In dieser Miniserie soll es um den Javascript Code gehen, den man auf den Seiten der Website platzieren muß, soll und kann. Fangen wir einfach mal direkt mit ersterem an: Was muß auf die Seite, damit das Tracking funktioniert?

Minimaler Javascript Code (zu minimal)

Das absolute Minimum sind vier Zeilen Code:


<script type="text/javascript" src="/include/s_code.js"></script>
<script type="text/javascript">
s.t();
</script>

Die erste Zeile lädt die s_code.js Datei, in der das Tracking definiert wird. Zeile 3 ist dann der eigentliche Aufruf der Methode, die den Trackingcall abschickt.

Achtung: Der Code funktioniert so, wird aber kein lesbares Tracking erzeugen. Warum? Weil eine wichtige Variable fehlt.

Minimaler Javascript Code (besser)

SiteCatalyst identifiziert alle getrackten Seiten nicht etwa anhand der URL sondern anhand des Namens, den man in der Variable s.pageName setzt. Der Code sollte also mindestens so aussehen:


<script type="text/javascript" src="/include/s_code.js"></script>
<script type="text/javascript">
s.pageName="Testseite";
s.t();
</script>

Was genau man in s.pageName für eine bestimmte Seite reinschreibt, hängt davon ab, was man hinterher im Report sehen will. Kurz und prägnant ist dabei immer gut.

Im Zweifel kann man den „Reportlesertest“ machen: kann eine beliebige Person im Unternehmen anhand eines Reports, der den Namen enthält spontan erkennen, um welche Seite es sich handelt? Ja? Dann ist der Name gut.

Was kann das?

Der minimale Code mit s.pageName alleine bringt schon eine ganze Menge Metriken und Reports mit sich: Page Views, Visits, Visitors (also eigentlich alle Traffic Metriken) für den Pages Report, Path Reports für Pages (also z.B. „Next Page Flow“) und diverse „eingebaute“ Reports wie z.B. „Browser Type“ oder „Visit Number“.

Wenn die Report Suite entsprechend konfiguriert ist, bekommt man auch die Geosegmentation Reports.

Damit haben wir abgedeckt, was im Code stehen muß.

Minimal sinnvoller Javascript Code

Wer hier schon länger mitliest weiß was ich von Traffic Reports halte, darauf will ich jetzt gar nicht lange herumreiten. Daraus folgt aber, daß der minimale Code eben auch nur minimal nützlich ist. Gehen wir also einen Schritt weiter.

Jetzt müssen wir schon unterscheiden, von welcher Seite genau wir reden. Simpel ausgedrückt können wir das Verhalten unserer Benutzer nur dann sinnvoll untersuchen, wenn wir mehr wissen als nur „die haben sich da so Seiten auf unserer Site geladen“.

Ein erster Schritt wäre sich zu überlegen, was für Seiten die Besucher ansehen können, Artikel, Produktübersicht, Suchergebnisliste, Warenkorb, und so weiter. Warum? Weil wir dann auf vielen davon entsprechend Success Events setzen können. „Product Views“ fällt mir ein, aber auch „Searches“ (auf Suchergebnisseiten) oder eben „Article Views“ auf den Artikeln einer Zeitung.

Warum sind solche Events sinnvoll?

„Product Views“ kann man in einem Funnel benutzen, wenn man die Checkout Seiten untersucht. „Article Views“ sind eine bessere Metrik als „Page Views“ für Onlinezeitungen. „Searches“ geben einen Hinweis darauf, wie Besucher auf der Seite navigieren, und man kann sie grob für die Analyse des Produktportfolios verwenden, wenn man auch die Suchterme trackt. Und so weiter.

Es ist nur ein kleiner Schritt vom „Page View“ zu einer spezifischeren Metrik. Die Ergebnisse aber sind relevanter, mehr auf den Punkt oder einfacher zu verstehen.

Ein Beispiel für einen Blogartikel namens „SAINT Classifications“ könnte so aussehen:


<script type="text/javascript" src="/include/s_code.js"></script>
<script type="text/javascript">
s.pageName="Blog:b57:SAINT Classifications";
s.events="event1,event20";
s.t();
</script>

Dabei ist event1 ein „Page Views (custom)“ Event und event20 ein „Blog Article Views“ Event.

Wir haben jetzt ein paar zusätzliche Metriken, besser als Page Views weil relevanter.

Wir haben die Welt der Conversion Variables betreten und können mit geeigneter s_code.js Datei auch schon Kampagnen analysieren, also z.B. herausfinden, wieviele Blogartikel gelesen wurden, weil wir eine entsprechende Email gesendet haben.

Es bietet sich jetzt an, mithilfe diverser Plugins in der s_code.js Datei eine ganze Reihe von eVars zu setzen die uns nachher erlauben werden, die neuen Metriken genauer zu analysieren: Dimensionen wie „Visit Number“, „Channel“, „Days since last Visit“, „Time of Day“ und viele weitere.

Sinnvollerweise klassifizieren wir viele davon. Numerische Reports sind unlesbar und sollten unbedingt mit SAINT abstrahiert werden.

[Screenshot]

Visit Number Report – schlecht

Beispiel: Die „Visit Number“ eVar wird auf 3 Werte reduziert, „New Visitor“ (Visit Number <= 2), „Return Visitor“ (Visit Number <= 5 oder vielleicht 10) und
„Regular Visitor“.

[Screenshot]

Visit number Report – gut

Das ist schonmal gar nicht so schlecht.

Und abgesehen von s.pageName kann man soweit alles im Template abdecken, falls man ein Template-basiertes CMS benutzt.

Für Leser im Raum Köln: Ich bin am 12. und 13. September auf der dmexco, Halle 7, Stand A11 – A15. Ich werde dort den ganzen Tag an der Bar sitzen (kein Scherz). Vielleicht sieht man sich ja!

3 Gedanken zu „Back to Basics – Page Code, Teil 1

  1. Pingback: Die s.pageName Variable « Webanalyse auf Deutsch

  2. Pingback: Tracking entfernen | Webanalyse auf Deutsch

  3. Pingback: Mindestens Zwei! | Webanalyse auf Deutsch

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.