Chiedi ai tuoi dati dove mollano

Cos'è e perché conta

La gente scarica la tua app, e poi? Una parte arriva al primo uso vero, una parte si perde per strada. Dove, di solito non lo sai: apri le analytics, guardi dieci grafici e chiudi senza aver cambiato niente.

Se usi PostHog per le analytics, lo puoi collegare a Claude Code con il suo server MCP. MCP è il modo standard in cui Claude Code parla con un servizio esterno: una volta collegato, Claude interroga i tuoi dati da solo, con gli strumenti di PostHog per funnel, query, insight, feature flag ed esperimenti. E siccome è la stessa sessione in cui c'è il tuo codice, dal numero passa direttamente alla schermata.

Il giro completo: funnel, passaggio dove perdi più gente, codice di quella schermata, una modifica mostrata a metà degli utenti, risultato dopo qualche giorno. Collegarsi al server MCP è gratis e PostHog ha un free tier generoso su ogni prodotto, senza carta di credito. Solo alcuni strumenti che usano l'AI di PostHog possono essere fatturati a parte.

1. Collega PostHog a Claude Code

Il server MCP di PostHog è ospitato da loro, all'indirizzo https://mcp.posthog.com/mcp. Nel terminale, fuori da Claude Code, lancia:

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

-s user vuol dire «per me, in tutti i progetti». Senza, il server vale solo nel progetto in cui sei, che è l'ambito predefinito. Poi apri Claude Code, scrivi /mcp, scegli posthog e accedi: si apre il browser, fai login su PostHog e autorizzi. Niente chiavi da copiare, ed è PostHog a portarti nella regione giusta, Stati Uniti o Europa, in base al tuo account.

Con Claude Code il server dà un solo strumento, exec, con cui Claude trova e chiama gli altri quando servono: risparmi contesto. Per prima cosa controlla il progetto:

Usa PostHog: dimmi a quale organizzazione e a quale progetto sei collegato, e dammi i 20 eventi più frequenti degli ultimi 30 giorni, con il numero di persone uniche per ognuno. Non creare e non modificare niente.

Se all'inizio vuoi che Claude possa solo leggere, al posto del comando di prima usa questo, con ?readonly=true in fondo all'indirizzo: gli strumenti che creano, modificano o cancellano spariscono. Per la parte del flag lo togli con claude mcp remove posthog e rimetti quello normale. E come dice PostHog stesso, leggi ogni chiamata prima di approvarla.

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

2. Il funnel, dall'installazione al primo uso vero

Un funnel, o imbuto, è una fila di passaggi in ordine, con quante persone arrivano a ognuno. Il primo uso vero lo decidi tu: il primo allenamento finito, la prima nota salvata. Non «ha aperto l'app», ma il momento in cui ha avuto quello per cui l'ha scaricata. Nelle app per telefono gli SDK di PostHog possono registrare da soli l'evento Application Installed: controlla che sia attivo.

Usa PostHog. Costruisci un funnel degli ultimi 30 giorni dall'installazione al primo uso vero della mia app: [Application Installed] → [registrazione completata] → [onboarding finito] → [primo allenamento completato]. Prima controlla che questi eventi esistano davvero e dimmi se ne manca qualcuno, senza inventarli. Poi dammi per ogni passaggio quante persone ci arrivano, la percentuale rispetto al passaggio prima e quanto ci mettono di solito.

Metti i nomi dei tuoi eventi al posto di quelli tra parentesi quadre: se non li sai, prendili dalla lista di prima. E chiedi la percentuale rispetto al passaggio prima: la documentazione di PostHog spiega che è quella che mostra dove c'è più da guadagnare.

3. Trova dove mollano

Nel funnel, qual è il passaggio dove perdo più persone? Dammi il numero e la percentuale. Poi dividi quel passaggio per sistema operativo, versione dell'app e paese, e dimmi se il calo è uguale per tutti o concentrato in un gruppo. Infine trova nel codice la schermata dove avviene quel passaggio e mostrami il file.

La divisione per gruppi conta: se il calo è tutto su una versione o su un sistema, forse è un bug, non un problema di design. E se registri le sessioni con PostHog, chiedi a Claude di elencare alcune persone che si sono fermate proprio lì e guarda le loro registrazioni: spesso è il modo più veloce per capire il perché.

4. Una modifica, a metà degli utenti

Adesso chiedi una proposta, non una correzione:

Apri il codice della schermata di [passaggio] e dimmi le 3 cause più probabili per cui le persone si fermano lì, partendo da quello che vedi nel codice e nei dati. Per ognuna proponi una sola modifica piccola. Non scrivere codice finché non ne scelgo una.

Scegline una. Per provarla serve un feature flag, cioè un interruttore che l'app legge mentre gira (ne parlo nella guida INTERRUTTORE, strikt.fit/interruttore). Per misurare, il modo più pulito è un esperimento di PostHog: crea lui il flag con due varianti, control (com'è adesso) e test (la modifica), divide le persone a caso, tiene il conto di chi vede cosa e fa i calcoli statistici al posto tuo.

Usa PostHog. Crea un esperimento chiamato [onboarding-piu-corto] con due varianti, control e test, divise 50 e 50, con il funnel da [passaggio] a [primo allenamento completato] come metrica principale. Poi metti la modifica scelta dietro il suo flag: con control l'utente vede la schermata di adesso, con test quella nuova. Includi solo chi arriva a quella schermata per la prima volta, e se il flag non si riesce a leggere mostra la versione di adesso. Prima di lanciarlo dimmi quante persone servono e quanti giorni ci vogliono con il traffico che ho.

«Per la prima volta», perché PostHog consiglia di includere solo chi è toccato dalla modifica. «Se non si legge», così un problema di rete non mostra a tutti una cosa a metà. «Quante persone servono», perché il calcolatore di PostHog te lo dice prima di partire. E su iPhone la modifica deve già essere nella versione pubblicata: il flag accende solo codice che c'è.

Prima del 50 e 50, PostHog suggerisce un giro di prova su una piccola parte degli utenti, per esempio il 5%, per qualche giorno: controlli che gli eventi arrivino e che non ci siano crash. Se l'esperimento parte rotto e lo rilanci, i risultati non sono più affidabili, perché molti hanno già visto la modifica.

5. Leggi il risultato

Quando sono passati i giorni che ti ha detto il calcolatore, per esempio una settimana:

Usa PostHog. Dammi i risultati dell'esperimento [onboarding-piu-corto]: quante persone per variante, la conversione di control e di test e se la differenza è statisticamente significativa. Dimmi se abbiamo raggiunto le persone che servivano. Se non è significativa o ne mancano, dimmelo chiaro e non dichiarare un vincitore.

Se vince test, la porti a tutti e pulisci: PostHog stesso, a fine esperimento, dice di tenere il codice della variante vincente e cancellare quello della perdente. Se non c'è differenza, è un risultato anche quello: torni alla lista delle 3 cause e provi la seconda.

L'esperimento [onboarding-piu-corto] l'ha vinto test. Concludilo in PostHog portando test a tutti, poi togli dal codice il flag e la versione vecchia, lancia i test e dimmi cosa hai cambiato.

6. Come non ingannarti

• Decidi prima quanto dura. Guardare i risultati ogni giorno e fermarsi al primo numero bello è quello che PostHog chiama peeking problem: con abbastanza sbirciate, prima o poi qualcosa sembra vincere per caso.
• Abbastanza persone. Con pochi utenti una differenza è spesso solo caso. Per darti un'idea, nell'esempio della documentazione di PostHog, con una conversione del 10% e un cambio da vedere del 20%, servono circa 3.600 persone per variante. Se ne hai molte meno, prova modifiche più grosse.
• Una modifica alla volta. Se cambi testo, colore e numero di passaggi insieme, non saprai mai cosa ha funzionato.
• Guarda anche cosa peggiora. Una schermata più corta può far arrivare più gente al passaggio dopo e meno gente a tornare il giorno dopo. Scegli prima una seconda metrica da tenere d'occhio.

Gli errori più comuni

• Lasciare che Claude indovini i nomi degli eventi. Fatti dare prima la lista, poi costruisci il funnel.
• Lavorare sul progetto sbagliato. Una connessione ha un account e un progetto attivo: controlla quale prima di creare qualcosa.
• Accendere la modifica per tutti. Senza un gruppo che vede la versione vecchia, non hai niente con cui confrontare.
• Fermare l'esperimento al primo giorno buono. Aspetta la durata decisa prima.
• Lasciare il flag nel codice dopo la decisione. Togli il flag e la variante che ha perso.

Checklist

• Server MCP di PostHog aggiunto e login fatto da /mcp.
• Progetto giusto controllato, lista degli eventi in mano.
• Funnel fino al primo uso vero, con le percentuali passaggio per passaggio.
• Passaggio peggiore diviso per gruppi e schermata trovata nel codice.
• Una sola modifica, dietro un esperimento 50 e 50, provata prima su pochi utenti.
• Durata e numero di persone decisi prima di partire.
• Risultato letto con la significatività, flag tolto a fine esperimento.

Domande frequenti