Tracking mit Javascript

Von | 6. März 2012

Letzte Woche haben wir beschrieben, wie die Daten in SiteCatalyst gelangen. Dabei haben wir eine ganze Reihe Möglichkeiten aufgezählt und eine davon ohne weitere Erklärung als den „Normalfall“ bezeichnet: Datensammlung per Javascript.

Wie funktioniert das eigentlich?

Tracken mit Javascript

Prinzipiell kann man die Interaktionen der Besucher einer Website an zwei Stellen tracken: auf dem Webserver selber oder im Browser. Beides hat Vor- und Nachteile, darum soll es hier nicht gehen. Stattdessen möchten wir heute erklären, wie das Tracking per Javascript im Browser genau funktioniert.

Der grobe Abriß sieht so aus:

  1. Benutzer tippt URL ein oder klickt auf Link
  2. Browser fordert URL beim Server an
  3. Server sendet HTML zum Browser
  4. Browser parst HTML und beginnt rendern der Seite
  5. Beim rendern stößt Browser auf Javascript Code
  6. Browser führt Javascript Code aus
  7. Javascript Code kreiert ein Tracking Object („s Objekt“)
  8. Code weist dem Objekt Werte zu
  9. Code sendet Objekt zum Trackingserver

Interessant sind für uns heute die Schritte 7 – 9.

Eine (sehr simple) Landingpage könnte z.B. so aussehen:

01 - <html>
02 - <head>
03 - <title>Landingpage</title>
04 - </head>
05 - <body>
06 -   <p>Hallo! Bitte kaufen Sie <a href="produkt.html">unser
07 -   Produkt</a></p>
08 - <script type="text/javascript" src="s_code.js"></script>
09 - <script type="text/javascript">
10 - s.pageName="Landingpage";
11 - s.t();
12 - </script>
13 - </body>
14 - </html>

Wir haben hier bewußt ein paar Dinge weggelassen damit man die wichtigen Teile besser sehen kann.

Schritt 5 im Abriß oben passiert, wenn der Browser bei Zeile 8 ankommt. Er lädt dann die s_code.js Datei und führt sie aus. Das sind die Schritte 6 und 7. Zeile 9 öffnet wieder einen Javascript Block, der Browser führt also wieder Code aus. Der Code in Zeile 10 entspricht Schritt 8 im Abriß, Schritt 9 geschieht in Zeile 11.

Der Javascript Code hat also zwei Teile, die s_code.js Datei und den Code auf der eigentlichen Seite.

s_code.js

Die s_code.js ist die zentrale Javascript Datei für SiteCatalyst. Üblicherweise hat man für die gesamte Website nur eine s_code.js Datei. Innerhalb der Datei gibt es mehrere Abschnitte:

  • Initialisierung – die s_account Variable wird gesetzt und mit der Funktion s_gi() wird das Trackingobjekt („s Objekt“) erzeugt.
  • Konfiguration – die wichtigsten Einstellungen werden gesetzt, z.B. die Währung und der CharSet.
  • s_doPlugins(s) – die doPlugins Funktion wird definiert. Darauf kommen wir gleich noch zurück.
  • Plugins – hier werden benötigte Plugins eingefügt / definiert. Diese kann man dann in der doPlugins Funktion benutzen.
  • Modules – enthält Code für Zusatzmodule wie Video oder Survey.
  • Code („DO NOT ALTER ANYTHING BELOW THIS LINE !“) – der eigentliche Code für die Grundfunktionalität von SiteCatalyst.

Beim Laden der s_code.js wird wie gesagt das s Objekt erzeugt. Das ist eine Art Behälter, in den man Daten hineinlegen kann. Außerdem stecken im Behälter alle Modules und Plugins und die doPlugins Funktion (eigentlich Methode), damit der Browser später Zugriff darauf hat.

Einige Daten im s Objekt setzt die s_code.js Datei, z.B. wie schon erwähnt die Währung und den CharSet. Sie setzt außerdem die Variablen s.trackingServer und s.visitorNamespace, die letztendlich bestimmen, wohin der Trackingrequest gesendet wird.

Javascript Code auf der Seite

Wenn der Browser bei Zeile 10 / Schritt 8 ankommt, gibt es also ein s Objekt. In unserem Beispiel wird hier die wichtigste Variable zugewiesen, s.pageName.

Eine „normale“ Seite würde mehr als nur s.pageName zuweisen, das Beispiel oben ist stark vereinfacht. Je nach Seite könnten hier zum Beispiel ein paar props zugewiesen werden, die mir bei der Analyse meiner Hierarchie helfen. Oder es handelt sich um eine Produktseite, dann würde ich s.products zuweisen und einen oder mehrere Success Events:

s.pageName="Produktansicht - Klopfstaubsauger Heinzelmann";
s.products=";KSHZ01";
s.events="prodView,event2";

Der Gedanke liegt nahe: Man sollte den Seitencode so kurz halten wie möglich. Es ist sinnvoll, so viel davon wie möglich in Templates zu verlagern, falls das CMS dies unterstützt. Wer jede einzelne Produktseite mit Code ergänzt hat einen viel höheren Verwaltungsaufwand als jemand der den Code in Templates ablegt und dann im Idealfall bei Änderungen nur eine Datei anfassen muß.

Meine Website, die hier ja immer als Beispiel herhalten muß, ist in diesem Zusammenhang ein extrem schlechtes Vorbild!

Daten absenden!

Schritt 9 (Zeile 11) sendet die Daten aus dem s Objekt zum Trackingserver.

Fertig.

Stop! Ganz so einfach ist es nicht!

Zeile 11 enthält einen Funktionsaufruf:

s.t();

Die Funktion s.t() löst den Versand des Trackingcalls aus, ebenso wie die im Artikel zum Klicktracking erwähnte Funktion s.tl().

In beiden Fällen sucht sich das System (der Code aus der „DO NOT ALTER ANYTHING“ Sektion) zunächst einige Daten zusammen. Neben den zugewiesenen Daten wie s.pageName, props, eVars usw. sind das auch automatische Daten wie Browser, Sprache oder OS. Dann wird die doPlugins Funktion aufgerufen und danach der Request abgeschickt.

Nochmal in die s_code.js

Wer sich schon gefragt hatte, was die ganzen Plugins und Modules eigentlich tun oder wann die in’s Spiel kommen, der wird erfreut sein: der letzte Schritt vor dem Versand der Daten ist der Aufruf der doPlugins Funktion, hier kommen Plugins und Module endlich zum Zuge.

Was genau innerhalb der Funktion passiert, hängt von der Website ab. Das kann mal mehr sein, mal weniger. Grundsätzlich ist es sinnvoll, all die Dinge innerhalb der doPlugins zu erledigen, die auf jeder Seite der Website gemacht werden müssen. Das wären zum Beispiel:

  • Den Visit einem Channel zuordnen
  • Kampagnencodes tracken
  • Werte kopieren (von prop nach eVar oder umgekehrt)
  • Success Events setzen für bestimmte Ereignisse
  • Werte säubern (alles nach Kleinbuchstaben konvertieren, Sonderzeichen entfernen, …)
  • Wochentag und Stunde tracken (Time Parting)
  • und vieles mehr…

Innerhalb der doPlugins Funktion werden also zusätzliche Variablen gesetzt und manchmal auch die Werte in existierenden Variablen geändert oder sogar entfernt.

Wer den Javascript Code debuggen möchte, setzt am besten einen breakpoint in der doPlugins Funktion. Wenn der Debugger hier stoppt, kann man sich das s Objekt in Ruhe ansehen. Man findet es unter window.s im DOM.

Und damit ist die Arbeit des Browsers beendet, er muß nur noch den eigentlichen Trackingrequest versenden.

Notizen

Man beachte, daß der Javascript Code nicht zwingend an einer bestimmten Stelle in der Seite stehen muß!

Je weiter oben der Code steht, desto mehr Page Views wird man für die Seite zählen. Das liegt daran, daß es Visitors gibt, die weiterklicken bevor der Trackingrequest abgesendet wurde. Aber: Man zählt dann auch Page Views obwohl die Seite nicht einmal komplett geladen wurde, d.h. der Besucher hat die Seite zwar angefordert, vermutlich aber nicht angesehen.

Je weiter unten der Code steht, desto wahrscheinlicher ist es, daß ein Page View nur dann rausgeht wenn die Seite tatsächlich angesehen wurde. Und vor allem kann man sicher sein, daß das Laden der Seite schnellstmöglich vonstatten geht, der Visitor also den Inhalt zu sehen bekommt, den er möchte.

Die Empfehlung seitens Omniture & Adobe war daher seit jeher: Der Code sollte direkt vor dem schließenden </body> Tag stehen, also ganz unten auf der Seite.

Nicht sinnvoll ist übrigens, die s_code.js Datei im <head> zu laden! Das hat nämlich den Nachteil, daß Clickmap dann nicht funktioniert, weil beim Laden der s_code.js nicht nur das s Objekt kreiert wird sondern auch ein paar andere Dinge passieren, die aber nur funktionieren, wenn das DOM schon zumindest teilweise existiert.

10 Gedanken zu „Tracking mit Javascript

  1. Pingback: Back to Basics – Page Code, Teil 1 « Webanalyse auf Deutsch

  2. Pingback: Was wenn? – Page Views niedrig « Webanalyse auf Deutsch

  3. Pingback: s_code.js « Webanalyse auf Deutsch

  4. Pingback: Webanalyse ohne Cookies « Webanalyse auf Deutsch

  5. Pingback: Apps tracken « Webanalyse auf Deutsch

  6. Pingback: Visitors & hybride Apps | Webanalyse auf Deutsch

  7. Pingback: IP Adressen Nicht Tracken | Webanalyse auf Deutsch

  8. Pingback: “Nein” Sagen! | Webanalyse auf Deutsch

  9. Pingback: Tracking entfernen | Webanalyse auf Deutsch

  10. Pingback: Mehr über eVars | Webanalyse auf Deutsch

Kommentar verfassen

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