La mayoría de los embudos miden el producto, no al usuario

Abre una herramienta de analítica típica y los embudos están construidos a partir de los eventos que el equipo de ingeniería resultó instrumentar: route_loaded, account_created_v2, modal_opened. Son técnicamente precisas y casi inútiles para las decisiones de producto, porque describen lo que el software hizo, no lo que el usuario intentaba hacer. Un embudo que mide tu base de código te dice cuándo se renderizó un componente; un embudo que mide la intención te dice dónde alguien se rindió.

La solución es construir los embudos al revés, a partir del comportamiento observado — y validar cada paso contra grabaciones reales antes de confiar en un solo número. Aquí está el flujo de trabajo.

Nombra los pasos según la intención del usuario

Los mejores embudos se leen como una historia de usuario: llega a precios → inicia el registro → crea un espacio de trabajo → instala el fragmento → ve la primera grabación. Cada paso describe el progreso desde el punto de vista del usuario. Las etiquetas internas como account-created-v2 o dashboard-route-loaded son útiles para el código, pero ocultan la intención en la revisión de producto.

Cuando un embudo se nombra en el lenguaje del usuario, todos detectan el hueco más rápido. Si muchos usuarios crean un espacio de trabajo pero no instalan el fragmento, la siguiente pregunta es obvia — y no necesitas un analista para traducir. Una prueba simple: si una persona recién contratada no puede leer en voz alta los pasos de tu embudo y entender el objetivo del usuario, los pasos están nombrados para ingenieros, no para decisiones.

Valida cada paso con grabaciones

Antes de tratar un embudo como una verdad, observa sesiones en torno a cada transición. Los errores de embudo más comunes no están en el gráfico, sino en las definiciones de eventos que lo alimentan:

  • Se dispara demasiado pronto: el evento se dispara cuando un componente se renderiza o una ruta se carga, no cuando el usuario completa realmente la acción — inflando ese paso y ocultando la fuga que hay debajo.
  • Se dispara con demasiada frecuencia: un reintento, un re-renderizado o un doble envío cuentan dos veces al mismo usuario, de modo que la conversión parece mejor de lo que es.
  • Se dispara por el motivo equivocado: el evento captura un efecto secundario en lugar del estado de éxito previsto.

Grabaciones de sesión son la forma más rápida de detectar definiciones de eventos que parecen correctas en un panel pero fallan en contexto. Mira tres sesiones por transición; si el evento coincide con lo que el usuario claramente pretendía, confía en el paso. Si no, corrige la definición antes de actuar sobre los datos.

Lee el abandono, luego ve a observarlo

El trabajo de un embudo no es mostrar un número — es señalarte las grabaciones que explican ese número. Cuando un paso pierde usuarios, no rediseñes por corazonada. Filtra a los usuarios que llegaron a ese paso y lo abandonaron, mira cinco de sus sesiones y normalmente encontrarás una de un pequeño conjunto de causas:

  • Un error de validación o un botón deshabilitado sin explicación.
  • Un campo obligatorio o un permiso que el usuario no tenía y no podía resolver.
  • Un momento de confusión — la siguiente acción no estaba donde miraban.
  • Nada malo en absoluto: consiguieron lo que necesitaban y se fueron satisfechos (una «fuga» que no lo es).

Ese último caso es por qué los embudos por sí solos engañan. El número dice «abandono»; la grabación dice «éxito». Solo el par dice la verdad.

Mantén un embudo de activación sagrado

Los equipos pequeños deberían mantener un único embudo de activación central y revisarlo cada semana. Resiste la tentación de crear una docena de embudos solapados — fragmentan la atención y dejan que cada uno elija el gráfico que favorece su proyecto. Un embudo enfocado crea un ritmo operativo compartido: qué cambió esta semana, dónde se movió la conversión y qué sesiones explican el movimiento.

En torno a ese único embudo sagrado puedes crear embudos efímeros y desechables para investigaciones específicas, y luego archivarlos. La disciplina consiste en tener un único número en el que todo el equipo confía y al que vuelve, no en maximizar la cantidad de paneles.

Preguntas frecuentes

¿Los pasos del embudo deben ser páginas vistas o eventos?

Eventos, casi siempre. Las páginas vistas describen la navegación, no el logro: un usuario puede cargar la página de «éxito» sin lograrlo, o lograrlo dentro de una aplicación de una sola página sin navegación. Define los pasos como los eventos que representan la intención real del usuario.

¿Cuántos pasos debería tener un embudo?

Solo los que cuenten la historia: normalmente entre cuatro y seis. Cada paso debe ser un punto de decisión significativo. Si dos pasos adyacentes siempre convierten juntos, fusiónalos; la diferencia entre ellos no te enseña nada.

¿Por qué la conversión de mi embudo parece peor que la realidad?

Normalmente un paso se dispara demasiado pronto o cuenta al mismo usuario más de una vez, o no estás deduplicando por usuario. Valida cada evento contra grabaciones y confirma que estás midiendo usuarios únicos, no eventos brutos.

¿Necesito session replay para usar bien los embudos?

Puedes ejecutar embudos sin ello, pero estarás adivinando las causas. Emparejar cada abandono con las grabaciones que hay detrás es lo que convierte un embudo de un informe de estado en una fuente de soluciones. Ve session replay sin el ruido.