Mehr über eVars

Ich glaube ich habe schon zu lange nicht mehr über eVars geschrieben.

Man kann vermutlich beliebig viele Artikel über eVars machen, selbst wenn man sich vornimmt, sich nicht zu wiederholen. Bloggerparadies.

Persistenz

Jeder Leser dieses Blogs sollte wissen, daß eVars persistent sind, d.h. sich über einen Hit hinaus merken, welchen Wert sie haben.

Das ist deswegen relevant, weil auf diese Weise Success Events einem Wert angerechnet werden, auch wenn sie später passieren. Genau deswegen benutzt man eVars. Tracking Code speichern wenn der Visit beginnt, später dann eine Transaktion („Order“) tracken, und das System weist das eine dem anderen zu.

Aber wie funktioniert das eigentlich?

Wer mal ganz naiv probiert hat, den Wert einer eVar im Javascript auszulesen, wird gemerkt haben: Da steht gar nichts drin, außer natürlich man hat gerade etwas reingeschrieben.

Und wo wird dann der Wert gespeichert?

Der Wert steht im Backend in einer Art Tabelle. Diese Tabelle wiederum wird über die visitor ID referenziert.

Wenn ein Benutzer seine Cookies löscht und damit seine visitor ID neu gesetzt wird, dann geht quasi die ganze Historie dieses Benutzers verloren. Nee, moment: Sie geht eigentlich nicht verloren, sondern weil der Benutzer jetzt eine neue visitor ID bekommt, wird eine neue Tabelle für ihn aufgemacht. Damit wird das System alle von nun an ausgelösten Events nicht mehr auf die alten Werte anschreiben können.

Beispiel Kampagnen: Benutzer A kommt über eine unserer Emails auf die Site und wir greifen einen Trackingcode ab. Der landet in s.campaign, also einer eVar, und damit in der Tabelle im Backend. Jetzt löscht Benutzer A seine Cookies und kommt wieder zur Site, diesmal direkt. Da er den ursprünglichen s_vi Cookie nicht mehr hat, bekommt er eine neue visitor ID. Jetzt kauft er was. Das wird dann gegen welchen Trackingcode gerechnet? Genau: Gar keinen.

Die „Allocation“ einer eVar (First oder Last) stellt ein, ob ein neuer Wert der in der eVar transportiert wird, dann auch wirklich in der Tabelle landet.

Steht die eVar auf „Original (First)“, dann wird ein neuer Wert nur dann geschrieben, wenn zur Zeit keiner da steht. Steht die eVar auf „Most Recent (Last)“, wird immer überschrieben. Mit der „Allocation“ stellt man also zwischen „first touch“ und „last touch“ um.

Wo ich gerade „transportiert“ geschrieben habe: Im Grunde sind alle „Variablen“ in SiteCatalyst Adobe Analytics einfach „Transportbehälter“. Sie dienen dazu, Daten aus dem Browser auf Adobe Server zu transportieren. Nicht mehr und nicht weniger.

Alles andere findet im Backend statt.

Eine eVar „löschen“

In einem Emailwechsel letzte Woche kam noch eine Frage auf, die viele im Kopf haben aber kaum einer wirklich stellt: Kann man eigentlich eine eVar löschen?

Jetzt wo wir wissen, daß der Wert im Backend gehalten wird, ahnen wir auch schon die Antwort, oder?

Der naive Ansatz ist wieder, einfach mal im Javascript die eVar „auf leer“ zu setzen, z.B. so:

	s.eVar5 = "";

Wer mit dem Debugger umgehen kann, wird gleich sehen: Das geht so nicht. Der Trackingcall enthält die eVar5 einfach gar nicht.

Wie sieht’s aus mit Alternativen?

	s.eVar5 = null;

oder vielleicht

	s.eVar5 = "null";

Ersteres übrträgt wieder nichts, letzteres sendet genau das, was da steht: „null“. Und das steht dann so auch in den Reports.

Die Antwort lautet: Man kann eine eVar nicht löschen, man expired sie.

Und damit wird auch klar, warum es so viele unterschiedliche Optionen gibt für „Expire After“

[Screenshot]

Optionen für Expire After

Es gibt Zeit-basierte Optionen (Minute, Hour, Day, Week, Month, …, Custom), Aktions-basierte (on Purchase oder anderem Event) und natürlich Visit und Never.

Man muß sich für jede eVar gut überlegen, wann und wofür man sie benötigt, und dann entsprechend die Expiry setzen. In vielen Fällen bedeutet das „Visit“ (Quasi der Standard). In vielen Fällen bedeutet das auch „Month“ oder „Custom 30 days“ (Standard für viele Marketer).

Es spricht nichts dagegen, einen Wert in mehrere eVars zu schreiben, wenn man das braucht!

Beispiel Kampagnen: Man könnte Trackingcodes gut und gerne in 2 eVars schreiben, eine davon auf „Original (First)“, die andere auf „most Recent (Last)“ konfiguriert. Und schon hat man first touch und last touch Daten. Man könnte diese zwei eVars nach „Month“ expiren lassen.

Und wenn man für manche Affiliates mit anderen Fenstern arbeitet, z.B. 7 Tage, dann spricht auch nichts dagegen, den Trackingcode in eine weitere eVar zu stecken, die nach 7 Tagen expired.

Das einzige Problem mit dieser Vervielfältigung: Jede dieser eVars ist ein Report, und jeder dieser Reports zeigt eine unterschiedliche Sicht auf die gleichen Daten. Das verwirrt andere Benutzer, ist also nur wirklich gut, wenn man die Reports sehr explizit benennt, im Menü gezielt präsentiert (mit Namen, die nur die jeweilige Zielgruppe ansprechen) und dokumentiert bis der Arzt kommt.

Ü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 Nächste Schritte

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: