Statistiken, die niemand liest — und die drei, die zählen

Im Sommer habe ich dem Dashboard eine Statistikseite verpasst. Diagramme über Nachrichten pro Tag, aktivste Kanäle, Verteilung nach Uhrzeit, Wachstum der Mitgliederzahl, Verhältnis von Text zu Sprache. Es sah gut aus, und ich war stolz darauf.

Nach zwei Monaten habe ich in die Zugriffszahlen geschaut. Die Seite wurde im Schnitt einmal pro Server aufgerufen — nämlich beim ersten Mal, aus Neugier. Danach nie wieder.

Warum niemand hinsieht

Ich habe eine Weile gebraucht zu verstehen, warum. Der Grund ist nicht, dass die Zahlen falsch oder hässlich waren. Er ist einfacher: Sie haben keine Frage beantwortet, die jemand hatte.

„Wie viele Nachrichten wurden diese Woche geschrieben?" ist keine Frage, die sich ein Serveradmin stellt. Er stellt sich Fragen wie:

• Warum ist es hier gerade so ruhig?
• Wer sollte ins Team, weil er ständig hilft?
• Funktioniert unser Willkommensbereich, oder springen Leute sofort wieder ab?

Das sind Fragen, auf die man mit Daten antworten kann. Aber nicht mit einem Diagramm „Nachrichten pro Tag", sondern mit einer konkreten Aussage.

Die drei Zahlen, die tatsächlich benutzt wurden

Ich habe die Seite später zusammengestrichen. Was geblieben ist, waren drei Dinge, und alle drei sind keine Diagramme.

Wer ist neu und geblieben? Eine Liste der Mitglieder der letzten dreißig Tage mit der Angabe, ob sie seitdem etwas geschrieben haben. Das beantwortet „funktioniert unser Einstieg" direkt, ohne Interpretation.

Wer ist aktiv, ohne im Team zu sein? Eine Rangliste der Beteiligung, gefiltert auf Leute ohne Teamrolle. Der meistgenutzte Teil überhaupt — er beantwortet eine echte Frage, nämlich wen man ansprechen könnte.

Was hat sich seit letzter Woche verändert? Nicht der absolute Stand, sondern die Differenz. „38 Nachrichten pro Tag" sagt niemandem etwas. „−40 % gegenüber der Vorwoche" ist ein Anlass, nachzusehen.

Der dritte Punkt ist der, der mich am meisten gelehrt hat: Ein Wert ohne Vergleich ist keine Information. Fast jede nützliche Zahl ist eine Veränderung, ein Verhältnis oder eine Abweichung von einer Erwartung.

Was ich technisch falsch gemacht hatte

Neben der inhaltlichen Fehleinschätzung hatte die erste Fassung ein handwerkliches Problem: Sie hat bei jedem Aufruf über Rohdaten gerechnet.

SELECT date(erstellt_am) AS tag, count(*) 
FROM nachrichten_log 
WHERE gilde = ? AND erstellt_am > date('now','-90 days')
GROUP BY tag;

Bei einem Server mit ein paar hunderttausend Zeilen ist das eine spürbare Wartezeit — und diese Wartezeit trifft jeden Aufruf, obwohl sich das Ergebnis für vergangene Tage nie mehr ändert.

Die Lösung war eine Verdichtungstabelle: Einmal pro Nacht werden die abgeschlossenen Tage zusammengefasst, und die Seite liest nur noch diese Zusammenfassung plus den laufenden Tag.

CREATE TABLE tagesstatistik (
  gilde       VARCHAR(20) NOT NULL,
  tag         DATE        NOT NULL,
  nachrichten INT         NOT NULL,
  aktive      INT         NOT NULL,
  beitritte   INT         NOT NULL,
  austritte   INT         NOT NULL,
  PRIMARY KEY (gilde, tag)
);

Nebeneffekt, der mir wichtiger wurde als die Geschwindigkeit: Man kann die Rohdaten danach löschen. Wer wissen will, wie viele Nachrichten an einem Tag im März geschrieben wurden, braucht nicht die Nachrichten selbst.

Die Auswertungen, die ich später gebaut habe

Nachdem klar war, dass Diagramme über Nachrichtenmengen niemanden interessieren, habe ich die Frage anders gestellt: Welche Entscheidung soll diese Zahl unterstützen?

Daraus sind drei Ansichten entstanden, die tatsächlich benutzt wurden:

„Wer ist neu und geblieben?" Eine Liste der letzten dreißig Tage mit der Angabe, ob die Person seitdem etwas geschrieben hat. Unterstützt die Entscheidung: Müssen wir am Einstieg etwas ändern?

„Wer ist aktiv, aber nicht im Team?" Unterstützt die Entscheidung: Wen könnten wir ansprechen?

„Was ist ungewöhnlich?" Abweichungen gegenüber dem Vorzeitraum, nur wenn sie deutlich sind. Unterstützt die Entscheidung: Muss ich hinsehen?

Alle drei sind Listen mit Namen, keine Kurven. Das ist kein Zufall: Entscheidungen betreffen fast immer konkrete Fälle, und eine Kurve zeigt keine Fälle.

Die Falle bei Vergleichszeiträumen

Ein Detail, das mich später einiges gekostet hat: Der Vergleich mit „der Vorwoche" ist tückischer, als er aussieht.

Ein Discord-Server hat einen sehr deutlichen Wochenrhythmus. Freitagabend sieht anders aus als Dienstagvormittag. Wer den Durchschnitt der letzten sieben Tage mit dem der vorherigen sieben vergleicht, bekommt sinnvolle Werte. Wer gestern mit vorgestern vergleicht, bekommt Rauschen — es sei denn, gestern war derselbe Wochentag.

Ebenso: Feiertage, Ferien, Ereignisse. Ein Einbruch um vierzig Prozent kann bedeuten, dass etwas kaputt ist — oder dass Sommerferien angefangen haben.

Meine Konsequenz: Vergleichswerte immer über mindestens eine volle Woche, und bei jeder auffälligen Abweichung als Erstes prüfen, ob es einen banalen Grund im Kalender gibt. Diese Prüfung hat mir mehrfach eine Fehlersuche erspart, die nie eine gewesen wäre.

Der Unterschied zwischen Kennzahl und Anzeige

Aus diesem Fehlschlag ist eine Unterscheidung geworden, die ich seitdem beim Bauen jeder Auswertung mache.

Eine Anzeige zeigt, wie etwas gerade steht. Sie beantwortet keine Frage, sie stellt einen Zustand dar. Nützlich für laufende Beobachtung, wertlos für Entscheidungen.

Eine Kennzahl vergleicht — mit einem früheren Zeitpunkt, mit einer Erwartung, mit einer anderen Gruppe. Sie beantwortet die Frage „ist das gut oder schlecht", und ohne diese Antwort tut jede Zahl gar nichts.

Meine Statistikseite bestand aus Anzeigen. Kurven, Zahlen, Verteilungen — alles korrekt, alles ohne Bezug.

Der Umbau war klein: bei jeder Zahl einen Vergleichswert dazu. Vorwoche, Durchschnitt, erwarteter Bereich. Dieselben Daten, dieselbe Darstellung — und plötzlich stand dort etwas, worauf man reagieren kann.

Die Regel, die ich daraus mitgenommen habe

Bevor ich heute eine Auswertung baue, schreibe ich die Frage auf, die sie beantworten soll. In einem Satz, in der Sprache eines Nutzers.

Wenn mir kein Satz einfällt, baue ich sie nicht. Wenn mir einer einfällt, prüfe ich, ob die geplante Darstellung ihn tatsächlich beantwortet — und ziemlich oft ist die Antwort dann ein Satz mit einer Zahl darin, kein Diagramm.

Das hat später auch außerhalb dieses Projekts gehalten. Bei Statistiken für meine Minecraft-Server bin ich derselben Regel gefolgt, und dort hat sie noch deutlicher gewirkt: Spieler interessieren sich nicht für Kurven. Sie interessieren sich dafür, wie sie im Vergleich zu den anderen stehen und was sie diese Woche geschafft haben.