Las decisiones de configuración detrás de todo análisis de embudos

¿Qué es el análisis de embudos?

En analítica web y de producto, el análisis de embudos es el método de definir una secuencia ordenada de pasos, nombrar un primer paso que marca la entrada y un último paso que marca la finalización, y contar después cuántos usuarios distintos llegan a cada paso dentro de un límite de tiempo fijo. El método convierte un flujo de eventos indiferenciados en una forma, porque cada paso contiene un subconjunto del paso anterior. Nada en los datos de evento en bruto decide esa forma: la decide un analista, al escribir la lista de pasos, la regla de entrada y el límite de tiempo.

¿Qué hace que un embudo sea un embudo?

Un embudo necesita tres cosas que un informe de eventos corriente no tiene: una lista ordenada de pasos, un punto de entrada definido y una ventana de conversión. El orden permite a la herramienta restar un paso del siguiente, la entrada fija el denominador entre el que dividen todos los porcentajes posteriores, y la ventana decide cuándo un usuario que no ha terminado cuenta como perdido en lugar de como todavía en curso. Un recuento de eventos de compra no tiene ninguna de esas tres cosas, y por eso puede subir en la misma semana en que el embudo empeora.

Ingrediente	Qué fija	Qué se rompe sin él
Lista ordenada de pasos	Qué evento va después de cuál	Los pasos no se pueden restar, así que no hay caída
Paso de entrada	El denominador de todos los pasos posteriores	Los porcentajes no tienen una base común
Ventana de conversión	Cuándo se cuenta como perdido a un usuario sin terminar	Los usuarios recientes tiran del número hacia abajo para siempre
Unidad de conteo	Si una fila es un usuario o una sesión	Los denominadores entre pasos dejan de ser comparables

Escribe esas cuatro reglas en el propio nombre del embudo. Un embudo llamado "Checkout, por usuario, orden estricto, 24h" sobrevive a un traspaso, y uno llamado "Checkout v2" no.

¿Cómo cambia las cifras la secuencia de pasos?

La secuencia decide si los eventos que llegan desordenados o con otros eventos por medio siguen contando como conversión, y cada ajuste produce un número distinto a partir de datos en bruto idénticos. La documentación de embudos de PostHog enumera tres modos: secuencial (sequential), donde "el paso B debe ocurrir después del paso A, pero puede ocurrir cualquier número de eventos entre A y B"; orden estricto (strict order), donde "el paso B debe ocurrir directamente después del paso A, sin ningún evento por medio"; y cualquier orden (any order), donde "los pasos se pueden completar en cualquier secuencia". La documentación de embudos avanzados de Mixpanel traza la misma línea con dos ajustes: "los embudos de orden específico exigen que el usuario complete cada uno de los pasos del embudo en el orden establecido", mientras que un interruptor de Any Order deja que los usuarios "completen los pasos no anclados del embudo en cualquier secuencia y aun así conviertan".

Toma una semana de eventos: 10,000 usuarios llegaron al paso 1. De ellos, 4,000 llegaron al paso 2 en algún momento posterior, y 2,600 de esos 4,000 llegaron sin ningún otro evento medido por medio. Otros 700 usuarios hicieron el paso 2 antes que el paso 1.

Regla de secuencia	Usuarios contados como conversión del paso 1 al paso 2	Conversión reportada
Orden estricto	2,600	26.00%
Secuencial, con huecos permitidos	4,000	40.00%
Cualquier orden	4,700	47.00%

Los mismos eventos, la misma semana, una horquilla de 21 puntos. La página de ayuda de exploración de embudos de GA4 de Google añade una cuarta palanca encima del orden, ya que un embudo abierto (open funnel) significa que "los usuarios pueden entrar en el embudo por cualquier paso", mientras que un embudo cerrado (closed funnel) significa que "los usuarios deben entrar en el embudo por el primer paso". Elige la regla que encaje con el producto y deja de cambiarla, porque un cambio de secuencia y un cambio real de conversión se ven idénticos en un gráfico de tendencia.

¿Qué hace la ventana de conversión?

La ventana de conversión es el tiempo que tiene un usuario para terminar el flujo después de entrar en él, y acortarla baja la conversión reportada sin tocar el producto. La documentación de embudos avanzados de Mixpanel indica que, por defecto, "todos los clientes tienen 7 días para completar un embudo desde la marca de tiempo en la que realizan el evento del paso 1", y que "el tiempo máximo que puedes elegir para la ventana de conversión es de 366 días, o su equivalente (12 meses, 52 semanas, etc.). Para ventanas de conversión basadas en sesiones, el máximo es de 12 sesiones".

Arrastra hacia adelante esos mismos 4,000 convertidores secuenciales. Si 2,900 de ellos terminaron en 1 hora y 3,600 en 24 horas, el embudo reporta tres resultados distintos a partir de un solo conjunto de datos:

Ventana de conversión	Convertidores	Conversión reportada
1 hora	2,900	29.00%
24 horas	3,600	36.00%
7 días	4,000	40.00%

Ajusta la ventana a la decisión que está tomando el usuario: un checkout que se termina de una sentada no necesita 7 días, y un plan de pago que un comprador lleva a su responsable sí. El mismo equilibrio gobierna una ventana de atribución, donde una ventana más larga acredita más conversiones y difumina la causa.

¿Debe un embudo contar usuarios o sesiones?

Los embudos con alcance de usuario cuentan a cada persona una sola vez, sin importar cuántas visitas abarque el flujo, y los embudos con alcance de sesión cuentan cada visita por separado, así que los dos reportan denominadores distintos para el mismo tráfico. La documentación de embudos avanzados de Mixpanel describe así el método Uniques: "los usuarios entrarán en el embudo la primera vez que registren el paso 1 dentro del periodo de tiempo seleccionado".

Supón que esos 10,000 usuarios produjeron 13,500 sesiones que contenían el paso 1, y que 3,100 de los 4,000 convertidores terminaron dentro de la sesión en la que empezaron. La conversión con alcance de sesión es 3,100 / 13,500, o sea 22.96%, frente al 40.00% con alcance de usuario. Elige alcance de sesión cuando el flujo está diseñado para terminarse de una sentada, y alcance de usuario cuando abarca varias visitas, y lee después qué es una sesión antes de dar por hecho que el límite de sesión de una herramienta coincide con el tuyo.

Una semana, seis configuraciones, seis cifras

Por sesión22,96%

Orden estricto26,00%

Ventana de 1 hora29,00%

Ventana de 24 horas36,00%

Orden secuencial40,00%

Orden libre47,00%

¿Cuándo es el análisis de embudos la herramienta equivocada?

El análisis de embudos es la herramienta equivocada siempre que el recorrido no tiene un orden fijo, porque todo lo que produce el método depende de un orden que los usuarios no están siguiendo. Un panel donde la gente usa cinco funciones en la secuencia que le pida la semana, y una compra B2B con cuatro personas entrando por cuatro canales, fallan la misma prueba: ninguna lista de pasos describe cómo se mueve la mayoría de los usuarios. Forzar un embudo sobre esos flujos dibuja la suposición del analista sobre el orden en lugar del producto.

Tres señales dicen que hay que parar. El ajuste de cualquier orden convierte a muchos más usuarios que el ajuste secuencial, lo que significa que la población no se mueve en el orden que se afirma. La mayoría de los entrantes aparece en el paso 3, lo que significa que el paso de entrada no es la entrada. El flujo no tiene un evento de finalización que un usuario pueda completar, lo que significa que no hay último paso entre el que dividir. Usa analítica de recorrido del cliente y análisis de cohortes para esos casos.

¿Cómo encaja el análisis de embudos junto a las demás preguntas sobre embudos?

El análisis de embudos es el método, y las páginas vecinas cubren lo que haces una vez el método está montado. Leer la forma resultante y localizar dónde se van los usuarios le corresponde al embudo de conversión, la aritmética de la pérdida por paso y de extremo a extremo le corresponde a la tasa de drop-off, construir y segmentar el informe en sí le corresponde al informe de embudo, y el lado de la adquisición le corresponde a la optimización del embudo de marketing.

¿Qué pasa después de que el análisis de embudos señale un paso malo?

Un embudo nombra el paso que pierde usuarios, y un replay de ese paso nombra la causa. Flowsery graba cada sesión de usuario y detecta rage clicks, dead clicks, errores de JavaScript, drop-offs y flujos rotos de forma automática, luego agrupa las sesiones coincidentes en un solo issue y ordena los issues por cuántos usuarios los sufren. Su análisis de embudos se ejecuta sobre el mismo flujo de eventos que las grabaciones, así que el paso y las sesiones que hay detrás salen de un único conjunto de datos en lugar de dos herramientas con dos definiciones.

Cada issue llega a Slack, Linear o Jira con el replay y los pasos de reproducción adjuntos, y mencionar a @flowsery en Slack abre un borrador de pull request en el repositorio de GitHub del equipo. Flowsery también se conecta a los replays de PostHog o Amplitude ya grabados, sin reinstrumentar nada.

Preguntas frecuentes

¿Qué es el análisis de embudos en términos sencillos?

El análisis de embudos cuenta cuánta gente llega a cada paso de un flujo que definiste de antemano, en el orden que definiste. El método necesita una lista ordenada de pasos, un primer paso que marca la entrada y un límite de tiempo para terminar. Todo lo que reporta un embudo sale de esas tres decisiones más los propios eventos.

¿Por qué dos herramientas reportan cifras distintas para el mismo embudo?

Las reglas de secuencia, las ventanas de conversión y las unidades de conteo difieren entre herramientas, y cada una cambia el denominador. Una semana de eventos del ejemplo anterior reporta 26.00% con orden estricto, 40.00% con orden secuencial y 47.00% con cualquier orden. Compara las dos definiciones campo por campo antes de decidir que una de las herramientas se equivoca.

¿Qué ventana de conversión debería usar un embudo?

Fija la ventana en el tiempo más largo que necesita un usuario que convierte para esa decisión concreta, y déjala quieta. El valor por defecto de Mixpanel es de 7 días desde el evento del paso 1, con un máximo de 366 días. Una ventana más corta reporta menos conversión para el mismo comportamiento, así que un cambio de ventana y un cambio de producto son indistinguibles en una línea de tendencia.

¿Cuál es la diferencia entre un embudo estricto y un embudo abierto?

El orden estricto controla qué puede ocurrir entre dos pasos, mientras que abierto frente a cerrado controla por dónde se le permite entrar a un usuario. El modo de orden estricto de PostHog exige el paso B directamente después del paso A, sin eventos por medio. El embudo abierto de GA4 de Google deja entrar a los usuarios por cualquier paso, y un embudo cerrado exige la entrada por el primer paso.

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

Usa un paso por cada cambio de estado significativo del flujo, no uno por clic. Añadir pasos reparte la misma pérdida entre más transiciones, lo que baja cada porcentaje por paso mientras deja intacta la conversión de extremo a extremo. Por eso no se pueden comparar cifras de extremo a extremo de embudos con distinto número de pasos.

¿Funciona el análisis de embudos en productos sin un orden fijo?

No. El método reporta una secuencia, así que un recorrido sin secuencia produce un gráfico del orden que asumió el analista en lugar del comportamiento del usuario. Cuando el ajuste de cualquier orden convierte a muchos más usuarios que el secuencial, o cuando la mayoría de los entrantes aparece en un paso intermedio, cambia a análisis de recorrido o de cohortes.

¿Cómo debería el nombre de un embudo describir su configuración?

El nombre de un embudo debería incluir la regla de entrada, el modo de secuencia, la ventana de conversión y la unidad de conteo, porque esas cuatro decisiones son las que determinan la cifra reportada. Un nombre como "Checkout, user-scoped, strict order, 24h" sobrevive a un traspaso de equipo, mientras que "Checkout v2" oculta cada configuración que produjo el resultado. Escribe esos ingredientes en el nombre en lugar de dejarlos en un panel de configuración que nadie revisa antes de comparar cifras entre semanas.

¿Cuál es la diferencia entre un embudo por usuario y un embudo por sesión?

Un embudo por usuario cuenta a cada persona una sola vez sin importar cuántas visitas abarque el flujo, mientras que un embudo por sesión cuenta cada visita como un intento propio. En una semana de datos, la misma conversión midió 40,00 % por usuario y 22,96 % por sesión, porque un embudo por sesión divide entre un número de sesiones mucho mayor que el conteo de usuarios únicos. Elige el alcance de sesión para un flujo pensado para completarse en una sola visita, y el alcance de usuario para uno que se extiende a varias visitas.

¿Cuándo debería sustituirse el análisis de embudos por análisis de journey o de cohortes?

Cambia de herramienta cuando la opción de orden libre convierte a muchos más usuarios que la opción secuencial, porque esa brecha significa que la población no sigue el orden que asume el embudo. La misma señal aparece cuando la mayoría de los entrantes llega en un paso intermedio en lugar del primer paso definido, o cuando el flujo no tiene un evento de finalización que sirva como último paso. Cualquiera de esas tres señales indica que el gráfico muestra el orden que supuso el analista y no el comportamiento real de los usuarios, y ahí el análisis de journey o de cohortes encaja mejor.

¿Qué pasa después de que un análisis de embudos señala un paso problemático?

La reproducción de sesiones de Flowsery registra cada sesión de usuario y detecta automáticamente rage clicks, dead clicks, errores de JavaScript, abandonos y flujos rotos, luego agrupa las sesiones coincidentes en un solo issue y clasifica los issues según cuántos usuarios lo sufren. Su análisis de embudos corre sobre el mismo flujo de eventos que las grabaciones, así que el paso que pierde usuarios y las sesiones detrás de él vienen de un solo conjunto de datos. Cada issue llega a Slack, Linear o Jira con la grabación y los pasos para reproducirlo, y mencionar a @flowsery en Slack abre un borrador de pull request en el repositorio de GitHub del equipo.