Die 2 Nutzen des Herrn Prop

Von | 4. August 2015

Traffic variables („props„) sind für viele der Einstiegspunkt in die Webanalyse. Leicht zu verstehen, tun was man denkt, schnell analysiert.

Wenn man dann etwas weiter ist und sich auf der „maturity curve“ hochgelernt hat, dann benutzt man relativ schnell hauptsächlich events und conversion variables („eVars„). Und man beginnt, jede Variable als prop und als eVar zu tracken.

Wenig später fragt man sich, ob das eigentlich sinnvoll oder notwendig ist. Meist legt man die Frage schnell wieder weg und lässt aus historischen Gründen und weil es die Folklore so will beide weiterlaufen.

Dann stösst man eines Tages im Internet auf einen Artikel, der einem nahelegt, die props wegzulassen, denn — mal ganz ehrlich — die taugen doch zu nichts.

Diesen Artikel wird vermutlich ein gewissen Jan Exner geschrieben haben, und vermutlich auch nicht nur einmal.

Da besagter Herr Exner auf der anderen Seite bemüht ist, fair zu sein, will er heute die andere Seite der Medaille zeigen. Es gibt nämlich durchaus gute Gründe, etwas in eine prop zu tracken. Nur eben nicht so viele.

Pathing

Einen der Gründe habe ich schon oft erwähnt: Pathing.

Wenn ich etwas in eine prop schreibe und dann für diese prop „pathing“ anschalte (in der Admin Console), dann kann ich hinterher im Reporting sehen, wie sich der Wert der prop über die Zeit verhält.

[screenshot]

Das ist für eine ganze Reihe von Anwendungsfällen sinnvoll, auch solche, die mit Seiten gar nichts zu tun haben.

Das Besondere an den Reports hinter pathing ist die zeitliche Komponente, bzw. die Darstellun einer Reihenfolge. Wo immer eine solche Reihenfolge interessant ist, kommt Pathing zum Zug.

Pathing nur für die s.pageName zu verwenden ist pure Verschwendung. Damit sollte man wirklich kreativ sein!

Und: In Ad Hoc kann man das sogar über Visits hinweg machen.

[Screenshot]

Pathing auf Visitors Level

Segmentation

Ein mindestens ebenso nützlicher aber weit weniger oft zitierter Nutzen der props hat damit zu tun, wie Segmentierung in Adobe Analytics funktioniert.

Wir erinnern uns: Es gibt die Möglichkeit, auf Ebene von einer Seite, einem Visit oder für alle Visits eines Visitors zu segmentieren.

Damit wird plötzlich der Hauptnachteil der props, die fehlende Persistenz, vollkommen egal.

Beispiel: Wenn ich wissen möchte, wieviel Umsatz ich dank meiner Emailkampagne „em-je1505“ gemacht habe, dann sehe ich mir den Campaigns Report an und nehme die Revenue Metrik.

Das funktioniert, weil s.campaign persistent ist, d.h. wenn der Umsatz zustande kommt, erinnert sich Analytics noch daran, welche Kampagne da mitgespielt hat.

Genau dafür sind eVars gemacht, und weil man ihre Persistenz einstellen kann, sind sie auch so nützlich.

Segmente haben einen ganz ähnlichen Mechanismus, wenn auch weniger flexibel. Ich kann die Entscheidung, ob Daten Teil des Segmentes sein sollen oder nicht über die Auswahl des Containers („Hit“/“Visit“/“Visitor“) feiner oder gröber einstellen.

Wenn mir ein einziger Datenpunkt in einem Visit ausreicht für die Definition meines Segmentes, dann spricht nichts dagegen, diesen einen Datenpunkt in einer prop zu tracken und den Rest erledigt dann die Segmentierung.

Sprich: Ich benutze einen „Visit“ oder „Visitor“ Container, in dem die prop auf einen Wert abgetestet wird. Sobald dieser Wert nur ein mal getrackt wurde, kommen alle Hits des Visits („Visit“ Container) oder des Visitors („Visitor“ Container) durch.

Das kann man im Prinzip für so ziemlich alle möglichen Analysen benutzen, es gibt aber einen Aspekt, den man im Kopf behalten sollte: Im Campaigns Report sehe ich die Namen aller Kampagnen, die getrackt wurden. Würde ich das mit Segmenten abdecken wollen, bräuchte ich recht viele Segmente. Das scaled nicht.

Als Ersatz für eVars ganz generell taugt das also nicht, wohl aber in Situationen, wo es klar ist, dass segmentiert werden soll, und wo man dann eine eVar einsparen kann (z.B. für desktop v mobile site oder für Segmentierung nach break points bei responsive sites).

Es gibt mittlerweile ja eigentlich genug eVars für selbst die ausgefuchstesten Anwendungen, aber ich würde eine prop einer eVar immer dann vorziehen, wenn es nur um Segmentierung geht und nicht um Reports. Warum? Na weil dann das Reporting schlanker bleibt, also das Menü unterhalb von „Custom Conversion“ eben nur solche Einträge enthält, die auch wirklich für Reports gedacht sind.

Nur meine Meinung.

Kommentar verfassen

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