Es ist sicher kein Geheimnis, daß unsere Branche noch recht jung ist, vorsichtig ausgedrückt.
Während wirklich jeder weiß, was ungefähr die Zahl der „PS“ bei einem Auto bedeutet, muß man im Digitalen Marketing eigentlich jedesmal wieder jeden Quatsch auf’s Neue erklären.
Und bevor jetzt irgendwer hier „GENAU!“ denkt und sich besser fühlt: Selbst innerhalb unserer Branche ist das ein Problem! Das liegt zum Teil daran, daß sich die Tools kontinuierlich ändern, zum anderen am Unterangebot von Fachleuten, welches wiederum dazu führt, daß wir oft mit noch recht frischen Nutzern, Kollegen und Partnern zu tun haben.
So oder so gibt es viele Gelegenheiten, etwas zu erklären. Ich mache das gerne, hat man vielleicht schon gemerkt über die Jahre. Daher wollte ich ein paar der Erklärungsansätze, die ich in der Vergangenheit erfolgreich benutzt habe mal ausformulieren, damit andere sie ebenfalls nutzen können.
eVars
IMNSHO sind eVars das wichtigste Element in Adobe Analytics. Sie transportieren die Daten, anhand derer wir später segmentieren können, und ohne Segmente sind wir nichts. (sagt Avinash Kaushik.)
eVars sind Datencontainer, und sie haben zwei Attribute, die sie interessant machen: Expiry und Allocation.
Ich erkläre das normalerweise mit der „Supermarkt und Stempel“ Analogie, die ebenso krude wie erinnerungswürdig ist, die Konzepte aber gut rüberbringt.
Dazu muß ich also gar nicht mehr schreiben.
events
Die Funktionsweise von events ist recht einfach zu erklären: man verweise auf die Klicker, die das Kabinenpersonal im Flugzeug nach dem Einsteigen früher gern verwendete.
Man bemüht sich üblicherweise, events direkt auf Aktionen abzubilden, insbesondere auf solche, mit denen sich der Erfolg der Site oder besser des Unternehmens identifizieren kann (purchase, sign-up, login, …), oder die beim Marketing hilfreich sind (newsletter sign-up, download of white paper, …).
So weit, so gut.
events und eVars
Richtig sinnvoll sind eVars und events nur zusammen. Ein event ohne eVar ergibt nur einen trended report, und der liefert nicht genügend Informationen. Eine eVar ohne event ist totaler Quatsch, denn wenn man keine events nutzt, bekommt man für die eVar nur die „Instances“ Metrik, und dann kann man auch gleich eine prop benutzen (und hat dann noch pathing!).
Es ist also klar, daß der event irgendwie dem aktuellen Wert in den eVars zugeordnet werden muß. In der Supermarktanalogie passiert das, wenn die Person an der Kasse auf die Stirn des Kunden sieht und dann den Knopf für „hat Stempel“ drückt.
In Adobe Analytics ist das komplexer, nicht zuletzt weil es 75 eVars gibt (Stand Februar 2015) und die alle unterschiedlich konfiguriert sein können.
Grundsätzlich hält das System die Werte aller eVars in einer Tabelle pro Visitor vor. Die Tabelle wird über die visitor ID referenziert, d.h. wenn ich meine Cookies lösche, bekomme ich eine neue und habe damit eine nagelneue, leere Tabelle — vulgo: alle eVars sind für mich leer.
Wenn ein Hit einen event enthält, geht das System die Tabelle durch und jeder Wert, der aktuell in der Tabelle steht, bekommt den event angerechnet.
Beispiel Kampagnentracking: Der Trackingcode (vielleicht „em1503je“) wurde in der s.campaign
eVar abgelegt. Wenn ich jetzt etwas kaufe (purchase
event), dann bekommt der Trackingcode das angerechnet, das System speichert also ein order gegen „em1503je“ (weil dieser Wert gerade in s.campaign
steht), dazu den Umsatz und die Anzahl der Artikel. Der selbe purchase
wird auch den Werten in allen anderen eVars angerechnet!
Was ist mit den eVars, die keinen Wert haben: Ha! Da wird der event dann einfach auch „None“ angerechnet, und schon haben wir erklärt, woher die „None“ Werte kommen. Großartig!
props
Ich erkläre die 75 (Stand Februar 2015) props gerne wie folgt:
Man stelle sich einen Raum vor, in dem 75 leere Eimer stehen. Die Eimer dienen dazu, kleine Zettelchen zu sammeln, und wir haben eine Truppe Werksstudenten namens Kjell, die für jeden Eimer die Zettelchen auswerten.
Ich kann als Marketer festlegen, was die Zettel in einem Eimer bedeuten sollen, z.B. könnte Eimer Nummer 2 für „Sprache“ benutzt werden. Wann immer also eine Seite aufgerufen wird, werfe ich ein Zettelchen mit der Sprache der Seite in den Eimer, z.B. „en“ oder „fr“. Kjell zählt mit und wenn ich ihn frage (den Report aufrufe), sagt er schnell „12000 Zettel, davon 8000 de, 3000 en und 1000 fr“. Guter Student.
Da Kjell schlau ist, kann er mir nicht nur Aufrufe („Page Views„) sagen, sondern auch andere Metriken und sogar was üblicherweise nach oder vor einem bestimmten Wert geworfen wurde („Pathing“).
Manchmal verquirlen Leute props und events. Eine prop ist aber kein Klicker, sondern Kjell zählt für jeden Wert in der prop, wie oft er ihn gesehen hat. Wenn man also eine prop mit einem Klicker vergleichen will, dann braucht man pro Wert in der prop einen Klicker.
Was soll ich sonst noch erklären? Anregungen sind willkommen!
Pingback: Microsites tracken | Webanalyse auf Deutsch