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.

[Screenshot]

s_code: s_account Variable

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“.

[Screenshot]

s_code: Plugin Code

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.

[Screenshot]

s_code: Plugin benutzen

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.

Über

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , , ,
Veröffentlicht in Grundlagen
13 comments on “s_code.js
  1. […] Die Implementierung ist ziemlich einfach. Zunächst lädt man die Plugins aus der SiteCatalyst Knowledge Base herunter (getPrecentPageViewed ist kb ID 10134, getPreviousValue ist kb ID 1419) und kopiert den Code in die s_code.js Datei. […]

  2. […] in die neue Report Suite umleitet. Das kann man mit Charles, “Map Local” und einer s_code.js Datei mit angepaßter s_accounts Variable […]

  3. […] 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 […]

  4. […] 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 […]

  5. […] Oft genug trackt man die für’s Engagement interessanten Aktionen sowohl in die eVar als auch mit einem event. Das bedeutet, daß man den event auf der Seite selbst setzen kann und die eVar (deren Wert wir noch nicht so genau wissen) in der s_doPlugins Methode in der s_code.js Datei. […]

  6. […] Arbeit auf Seiten des Partners benötigt, und einige wenige brauchten ein Javascript Plugin in der s_code.js. Das steht dann aber im Wizard, wird einem also im Interface […]

  7. […] könnte den Firmenproxy so konfigurieren, daß er intern ein separates s_code.js file ausliefert. In dieser Datei müßte dann nur die Variable s_account anders gesetzt […]

  8. […] uns: Wer mit Javascript tracken will, der braucht zwei Dinge auf jeder Seite: 1. muß er die s_code.js Datei einbinden und 2. ein paar Zeilen Javascript […]

  9. […] Javascript muß implementiert werden (obwohl meist nur im s_code) […]

  10. […] Ein Retailer im UK hatte jahrelang mit einem Partner gearbeitet. Dieser hatte in der s_code.js jede Menge Code zum Scrapen der Seiten verbaut, weil die internen Prozesse langsam waren und er […]

  11. […] keine Processing Rules nutzt, oder wenn man die Daten wirklich nicht mehr will und auch den Code (s_code.js oder Code auf den Seiten) vereinfachen, dann sollte man das Tracking entfernen, sozusagen an der […]

  12. […] 1: Wie kommt der Trackingcode auf die Microsite, und welcher Trackingcode soll das […]

Sagen Sie Ihre Meinung!

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Autoren
%d Bloggern gefällt das: