Teil II der Miniserie über neue Features in Analytics 1.4. Während es in Teil I um Real-Time Reports ging, sehen wir uns heute Anomaly Detection an.
Anomaly Detection
Die zugrundeliegende Idee ist, daß Adobe Analytics genügend Daten zur Verfügung hat und damit in der Lage ist, automatisch Abweichungen zu erkennen. Das entlastet den Analysten oder Marketer und hilft, Überraschungen zu vermeiden.
Beispiele: Wenn plötzlich 10000 Besucher einen ganz bestimmten Artikel ansehen. 200 Verkäufe in einer halben Stunde, alle ohne Produkt, oder eine Transaktion im Wert von EUR1000000 („Ahh! Mißbrauch!“). Kein einziger Hit auf dem neuen Artikel über die ADAC Affäre („Nicht verlinkt!“).
Alle diese Beispiele haben eins gemeinsam: Sie sind keine Katastrophen, aber es wäre definitiv gut, wenn man schnell darauf reagieren würde.
Und genau das soll Anomaly Detection einfacher machen.
Die Dokumentation bringt eine Menge Details zu den verwendeten Algorithmen, aber vielleicht kann man das ganze auch kurz auf den Punkt bringen:
- Man wählt eine Metrik aus, z.B. „Orders“ oder „Article Views“
- Man wählt den Trainingszeitraum und Reportzeitraum: 30, 60 oder 90 Tage.
- Das System berechnet aus den Zahlen des Trainingszeitraums eine obere Schranke, eine untere Schranke und eine Vorhersage.
- Der Report zeigt für den Reportingzeitraum für jeden Tag an, wo der aktuelle Wert bzgl. der Schranken und der Vorhersage liegt.
So sieht das aus:
Im oberen Teil sieht man die Auswahlfelder für Reportsuite, die Länge der Trainingsperiode und das Datum.Die Trainingsperiode bestimmt, wieviele Daten das System für die Berechnung des Mittelwertes und der Schranken nimmt: 30, 60 oder 90 Tage. Je länger die Periode, desto breiter werden die Schranken (also nachsichtiger).
Im Graphen darunter sieht man kleine Marker, die Abweichungen darstellen. Je weiter weg von der Mittellinie, desto größer. Das wird auch farblich kodiert, dunkelgrün ist weiter weg vom erwarteten Wert als grau.
Ganz unten folgt dann eine Liste der Metriken, die man ausgewählt hat.
Man kann jede einzelne Metrik ausklappen und sieht dann eine Kurve der aktuellen Werte, hinterlegt mit einem grauen Bereich, der die 95% darstellt. Werte außerhalb dieses Bereiches sind Anomalien.
Wenn man mit der Maus über die kleinen Kreise streicht, sieht man unten sowohl den gemessenen als auch den erwarteten Wert.Gleiches gilt für die Marker im Graphen, auch dort kann man mit der Maus zeigen — man sieht dann welche Metrik als Ausreißer registriert wurde.
Alles in allem kann man in diesem Report schnell sehen, ob und wann welche Metrik sich verdächtig verhalten hat. Das hilft, schnell Probleme zu finden, oder vielleicht auch Chancen.
Metriken
Welche Metriken angezeigt werden, kann man auswählen, dazu muß man nicht viel sagen.
Nur eine Sache vielleicht: Anomaly Reports können nicht segmentiert werden, haben aber eine vergleichbare Funktion: Filtered Metrics.
Filtered Metrics definiert man sich selbst. Dazu nimmt man eine existierende Metrik (im Bild „Article Page Views“, ein Success Event) und filtert sie nach dem Wert einer Dimension (im Bild „Author“ = „jexner“. „Author“ ist einfach eine prop und „jexner“ einer der möglichen Werte)Was tut diese Metrik in diesem Report?
Das System sieht sich für die Analyse nur solche „Article Page Views“ an, die gemeinsam mit „Author“ = „jexner“ gesetzt wurden, also im Endeffekt nur Views auf Artikel, die ich geschrieben habe.
Das funktioniert also ähnlich wie ein eingeschränktes Segment.
Sehr nützlich!
Notizen
Wie genau die obere und untere Schranke berechnet werden, findet man in der Dokumentation. Grob gesagt sind sie so gewählt, daß 95% aller Werte innerhalb der Schranken liegen sollten.
Die Anomaly Detection ist via Reporting API verfügbar, man kann sich also Tools programmieren, die automatisch die Daten abfragen und gegebenenfalls Alarm schlagen. Oder man kann die Daten einfach auf einem existierenden Bildschirm mit anzeigen.
Und auch in Report Builder ist Anomaly Detection verfügbar, praktisch für all die Excel Dashboards, die wir alle so lieben!
Pingback: Der API Explorer | Webanalyse auf Deutsch
Pingback: Wie Weihnachten und Ostern – Contribution Analysis | Webanalyse auf Deutsch