PostHog paso a paso: eventos, embudos, sesiones y feature flags

👁 119 lecturas

PostHog es un conjunto de herramientas para conocer a los usuarios de tu aplicación: analítica de eventos, embudos, grabaciones de sesión, feature flags y tests A/B en un solo lugar. Este tutorial te lleva desde la instalación hasta tu primer embudo y tu primera flag, siguiendo la documentación oficial de PostHog.

Antes de empezar: lista de preguntas

PostHog recoge muchos datos desde el momento de la instalación y es fácil ahogarse en ellos. Antes de instalar, anota tres preguntas a las que quieres encontrar respuesta, por ejemplo: cuántos usuarios nuevos completan el registro, qué funcionalidad se usa más, dónde abandona la gente la compra. Para cada pregunta, apunta los eventos que necesitas. Estos serán tus primeros eventos personalizados.

Establece también con tu equipo una convención de nombres para los eventos, porque luego es difícil cambiarla sin romper los gráficos.

Paso 1. Instalación

La vía más rápida según la documentación es el asistente que se ejecuta en el directorio del proyecto con un solo comando mediante npx. También funciona con asistentes de IA como Cursor. La alternativa es un fragmento de código que pegas en la página, en la sección head, con la clave del proyecto y la dirección del servidor, o bien una biblioteca instalada mediante npm.

La documentación también recomienda un servidor proxy, que reduce el riesgo de que los bloqueadores de anuncios intercepten los eventos. PostHog lo ofrece gratuitamente para usuarios de la nube.

Paso 2. Los eventos se recogen solos

Tras la instalación, la recogida automática está activada por defecto: vistas de página, clics, envíos de formularios y datos sobre sesiones. No necesitas configurar nada para ver los primeros datos. Los eventos personalizados, por ejemplo «registro completado», los envías con una línea de código con el nombre del evento y sus propiedades.

Paso 3. Primer embudo

Un embudo muestra cuántas personas pasan por cada paso y dónde se pierden. En el menú entras en Insights, de la lista junto al botón de nuevo gráfico seleccionas embudo. Empiezas por el primer evento, añades pasos intermedios y terminas en el evento que marca el éxito. Ejemplo: entrada en la página de registro, rellenado del formulario, confirmación del email.

El primer embudo suele mostrar de inmediato el paso donde se pierde más gente. Ahí es donde vale la pena mirar las grabaciones de sesión.

Paso 4. Grabaciones de sesión

Las grabaciones de sesión las activas con unas pocas líneas de configuración. Registran clics, scroll, escritura y transiciones entre páginas. Puedes filtrar las grabaciones, por ejemplo por clics múltiples frustrados, errores de JavaScript, eventos personalizados o variantes de flags. El soporte más completo es en páginas web; en aplicaciones móviles hay ciertas limitaciones.

Paso 5. Feature flags

Una flag te permite activar una nueva funcionalidad solo para parte de los usuarios. La creas en el panel de PostHog y en el código compruebas si está activada para esa persona. La documentación recomienda un lanzamiento gradual, empezando por el 5 o 10 por ciento de los usuarios y aumentando la proporción cuando todo funciona. Para pruebas puedes activar la flag para tu propio email.

Paso 6. Experimentos

Un test A/B lo creas en la sección de experimentos. El asistente tiene tres pasos: descripción con hipótesis y clave de flag, variantes con distribución porcentual, y métricas, por ejemplo conversión desde un embudo. En el código compruebas la variante de la flag y PostHog recoge los datos y calcula el resultado automáticamente.

Ejemplo: por qué la gente no completa el registro

Instalas PostHog con el asistente, esperas un día para tener datos y construyes un embudo de registro. El embudo muestra que la mitad de las personas se pierden en la confirmación del email. Filtras las grabaciones de sesión de quienes se perdieron y ves que vuelven al formulario porque no saben dónde buscar el email. Añades un mensaje tras una flag para la mitad de los usuarios y después de una semana comparas los resultados en el experimento.

En este ejemplo es importante el orden: primero los números del embudo, luego las grabaciones, al final el cambio. Si el equipo hubiera empezado por un cambio basado en una corazonada, por ejemplo rediseñar el formulario, podría haber estado mejorando un paso que no era el problema. El embudo señaló el lugar, las grabaciones explicaron la causa y el experimento comprobó si la corrección funciona. Cada uno de estos tres pasos lleva poco tiempo, pero juntos convierten las suposiciones en conocimiento.

Errores más frecuentes

• Falta de eventos personalizados para las acciones más importantes.
• Lanzar funcionalidades a todos a la vez en lugar de gradualmente.
• Grabaciones sin filtros, por lo que se pierden horas en ellas.

Cómo evaluar la primera semana

Después de una semana comprueba si tienes respuesta a al menos una de las tres preguntas. Si es así, pasa a las grabaciones de sesión de las personas del paso problemático. Si no, normalmente falta algún evento o está mal nombrado.

Comprueba también si los datos coinciden con la realidad. Compara por ejemplo el número de registros en PostHog con el número de cuentas en la base de datos. Una gran diferencia suele deberse a bloqueadores de anuncios, y el servidor proxy descrito en la documentación ayuda con esto.

Si tienes una aplicación pequeña y poco tráfico, no saques conclusiones de unos pocos días de datos. Un embudo con veinte personas puede mostrar diferencias aleatorias. Es mejor esperar unas semanas o centrarte en las grabaciones de sesión, que incluso con poco tráfico muestran problemas concretos.

// sigue leyendoCustomer.io paso a paso: usuarios, eventos y primera automatizaciónGuíasNVIDIA RTX Spark llega al mercado: eventos en seis ciudadesNoticiasBlack Friday 2026 y suscripciones de IA: ChatGPT, Gemini, ClaudeGuías