150 Befehle sind kein Ziel, sondern eine Warnung

„Über 150 Slash-Commands" stand auf meiner Startseite, und ich war stolz darauf. Es ist die Kennzahl, mit der Discord-Bots seit jeher werben, und sie klingt nach Leistung.

Im Januar habe ich zum ersten Mal ausgewertet, welche Befehle in den letzten neunzig Tagen tatsächlich aufgerufen wurden. Das Ergebnis war ernüchternd und ist der Grund für alles, was ich dieses Jahr an dem Projekt gemacht habe.

Die Zahlen

Ich hatte eine simple Zählung eingebaut: Bei jedem Aufruf eine Zeile mit Befehl, Server, Zeitpunkt. Nach drei Monaten sah die Verteilung so aus:

Und der Teil, der mich wirklich getroffen hat: Etwa dreißig Befehle wurden in neunzig Tagen kein einziges Mal aufgerufen. Nicht selten. Kein einziges Mal.

Darunter Sachen, an denen ich Wochenenden gesessen hatte. Ein Befehl, der ein Bild mit Statistiken über den Server zeichnet. Eine Umfragefunktion mit mehreren Antwortmöglichkeiten und Auswertung. Verschiedene Bildbearbeitungsspielereien.

Warum ich sie trotzdem gebaut hatte

Ich habe eine Weile darüber nachgedacht, wie es dazu kommt, und drei Muster gefunden, die mir bis heute begegnen.

Der Befehl war technisch interessant. Die Bildbearbeitung war die spannendste Programmierarbeit des Jahres. Ob jemand sie benutzt, war beim Bauen keine Frage, die ich gestellt habe.

Jemand hat einmal gefragt. Eine einzelne Nachricht — „wäre cool, wenn der Bot X könnte" — hat bei mir mehrfach zu einem Wochenende Arbeit geführt. Ohne zu prüfen, ob es außer dieser Person noch jemanden interessiert.

Die Konkurrenz hatte es. Der schlechteste Grund von allen. Ich habe Features nachgebaut, weil andere Bots damit warben — ohne zu wissen, ob sie dort benutzt werden.

Was ein ungenutzter Befehl kostet

Die verlockende Antwort ist: nichts. Er liegt da, er stört keinen. Das stimmt nicht, und die Kosten sind nur nicht sofort sichtbar.

Er muss migriert werden. Bei jeder Bibliotheks-Hauptversion. Bei jeder Änderung an der internen Struktur. Ein Befehl, der niemandem nützt, kostet bei jedem Umbau dieselbe Zeit wie ein wichtiger.

Er verschmutzt die Auswahl. Discord zeigt beim Tippen eines Schrägstrichs eine Liste. Wenn dort hundertfünfzig Einträge stehen, findet man die zehn wichtigen schlechter. Jeder zusätzliche Befehl macht die anderen ein Stück unauffindbarer.

Er erweitert die Angriffsfläche. Jeder Befehl ist ein Eingang mit Parametern. Ein selten benutzter Befehl wird auch selten geprüft.

Er täuscht Vollständigkeit vor. Wenn eine Kategorie zwölf Befehle hat, von denen zwei gut sind, wirkt sie gepflegt. Beim Benutzen merkt man den Unterschied.

Was ich daraus gemacht habe

Der offensichtliche Schluss wäre, dreißig Befehle zu löschen. Ich habe es nicht getan — jedenfalls nicht sofort, und nicht alle. Denn zwischen „wird nicht benutzt" und „ist nutzlos" liegt eine Zwischenstufe: Wird nicht gefunden.

Bei mindestens fünf Befehlen habe ich nach Nachfragen festgestellt, dass die Funktion durchaus gewünscht war — nur wusste niemand, dass es sie gibt, oder sie hieß so, dass man nicht auf sie kommt.

Also erst die Diagnose, dann die Entscheidung. Die Aufräumaktion selbst ist der nächste Eintrag; sie hat mehrere Monate gedauert und war unangenehmer als erwartet.

Wie ich gemessen habe

Damit die Zahlen nachvollziehbar bleiben, hier der Aufbau — er ist absichtlich simpel.

Bei jedem Befehlsaufruf eine Zeile: Zeitpunkt, Befehlsname, Server, Erfolg oder Fehler. Kein Nutzer, kein Inhalt, keine Argumente. Das reicht für die Frage „was wird benutzt" und erzeugt keine personenbezogene Auswertung.

Nach einer Woche werden die Zeilen zu Tageswerten verdichtet und die Einzelzeilen gelöscht. Damit bleibt die Tabelle klein, und die Frage nach Aufbewahrungsfristen stellt sich nicht.

Die Auswertung selbst ist eine Abfrage:

SELECT befehl, sum(aufrufe) AS gesamt, count(DISTINCT gilde) AS server
FROM befehl_tag
WHERE tag > date('now', '-90 days')
GROUP BY befehl
ORDER BY gesamt DESC;

Die zweite Spalte ist die wichtigere. Ein Befehl mit vielen Aufrufen auf einem einzigen Server ist etwas anderes als einer mit derselben Zahl auf dreißig Servern. Der erste ist eine Spezialität, der zweite ein Grundbedürfnis.

Was mich bei der Auswertung überrascht hat

Die Hilfe war der meistgenutzte Befehl. Nicht der lustigste, nicht der nützlichste — der, mit dem Leute herausfinden, was es gibt. Das hat mich dazu gebracht, deutlich mehr Zeit in ihre Gestaltung zu stecken.

Ein Befehl wurde fast nur nachts benutzt. Ein Zufallsspiel, das offenbar seinen Platz in einer bestimmten Runde hatte. Ohne Zeitverteilung hätte ich ihn nach Gesamtzahlen aussortiert.

Zwei Befehle hatten sehr hohe Fehlerquoten. Nicht weil sie kaputt waren, sondern weil ihre Bedienung unklar war. Beide habe ich umbenannt und die Parameter umgestellt — danach fiel die Quote auf ein Zehntel.

Der letzte Punkt ist der, den ich am wertvollsten finde: Eine hohe Fehlerquote ist selten ein Nutzerproblem. Sie zeigt fast immer, dass eine Bedienung nicht das nahelegt, was gemeint ist.

Was ich seitdem anders mache

Ich baue kein Feature mehr, ohne vorher zwei Sachen aufzuschreiben:

Wer fragt danach, und wie oft? Eine einzelne Anfrage ist ein Datenpunkt, keine Nachfrage. Fünf Anfragen von verschiedenen Leuten sind ein Signal.

Woran erkenne ich in drei Monaten, ob es benutzt wird? Wenn die Antwort „gar nicht" lautet, baue ich zuerst die Messung. Das klingt bürokratisch für ein Hobbyprojekt und ist der einzige Weg, sich selbst nicht zu belügen.

Der zweite Punkt hat sich in den Jahren danach mehrfach ausgezahlt, auch außerhalb dieses Projekts. Bei meinen Minecraft-Servern messe ich heute, welche Befehle und Menüs tatsächlich benutzt werden — und die Antworten überraschen mich regelmäßig.