Die Beschwerdequote und die auffälligen Tage

Teil 4 der Serie „Hinter der Karte" — eine einzige, geteilte Regel für „das lohnt einen zweiten Blick"

Kurzfassung

Ein Sterne-Schnitt bewegt sich träge — ein einzelner schlechter Tag geht in ihm unter, lange bevor er den Durchschnitt merklich verschiebt. Dieser Artikel zeigt, wie YelmeAtlas Beschwerden definiert, wie eine Beschwerdequote über ein Zeitfenster berechnet wird, und mit welcher einzigen, arithmetisch einfachen Regel ein Tag als „auffällig" markiert wird — derselben Regel, die sowohl die API als auch den PDF-Bericht speist, damit beide niemals widersprüchliche Aussagen treffen können.

1. Diagnose: der Durchschnitt verschleppt Ereignisse

Eine App mit 4,3 Sternen im Gesamtdurchschnitt kann trotzdem letzte Woche einen einzelnen, dramatischen Tag gehabt haben — zum Beispiel nach einem fehlerhaften Update. Der Gesamtdurchschnitt integriert über Monate oder Jahre; ein einzelner schlechter Tag verschiebt ihn kaum sichtbar. Wer nur auf den Durchschnitt schaut, bemerkt das Ereignis frühestens dann, wenn der Schaden längst angerichtet ist — oder gar nicht, wenn sich die Lage danach wieder normalisiert.

Zwei Fragen bleiben unbeantwortet, solange nur ein Gesamt-Schnitt existiert: „Ist die Lage gerade schlechter als sonst?" und „Gab es einen Tag, der aus der Reihe tanzt?"

2. Bisherige Lösungsansätze und ihre Grenzen

  • Den Gesamt-Sterne-Schnitt beobachten. Reagiert zu träge für einzelne Ereignisse (siehe oben).
  • Jeden Tag manuell durchsehen. Skaliert nicht — genau das Problem aus Teil 1 dieser Serie.
  • Eine feste Alarmschwelle („mehr als 5 Beschwerden an einem Tag"). Ignoriert die Größe der App: 5 Beschwerden sind bei einer kleinen App ein echter Ausreißer, bei einer großen App Rauschen.

3. Der Ansatz von YelmeAtlas

Zwei Ebenen, sauber getrennt: erstens eine klare, einfache Definition, was überhaupt als Beschwerde zählt; zweitens eine relative, größenunabhängige Regel dafür, wann ein Tag als auffällig gilt.

Ebene 1 — die Beschwerde. Eine Bewertung mit 2 Sternen oder weniger zählt als Beschwerde. Keine Textanalyse, keine Interpretation — eine Zahl, die jeder Kunde selbst nachrechnen kann, ohne das System zu verstehen. Die Beschwerdequote ist schlicht: Beschwerden geteilt durch Gesamtzahl der Bewertungen im Fenster.

Ebene 2 — der auffällige Tag. Ein Tag gilt als auffällig, wenn seine Beschwerdezahl mindestens doppelt so hoch wie der Tagesdurchschnitt des Fensters ist — und gleichzeitig eine absolute Mindestzahl von 3 Beschwerden erreicht.

4. Der Algorithmus im Detail

flowchart TD
    A["Beschwerdezahl je Tag im Fenster"] --> B["Tagesdurchschnitt berechnen<br/>(Gesamt-Beschwerden ÷ Fenstertage)"]
    B --> C["Schwelle = max(3, 2,0 × Durchschnitt)"]
    C --> D{"Tag erreicht oder überschreitet Schwelle?"}
    D -->|ja| E["Als auffällig markiert,<br/>sortiert nach Beschwerdezahl"]
    D -->|nein| F["Normaler Tag, keine Markierung"]

Die Formel dahinter, wörtlich aus der Implementierung:

Schwelle = max(3, 2,0 × Tagesdurchschnitt)
Tag ist auffällig, wenn: Beschwerden_an_diesem_Tag ≥ Schwelle

Warum zwei Bedingungen statt einer? Die absolute Mindestzahl (3) verhindert, dass eine winzige, ruhige App bereits bei zwei Beschwerden Alarm schlägt — zwei Grummler an einem sonst stillen Tag sind ein relativer Ausreißer, aber absolut betrachtet nichts. Der Faktor (2,0×) verhindert das Gegenteil: dass eine vielbesprochene App ständig „Alarm" meldet, obwohl die Zahl im Rahmen des Üblichen liegt. Erst wenn beide Bedingungen erfüllt sind, ist ein Tag tatsächlich einen Blick wert.

Eine Regel, zwei Verbraucher. Genau diese eine Funktion liefert sowohl die auffälligen Tage in der Trend-Auswertung als auch den „Ausreißertag"- Hinweis im PDF-Bericht. Es gibt keine zweite, unabhängige Implementierung derselben Idee — würde es sie geben, könnten API und Bericht für dasselbe Fenster unterschiedliche Tage als auffällig markieren, und niemand könnte sagen, welche Aussage stimmt.

Die Beschwerdequote selbst wird zusätzlich gegen eine feste Aufmerksamkeitsschwelle von 40 % gespiegelt: Überschreitet die Quote diesen Wert, gilt das Fenster insgesamt als „besorgniserregend" — unabhängig davon, ob es dabei auch einen einzelnen auffälligen Tag gab oder nicht.

5. Ein gemessenes Beispiel

Eine App mit einem Tagesdurchschnitt von 4 Beschwerden hat an einem Tag 9 Beschwerden. Die Schwelle liegt bei max(3, 2,0 × 4) = 8. Da 9 ≥ 8, wird der Tag markiert. Am selben Fenster: eine sehr kleine App mit einem Tagesdurchschnitt von 0,5 Beschwerden hat an einem Tag 2 Beschwerden. Die Schwelle liegt bei max(3, 2,0 × 0,5) = max(3, 1) = 3. Da 2 < 3, wird der Tag nicht markiert — obwohl er relativ betrachtet das Vierfache des Durchschnitts war. Genau das ist die Absicherung durch die absolute Mindestzahl.

6. Grenzen der Methode

  • Die Regel misst Häufigkeit, nicht Schwere. Ein einzelner Ein-Stern-Ausbruch über einen Datenverlust-Bug zählt gleich wie zehn milde Beschwerden über Werbung, solange die Zahl stimmt.
  • Der Faktor 2,0 und die Mindestzahl 3 sind bewusst gewählte, feste Konstanten — kein statistisches Modell mit Standardabweichung. Das macht die Regel für jeden nachvollziehbar, der die zwei Zahlen kennt, aber auch weniger empfindlich für sehr unregelmäßige, seltene Verläufe.
  • Ein auffälliger Tag sagt „hier lohnt ein Blick" — er sagt nicht, warum. Die Ursache (ein Update, ein Vorfall, eine Kampagne) muss der Mensch danach selbst zuordnen.

7. Fazit

Die Stärke dieser Regel liegt nicht in mathematischer Raffinesse, sondern in Konsequenz: eine einzige, einfache Formel, geteilt zwischen allen Stellen, die „auffällig" behaupten. Kein Kunde muss einer Blackbox vertrauen — die Formel passt in zwei Zeilen und lässt sich mit Taschenrechner nachprüfen. Das ist der Unterschied zwischen einem System, dem man glauben muss, und einem, das man selbst überprüfen kann.

Der nächste Teil bringt Beschwerdequote, Themen und auffällige Tage zusammen: wie daraus ein Bericht entsteht, der nicht nur Zahlen zeigt, sondern konkrete Empfehlungen ausspricht — mit einer eingebauten Ehrlichkeitsschwelle, die auch einmal „dafür reicht die Datenlage nicht" sagen darf. → Teil 5: Der Bericht, der auch Nein sagen kann (folgt)

← Teil 3: Ohne Entwicklerkonto an die Daten