Event Serialisierung? Pfff!

Von | 5. April 2016

Als ich dieses Blog aus der Taufe hob, war eins meiner erklärten Ziele, all diese wundervoll hilfreichen Postings aus Adam Grecos Feder zu übersetzen. Bis heute habe ich dabei einige Artikel geflissentlich übersehen, z.B. den über Event Serialization.

Bei der Event Serialization geht es darum, dass man Success Events manchmal nicht bei jedem Auftreten einer Aktion senden möchte, sondern zum Beispiel nur einmal pro Visit, oder vielleicht einmal pro Transaktion.

Man kann das in SiteCatalyst Adobe Analytics leicht bewerkstelligen, indem man den gesendeten Events quasi eine ID mitgibt. Das System zählt dann den Event nur einmal pro ID. Die purchaseID ist so eine ID.

Praktisch.

Inflation

Nun gibt es manchmal Kunden, die möchten „beide Sichten“.

Ein Beispiel aus der Automobilbranche: Man möchte sehen, wie oft der car configurator gestartet wurde. Und man möchte auch sehen, in wievielen Visits er aufgerufen wurde.

„Kein Problem“, sagt da der Consultant, und richtet für den Start des car configurator zwei Events ein, einer davon mit Serialization auf Visit, den anderen ohne.

Ratet mal, was ich davon halte…

Ok, egal, darum soll es gar nicht gehen.

Trick

Vielmehr muss ich jetzt gestehen, dass ich einen irreführenden Titel gemacht habe, denn um Event Serialisierung geht es mir hier weniger, sondern eigentlich um die neuen Calculated Metrics. Sorry!

Denn:

Alteingesessener Consultant: „Ich brauche einen Event, der auf Visit serialisiert ist“
Unbeleckter Consultant: „Was?“
AC: „Na einen der pro Visit nur einmal feuert…“
UC: „Was willst Du denn genau zählen?“
AC: „Starts des car configurators, aber eben nur einmal pro Visit“
UC: „Wäre das nicht eher ‚in wievielen Visits wurde der CC gestartet?“
AC: „Ja, genau“
UC: „???“
AC: „???“
UC: „Wieso nimmst Du dann nicht die Visits Metrik? Mit einem Segment?“
AC: „Uhm“

Und das ist die moderne Variante:

  1. Man baut sich ein Segment. „Visit“ Container, Kondition „eventXY exists“. Das Segment soll einfach alle Visits abdecken, in denen der CC gestartet wurde.
  2. Jetzt macht man eine neue Calculated Metrik, basierend auf „Visits“ und mit dem eben gebauten Segment.
  3. Man nennt die Metrik „Visits with CC starts“.

Übrigens: Wer die Metrik „CC starts (Visit-based)“ nennt, steht dem Erfolg seiner Kunden im Weg.

Metriken

Es gibt nur einen einzigen Grund, warum ich in meinem Analytics Tool eine Metrik sehen will: Weil sie für mein Business relevant ist.

Daraus folgen zwei Dinge:

  1. Ich habe tendenziell zu viele Metriken konfiguriert. KISS.
  2. Die Namen meiner Metriken sollen sich aus dem Bedarf ergeben, nicht aus dem technischen Setup hintendran.

Zweiteres erklärt, warum „CC starts (Visit-based)“ ein schlechter Name ist. Im Zweifelsfall weiss kein Anwender, was das sein soll.

Wahrscheinlich ist auch „Visits with CC starts“ ein schlechter Name!

Ich würde davon ausgehen, dass CC Starts intern ein wichtiges Ziel sind, und dass sie daher vermutlich einen Namen haben, den im Marketing jeder benutzt, sowas wie „Softe Konversion 1“. (Ich bin schlecht mit Namen. Mein erster eigener Kater hiess „Kater“.)

Was auch immer dieser interne Ausdruck ist: So sollte die Metrik heissen! Es lebe die Relevanz!

Und dann stellt sich noch die Frage, warum die Calculated Metric besser ist, als der serialisierte Event. Warum?

Die Event Serialisierung haben wir früher benutzt, als es nicht anders ging. Und wir benutzen sie heute in den seltenen Fällen, wo ein Segment einfach nicht passt. Der Nachteil ist, dass wir einen Event verschwenden. Und bei Events, die auf etwas anderes als Visit serialisiert sind, müssen wir auch noch im Browser die ID berechnen.

Dahingegen ist eine Calculated Metric ein einfacherer Weg, und meist auch der klarere. Wenn ich „Visits, in denen der CC gestartet wurde“ sehen will, dann ist eben „Visits“ die richtige Metrik!

9 Gedanken zu „Event Serialisierung? Pfff!

  1. Till

    Der Nachteil ist, dass wir einen Event verschwenden.

    Bei mittlerweile 1000 möglichen Events halte ich diesen Nachteil für nicht so relevant. Ansonsten stimme ich mit Dir überein. Eine Calculated Metric lässt sich auch schneller löschen/ändern als ein Event zu deimplementieren/ändern.

    Antworten
    1. Frank Räther

      Hallo Jan, sehr schöner Artikel. Ich arbeite seit einiger Zeit so. Das führt zu großartigen Ergebnissen. Man kann diverse Drop Out Funnel Reports auf einem Prozess bauen… Schritte 1-2, 1-3, 1-4 etc. Daraus Segmente ableiten, die Visits darin zu einer calculated metric machen (Visits mit Schritt 1-3 beispielsweise sind dann alle Visits in denen Schritt 3 des Funnels erreicht wurde). Nun Conversion Rates daraus kalkulieren (Schritt 1-3 / Schritt 1), trended darstellen. Die Zahlen aus dem Report sind 100% deckungsgleich mit dem Ausgangsfunnel, nur eben trended 🙂 Das spart Diskussionen über „die Korrektheit der Zahlen“ … war ich verwirrend? Gruß aus Hamburg, Frank

      Antworten
  2. Christoph Ludwig

    Es gibt einen weiteren Nachteil. Calculated Metrics stehen nicht für Custom Event Funnel zur Verfügung. Für Kunden die hauptsächlich Adobe Dashboards verwenden müsste man also weiterhin 2 Events anlegen.

    Antworten
  3. Till

    An sich kann ich so doch auch eine eVar serialisieren. Zum Beispiel wenn man jede Fehlermeldung z.B. vom Login in eine eVar schreibt. Nun möchte man wissen wie viele Besuche davon betroffen sind, egal wie oft es auftritt.

    Oder hab ich nen Denkfehler?

    Antworten
    1. Christoph Ludwig

      Dann würde doch auch der Report dieser eVar mit der Metrik Visit dienen.

      Antworten
      1. Till

        An sich ja, wenn ich mir aber weitere Metriken anschauen möchte (Gesamtanzahl aller Fehlermeldungen, weitere kalkulierte Metriken auf Gesamtbasis) kann ich dies nicht nebeneinander.

        Antworten
      2. Till

        Weitere Anwendungsfall: Man trackt die Fehlermeldung einer Eingabe in eine eVarX. Man trackt den Inhalt der Eingabe in eine andere eVarY. Nun kann man den Report zur eVarY betrachten mit der kalkulierten Visit-Metrik des eVarX Reports. Oder zum Beispiel auch eine Fehlerquote kalkulieren lassen.

        Antworten
  4. Pingback: Warum stimmt die Summe nicht? | Webanalyse auf Deutsch

  5. Pingback: Wir sind weit gekommen! - Webanalyse auf Deutsch

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.