Frag deine Daten, wo die Leute aufgeben

Was es ist und warum es zählt

Die Leute laden deine App herunter, und dann? Ein Teil kommt bis zur ersten echten Nutzung, ein Teil geht unterwegs verloren. Wo, weißt du meistens nicht: Du öffnest die Analytics, schaust dir zehn Diagramme an und schließt sie wieder, ohne etwas geändert zu haben.

Wenn du PostHog für deine Analytics nutzt, kannst du es über seinen MCP-Server mit Claude Code verbinden. MCP ist der Standardweg, auf dem Claude Code mit einem externen Dienst spricht: Sobald die Verbindung steht, fragt Claude deine Daten selbst ab, mit den Werkzeugen von PostHog für Funnels, Abfragen, Insights, Feature Flags und Experimente. Und weil es dieselbe Sitzung ist, in der dein Code liegt, geht es von der Zahl direkt zum Bildschirm.

Die ganze Runde: Funnel, der Schritt mit den meisten Verlusten, der Code dieses Bildschirms, eine Änderung für die Hälfte der Nutzer, das Ergebnis ein paar Tage später. Die Verbindung zum MCP-Server ist kostenlos, und PostHog hat für jedes Produkt einen großzügigen Gratisrahmen, ohne Kreditkarte. Nur manche Werkzeuge, die die KI von PostHog nutzen, können extra abgerechnet werden.

1. Verbinde PostHog mit Claude Code

Der MCP-Server von PostHog wird von PostHog selbst gehostet, unter https://mcp.posthog.com/mcp. Führe im Terminal, außerhalb von Claude Code, aus:

claude mcp add --transport http posthog https://mcp.posthog.com/mcp -s user

-s user heißt „für mich, in allen Projekten“. Ohne gilt der Server nur in dem Projekt, in dem du gerade bist, das ist der Standardbereich. Dann öffne Claude Code, gib /mcp ein, wähle posthog und melde dich an: Der Browser öffnet sich, du loggst dich bei PostHog ein und erteilst die Freigabe. Keine Schlüssel zum Kopieren, und PostHog leitet dich anhand deines Kontos in die richtige Region, USA oder EU.

Mit Claude Code stellt der Server nur ein Werkzeug bereit, exec, mit dem Claude die anderen bei Bedarf findet und aufruft: Du sparst Kontext. Prüf zuerst das Projekt:

Nutze PostHog: Sag mir, mit welcher Organisation und welchem Projekt du verbunden bist, und gib mir die 20 häufigsten Events der letzten 30 Tage, mit der Zahl der einzelnen Personen pro Event. Erstelle und ändere nichts.

Wenn Claude anfangs nur lesen können soll, nimm statt des Befehls von oben diesen, mit ?readonly=true am Ende der Adresse: Die Werkzeuge, die erstellen, ändern oder löschen, verschwinden. Für den Teil mit dem Flag entfernst du ihn mit claude mcp remove posthog und fügst den normalen wieder hinzu. Und wie PostHog selbst sagt: Lies jeden Aufruf, bevor du ihn freigibst.

claude mcp add --transport http posthog "https://mcp.posthog.com/mcp?readonly=true" -s user

2. Der Funnel, von der Installation bis zur ersten echten Nutzung

Ein Funnel, also ein Trichter, ist eine Reihe von Schritten in fester Reihenfolge, mit der Zahl der Personen, die jeden erreichen. Was die erste echte Nutzung ist, entscheidest du: das erste abgeschlossene Training, die erste gespeicherte Notiz. Nicht „hat die App geöffnet“, sondern der Moment, in dem jemand bekommen hat, wofür er sie heruntergeladen hat. In Handy-Apps können die SDKs von PostHog das Event Application Installed selbst erfassen: Prüf, ob es aktiv ist.

Nutze PostHog. Bau einen Funnel der letzten 30 Tage von der Installation bis zur ersten echten Nutzung meiner App: [Application Installed] → [Registrierung abgeschlossen] → [Onboarding fertig] → [erstes Training abgeschlossen]. Prüf zuerst, ob es diese Events wirklich gibt, und sag mir, ob eines fehlt, ohne etwas zu erfinden. Dann gib mir für jeden Schritt, wie viele Personen ihn erreichen, den Prozentsatz im Vergleich zum vorigen Schritt und wie lange sie normalerweise brauchen.

Setz die Namen deiner Events an die Stelle der Begriffe in eckigen Klammern: Wenn du sie nicht kennst, nimm sie aus der Liste von vorhin. Und frag nach dem Prozentsatz im Vergleich zum vorigen Schritt: Die Dokumentation von PostHog erklärt, dass genau er zeigt, wo es am meisten zu holen gibt.

3. Finde heraus, wo sie aufgeben

An welchem Schritt im Funnel verliere ich die meisten Personen? Gib mir die Zahl und den Prozentsatz. Dann teil diesen Schritt nach Betriebssystem, App-Version und Land auf und sag mir, ob der Einbruch bei allen gleich ist oder sich auf eine Gruppe konzentriert. Zum Schluss such im Code den Bildschirm, auf dem dieser Schritt passiert, und zeig mir die Datei.

Die Aufteilung nach Gruppen zählt: Wenn der Einbruch ganz auf einer Version oder einem System liegt, ist es vielleicht ein Bug und kein Design-Problem. Und wenn du Sitzungen mit PostHog aufzeichnest, bitte Claude, ein paar Personen aufzulisten, die genau dort aufgehört haben, und sieh dir ihre Aufnahmen an: Oft ist das der schnellste Weg, das Warum zu verstehen.

4. Eine Änderung, für die Hälfte der Nutzer

Jetzt bitte um einen Vorschlag, nicht um eine Korrektur:

Öffne den Code des Bildschirms [Schritt] und nenn mir die 3 wahrscheinlichsten Gründe, warum die Leute dort aufhören, ausgehend von dem, was du im Code und in den Daten siehst. Schlag für jeden eine einzige kleine Änderung vor. Schreib keinen Code, bis ich eine ausgewählt habe.

Wähl eine aus. Um sie zu testen, brauchst du ein Feature Flag, also einen Schalter, den die App während der Laufzeit liest (mehr dazu im Guide INTERRUTTORE, strikt.fit/interruttore). Zum Messen ist ein Experiment von PostHog der sauberste Weg: Es legt das Flag mit zwei Varianten an, control (wie jetzt) und test (die Änderung), teilt die Leute zufällig auf, hält fest, wer was sieht, und erledigt die Statistik für dich.

Nutze PostHog. Leg ein Experiment namens [kuerzeres-onboarding] mit zwei Varianten an, control und test, aufgeteilt 50 zu 50, mit dem Funnel von [Schritt] bis [erstes Training abgeschlossen] als Hauptmetrik. Dann setz die gewählte Änderung hinter ihr Flag: Bei control sieht der Nutzer den aktuellen Bildschirm, bei test den neuen. Nimm nur Leute auf, die diesen Bildschirm zum ersten Mal erreichen, und wenn sich das Flag nicht lesen lässt, zeig die aktuelle Version. Sag mir vor dem Start, wie viele Personen nötig sind und wie viele Tage es bei meinem Traffic dauert.

„Zum ersten Mal“, weil PostHog empfiehlt, nur die Leute einzubeziehen, die von der Änderung betroffen sind. „Wenn es sich nicht lesen lässt“, damit ein Netzwerkproblem nicht allen etwas Halbfertiges zeigt. „Wie viele Personen nötig sind“, weil der Rechner von PostHog dir das vor dem Start sagt. Und auf dem iPhone muss die Änderung schon in der veröffentlichten Version stecken: Das Flag schaltet nur Code ein, der da ist.

Vor der 50-zu-50-Aufteilung empfiehlt PostHog einen Probelauf mit einem kleinen Teil der Nutzer, zum Beispiel 5 %, für ein paar Tage: Du prüfst, ob die Events ankommen und ob es keine Abstürze gibt. Startet das Experiment kaputt und du startest es neu, sind die Ergebnisse nicht mehr verlässlich, weil viele die Änderung schon gesehen haben.

5. Lies das Ergebnis

Wenn die Tage um sind, die dir der Rechner genannt hat, zum Beispiel eine Woche:

Nutze PostHog. Gib mir die Ergebnisse des Experiments [kuerzeres-onboarding]: wie viele Personen pro Variante, die Conversion von control und von test und ob der Unterschied statistisch signifikant ist. Sag mir, ob wir die nötige Zahl an Personen erreicht haben. Wenn er nicht signifikant ist oder Leute fehlen, sag es klar und ruf keinen Gewinner aus.

Gewinnt test, bringst du die Änderung zu allen und räumst auf: PostHog selbst sagt, dass man am Ende eines Experiments den Code der Gewinner-Variante behält und den der Verlierer-Variante löscht. Gibt es keinen Unterschied, ist auch das ein Ergebnis: Geh zurück zur Liste der 3 Gründe und probier den zweiten.

Das Experiment [kuerzeres-onboarding] hat test gewonnen. Beende es in PostHog, indem du test für alle ausrollst, entferne dann das Flag und die alte Version aus dem Code, führe die Tests aus und sag mir, was du geändert hast.

6. Wie du dich nicht selbst täuschst

• Leg die Dauer vorher fest. Jeden Tag auf die Ergebnisse zu schauen und beim ersten schönen Wert aufzuhören, nennt PostHog das Peeking-Problem: Wer oft genug nachsieht, findet früher oder später zufällig einen scheinbaren Gewinner.
• Genug Personen. Bei wenigen Nutzern ist ein Unterschied oft nur Zufall. Zur Orientierung: Im Beispiel der Dokumentation von PostHog braucht man bei 10 % Conversion und einer zu erkennenden Änderung von 20 % rund 3.600 Personen pro Variante. Wenn du viel weniger hast, teste größere Änderungen.
• Eine Änderung nach der anderen. Wenn du Text, Farbe und Zahl der Schritte gleichzeitig änderst, weißt du nie, was gewirkt hat.
• Schau auch, was schlechter wird. Ein kürzerer Bildschirm kann mehr Leute zum nächsten Schritt bringen und weniger dazu, am nächsten Tag wiederzukommen. Leg vorher eine zweite Metrik fest, die du im Blick behältst.

Häufige Fehler

• Claude die Namen der Events raten lassen. Lass dir erst die Liste geben, dann bau den Funnel.
• Im falschen Projekt arbeiten. Eine Verbindung hat ein Konto und ein aktives Projekt: Prüf, welches, bevor du etwas anlegst.
• Die Änderung für alle einschalten. Ohne eine Gruppe, die die alte Version sieht, hast du nichts zum Vergleichen.
• Das Experiment am ersten guten Tag stoppen. Warte die vorher festgelegte Dauer ab.
• Das Flag nach der Entscheidung im Code lassen. Entferne das Flag und die Verlierer-Variante.

Checkliste

• MCP-Server von PostHog hinzugefügt und über /mcp angemeldet.
• Richtiges Projekt geprüft, Liste der Events zur Hand.
• Funnel bis zur ersten echten Nutzung, mit Prozentsätzen Schritt für Schritt.
• Schlechtester Schritt nach Gruppen aufgeteilt und Bildschirm im Code gefunden.
• Eine einzige Änderung, hinter einem 50-zu-50-Experiment, vorher an wenigen Nutzern getestet.
• Dauer und Zahl der Personen vor dem Start festgelegt.
• Ergebnis mit Signifikanz gelesen, Flag am Ende des Experiments entfernt.

Häufige Fragen