Tips zu SAINT Klassifikationen

Klassifizierungen und SAINT haben wir schon öfter erwähnt. Mit SAINT ist es möglich, die in SiteCatalyst gesammelten Daten nachträglich mit Metadaten anzureichern oder sie zu aggregieren. Das hilft ungemein und kann aus einem vollkommen nutzlosen Report einen lesbaren, relevanten Report machen, wenn man es richtig einsetzt.

Wir wollen heute ein paar Tips und Hinweise eher technischer Natur zu SAINT geben.

Tips zur Arbeit mit SAINT

Wer noch nicht weiß wie es geht kann heute lernen, wie man am besten mit SAINT anfängt, wie man Metadaten löscht, daß man jederzeit Fehler korrigieren und Metadaten überschreiben kann, wie man mit Excel und Planung die Klassifizierung von Kampagnencodes teilweise automatisieren kann und vielleicht mehr.

Wie fange ich am besten an?

Erster Schritt ist immer, eine Variable in der Admin Console für Klassifizierungen einzurichten. Das geht recht schnell, die eigentliche Arbeit fängt aber erst danach an: SAINT ist nur sinnvoll, wenn man die bereits gesammelten Daten auch wirklich mit Metadaten anreichert. Wie macht man das? 3 Schritte sind nötig:

1. Daten exportieren,
2. Daten anreichern und
3. Daten wieder hochladen.

Man kann im SAINT Interface ein Template herunterladen und damit anfangen. Sinnvoller ist es aber meist, stattdessen über Browserexport die bereits gesammelten Daten zu exportieren, damit man weiß, was man eigentlich klassifizieren muß.

SAINT Browser Export

Den Export liefert das System in einer Textdatei mit TAB-separierten Feldern, die man einfach in Excel öffnen kann. Das sieht dann so aus:

SAINT leerer Export

Ganz leer ist der Export nicht. Spalte B enthält Daten, die wohl ein Kollege irgendwann einmal hochgeladen haben muß.

Die eigentliche Arbeit beim Klassifizieren besteht darin, die leeren Spalten mit Werten zu belegen. Das sollte dann so aussehen:

SAINT ausgefüllter Export

Wie schon erwähnt sollte man an dieser Stelle soweit es geht automatisieren, also z.B. Makros in Excel benutzen, die in jeder Reihe den Wert einer oder mehrerer Spalten aus der “Key” Spalte ableiten.

Beispielsweise würde man in Spalte F (“Campaign Type”) immer dann “Email” eintragen, wenn der Wert in Spalte A (“Key”) mit “EM” beginnt.

Und jetzt wird auch klar warum es sinnvoll ist, für die Trackingcodes eine gewisse Struktur und Disziplin durchzusetzen: Dann läßt es sich hinterher eben besser automatisieren.

Als nächstes speichert man die Datei wieder als TAB-separierte Textdatei und lädt sie über das SAINT Interface in SiteCatalyst hoch.

Je nach Größe kann es mehr oder weniger lange dauern, bis die Daten dann auch im Report sichtbar sind. Für SiteCatalyst werden die Klassifizierungen zur Zeit 4 mal am Tag hochgeladen, also etwa einmal alle 6 Stunden.

Überschreiben

SAINT ist retroaktiv, weil die eigentliche Zuordnung zu den Metadaten erst beim Aufruf des Reports geschieht.

Beispiel: Der Trackingcode “tw” fällt aktuell unter den Typ “social”. Click-throughs oder andere Success Events oder Metriken, die mit dem Trackingcode “tw” verknüpft sind, tauchen also im “Campaign Type” Report unter “social” auf.

Nun will Marketing aber Twitter gesondert betrachten, also unabhängig von anderen Social Media Sites. Im “Campaign Type” Report soll dieser Traffic also unter “twitter” firmieren, nicht mehr unter “social”.

Das geht ohne Probleme. Einfach in der Spalte F in Zeile 6 “twitter” eintragen und die Datei wieder importieren. Dabei muß man die Checkbox “Overwrite data on conflicts” anticken, damit SAINT den neuen Wert überschreibt.

SAINT Importdialog

Tip: Man kann Werte in Zellen löschen! In meinem Beispiel ist Spalte B nicht länger relevant, daher ersetze ich dort alle Werte mit “~empty~”.

SAINT Zellen löschen mit ~empty~

Alternativ könnte ich auch die Klassifizierung ändern und die “Creative Elements” Komponente einfach entfernen.

Schlagworte: saint, tips

Segment Builder für Fortgeschrittene

Nachdem wir die Funktionsweise der Segmente bereits vorgestellt haben, wollen wir heute etwas tiefer gehen und beschreiben, wie man Container schachteln und damit fast beliebig komplizierte Segmente erstellen kann.

Ganz schnelle Zusammenfassung:

1. ziehe ich einen Container auf den Canvas,
2. definiere ich innerhalb des Containers Rules.

Klingt ganz einfach, wo genau also kann man das kompliziert machen?

Wer sich das Fenster für die Regeldefinition genauer ansieht, wird dort zwei Elemente sehen, die auf mehr Möglichkeiten hindeuten.

Mehr als eine Regel möglich

 

Oben Links unter “This Visitor must match:” kann man definieren ob alle oder nur mindestens eine Regel greifen müssen bzw. muß. Aha! Man kann also mehr als eine Regel definieren!

Genau. Der “Add” Knopf neben der Regeldefinition verschwindet nicht, wenn man eine Regel eingefügt hat. Man kann damit nämlich mehr als eine Regel in die Liste setzen. Das sieht dann so aus:

Zwei Regeln im Container

 Mit mehreren Regeln in einem Container kann ich schon ganz interessante Segmente bauen: “Traffic aller Benutzer, die den Newsletter abonniert oder am Gewinnspiel teilgenommen haben”, oder “Alle Visits, in denen gekauft wurde, und zwar per Kreditkarte”.

Es geht aber noch viel spezifischer und komplexer, denn man kann Container schachteln. Obendrein gibt es noch den “Exclude” Canvas, in dem man ebenfalls mehrere Container mit Rules definieren kann, was dann den Traffic wieder weiter limitieren würde.

Container kombinieren kann man auf zwei Arten: ineinander schachteln oder nebeneinander stellen.

Unterhalb eines Containers kann ich einen spezifischeren Container schachteln, also z.B. einen Visits Container in einen Visitors Container. Anwendungsbeispiel: Traffic für alle Visitors, die gekauft haben, aber nur für Visits, in denen ein bestimmtes Produkt angesehen wurde.

Verschachtelte Segmente

Discoanalogie

Das funktioniert ein bißchen so, als gäbe es vor einem Club mehrere Türsteher, die sich die Gäste nach immer detaillierteren Kriterien ansehen. Wer einen Türsteher (die Regeln in einem Container) passiert, ist noch lange nicht drin denn der nächste legt vielleicht ganz andere Kriterien an.

Nebeneinanderstehende Container sind hingegen laxer. Wenn ein Hit die Rules in einem Container nicht passiert, hat er immer noch die Möglichkeit, durch die Regeln in einem anderen Container durchzuschlüpfen. Anwendungsbeispiel: Traffic aller Visitors, die dem Link einer Kampagne gefolgt sind bzw. aller Visits, in denen das beworbene Produkt angesehen wurde.

Segmente Nebeneinander

Wir haben hier also einen Club mit zwei Eingängen. Die Türsteher entscheiden individuell, ohne sich abzustimmen. Damit hat man als Gast mehrere Chancen: Wer an einer Tür abgelehnt wurde kann es einfach an der anderen nochmal probieren.

Der “Exclude” Canvas erlaubt weitere Regeln zu definieren, diesmal aber Regeln, die Teile der Daten ausschließen. Technisch werden zunächst die Regeln der Container im “Include” Canvas angewendet. Die resultierenden Daten werden dann gegen die Regeln aus dem “Exclude” Canvas getestet.

Testen! Testen! Testen!

Lange Zeit waren Segmente ein Thema für Fortgeschrittene.

Man konnte Segmente mit Data Warehouse benutzen, zum Befüllen von ASI Slots oder in Discover. SiteCatalyst konnte ansonsten nicht mit Segmenten umgehen, die meisten Analysten kamen also nie damit in Berührung.

Das hat sich mit SiteCatalyst 15 gründlich geändert: Segmente sind jetzt “ein Feature für Alle” und daher in den Blickpunkt eines viel größeren Publikums gerückt.

Da es außerhalb von Discover nicht ganz einfach ist, auf Anhieb die Validität eines Segmentes zu kontrollieren, stellt sich natürlich die Frage: Wie macht man das am besten?

Die beste Möglichkeit ist sicher, Testdaten in eine separate Report Suite zu senden und das Segment darauf anzuwenden. Bei Testdaten weiß man natürlich genau, was man getrackt hat und man kann daher auch genau sagen, welche dieser Daten Teil des Segments sein sollen und welche nicht.

Wie macht man das genau?

Eine Report Suite zum Testen kann man sich einfach selber in SiteCatalyst anlegen. Wahrscheinlich hat man sowieso eine, die sollte nämlich bei der Implementierung angelegt worden sein. (Wichtig: wer später Einstellungen in seiner Produktionsreportsuite ändert, muß die natürlich auch für die Entwicklungsumgebung nachziehen!) Ansonsten kann man seinen Account Manager oder ClientCare bitten, eine Kopie der Produktionsumgebung anzulegen.

Testdaten sendet man z.B., indem man sich lokal Webseiten macht. Dazu kann man auf Windows oder Mac XAMPP heranziehen, eine sehr schnell installierte Kombination von Webserver und anderen Tools.

Wie immer beim Testen einer Hypothese (“Dieses Segment tut das, was ich erwarte”) ist es sinnvoll, sich vor dem Test zu überlegen, wie das Resultat aussehen sollte. Es ist viel zu einfach, sich hinterher jedes beliebige Ergebnis “zurechtzuerklären”.

Und was tut man, wenn man keine Tests machen kann oder will?

In dem Falle würde man wahrscheinlich zwei Dinge tun:

1. Die Beschreibung der Regeln für das Segment aufschreiben und sie mit einem Kollegen diskutieren. Das könnte ein Entwickler sein, ein anderer Analyst oder meinetwegen der Pförtner. Vier Augen sehen immer mehr als zwei.
2. Zeitraum einschränken. Wer aus dem Wust an Daten einen Tag herauspicken kann, an dem das Segment Daten enthalten müßte, hat einen klaren Vorteil. Wer dann noch einen Tag finden kann, an dem keine Daten im Segment sein dürften, hat zwei Meßpunkte und damit schon gute Chancen, daß der Test aussagekräftig ist, obwohl er auf echten (und damit unkontrollierbaren) Daten stattfindet.

Selbstverständlich ist es immer besser, die Segmente tatsächlich zu testen. Schon meine Großmutter wußte: “Versuch macht kluch!”

Schlagworte: 15, data warehouse, discover, dwh, segmente, sitecatalyst

Kein Artikel heute

Aus gesundheitlichen Gründen gibt es heute keinen Artikel.

Frage: gibt es irgendwelche Themen, die Sie behandelt sehen möchten?

SiteCatalyst 15 – contextData Variablen & Processing Rules

Zeitgleich mit SiteCatalyst 15 wurden zwei neues Feature freigeschaltet, die weniger mit dem Processing der Daten zu tun haben, also dem eigentlichen Schwerpunkt der Unterschiede zwischen SiteCatalyst 14 und 15, sondern mit der Datensammlung: contextData Variablen und Processing Rules.

Die beiden sind eng verknüpft: Processing Rules werden überwiegend mit contextData Variablen benutzt, und contextData Variablen sind ohne Processing Rules sogar sinnlos.

contextData Variablen

Eine typische Komplikation bei jeder Implementierung ist die Übersetzung von Semantik einer Variablen zu ihrem Namen. Consulting händigt am Ende einer Implementierung ein Dokument aus: Das “Solution Design Reference” Spreadsheet oder “SDR” enthält einer Liste aller Variablen und definiert, wofür sie genutzt werden.

Theoretisch sollte ein Entwickler jede Seite korrekt implementieren können, wenn er nur das SDR hat. Das ist in der Praxis nicht immer so, und vor allem läßt umgekehrt der Code auf einer Seite keine direkten Rückschlüsse zu auf den Zweck einer Variablen.

Die contextData Variablen sollen das ein Stück vereinfachen. Anstatt die Werte in eVars und props zu schreiben, weist man sie semantisch korrekt benannt zu. Also nicht:

s.prop1 = "Damenmoden";
s.prop2 = "Hosen & Röcke";

Sondern stattdessen:

s.contextData['Abteilung'] = "Damenmoden";
s.contextData['Bereich'] = "Hosen & Röcke";

Natürlich “weiß” SiteCatalyst nicht, was eine ‘Abteilung’ ist. Die Zuweisung konfiguriert man daher einmalig. Die eigentlichen Werte landen letztendlich wieder in s.prop1 und s.prop2 und zwar mithilfe der Processing Rules.

Ziel der contextData Variablen ist wie gesagt, Entwicklern das Leben einfacher zu machen und einen direkten Bezug zwischen Semantik und Inhalt herzustellen.

Processing Rules

Mit Processing Rules kann man Werte in Variablen schreiben (props, eVars und events), basierend auf anderen Informationen im gleichen Request.

Das hört sich erstmal recht einfach an, kann aber weitreichende Auswirkungen haben, je nach Umgebung.

Wer schon mit VISTA Rules gearbeitet hat, wird die zugrundeliegenden Konzepte wiedererkennen: Processing Rules können die Daten des aktuellen Tracking Calls lesen und teilweise modifizieren.

Verarbeitungsreihenfolge

Die Grafik soll zeigen, wo genau im Prozeß die Processing Rules ausgeführt werden: vor den VISTA Rulesund dem Prozeß für Marketing Channels.

Was kann mit Processing Rules machen?

• Einfache Regeln
• Werte aus URL oder Query String auslesen
• Werte aus SiteCatalyst Variablen lesen (inklusive contextData!)
• Werte zusammenfassen
• SiteCatalyst Variablen einen Wert zuweisen

Was kann man mit Processing Rules nicht machen?

• Hits in eine andere Report Suite umleiten
• IP-basierte Ausschlußregeln
• Werte auftrennen (z.B. “logged in|Homepage” in “logged in” und “Homepage” zerlegen)

Die Anwendungsbeispiele aus dem Originalposting gefallen mir ganz gut, daher:

Beispiel 1 – URL Parameter

Ähnlich wie mit dem getQueryParam Plugin kann man Kampagnencodes für’s Tracken der Kampagnen auch direkt mit einer Processing Rule aus der URL lesen und der Variablen s.campaign zuordnen. Das geht so:

Processing Rules für Kampagnentracking

Vorteil einer Processing Rule: man kann die ohne Deployment schnell einstellen, bricht also aus dem Releasezyklus aus. Weiterer Vorteil: Die s_code.js Datei kann kleiner ausfallen. Das ist besonders bei Sites die für Mobile optimiert sind durchaus etwas wert.

Beispiel 2 – Event setzen

Angenommen wir haben im letzten Monat endlich das Release gehabt mit dem interne Suche getrackt wird. Heute merken wir, daß zwar die Suchbegriffe in die entsprechende eVar getrackt werden, der event wird aber nicht gesetzt. Ein Fehler! Der nächste Release ist in 6 Wochen. Autsch.

Mit Processing Rules kann man den event in der Zwischenzeit setzen, und zwar basiert auf entweder der eVar oder dem Namen der Suchergebnisseite.

Wie bekomme ich Processing Rules?

Die Kollegen bei ClientCare können den Zugriff auf Processing Rules für zertifizierte Benutzer freischalten.

Warum braucht man eine Zertifizierung? Adam Egbert sagt das so: “Essentially, by giving you access to these features, we are also giving you the power to royally mess up your implementation!” Schön gesagt.

Wie man sich zertifiziert, beschreibt Artikel 10655 in der Knowledge Base. Die Zertifizierung kostet nichts.

Die beste Vorbereitung auf den Test ist die Dokumentation, Trainings gibt es meines Wissens zur Zeit nicht.

Schlagworte: 15, contextData, implementierung, mobile, plugins, processing rules

Aktuell: Neu in SiteCatalyst 15.3

Gestern am späten Abend ging SiteCatalyst 15.3 live. Wer sich heute schon eingeloggt hat, wird einige Neuigkeiten bemerken sowie die eine oder andere Änderung.

Warum das Release “15.3″ heißt, ist uns nicht ganz klar, denn eigentlich hätte es mindestens eine “15.5″ verdient. Product Management sieht das Release aber eher unter dem Gesichtspunkt “Accuracy”, weniger als ein Featurerelease.

Einiger der Änderungen sind übrigens auch in SiteCatalyst 14 zu sehen!

Reports wieder da

Zunächst sind einige der aus SiteCatalyst 14 bekannten Reports wieder verfügbar, die es zwischenzeitlich nicht gab. Für viele Reportsuites werden sogar die Daten aus der Zeit seit der Migration verfügbar sein! Die folgenden Reports sind jetzt wieder da:

• Full Paths
• Pathfinder
• Path Length
• Original Entry
• Days Before First Purchase
• All Search Page Ranking Reports
• Pages Not Found

Filterung von Bots und Spiders

Neu ist auch die Möglichkeit, direkt aus der Admin Console heraus Filterung für Bots und Spiders anzuschalten. Anders als die “Bots & Spiders” VISTA Rule leitet diese Filterung die Hits nicht in eine separate Reportsuite um, sondern gefilterte Hits landen in 2 neuen Reports: Bots und Bot Pages. Die Hits landen nur in diesen 2 Reports!

Die Liste der Bots und Spiders stammt vom IAB und wird einmal im Monat abgeglichen. Das ist ein großer Vorteil gegenüber der VISTA Rule, für die man die Liste selber pflegen muß. Wer einen Zugang zur IAB hat, kann sich die Liste der Bots und Spiders dort ansehen.

Änderungen für Uniques Exceeded

Des weiteren werden ab heute die (un)beliebten “Uniques Exceeded” anders gehandhabt, und zwar sind die nicht mehr wie bisher ein einfaches Überlaufbecken, sondern sie werden in Zukunft die am wenigsten besuchten Werte zusammenfassen.

Grob werden Werte in 3 Gruppen eingeteilt (“die mit vielen Hits”, “die mit wenigen Hits” und “die mit mittelvielen Hits”). Wo genau diese Teilung stattfindet ist Reportsuite-spezifisch. Wenn eine Variable über den Grenzwert geht (was früher die 500000 individuellen Werte waren), werden alle Werte aus der “die mit wenigen Hits” Gruppe zusammengefasst. Es gibt einen zweiten Grenzwert, ab dem dann auch Werte aus der “die mit mittelvielen Hits” Gruppe zusammengefasst werden.

Die Grenzwerte selber werden in Zukunft (nicht sofort) höher liegen als 500000, und man wird sie gegen Geld auch erhöhen können.

Resultat der Änderung ist, daß man in Zukunft nicht mehr “Uniques Exceeded” oder “Unidentified” am oberen Ende der Reports sehen sollte. Der Long Tail wird also zusammengefaßt, nicht die wichtigen Werte am oberen Ende.

Der neue Auffangbehälter wird übrigens zunächst weiter “Uniques Exceeded” heißen, das soll sich aber bald ändern.

Die Änderung betrifft SiteCatalyst 14 und 15.

Zu diesem Thema wird es einen separaten Artikel geben. Mehr Details gibt es auch auf Englisch im Adobe Blogartikel.

Groß-/Kleinschreibung bei Traffic Variables

Traffic Variables (props) waren bisher “case sensitive”, d.h. s.pageName=”Home” und s.pageName=”home” waren zwei unterschiedliche Seiten. Bei den eVars war das anders.

Seit gestern ist das nun konsistent, auch props sind nicht mehr case sensitive.

Code H.24.4

Seit heute steht der neue Code H.24.4 zur Verfügung. Ausnahmsweise ist die Empfehlung für alle Kunden, diesmal upzudaten. Warum?

Im Code H.24.4 ist ein Mechanismus eingebaut, der mit dem vorzeitigen Laden von Seiten in Google Chrome umgehen kann. Google Preview zeigt eine verkleinerte Ansicht der Seite schon an, bevor die Seite wirklich im Browser geladen wird. In der Vergangenheit hat das zu Page Views geführt, H.24.4 enthält aber Code, der den Trackingrequest erst absendet, wenn die Seite tatsächlich geladen wird.

Das funktioniert zur Zeit nur für Chrome.

Wer mehr Details möchte, sollte sich Ben Gaines Artikel ansehen. (Ja! Ben Gaines ist wieder da!)

Schlagworte: 14, 15, bots, uniques exceeded

VISTA

Dieser Artikel soll einen viel benutzten aber selten wirklich verstandenen Teil der SiteCatalyst Architektur vorstellen: VISTA Rules.

Die interne Folklore sagt, VISTA sei ein Akronym und stehe für “Visitor Identification, Segmentation & Transformation Architecture”. Das hört sich erstmal kompliziert an, schreit also nach einer Erklärung.

Weil VISTA in der Tat recht flexibel ist, sieht man sich VISTA Rules am besten unter zwei verschiedenen Gesichtspunkten an:

1. Was passiert, wenn eine VISTA Rule bei der Datensammlung im Spiel ist?
2. Was kann man mit so einer VISTA Rule tun und was nicht?

Was ist VISTA?

VISTA ist ein Mechanismus, mit dem man Daten in SiteCatalyst ändern kann, und zwar nachdem sie gesammelt aber bevor sie gespeichert wurden.

Mit anderen Worten: Nachdem ein Browser einen Trackingcall abgeschickt hat und dieser auf den SiteCatalyst Servern in Empfang genommen wurde, kann man die Daten im Call per VISTA Rule noch ändern, bevor sie dann bearbeitet und in die entsprechenden Reports abgelegt werden.

Die VISTA Rule hat Zugriff auf alle im Trackingcall gesendeten Daten sowie einige der HTTP und IP Header (z.B. die IP Adresse des Besuchers). Die meisten aber nicht alle dieser Datenfelder kann die VISTA Rule verändern. Darüberhinaus kann sie Daten in eine andere Reportsuite kopieren oder als “nicht anzeigen!” markieren.

Eine VISTA Rule hat keinen Zugriff auf historische Daten. Jeder Trackingcall ist wie Neuland für die VISTA Rule. Sie hat auch keinen Zugriff auf bereits gespeicherte Werte wie z.B. eVars oder s.campaign.

Wie genau muß man sich so eine VISTA Rule vorstellen?

Eine VISTA Rule ist ein kurzes Programm. VISTA Rules werden von den Kollegen bei “Engineering Services” programmiert und implementiert. Die Palette geht dabei von Standard VISTA Rules bis hin zu hochgradig komplexen und angepaßten Spezialregeln.

Wer ein Login hat, kann sich die Standardlösungen und das Portfolio ansehen.

VISTA Rules kosten Geld, und zwar sowohl das Anlegen als auch zukünftige Änderungen.

Wenn eine VISTA Rule implementiert ist, wird fortan jeder Trackingcall durch VISTA geschickt. Die VISTA Rule bearbeitet den Call und ändert je nach Zweck einzelne Felder.

Was kann man mit VISTA Rules machen und was nicht?

• Die IP Exclusion VISTA Rule sieht sich für jeden Trackingcall die IP Adresse des Browsers an und schickt Calls von internen Adressen in eine separate Reportsuite.
• Mit einer VISTA Rule kann man Daten aus einer SiteCatalyst Variable in eine andere kopieren, z.B. Tracking Codes von s.campaign in eine eVar mit anderer Allokation (damit man first und last touch auswerten kann).
• VISTA kann z.B. Daten aus Geosegmentation oder Technology Reports in props und/oder eVars kopieren.
• Einen Success Event oder eine Variable setzen, wenn ein URL Parameter oder die URL passen.
• Daten entschlüsseln, die zuvor mit JavaScript im Browser verschlüsselt und damit nicht im Klartext über’s Netz gesendet wurden.
• Visits in Kanäle einteilen (“Unified Sources”).
• Traffic von Bots und Spidern in eine getrennte Reportsuite leiten.
• …

Es gibt zwei verschiedene Typen von VISTA Rules, die “normalen” VISTA Rules, bei denen die Logik komplett in Code gegossen wird, und die DB VISTA Rules, die mit einer Lookuptabelle arbeiten, welche man anpassen kann. Letztere beschreiben wir in einem künftigen Posting genauer.

Wann benutzt man VISTA Rules?

Es gibt eine ganze Reihe von Szenarios, in denen VISTA Rules sinnvoll sind.

Erstens die schon erwähnten Fälle, in denen man Daten aus einem der eingebauten Reports wie z.B. Geosegmentation zum Segmentieren aller möglichen Reports benötigt. VISTA kann die Daten aus den Reports in eine prop und/oder eVar kopieren und sie damit überall in SiteCatalyst verfügbar machen.

Zweitens wenn man aufgrund bestimmter Informationen den Traffic in verschiedene Reportsuites tracken will. Hierunter fallen Dinge wie die Erkennung und Sonderbehandlung von Bots oder internen IP Adressen, aber man kann auch Daten in mehrere Reportsuites tracken so wie beim Multi-Suite Tagging, oder man kann Sampling implementieren.

Drittens kann eine VISTA Rule Daten beliebig bearbeiten. Die schon erwähnte Entschlüsselung von vorher in JavaScript verschlüsselten Daten ist ein gutes Beispiel für diese Anwendung. Manche Websites verschlüsseln die Kundennummer, bevor sie im Trackingcall gesendet wird.

Viertens kann man mit VISTA Daten aggregieren. Beispiel: Eine Website trackt die Visitnummer in eine eVar. Mit VISTA kann ich diese Nummer einer Gruppe (z.B. “Wiederkehrer”) zuordnen und die Gruppe in eine weitere eVar schreiben. Gegenüber SAINT hat das den Vorteil, daß man später weniger Aufwand hat.

Fünftens kann man Dinge implementieren, die man zur Zeit auf der Website nicht machen kann, sei es weil der Releasezyklus zu lange dauert, oder weil das CMS es schlicht nicht kann.

VISTA ist so flexibel, daß sich diese Liste beliebig erweitern ließe. Daher unsere Frage: Benutzen Sie VISTA? Wofür?

Schlagworte: implementierung, Javascript, vista

Wie funktioniert ClickMap?

Ben Gaines beschrieb vor ziemlich genau drei Jahren, wie er beim ersten Kontakt mit ClickMap beeindruckt war, und wie er sich fragte, was wohl die Technik hinter den fast wie Magie anmutenden Overlays sein mochte. Ben wäre nicht Ben, wenn er nicht anschließend einen hervorragenden Artikel daraus gemacht hätte. Den möchten wir heute nachvollziehen.

Überblick

ClickMap besteht aus zwei Komponenten:

1. Datensammlung und
2. einem Browser Plugin.

Das Plugin ist für die Anzeige der Daten zuständig, d.h. es kann auf einer Seite die gesammelten Daten als Overlay über die Links einblenden. Man hat damit einen sehr visuellen Eindruck davon, welche Links oder Elemente auf der Seite wichtig sind.

Und man kann in ClickMap nicht nur Klicks als Metrik heranziehen, sondern auch relevantere Metriken wie Umsatz oder Success Events.

Wie aber werden die Daten gesammelt?

Wenn der Browser eine Seite lädt, initialisiert er den SiteCatalyst Code. Bei dieser Initialisierung (die mit der s_gi() Methode geschieht) wird unter anderem ein onClick-Handler an document.body angefügt.

Der Handler wird immer dann aufgerufen, wenn der Benutzer ein Element auf der Seite anklickt. Der Handler bestimmt dann eine “Object ID” und schreibt diese entweder in den “s_sq” Cookie (bei “normalen Links”) oder schickt sie an SiteCatalyst (bei Exitlinks, Downloads oder Custom Links). Daten aus dem “s_sq” Cookie werden auf der nächsten Seite gesendet.

Das Plugin benutzt später die Daten und zeigt sie als Overlay über der aktuell im Browser dargestellten Seite an.

Woher weiß das Plugin, welche Daten genau es benutzen muß?

Erstens sieht sich das Plugin den Namen der aktuell geladenen Seite an, also den Inhalt der s.pageName Variable. Im Debugger kann man diesen Wert unter dem Parameter “pid=” sehen.

Das bedeutet natürlich, daß ClickMap nur solange Daten anzeigen kann, wie der Name sich nicht ändert. Dynamische Seitennamen oder Änderungen werfen ClickMap aus der Bahn.

Tip: Es bedeutet auch, daß man sich eine lokale Kopie einer Seite machen und das Plugin darauf benutzen kann. Sinnvoll vor Redesigns.

Zweitens identifiziert das Plugin wie erwähnt individuelle Links über ihre “Object ID”. Im Debugger taucht die als URL Parameter “oid=” auf.

Wenn das ClickMap Plugin also für die aktuelle Seite und den aktuellen Link Daten im Backend findet, blendet es ein Overlay ein.

Drittens benutzt der Initialisierungscode die document.all() Methode um jedem Link auf der Seite eine numerische ID zuzuweisen. Die sieht man im Debugger unter dem URL Parameter “oi=”, wenn der Code sie überträgt. Eine numerische ID nicht immer nötig, darauf kommen wir gleich.

So weit so gut.

Object ID?

Die “Object ID” berechnet ClickMap normalerweise selber. Es zieht dazu die URL des Links heran.

Das kann unter zwei Umständen problematisch sein.

Einerseits gibt es auf vielen Seiten mehrere Links mit gleichem Ziel. Man denke nur an die allgegenwärtigen “Homepage” Links auf praktisch jeder Seite im Web, oder daran, daß es meist mehr als nur einen “Buy >” Knopf gibt.

Die “Object ID” eines Links ist also nicht unbedingt eindeutig und daher braucht das System noch die numerische ID, die sich grob aus der Position des Links auf der Seite ableitet. Der “Home” Link oben links ist also ein anderes Objekt als der “Home” Link ganz unten im Footer.

Browser sehen allerdings eine Seite nicht nur grafisch (das tun sie natürlich, sonst würden wir nichts sehen). Intern speichern Browser eine HTML Seite aber in einer Repräsentation namens “Document Object Model” oder kurz “DOM”. Die Position eines Links auf der Seite wie wir sie sehen hat leider mit der Position im DOM nichts gemein. Der Code nutzt aber die Position im DOM für die Berechnung der numerischen ID.

Das bedeutet: Wenn der Webdesigner beschließt Code der Seite zu ändern, kann das ClickMap aus dem Trab bringen. Das gilt sogar, wenn die Änderungen keinerlei optische Auswirkungen haben. Beliebtes Beispiel: Das Menü auf der linken Seite wird im Code hinter den Inhalt der Seite gestellt und per Style bei der Darstellung nach links geschoben.

Das klingt akademisch, wird aber für SEO oder die Optimierung für Mobilgeräte durchaus gemacht.

Zweitens sind solche Links problematisch, die per URL Parameter auf verschiedene Seiten zeigen, z.B. http://www.test.com/?page_ID=1630.

Die “Object ID” dieses Links wäre “http://www.test.com/?page_ID=1630″, aber in SiteCatalyst werden als Standard bei URLs die Parameter nicht gespeichert. (Kann man ändern, das hat aber Seiteneffekte.) Das bedeutet, daß ClickMap nicht sicher wissen kann, welcher Link denn nun genau mit “http://www.test.com/” gemeint war.

Wie kann man ClickMap helfen?

Man kann ClickMap die Arbeit erleichtern und gleichzeitig die Zahlen verbessern, indem man die “Object ID” für die Links im onClick-Handler spezifiziert.

Damit werden alle Unsicherheiten bzgl. “Object ID” und numerischer ID eliminiert und ClickMap weiß ganz genau, welcher Link welcher ist, solange die “Object ID” eines Links sich nicht ändert.

Wie setzt man die “Object ID”?

Es genügt, dem Link einen onClick-Handler zu spendieren und in diesem die Variable “s_objectID” zu setzen, z.B. so:

<a href=“http://www.test.com/?page_ID=1630″ 
   onclick=“var s_objectID=‘homepage_link1’;”>

Das ist ein recht großer Aufwand, wenn man es wirklich mit allen Links auf allen Seiten einer Website machen will. Das sollte aber vielfach gar nicht notwendig sein.

Wer wirklich für alle Links “Object ID”s berechnen will kann sich bei Consulting nach dem entsprechenden Plugin erkundigen. Das ist allerdings nicht frei verfügbar.

Ein großer Vorteil der “s_objectID” Variable ist noch, daß man damit Unterschiede zwischen Browsern überspielt. Firefox und IE geben unterschiedlich viel Informationen über Linkpositionen preis. Das führt dazu, daß ein und dieselbe Seite im ClickMap Plugin für Firefox anders aussehen kann als im Plugin für IE. Wer aber “s_objectID” setzt, sieht in beiden Browsern das gleiche.

Schlagworte: clickmap, cookies, implementierung, Javascript, klicktracking