Lamont Crook, einer der wirklich guten Kollegen bei Adobe (leider in Orem), hat vor ein paar Wochen per Blogartikel das Thema TagManager und Tagging ohne Javascript angesprochen.
Die Idee dahinter ist naheliegend, oder besser gesagt das Problem mit aktuellen Implementierungen: Templates oder sogar einzelne Seiten per Javascript zu taggen kann aufwendig sein und vor allem gehört es nicht zum angestammten Umfeld der Entwickler, daher fällt es in vielen Unternehmen schwerer als man meinen sollte.
Ich persönlich kann eine Seite innerhalb weniger Minuten korrekt taggen, aber das geht natürlich nur, weil ich a) weiß was die ganzen Tags bedeuten, b) eine gute Vorstellung davon habe, welche Daten ich eigentlich sammeln sollte und c) die komplette Kontrolle über meine Website habe.
In jedem Unternehmen das groß genug ist SiteCatalyst zu benutzen, sind mindestens zwei dieser drei Punkte in der Hand verschiedener Teams, ublicherweise sind sogar mehr als drei Teams beteiligt, manche davon extern. Dazu kommen Prozesse und schon werden aus den Minuten Wochen oder Monate.
Ein Marketer, der etwas auf sich hält wird das nicht akzeptieren wollen und daher nach Alternativen suchen.
Schneller
TagManager (und natürlich ähnliche Lösungen von anderen Anbietern) versprechen eine
Linderung des Problems.
Tatsächlich können sie dazu benutzt werden, für das Tagging wichtige Informationen aus dem HTML der Templates oder der Seite zu extrahieren. Dadurch entfällt das Taggen des Templates und damit ein wichtiges Nadelöhr.
Aber…
Man erkauft sich das mit einer nicht zu verachtenden Komplexität des Codes im TagManager sowie einer zusätzlichen (impliziten) Abhängigkeit, vulgo die Lösung ist wacklig. Der Code im TagManager macht bei solch einer Lösung nichts anderes als Scraping.
Sobald die Struktur des Templates oder der Seite sich ändert, muß im Zweifelsfall auch der Code geändert werden. Anders gesagt: Jedes neue Release der Website macht potentiell das Tracking kaputt. Dazu kommt, daß die Abhängigkeit implizit ist, die Entwickler der Seite also nicht wissen, bei welchen Änderungen sie dem Webanalysten Bescheid geben müssten und bei welchen nicht.
Ohne Javascript
Lamont Crook schlägt vor, die Abhängigkeit explizit zu machen, den HTML Code also ganz offiziell für’s Tagging zu benutzen. Wohlgemerkt nicht Javascript sondern das HTML.
Beispiel Seitenname: Man einigt sich mit den Webentwicklern, daß der Name einer Seite, egal ob er in einem <h1> Tag steht, einem <div> oder einem <p> immer mit einem bestimmten „id“ und/oder „class“ Attribut versehen wird:
Aus <h1>Homepage</h1>
wird <h1 class="tag" id="pageName">Homepage</h1>
Und was soll das?
Im TagManager kann ich jetzt Code einbauen, der ganz offiziell scraped.
Mein Code würde alle Elemente aus dem HTML lesen, die im class Attribut „tag“ stehen haben. Anhand der id dieser Elemente oder anderer Eigenschaften kann der Code entscheiden, welche Variable in SiteCatalyst den Wert aufnehmen soll. Bei Elementen mit einer id kann der Code auch direkt auf das Element zugreifen, in unserem Fall mit s.pageName also etwa:
s.pageName=$('#pageName').innerHTML();
(Wer sowas ohne jQuery oder ähnliche Helfer macht, der hört auch Eurythmics und beantwortet Spam aus Nigeria.)
Weil die Abhängigkeit explizit ist, weiß der Webentwickler, daß er class und id übernehmen muß, falls er bei einem Redesign entscheidet, den Namen der Seite ab jetzt in ein <p> zu schreiben. Der Code im TagManager funktioniert so ohne Änderungen weiter. Und falls sich id oder class ändern müssen weiß der Webentwickler, daß er den Webanalysten informieren muß.
Diskussion
Die Idee ist gut, keine Frage.
Ein Teil der Komplexität der Implementierung wandert in den Verantwortungsbereich der Person, die sich am ehesten damit identifizieren kann. Durch die explizite Abhängigkeit wird auch gleich der Kommunikationskanal definiert und sinnvollerweise ein Prozeß auf beiden Seiten.
Daten aus dem Backend, die getrackt werden sollen aber nicht auf der Seite dargestellt kann man einfach über Elemente im der Seite mitliefern, oder man blendet sie mit CSS aus (style="display: none;").
Wenn sich die Anforderungen an’s Tagging ändern muß im Idealfall nur der Code im TagManager geändert werden. Wer zum Beispiel bisher die s.products Variable benutzt hat um Ad Impressions zu tracken, jetzt aber lieber eine list Variable nutzen möchte, kann die Änderung komplett im Code machen, ohne dabei die Seite oder das Template anzufassen.
Sogar onClick Handler für’s Linktracking kann man dynamisch erzeugen und zuweisen.
Das größte Problem dürfte die Akzeptanz sein, je nach Branche: Der (eventuell externe) Betreiber der Plattform dürfte es nicht gerne sehen, daß hier JS Code „an der Plattform vorbei“ eingeschleust wird.
Ob man sich mit dem Betreiber auf Richtlinien, Testprozeduren oder ein Abnahmeprotokoll einigen kann hängt wie gesagt von der Branche ab, sowie vom Betreiber selber. Wer für die Webanalyse auf einer Bankenwebsite verantwortlich ist wird es schwerer haben als der Webanalyst bei „meinekleineholzspielzeugfabrik.de“ (gibt’s das? nein, ok.)
Auch nicht zu unterschätzen: Der Webanalyst baut im TagManager potentiell sehr komplizierten Code zusammen, der bei seinem Weggang je nach Nachfolger nicht mehr wartbar sein könnte. Dieser Nachteil ist dank der expliziten Abhängigkeit aber weniger unangenehm als bei echtem Scraping.
Ein kleiner Vorteil ganz nebenbei: das HTML wird kleiner, wird also schneller ausgeliefert. Potentiell läßt sich auch die Anzahl der Javascript Dateien verringern, ideal sendet man genau eine. Das ist für all die Smartphones und 3G-Nutzer auf Achse nicht unwichtig. Natürlich wird dafür mehr Javascript ausgeliefert, das beeinträchtigt aber nicht wie sich die Ladezeit anfühlt.
Ich denke, die Idee ist es wert, genauer unter die Lupe genommen zu werden.
Dabei geht es weniger um die Technik, also das Programmieren, sondern eher um die Abhängigkeiten im Betrieb: Wer muß zustimmen? Hat die Webanalyse genug Mittel, die zusätzliche Verantwortung zu übernehmen? Welche Abhängigkeiten bestehen mit dem Releasezyklus? Wer ist für die Abnahme des Codes verantwortlich?
Technische Fragen stellen sich natürlich auch: Inwieweit erlaubt das eingesetzte CMS eigentlich die freie Vergabe von class und id Attributen? Ist der Webanalyst gut genug im Umgang mit Javascript? Will man auch solche Benutzer tracken die kein Javascript zulassen?
Frage: Hat hier jemand sowas schon implementiert oder benutzt? Wie gut funktioniert das im praktischen Einsatz?
Ich persönlich kenne nur ein Beispiel: Ein Partner hatte die s_code Datei um Scraping ersetzt, weil der Betreiber der Site (ein anderer Partner) nicht fähig oder willens war, funktionierendes Tracking zu implementieren. Nachdem der Kunde den Vertrag mit dem Partner nicht verlängerte wurde es faktisch unmöglich, den Code zu pflegen und neue Releases der Site haben daher Teile des Trackings zerstört.
Ich gehe wie gesagt davon aus, daß sich das mit der hier beschriebenen Methode nicht so verhalten hätte.
Pingback: Visitors & hybride Apps | Webanalyse auf Deutsch