Qué funciones de PostHog vale la pena mirar primero en un ecommerce

Un ecommerce pierde plata en varios puntos del camino a la compra, casi nunca en uno solo. Alguien llega por un anuncio y rebota antes de ver el segundo producto. Otra persona arma el carrito y lo abandona en el paso de envío. Un pago falla y nadie se entera hasta que el cliente escribe a soporte. Se cambia el copy de la landing sin saber si la conversión subió por eso o por otra cosa de esa misma semana. Cada momento es una pregunta de negocio distinta, y PostHog es un conjunto de productos que responden preguntas distintas, no una sola herramienta. Vale la pena mirarlos agrupados por la pregunta que resuelven, no como catálogo de features.

¿De dónde viene el tráfico y qué está pasando en el sitio, en general?

El punto de partida razonable es Web Analytics: un dashboard con los números que cualquier equipo de sitio mira todos los días (visitantes, pageviews, sesiones, bounce rate, páginas top y de dónde vino el tráfico). PostHog lo describe a propósito como algo simple, no como reemplazo de la analítica de producto completa. Para un ecommerce con inversión en medios hay un plus concreto: la integración de spend de Google, Meta, LinkedIn, TikTok, Reddit y Bing, que muestra el gasto de ads junto al tráfico que generó, sin exportar planillas por plataforma. Lo que no hace es conectar ese tráfico con revenue de forma directa; eso llega más abajo.

¿Dónde se cae la gente en el camino a la compra?

Acá conviene ser preciso con lo que existe y lo que no. No hay una feature dedicada de "abandono de carrito": lo que hay es Funnels, la metodología general de embudos multi-paso de PostHog, y el embudo de checkout es una aplicación de esa metodología, no un producto aparte. Se arman los pasos de la compra (ver producto, agregar al carrito, iniciar checkout, cargar el pago, confirmar) y el sistema muestra en qué paso se cae más gente, con la lógica de que en cualquier flujo arranca más gente de la que termina. Lo más útil es la conversión relativa por paso, qué escalón pesa más sobre la conversión total en vez de la caída acumulada, y la posibilidad de segmentar por dispositivo o fuente de tráfico. Esta lógica de medir antes de decidir es la que desarrollamos en la nota sobre el gate de medición de PostHog.

¿Por qué falló ese pago puntual?

El funnel dice dónde se cae la gente en agregado, no por qué falló un caso puntual, el del cliente que escribió furioso porque su pago no pasó. Para eso sirve Session Replay: graba lo que hizo un usuario real y lo reproduce como un DVR, con un panel sincronizado tipo DevTools que muestra logs de consola, requests de red y errores en el momento exacto en que pasaron, en vez de pedirle al cliente que describa lo que vio. No hay una integración específica de replay con eventos de pago: es una herramienta genérica, y el valor para checkout aparece porque uno decide mirar ahí.

¿Qué cambio conviene testear?

Una vez que el funnel señaló el paso problemático, la pregunta siguiente es qué cambiar y cómo saber si funcionó. Experiments permite testear una variante contra un control usando los eventos que ya se capturan, sin instrumentación nueva, y calcula el resultado con análisis bayesiano o frecuentista según se prefiera. También detecta amenazas a la validez (splits desbalanceados, contaminación entre variantes, cambios de flag a mitad de camino), pero esa detección requiere revisión humana: el sistema avisa, no corrige solo.

¿Qué no te dicen los números?

Los funnels y los experimentos muestran qué pasó, no por qué. Ahí entra Surveys, feedback cualitativo (NPS, product-market fit, motivos de churn, texto libre), con targeting: mostrarla solo a quien abandonó el checkout o a quien ya compró varias veces. Cada respuesta queda como un evento más, consultable junto al resto de los datos.

¿Cómo se mueve la gente por el sitio, qué clickea?

Antes de decidir qué embudo armar o qué testear, ayuda ver el comportamiento de forma visual. Heatmaps, scrollmaps y clickmaps muestran dónde clickea la gente, qué son dead clicks (clicks que no llevan a nada) o rageclicks (clicks repetidos por frustración), y hasta dónde scrollea. Requiere autocapture activado; si el sitio bloquea el embedding en iframe, el heatmap no se ve dentro de la app.

¿Cómo se une el dato de compra con el de producto?

Esta es la pregunta que más separa a un ecommerce chico de uno que ya mide en serio. Data Warehouse sincroniza fuentes externas (Stripe, Postgres, Salesforce, HubSpot y muchas otras, además de archivos CSV, JSON o Parquet) y las deja consultables junto a los eventos, personas y sesiones que ya vive en PostHog, en el mismo SQL: cruzar una compra registrada en Stripe con la sesión de producto que la originó. Sobre esa base aparece Revenue Analytics, hoy en beta y vale la pena entender antes de prometerlo en una reunión: el dashboard fijo de revenue que existía fue eliminado, y lo que queda son propiedades de revenue en personas y grupos, para insights, SQL y perfiles de cliente, conectadas a plataformas de pago (Stripe es el ejemplo explícito de la documentación). Para mover datos hacia afuera está Data Pipelines, la categoría de producto que en PostHog se llama así (no "el CDP de PostHog": CDP es la categoría, no el nombre), que transforma eventos al ingerirlos y los manda a destinos como Slack, HubSpot, Intercom, webhooks o el propio warehouse.

Todo esto se apoya en Product Analytics: trends, funnels, retention, paths, stickiness y lifecycle sobre los eventos ya capturados, la capa que conectamos en nuestra nota sobre product analytics en PostHog. Hay una forma más directa de usarla: PostHog AI, el analista embebido que responde en lenguaje natural y arma insights, SQL, dashboards, encuestas, alertas y flags a pedido, respetando los controles de acceso que ya existen. Es una capa de asistencia, no de piloto automático sobre el negocio; esa distinción la desarrollamos en la nota sobre el modo self-driving de PostHog.

Por dónde arrancar si estás en cero

No hace falta prender todo el día uno. El orden con más sentido: Web Analytics primero, para el panorama general; Funnels sobre el checkout, para encontrar el paso que más gente pierde; Session Replay en las páginas de pago, para casos puntuales; y recién después Experiments, cuando ya hay una hipótesis concreta. Heatmaps, Surveys, Data Warehouse y Revenue Analytics suman valor real, pero conviene sumarlos cuando ya hay hábito semanal de mirar los primeros tres, la misma lógica de priorizar medición sobre herramientas que planteamos en la nota sobre producto, growth y tecnología.

Para quién es esto

Esta nota sirve para equipos de producto o marketing de un ecommerce que ya tienen PostHog instalado, o lo están evaluando, y no saben por dónde arrancar entre tantos productos con nombres parecidos. También sirve para quien viene de mirar solo Google Analytics o una herramienta de heatmaps suelta y quiere entender qué gana al tener embudos, replay, experimentos y encuestas sobre la misma base de eventos. No es una guía de instalación, es un mapa de qué mirar según la pregunta.

Este contenido fue desarrollado con asistencia de IA y revisado por el equipo de Zenda. Las malas ideas son 100% nuestras.