Pregunta a tus datos dónde abandonan

Qué es y por qué importa

La gente descarga tu app, ¿y luego? Una parte llega al primer uso de verdad y otra se pierde por el camino. Dónde, normalmente no lo sabes: abres las analíticas, miras diez gráficos y cierras sin haber cambiado nada.

Si usas PostHog para las analíticas, puedes conectarlo a Claude Code con su servidor MCP. MCP es la forma estándar en que Claude Code habla con un servicio externo: una vez conectado, Claude consulta tus datos solo, con las herramientas de PostHog para funnels, consultas, insights, feature flags y experimentos. Y como es la misma sesión en la que está tu código, pasa directamente del número a la pantalla.

La vuelta completa: funnel, el paso donde pierdes más gente, el código de esa pantalla, un cambio que ve la mitad de los usuarios, el resultado unos días después. Conectarse al servidor MCP es gratis y PostHog tiene un plan gratuito generoso en cada producto, sin tarjeta de crédito. Solo algunas herramientas que usan la IA de PostHog pueden facturarse aparte.

1. Conecta PostHog a Claude Code

El servidor MCP de PostHog lo alojan ellos, en https://mcp.posthog.com/mcp. En el terminal, fuera de Claude Code, lanza:

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

-s user significa «para mí, en todos los proyectos». Sin él, el servidor solo vale en el proyecto en el que estás, que es el ámbito por defecto. Luego abre Claude Code, escribe /mcp, elige posthog e inicia sesión: se abre el navegador, entras en PostHog y autorizas. Nada de claves que copiar, y es PostHog quien te lleva a la región correcta, Estados Unidos o Europa, según tu cuenta.

Con Claude Code el servidor ofrece una sola herramienta, exec, con la que Claude encuentra y llama a las demás cuando hacen falta: ahorras contexto. Lo primero, comprueba el proyecto:

Usa PostHog: dime a qué organización y a qué proyecto estás conectado, y dame los 20 eventos más frecuentes de los últimos 30 días, con el número de personas únicas de cada uno. No crees ni modifiques nada.

Si al principio quieres que Claude solo pueda leer, en lugar del comando de antes usa este, con ?readonly=true al final de la dirección: desaparecen las herramientas que crean, modifican o borran. Para la parte del flag lo quitas con claude mcp remove posthog y vuelves a poner el normal. Y como dice el propio PostHog, lee cada llamada antes de aprobarla.

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

2. El funnel, de la instalación al primer uso de verdad

Un funnel, o embudo, es una fila de pasos en orden, con cuántas personas llegan a cada uno. El primer uso de verdad lo decides tú: el primer entrenamiento terminado, la primera nota guardada. No «abrió la app», sino el momento en que obtuvo aquello para lo que la descargó. En las apps de móvil, los SDK de PostHog pueden registrar solos el evento Application Installed: comprueba que esté activo.

Usa PostHog. Construye un funnel de los últimos 30 días desde la instalación hasta el primer uso de verdad de mi app: [Application Installed] → [registro completado] → [onboarding terminado] → [primer entrenamiento completado]. Primero comprueba que estos eventos existen de verdad y dime si falta alguno, sin inventarlos. Luego dame, para cada paso, cuántas personas llegan, el porcentaje respecto al paso anterior y cuánto tardan normalmente.

Pon los nombres de tus eventos en lugar de los que van entre corchetes: si no los sabes, sácalos de la lista de antes. Y pide el porcentaje respecto al paso anterior: la documentación de PostHog explica que es el que muestra dónde hay más que ganar.

3. Encuentra dónde abandonan

En el funnel, ¿cuál es el paso donde pierdo más personas? Dame el número y el porcentaje. Luego divide ese paso por sistema operativo, versión de la app y país, y dime si la caída es igual para todos o se concentra en un grupo. Por último, encuentra en el código la pantalla donde ocurre ese paso y enséñame el archivo.

La división por grupos importa: si la caída está toda en una versión o en un sistema, quizá es un bug y no un problema de diseño. Y si grabas las sesiones con PostHog, pide a Claude que liste algunas personas que se pararon justo ahí y mira sus grabaciones: a menudo es la forma más rápida de entender el porqué.

4. Un cambio, para la mitad de los usuarios

Ahora pide una propuesta, no una corrección:

Abre el código de la pantalla de [paso] y dime las 3 causas más probables por las que la gente se para ahí, a partir de lo que ves en el código y en los datos. Para cada una propón un solo cambio pequeño. No escribas código hasta que elija uno.

Elige uno. Para probarlo necesitas un feature flag, es decir, un interruptor que la app lee mientras funciona (hablo de ello en la guía INTERRUTTORE, strikt.fit/interruttore). Para medir, lo más limpio es un experimento de PostHog: crea él el flag con dos variantes, control (como está ahora) y test (el cambio), reparte a la gente al azar, lleva la cuenta de quién ve qué y hace los cálculos estadísticos por ti.

Usa PostHog. Crea un experimento llamado [onboarding-mas-corto] con dos variantes, control y test, repartidas 50 y 50, con el funnel de [paso] a [primer entrenamiento completado] como métrica principal. Luego pon el cambio elegido detrás de su flag: con control el usuario ve la pantalla actual, con test la nueva. Incluye solo a quien llega a esa pantalla por primera vez, y si el flag no se puede leer, muestra la versión actual. Antes de lanzarlo dime cuántas personas hacen falta y cuántos días se necesitan con el tráfico que tengo.

«Por primera vez», porque PostHog aconseja incluir solo a quien se ve afectado por el cambio. «Si no se puede leer», para que un problema de red no enseñe a todos algo a medias. «Cuántas personas hacen falta», porque la calculadora de PostHog te lo dice antes de empezar. Y en iPhone el cambio tiene que estar ya en la versión publicada: el flag solo enciende código que existe.

Antes del 50 y 50, PostHog sugiere una vuelta de prueba con una parte pequeña de los usuarios, por ejemplo el 5%, durante unos días: compruebas que llegan los eventos y que no hay cierres inesperados. Si el experimento arranca roto y lo relanzas, los resultados ya no son fiables, porque mucha gente ya ha visto el cambio.

5. Lee el resultado

Cuando hayan pasado los días que te dio la calculadora, por ejemplo una semana:

Usa PostHog. Dame los resultados del experimento [onboarding-mas-corto]: cuántas personas por variante, la conversión de control y de test, y si la diferencia es estadísticamente significativa. Dime si hemos llegado a las personas que hacían falta. Si no es significativa o faltan personas, dímelo claro y no declares un ganador.

Si gana test, lo llevas a todos y limpias: el propio PostHog dice que al final de un experimento se conserva el código de la variante ganadora y se borra el de la perdedora. Si no hay diferencia, eso también es un resultado: vuelves a la lista de las 3 causas y pruebas la segunda.

El experimento [onboarding-mas-corto] lo ha ganado test. Ciérralo en PostHog llevando test a todos, luego quita del código el flag y la versión antigua, ejecuta los tests y dime qué has cambiado.

6. Cómo no engañarte

• Decide antes cuánto dura. Mirar los resultados cada día y pararse en el primer número bonito es lo que PostHog llama el peeking problem: si miras suficientes veces, tarde o temprano algo parece ganar por casualidad.
• Suficientes personas. Con pocos usuarios, una diferencia suele ser pura casualidad. Para que te hagas una idea, en el ejemplo de la documentación de PostHog, con una conversión del 10% y un cambio a detectar del 20%, hacen falta unas 3.600 personas por variante. Si tienes muchas menos, prueba cambios más grandes.
• Un cambio cada vez. Si cambias texto, color y número de pasos a la vez, nunca sabrás qué ha funcionado.
• Mira también qué empeora. Una pantalla más corta puede llevar a más gente al paso siguiente y a menos gente a volver al día siguiente. Elige antes una segunda métrica que vigilar.

Errores comunes

• Dejar que Claude adivine los nombres de los eventos. Pide primero la lista y luego construye el funnel.
• Trabajar en el proyecto equivocado. Una conexión tiene una cuenta y un proyecto activo: comprueba cuál antes de crear nada.
• Activar el cambio para todos. Sin un grupo que vea la versión antigua, no tienes con qué comparar.
• Parar el experimento el primer día bueno. Espera la duración que decidiste antes.
• Dejar el flag en el código después de decidir. Quita el flag y la variante que perdió.

Lista de comprobación

• Servidor MCP de PostHog añadido y sesión iniciada desde /mcp.
• Proyecto correcto comprobado, lista de eventos a mano.
• Funnel hasta el primer uso de verdad, con los porcentajes paso a paso.
• Peor paso dividido por grupos y pantalla encontrada en el código.
• Un solo cambio, detrás de un experimento 50 y 50, probado antes con pocos usuarios.
• Duración y número de personas decididos antes de empezar.
• Resultado leído con su significancia, flag quitado al acabar el experimento.

Preguntas frecuentes