Real-Time Reports

In den nächsten zwei Beiträgen möchte ich zwei Features vorstellen, die im Oktober 2013 in Adobe Analytics 1.4 aufgenommen wurden: Real-Time Analytics & Anomaly Detection.

Real-Time Reports

Moment, wir müssen mal kurz ausholen…

Latency

Als SiteCatalyst 15 erschien, war eines der großen Themen die Latency, also die Zeit zwischen „etwas passiert auf der Website“ und „Ich sehe im Report, daß es passiert ist“.

In SiteCatalyst 14 war die Latency je nach Metrik zwischen ein paar Minuten (PVs, Events) und mindestens 30 Minuten (Visits) und mehr (Visitors). SiteCatalyst 15 und jetzt Adobe Analytics handhaben die Datenverarbeitung anders, nämlich in Blöcken, siehe hier.

Seit Anfang 2013 wurden in den „Current Data“ Reports Daten schneller zur Verfügung gestellt, nämlich in der gleichen Geschwindigkeit wie bei SiteCatalyst 14. Und seit Analytics 1.2 vom 23.5.2013 stehen diese Daten direkt in den Reports zur Verfügung, wenn man das anschaltet. Ben Gaines beschreibt das hier.

Damit sind die Daten in Adobe Analytics jetzt wieder ebenso schnell, wie sie das früher unter SiteCatalyst 14 waren.

Und seit Analytics 1.4 vom 17.10.2013 geht es jetzt noch schneller!

Real-Time Analytics

Seit 1.4 gibt es unter dem Menüpunkt Metrics > Real-Time neue Reports, die auf drei Funktionen getrimmt sind:

1. Geschwindigkeit — die Latency in diesen Reports liegt im Bereich von Sekunden.
2. Granularität — wo andere Reports höchstens bis auf eine Stunde heruntergebrochen werden können, bieten diese Minutenauflösung.
3. Automatische Visualisierung — die Reports müssen nicht im Browser neu geladen werden sondern zeigen alle 3 – 5 Sekunden neue Daten automatisch an.

Klingt alles super.

Grundsätzlich hat man 3 dieser Reports zur Verfügung. Beim ersten Aufruf entscheidet man sich, welche Daten man in den Reports sehen will. Diese Konfiguration findet auf Ebene der Report Suite statt, d.h. wer immer sich einloggt und die spezifische Report Suite wählt, sieht die gleichen Real-Time Reports.

Einstellen kann man, welche Metriken man sehen möchte, und nach welchen 3 Elementen die Metrik jeweils heruntergebrochen werden soll.

Ein Beispiel, heute mal aus der Branche Onlinezeitungen:

Die Website hat einen Success Event namens „Article View“, der immer dann gesendet wird, wenn jemand einen redaktionellen Artikel abruft. Im Artikel werden außerdem der Titel und Autor getrackt, beide in Traffic Variables (props).

Der Real-Time Report ist dann z.B. so konfiguriert:

• Metric: Article Views
• Primary Dimension: Article Title
• Secondary Dimension: Article Author
• Secondary Dimension: GeoSegmentation Region

Wie man im Screenshot sehen kann, gibt es 3 dieser Reports. Und wie gesagt sind das 3 pro Report Suite, nicht pro Benutzer!

Wie funktioniert das mit den Dimensionen?

Dimensions

Man hat ja wie gezeigt eine „primary dimension“ sowie zwei „secondary dimensions“ zur Verfügung. Das „primary“ und „secondary“ bezieht sich auf die Position im Report selber, d.h. die „primary Dimension“ wird im oberen Teil prominent angezeigt, die zwei „secondaries“ weiter unten in kleineren Bereichen.

Und welche Dimensionen kann man benutzen?

Die Liste enthält einige eingebaute Dimensionen (GeoSegmentation, Tracking Codes, Search Keyword/Engine, Product, Referring Domain) sowie die Traffic Variables.

Der wichtige Punkt: Die Real-Time Reports arbeiten nur in Echtzeit, ohne jede Kenntnis der Vergangenheit: Sie zeigen nur die Dimensionen an, die beim aktuellen Hit wirklich mitgesendet wurden!

Beispiel Tracking Code: Wenn ich als Metrik Page Views konfiguriere und als „primary dimension“ Tracking Code, dann werden mir zwar alle Page Views in der Summe oben angezeigt, die meisten jedoch ohne Dimension, denn ein Tracking Code wird ja üblicherweise nur auf einer Landingpage abgefragt und getrackt!

Das kann man natürlich mit Javascript auch anders handhaben, schon klar, wichtig ist aber, daß in den Real-Time Reports immer nur die Dimensionen angezeigt werden, die im aktuellen Hit dabei waren.

Das bedeutet, daß manche Dimensionen nur im Zusammenhang mit ganz bestimmten Metriken sinnvoll sind. Beispiel „Product“, das benutzt man sinnvollerweise mit der „Orders“ Metrik. Als Retailer hat man dann einen Report, der live anzeigt, was auf der Site gerade gekauft wird.

Der Report

Die eigentlichen Reports sehen so aus:

Ganz oben sieht man die letzten 15 Minuten für die ausgewählte Metrik. Die Zahl rechts ist der letzte gemessene Wert, also quasi der aktuelle.

Darunter sieht man die „primary dimension“. Man kann den Namen sehen, die Metrik, sowie ob es zur Zeit auf- oder abwärts geht. Die Liste kann nach Metrik („most popular“) sortiert werden, oder nach Veränderung („gainers“ oder „losers“).

Jede Zeile kommt mit einer individuellen Kurve.

Weiter unten sieht man die zwei Grafiken für die „secondary dimensions“. Die werden teilweise leicht anders formatiert, sind ansonsten aber ähnlich. Man kann mit der Maus über einzelne Werte gehen und sieht dann eine Grafik.

Links oben sieht man drei Icons, mit denen wählt man den Report aus.

Die zwei Icons rechts oben führen zur Konfiguration (das linke) und zur Vollbildansicht (das rechte).

Notizen

Wie oben schon erwähnt muß man den Report nicht manuell neu laden, sondern Daten fließen quasi live ein und werden dann alle 3 – 5 Sekunden angezeigt.

Die Reports können im Vollbildmodus dargestellt werden und eignen sich damit hervorragend für einen großen Bildschirm an der Wand im Büro.

Und wo wir gerade bei großen Dashboards sind: Real-Time Reports kann man auch via Reporting API abrufen, d.h. man kann die Daten in selbstgebaute Dashboards einfließen lassen.

Fazit: Klingt alles super. Ist auch super!