KPIs für KI-Produkte: Prompt-Success schlägt MAU

Warum MAU bei KI-Features lügt

Ein Beispiel, das sich in vielen Teams wiederholt: Der neue KI-Assistent zeigt beeindruckende Nutzungskurven – und sechs Monate später bricht alles ein. Was passiert ist: Nutzer haben probiert, mittelmässige Antworten bekommen, still korrigiert und irgendwann aufgegeben. MAU hat die ganze Zeit «Erfolg» gemeldet, weil Neugier wie Nutzen aussieht. Bei deterministischen Features ist Nutzung ein brauchbarer Wert-Proxy. Bei probabilistischen ist sie nur die Eintrittskarte.

Der Grund liegt in der Natur der Sache: Eine Suchfunktion, die funktioniert, funktioniert für alle gleich. Ein LLM-Feature liefert jedem Nutzer eine andere Qualität – je nach Eingabe, Kontext und Tagesform des Modells. Deshalb braucht KI-Messung eine Ebene, die klassische Produktanalytik nie hatte: Wie gut war die Antwort? Und die beantwortet kein Dashboard von der Stange, sondern eine bewusst gebaute Feedback-Architektur.

Die vier Ebenen eines KI-Messsystems

Qualität. Akzeptanzrate (übernommen ohne Edit), Korrektur- und Retry-Quote, Eval-Score auf dem fixen Testset. Das ist die Ebene, die über Leben und Tod des Features entscheidet – und die einzige, die Drift früh sieht.

Engagement. Wiederkehr nach 7 und 30 Tagen, Nutzungstiefe pro Session, Anteil der Workflows mit KI-Beteiligung. Hier hilft HEART (Happiness, Engagement, Adoption, Retention, Task Success) als Raster – Retention ist bei KI das ehrlichste Engagement-Signal.

System. Latenz-Perzentile, Fehler- und Timeout-Raten, Kosten pro Antwort. Unsichtbar fürs Marketing, entscheidend fürs Überleben: Ein brillantes Feature mit acht Sekunden Latenz wird nicht adoptiert, eines mit explodierenden Token-Kosten nicht verlängert.

Business. Zeitersparnis pro Aufgabe, Support-Deflection, Conversion- und Upgrade-Wirkung. Die Ebene, die C-Level und Kunden sehen wollen – glaubwürdig nur, wenn die Qualitätsebene darunter stimmt.

Feedback-Schleifen bauen, die nicht lügen

Daumen-Buttons sind besser als nichts – aber wer nur sie misst, hört vor allem die Extreme: Begeisterte und Verärgerte klicken, die Mitte schweigt. Die belastbare Architektur setzt auf implizite Signale, die ohnehin anfallen: Wurde der Vorschlag übernommen? Wie stark editiert? Kam ein Retry? Wurde das Ergebnis verworfen? Diese Signale decken praktisch jede Interaktion ab und korrelieren direkt mit Nutzwert.

Wichtig ist die Verbindung zur Operate-Phase: Dieselben Signale, die den Health-Score füttern, sind dein Drift-Frühwarnsystem und dein Rohstoff für bessere Eval-Sets. Ein gut instrumentiertes KI-Feature misst sich selbst – der PM muss nur noch Schwellen setzen und auf Trends reagieren statt auf Anekdoten.

Empfehlungen

• Mache die Akzeptanzrate zur Nordstern-Qualitätsmetrik. Übernommen ohne Nachbearbeitung – pro Feature, wöchentlich, mit Schwelle. Sie ist implizit, flächendeckend und schwer zu schönen.
• Berichte immer alle vier Ebenen. Ein KI-Dashboard mit Qualität, Engagement, System und Business nebeneinander. Jede Ebene allein erzählt eine schöne, falsche Geschichte.
• Instrumentiere implizit zuerst. Übernehmen, Editieren, Retry, Verwerfen – vor jedem Daumen-Button. Explizites Feedback ist die Ergänzung, nicht das Fundament.
• Rechne Kosten pro akzeptierter Antwort. Inferenzkosten geteilt durch akzeptierte Ausgaben. Diese eine Zahl verbindet Modellqualität, Nutzwert und Marge – und gehört in jedes Quartals-Review.

Einordnung & Grenzen

• Akzeptanzraten sind use-case-abhängig: Bei kreativen Aufgaben ist Editieren normal und kein Qualitätsmangel. Kalibriere Schwellen pro Feature-Typ statt eine Universalzahl zu jagen.
• Der Health-Score im Widget ist ein Denkwerkzeug mit illustrativen Gewichten, kein Benchmark. Die richtige Gewichtung hängt von deinem Use Case ab – ein Support-Bot gewichtet anders als ein Code-Assistent.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.