s_code.js

Was ist eigentlich diese ominöse Datei namens s_code.js, von der hier oft die Rede ist? Und was tut sie?

Die Datei wird im Zusammenhang mit Tracking per Javascipt benutzt, also wenn man Daten einer ganz normalen Seite im Web tracken möchte.

Sie hat zwei wichtige Aufgaben:

1. SiteCatalyst im Browser „bekannt machen“
2. Wiederkehrende Aspekte des Trackings automatisieren

Je nachdem ob man die Datei im SiteCatalyst Admin Interface selber heruntergeladen hat, oder ob ein Consultant daran mitgearbeitet hat, enthält die Datei 2 oder 3 Abschnitte:

Im ersten Teil werden ein paar Einstellungen vorgenommen. Der (optionale) zweite Teil dient der erwähnten Automatisierung und der dritte Teil enthält den eigentlich Code, also quasi das Herz des SiteCatalyst Codes.

Aufgabe 1 – SiteCatalyst

Ganz am Anfang der Datei sorgen die folgenden Zeilen dafür, daß erstens die korrekte Report Suite beschickt wird (die Variable s_account) und zweitens das „s object“ erzeugt wird.

Das „s object“ enthält sowohl die Logik als auch die Daten für’s Tracking. Es spezifiziert die Methoden s.t() und s.tl(), mit denen Trackingrequests abgesetzt werden. Es enthält all die Variablen, die wir auf der Seite und mit unseren Plugins setzen.

In den folgenden Zeilen werden dann grundlegende Einstellungen vorgenommen. Dabei geht es um Zeichensatz, Währung, die URL der Website und verschiedene Einstellungen für’s Tracken von Exitlinks oder Downloads.

Weiter unten in der Datei finden sich die Einstellungen für den Tracking Server oder das Data Centre (je nach Alter der Datei), die man übrigens wirklich nicht mal einfach so ändern sollte.

Der dritte Teil der Datei, also alles nach der berühmten Zeile mit „DO NOT ALTER ANYTHING BELOW THIS LINE !“ ist dann der eigentliche SiteCatalyst Code.

Hier wird dem Browser „SiteCatalyst bekannt gemacht“, wie ich das oben genannt habe. Der Code definiert letztendlich Javascript Code, der dem Browser das ganze Tracking zur Verfügung stellt. Ohne diesen Teil wüßte der Browser nicht, was s.t() sein soll, d.h. wie man mit SiteCatalyst trackt.

Aufgabe 2 – Automatisierung

Wozu man Plugins braucht und wie die ungefähr funktionieren haben wir an anderer Stelle erwähnt. Bleibt noch zu erwähnen, wie man ein Plugin in die s_code.js Datei einfügt und dort benutzt.

Plugins bekommt man entweder aus der Knowledgebase, oder von einem Consultant. Oder man schreibt sich selber welche, das ist durchaus üblich. Manche Plugins sind im Internet frei erhältlich. (Ich warte schon lange darauf, daß jemand eine Website dafür anlegt…)

Den Code platziert man dann in der „PLUGINS SECTION“.

So, jetzt kennt der Browser das Plugin, man muß es also nur noch benutzen. Das wiederum tut man in der Methode s_doPlugins, die weiter oben in der s_code.js Datei definiert wird.

Falls man diese Methode nicht hat, dann ist die s_code.js Datei wahrscheinlich direkt aus der Admin Console in SiteCatalyst generiert worden. Ein Consultant kann in dem Falle helfen. Es ist gut möglich, daß es eine ältere Version der Datei gibt, die die s_doPlugins noch enthält, siehe Anmerkung zum Updaten unten.

Im Beispiel mit s.getQueryParam würde irgendwo in der s_doPlugins Methode ein Aufruf stehen, der das Ergebnis einer Variablen zuordnet, im Screenshot für’s Kampagnentracking.

Und das war’s auch schon mit den Plugins.

Anmerkungen

Zwei wichtige Anmerkungen hätten wir noch:

SiteCatalyst updaten

SiteCatalyst wird kontinuierlich weiterentwickelt, sowohl die Datenverarbeitung im Backend als auch der Javascript Code in der s_code.js Datei.

Dabei geht es um Fehlerbereinigung (z.B. sicherheitsrelevante Fehler), neue Features (wie z.B. die zusätzlichen props und eVars, contextData und list Variablen) und Anpassungen an Änderungen anderswo im Internet (z.B. Erkennung von Chromes Preview Funktion).

All dies bedeutet, daß man seine s_code.js Datei auf dem neuesten Stand halten sollte.

Die jeweils neueste Version kann man sich aus der Admin Console in SiteCatalyst herunterladen, und zwar unter Admin > Code Manager.

Aber: Diese Datei kommt ohne Anpassungen und ohne die s_doPlugins Methode!

Das bedeutet, daß man alle Änderungen manuell in die neue, heruntergeladene Datei übernehmen muß!

Es gibt Leute, die kopieren einfach nur den Code unterhalb „DO NOT ALTER ANYTHING“ von der neuen Datei in die alte. Das geht auch und ist meistens einfacher.

Tip: Wer oft an der s_code.js herumbastelt, sollte der Datei eine Versionsnummer verpassen und diese auch in einer prop an SiteCatalyst senden. Das hilft ungemein bei der Fehlersuche im Falle eines Falles.

s_code aufsplitten

Man kann der Problematik mit dem Update auch aus dem Weg gehen, indem man die s_code.js Datei in mehrere Teile zerlegt. Dabei bietet es sich an, Part 1 und Part 3 zusammenzulegen und Part 2 (alles was mit Plugins zu tun hat) auszulagern.

Die zwei Teile kann man unabhängig voneinander an den Browser ausliefern. Das hilft beim Caching.

Wichtig ist, daß die Variable s_account definiert ist, bevor s_gi aufgerufen wird, und daß s_doPlugins definiert wird, bevor man mit s.t() oder s.tl() trackt.