Tracking entfernen

Wer meinem Rat folgt und Ein Ding zur Zeit analysiert, der muß konsequenterweise auch von Zeit zu Zeit Trackingcode entfernen.

Beispiel: Marketing hat in Zusammenarbeit mit der Bundesliga ein Gewinnspiel gestartet. Dazu wurde eine Microsite eingerichtet, auf der Besucher sich eintragen und dann das Spiel spielen können.

Die Microsite wurde komplett vertaggt, inklusive verschiedener Aktionen wie z.B. Besucher meldet sich an, erster Start des Spiels, Start des Spiels, Share und Like Buttons usw… Links von der Microsite zur eigentlichen Website wurden mit Trackingcodes versehen.

Jetzt, Monate später, läuft das Spiel nicht mehr, die Microsite dümpelt vor sich hin, niemand interessiert sich mehr für die Daten. Deshalb: Das Tracking muß weg! (Und die Microsite natürlich auch, aber das ist uns ja egal.)

Was kann weg?

Wir erinnern 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 platzieren.

Die s_code.js ist die Grundlage, ohne diese Datei wird nicht getrackt, weil der Browser von Haus aus ja erstmal gar nicht weiß, was Webanalyse ist oder wie das geht.

Auch ohne den Code auf der Seite wird nicht getrackt, denn hier wird erst die s.t Funktion aufgerufen, die den Trackingrequest absendet.

„Ah!“ denkt sich der schlaue Leser jetzt, „dann kann ich ja einfach eine der zwei Dinge entfernen und damit ist die Sache erledigt!“

Jein.

Hier muß man ein wenig ausholen und eines dieser häßlichen Monster der Neuzeit hinter dem Sofa hervorholen: Den Releasezyklus.

Javascript von einer Seite zu entfernen (oder gar von allen) bedeutet normalerweise, daß man der IT oder einem Partner einen Change Request sendet. Dieser benötigt Zeit und oft muß auch dafür bezahlt werden. Vor diesem Hintergrund ist es nur verständlich, daß Tracking oft eben nicht entfernt wird.

Wer ein Tag Management System einsetzt, ist fein raus, denn in einem TMS kann man üblicherweise für einzelne Seiten oder ganze Sites gezielt Tags einfach so abschalten. Ohne TMS jedoch muß die IT oder der Partner an’s Werk gehen.

Die Frage ist also: Wie handhabt man das am besten?

Planung

Fangen wir mal mit der idealen Lösung an: Planung.

Wer schon öfter Microsites geplant und benutzt hat, der weiß auch daß eine Microsite einen „Lebenszyklus“ hat, der mit der Planung anfängt, gefolgt von Implementierung und Go-live. Mit ein wenig Erfahrung lernt man dann, daß der Zyklus nach dem Go-live eben nicht zuende ist, sondern daß vermutlich noch weitere Phasen folgen, in denen angepaßt wird und irgendwann dann abgeschaltet. Jede Microsite sollte irgendwann den Weg alles Irdischen gehen.

Wer sowas von Anfang an plant, der bezieht die späteren Phasen von vornherein mit ein, IT oder Partner wissen also im Voraus, daß sie zu einem späteren Zeitpunkt das Tracking entfernen sollen. Planung und Budget sind damit erledigt und Marketing muß nur noch dafür sorgen, daß der Plan auch umgesetzt wird.

Davon träumen wir jedenfalls alle.

Wie wäre es stattdessen mit der einfachsten Lösung?

Stop statt Weg

Wer dank Releasezyklus keinen direkten Zugriff auf den Code der Microsite hat, trotz Releasezyklus aber die s_code.js Datei modifizieren kann, der könnte das Tracking stoppen, anstatt es zu entfernen.

Das funktioniert ab Version H.25.3, die im Januar 2013 herauskam so:

Innerhalb der s_doPlugins Methode in der s_code.js fügt man irgendwo die Zeile s.abort = true; ein.

Da s_doPlugins bei jedem Aufruf von s.t() oder s.tl() aufgerufen wird, bevor der Trackingrequest abgesendet wird, kann man mit dem s.abort Flag das komplette Tracking abschalten.

Ja, aber…

Ich weiß, es geht hier nicht um das gesamte Tracking, sondern nur um die Microsite.

Wenn die Microsite eine eigene s_code.js benutzt, ist das kein Problem. Falls aber eine gemeinsame s_code.js für die Microsite und andere Websites eingesetzt wird, dann muß man vorsichtiger sein.

In diesem Fall ist es sinnvoll, in der s_doPlugins Code einzubauen, der die URL der Seite abfragt und nur dann s.abort setzt, wenn die URL zur Microsite gehört.

Beispiel: Wenn ich als Betreiber von jan-exner.de und meinetwegen exner-gewinnspiel.de auf beiden Sites die gleiche s_code.js benutze und das Tracking nur auf exner-gewinnspiel.de abschalten will, dann könnte mein Code beispielsweise so aussehen:

	function s_doPlugins(s) {
	  if (window.location.host == 'exner-gewinnspiel.de') {
	    s.abort = true; // do not track here
	  }

	  // rest of doPlugins code here
	  // ...
	}

Ob man hier window.location benutzt oder document.url dürfte Geschmackssache sein, bzw. man sollte sich nach dem aktuellen Browserbugwetterbericht orientieren.

Übrigens: Für Trackingcode älter als H.25.3 konnte man einen ähnlichen Effekt erzielen, indem man einfach s.t und s.tl überschrieb.

Sicherheit

Wer auf Nummer Sicher gehen will, entfernt zunächst den Code auf allen Seiten.

Das wird sicherlich in Absprache mit der IT oder dem Partner und im nächsten Fenster im Releasezyklus geschehen müssen. Da wir hier von einer Microsite reden, kann es durchaus sein, daß es auch um mehrere und verschiedene Releases geht. Das ist überhaupt kein Problem, denn das Entfernen des Codes von einer Seite betrifft eben nur diese eine Seite!

Wenn dann der Code von allen Seiten verschwunden ist, dann kann man auch die s_code.js Datei vom Webserver löschen, denn sie wird ja jetzt nicht mehr gebraucht.

Und woher weiß man, wann der Code überall entfernt wurde?

Das kann man zum Beispiel in SiteCatalyst — sorry, in Reports & Analytics sehen. Einfach den Site Metrics > Page Views Report für die Microsite ansehen. Wenn dort seit der letzten Änderung nur noch 0 steht, dann sind alle Tags entfernt worden, oder es gab keine Besucher mehr auf der Microsite!

Man sollte dann noch einige Zeit warten um sicherzugehen. Oder man klickt sich selber einmal durch die komplette Microsite durch und checkt nocheinmal, ob Page Views angefallen sind oder nicht.

Und wenn man sich sicher ist, löscht man wie gesagt die s_code.js.

Wie man es nicht macht!

Oft gesehen habe ich eine Methode, die ganz eindeutig nicht gut ist: Einfach die s_code.js Datei vom Server entfernen.

Das funktioniert natürlich hervorragend, was das ursprüngliche Ziel angeht: Ohne die Definition des Trackingcodes in der s_code.js kann der Browser nicht wissen, was er mit einem Call auf s.t() anfangen soll, es findet folglich keinerlei Tracking mehr statt.

Aber!

Der Javascript Code auf der Seite ruft ja nachwievor s.t() auf, und das führt zu Fehlermeldungen im Browser und eventuell sogar Fehlern auf der Seite selber, jedenfalls wenn die Seite Javascript einsetzt.

So etwas ist schwer vorhersehbar und ob die Benutzer tatsächlich etwas von Fehlern bemerken, hängt nicht zuletzt vom Browser ab.

Merke: Google und Mozilla verbessern ihre Browser mehr oder weniger andauernd, man kann sich also hier auch nicht auf hausinterne Tests verlassen.

Dieser Weg ist also nicht zu empfehlen!

Ü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 Tips & Tricks
2 comments on “Tracking entfernen
  1. […] reichte dabei von technisch motivierten Artikeln (Cookies, Back to the Basics – Vorbereitung, Tracking entfernen) bis hin zu purer Meinungsäußerungen (“Nein” Sagen!, Analytics und ROI, Warum hat […]

  2. […] mehr will und auch den Code (s_code.js oder Code auf den Seiten) vereinfachen, dann sollte man das Tracking entfernen, sozusagen an der […]

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: