Embudos de conversión: dónde se pierde la gente

Ya sabes seguir una métrica a lo largo del tiempo: cada mes contra el mes anterior, cada mes contra el mismo mes del año pasado. Ahora vas a seguir a los usuarios a lo largo de un PROCESO. La pregunta ya no es «cómo va este mes comparado con el anterior» sino «cuántos pasan del paso 1 al paso 2, del 2 al 3, y dónde se caen». Eso es un embudo de conversión. El tráfico entra por arriba, cada paso pierde gente, y tu trabajo es señalar el escalón exacto donde la caída es más grande — porque ahí es donde un cambio pequeño mueve más el resultado final.

Este es el problema clásico que resuelve un embudo de conversión (funnel en el mercado laboral): una secuencia de pasos donde los usuarios entran por arriba y van abandonando en cada etapa hasta que solo un porcentaje llega al final. Tu trabajo como analista es construir ese embudo, medirlo, y señalar con el dedo el paso exacto donde se pierde más gente — porque ahí es donde merece la pena invertir esfuerzo.

### La analogía: la cola del supermercado

Imagina un supermercado un sábado por la mañana. Entran 1.000 personas por la puerta. De esas, 700 cogen un carrito. De las 700, 400 llegan a la caja con productos dentro. De las 400, 350 no se van al ver la cola. De las 350, 320 terminan pagando. Cada paso pierde gente: unos entraron a mirar, otros se arrepintieron al ver el precio, otros se cansaron de esperar. Si tú fueras el gerente y solo pudieras arreglar UNA cosa, querrías saber DÓNDE se pierde más gente. Si el salto grande está entre coger carrito y llegar a la caja, quizá el supermercado es un laberinto. Si está entre la caja y pagar, quizá hacen falta más cajeros.

Un embudo digital funciona exactamente igual. Los pasos cambian — en un e-commerce son visita, ficha de producto, añadir al carrito, iniciar checkout, pago completado — pero la lógica es la misma: contar cuánta gente llega a cada paso y calcular qué porcentaje se pierde en cada transición.

### De dónde viene el concepto de embudo

El embudo no es un invento del mundo digital. En 1898, un publicitario americano llamado Elias St. Elmo Lewis describió el modelo AIDA: Atención, Interés, Deseo, Acción. Era un embudo de ventas pensado para vendedores puerta a puerta: de toda la gente que te escucha, solo un porcentaje se interesa; de esos, solo un porcentaje desea el producto; y de esos, solo un porcentaje compra. El concepto tiene más de cien años.

Lo que cambió con internet es que ahora podemos MEDIR cada paso automáticamente. Antes de la web, sabías cuánta gente entraba en la tienda (más o menos) y cuánta pagaba, pero no sabías cuántas miraron un producto y lo dejaron en la estantería. Con los eventos digitales — cada clic, cada página vista, cada botón pulsado — puedes construir el embudo con precisión y actualizarlo cada hora si quieres. Esa es la ventaja del analista moderno: no tiene que adivinar dónde se pierde la gente, puede medirlo.

### Paso 0: Definir los pasos antes de escribir SQL

Antes de abrir el editor, necesitas tres decisiones que no son técnicas sino de negocio:

1. 01.Cuáles son los pasos del embudo. No los decides tú: los decide el flujo real del producto. Si el usuario puede comprar sin pasar por el carrito (botón de "comprar ahora"), el carrito no es un paso obligatorio y contarlo como tal infla artificialmente la caída en checkout.
2. 02.Qué cuenta como "llegar" a un paso. Un usuario que carga la página de checkout pero se va en 2 segundos, ¿llegó? Normalmente sí: el evento se registró, y eso es lo que medimos. Pero hay embudos donde el criterio es más exigente (por ejemplo, rellenar al menos un campo del formulario).
3. 03.La ventana temporal. Un embudo de una semana no es lo mismo que uno de un mes. Si el ciclo de compra es largo (un seguro, un coche), la ventana debe ser mayor. Para un e-commerce de ropa, una semana suele ser suficiente.

### La tabla de eventos: la materia prima

Todo embudo se construye a partir de una tabla de eventos. Cada fila es algo que un usuario hizo: visitó la home, vio un producto, añadió al carrito, inició el pago, completó la compra. La tabla mínima tiene tres columnas: quién (user_id), qué hizo (event_name) y cuándo (event_timestamp). Con esas tres columnas puedes construir cualquier embudo.

1-- Estructura tipica de una tabla de eventos
2-- user_id       | event_name      | event_timestamp
3-- u_001         | page_view_home  | 2024-03-01 09:12:33
4-- u_001         | view_product    | 2024-03-01 09:13:45
5-- u_001         | add_to_cart     | 2024-03-01 09:15:02
6-- u_001         | begin_checkout  | 2024-03-01 09:16:11
7-- u_001         | purchase        | 2024-03-01 09:18:44
8-- u_002         | page_view_home  | 2024-03-01 09:20:01
9-- u_002         | view_product    | 2024-03-01 09:21:30
10-- u_002         | add_to_cart     | 2024-03-01 09:23:15
11-- u_002         | begin_checkout  | 2024-03-01 09:24:00
12-- (u_002 abandona aqui, no llega a purchase)

### El embudo básico: contar usuarios únicos por paso

La query más sencilla de embudo cuenta cuántos usuarios distintos llegaron a cada paso. No exige orden temporal: basta con que el evento exista. Este es el embudo "relajado", el punto de partida.

1-- Embudo relajado: basta con que el usuario tenga el evento
2SELECT
3    'home'        AS paso,  1 AS orden,
4    COUNT(DISTINCT user_id) AS usuarios
5FROM eventos WHERE event_name = 'page_view_home'
6
7UNION ALL
8
9SELECT
10    'producto'    AS paso,  2 AS orden,
11    COUNT(DISTINCT user_id)
12FROM eventos WHERE event_name = 'view_product'
13
14UNION ALL
15
16SELECT
17    'carrito'     AS paso,  3 AS orden,
18    COUNT(DISTINCT user_id)
19FROM eventos WHERE event_name = 'add_to_cart'
20
21UNION ALL
22
23SELECT
24    'checkout'    AS paso,  4 AS orden,
25    COUNT(DISTINCT user_id)
26FROM eventos WHERE event_name = 'begin_checkout'
27
28UNION ALL
29
30SELECT
31    'compra'      AS paso,  5 AS orden,
32    COUNT(DISTINCT user_id)
33FROM eventos WHERE event_name = 'purchase'
34
35ORDER BY orden;

### Tasas de conversión: paso a paso y acumulada

El número de usuarios por paso es útil, pero lo que el stakeholder necesita son tasas. Hay dos formas de leer un embudo:

• ▹Tasa paso a paso (step conversion rate): qué porcentaje de los que llegaron al paso N llega al paso N+1. Responde "de los que añadieron al carrito, cuántos inician checkout". Es la que señala el cuello de botella.
• ▹Tasa acumulada (overall conversion rate): qué porcentaje del total inicial llega a cada paso. Responde "de todas las visitas, cuántas terminan en compra". Es la que resume la salud general del embudo.

1-- Embudo con tasas de conversion
2WITH embudo AS (
3    SELECT 'home' AS paso, 1 AS orden,
4        COUNT(DISTINCT user_id) AS usuarios
5    FROM eventos WHERE event_name = 'page_view_home'
6    UNION ALL
7    SELECT 'producto', 2, COUNT(DISTINCT user_id)
8    FROM eventos WHERE event_name = 'view_product'
9    UNION ALL
10    SELECT 'carrito', 3, COUNT(DISTINCT user_id)
11    FROM eventos WHERE event_name = 'add_to_cart'
12    UNION ALL
13    SELECT 'checkout', 4, COUNT(DISTINCT user_id)
14    FROM eventos WHERE event_name = 'begin_checkout'
15    UNION ALL
16    SELECT 'compra', 5, COUNT(DISTINCT user_id)
17    FROM eventos WHERE event_name = 'purchase'
18)
19SELECT
20    paso,
21    usuarios,
22    LAG(usuarios) OVER (ORDER BY orden) AS usuarios_paso_anterior,
23    ROUND(100.0 * usuarios / LAG(usuarios) OVER (ORDER BY orden), 1)
24        AS pct_paso_a_paso,
25    ROUND(100.0 * usuarios / FIRST_VALUE(usuarios) OVER (ORDER BY orden), 1)
26        AS pct_acumulado
27FROM embudo
28ORDER BY orden;

### Localizar el cuello de botella: dónde duele más

El valor real del embudo no está en calcularlo — está en interpretarlo. La tasa paso a paso te dice dónde se rompe el flujo. Si entre "producto" y "carrito" se pierde el 50% de la gente, eso es un problema de persuasión (el producto no convence, el precio asusta, falta información). Si entre "checkout" y "compra" se pierde el 33%, eso es un problema de fricción (formulario largo, métodos de pago limitados, costes de envío sorpresa).

La query que calcula la caída (drop-off) absoluta y relativa por paso:

1-- Drop-off por paso: quien se pierde y donde
2WITH embudo AS (
3    SELECT 'home' AS paso, 1 AS orden,
4        COUNT(DISTINCT user_id) AS usuarios
5    FROM eventos WHERE event_name = 'page_view_home'
6    UNION ALL
7    SELECT 'producto', 2, COUNT(DISTINCT user_id)
8    FROM eventos WHERE event_name = 'view_product'
9    UNION ALL
10    SELECT 'carrito', 3, COUNT(DISTINCT user_id)
11    FROM eventos WHERE event_name = 'add_to_cart'
12    UNION ALL
13    SELECT 'checkout', 4, COUNT(DISTINCT user_id)
14    FROM eventos WHERE event_name = 'begin_checkout'
15    UNION ALL
16    SELECT 'compra', 5, COUNT(DISTINCT user_id)
17    FROM eventos WHERE event_name = 'purchase'
18)
19SELECT
20    paso,
21    usuarios,
22    usuarios - LAG(usuarios) OVER (ORDER BY orden) AS drop_off_absoluto,
23    ROUND(100.0 * (LAG(usuarios) OVER (ORDER BY orden) - usuarios)
24        / LAG(usuarios) OVER (ORDER BY orden), 1) AS pct_drop_off
25FROM embudo
26ORDER BY orden;

### Embudo estricto vs embudo relajado

Hasta ahora hemos construido un embudo relajado: basta con que el usuario tenga el evento, sin importar si pasó por los anteriores ni en qué orden. Pero hay situaciones donde eso no es suficiente.

El embudo estricto exige que el usuario haya pasado por TODOS los pasos anteriores Y en el orden correcto. Es decir: para contar a alguien en "carrito", debe haber tenido primero "home", luego "producto", y después "carrito", en ese orden temporal. Si un usuario fue directo al carrito desde un email, no cuenta.

Cuándo usar cada uno:

• ▹Embudo relajado: cuando quieres una foto general de cuántos llegan a cada paso, sin importar el camino. Más simple, más inclusivo, bueno para un primer vistazo.
• ▹Embudo estricto: cuando el flujo del producto es lineal por diseño (un formulario de registro de 4 pasos donde no puedes saltarte ninguno) o cuando quieres medir la experiencia "ideal" del usuario que sigue el camino previsto.
• ▹En la práctica, el embudo relajado es el más común para e-commerce (la gente llega por mil caminos distintos) y el estricto para flujos de onboarding o formularios secuenciales.

### Construir el embudo estricto con window functions

El embudo estricto necesita verificar que cada usuario pasó por los pasos anteriores en orden temporal. La técnica: usar window functions para numerar los eventos de cada usuario y después comprobar la secuencia.

1-- Embudo estricto: exige que los pasos ocurran en orden
2WITH pasos_definidos AS (
3    SELECT unnest(['page_view_home','view_product','add_to_cart',
4                   'begin_checkout','purchase']) AS event_name,
5           unnest([1,2,3,4,5]) AS paso_orden
6),
7eventos_con_paso AS (
8    SELECT
9        e.user_id,
10        e.event_name,
11        e.event_timestamp,
12        p.paso_orden
13    FROM eventos e
14    JOIN pasos_definidos p ON p.event_name = e.event_name
15),
16primer_evento_por_paso AS (
17    -- Para cada usuario y paso, el timestamp mas temprano
18    SELECT
19        user_id,
20        paso_orden,
21        MIN(event_timestamp) AS ts_paso
22    FROM eventos_con_paso
23    GROUP BY user_id, paso_orden
24),
25secuencia_valida AS (
26    -- Un paso es valido si su timestamp es POSTERIOR al del paso anterior
27    SELECT
28        user_id,
29        paso_orden,
30        ts_paso,
31        LAG(ts_paso) OVER (PARTITION BY user_id ORDER BY paso_orden) AS ts_anterior,
32        LAG(paso_orden) OVER (PARTITION BY user_id ORDER BY paso_orden) AS paso_anterior
33    FROM primer_evento_por_paso
34),
35usuarios_validos AS (
36    -- Un usuario llega al paso N si:
37    -- 1. Tiene todos los pasos del 1 al N
38    -- 2. Cada paso ocurrio despues del anterior
39    SELECT user_id, MAX(paso_orden) AS max_paso_alcanzado
40    FROM secuencia_valida
41    WHERE paso_orden = 1  -- el primer paso siempre es valido
42       OR (paso_anterior = paso_orden - 1 AND ts_paso > ts_anterior)
43    GROUP BY user_id
44)
45-- Contar usuarios que alcanzaron cada paso
46SELECT
47    paso_orden,
48    COUNT(*) AS usuarios
49FROM usuarios_validos, LATERAL unnest(generate_series(1, max_paso_alcanzado)) AS t(paso_orden)
50GROUP BY paso_orden
51ORDER BY paso_orden;

### Segmentar el embudo: el mismo embudo, otra historia

Un embudo global te dice el QUÉ. Pero para saber el POR QUÉ, necesitas segmentar: partir el embudo por una dimensión y ver si el problema es universal o está concentrado en un grupo. Los segmentos más comunes:

• ▹Por canal de adquisición (orgánico, paid social, email, directo): descubre si el tráfico de pago convierte peor que el orgánico — o al revés.
• ▹Por dispositivo (móvil, escritorio, tablet): un checkout que funciona en escritorio pero no en móvil puede explicar toda la caída.
• ▹Por cohorte temporal (semana de primera visita): detecta si un cambio reciente rompió algo.
• ▹Por segmento de cliente (nuevo vs recurrente): los recurrentes suelen saltar pasos porque ya conocen el producto.

La query es la misma del embudo relajado, pero con un GROUP BY adicional:

1-- Embudo segmentado por canal
2WITH embudo_canal AS (
3    SELECT
4        channel,
5        'home' AS paso, 1 AS orden,
6        COUNT(DISTINCT user_id) AS usuarios
7    FROM eventos WHERE event_name = 'page_view_home'
8    GROUP BY channel
9    UNION ALL
10    SELECT channel, 'producto', 2, COUNT(DISTINCT user_id)
11    FROM eventos WHERE event_name = 'view_product'
12    GROUP BY channel
13    UNION ALL
14    SELECT channel, 'carrito', 3, COUNT(DISTINCT user_id)
15    FROM eventos WHERE event_name = 'add_to_cart'
16    GROUP BY channel
17    UNION ALL
18    SELECT channel, 'checkout', 4, COUNT(DISTINCT user_id)
19    FROM eventos WHERE event_name = 'begin_checkout'
20    GROUP BY channel
21    UNION ALL
22    SELECT channel, 'compra', 5, COUNT(DISTINCT user_id)
23    FROM eventos WHERE event_name = 'purchase'
24    GROUP BY channel
25)
26SELECT
27    channel,
28    paso,
29    usuarios,
30    ROUND(100.0 * usuarios / FIRST_VALUE(usuarios)
31        OVER (PARTITION BY channel ORDER BY orden), 1) AS pct_acumulado
32FROM embudo_canal
33ORDER BY channel, orden;

### Añadir la ventana temporal

En la vida real, un embudo sin ventana temporal puede engañar. Si cuentas todos los eventos del mes, un usuario que visitó la home el día 1 y compró el día 28 cuenta como conversión. Pero puede que esa "conversión" sea un usuario que volvió por otro canal tres semanas después — no una sesión continua. Para embudos de e-commerce, una ventana de 7 días o incluso de sesión (30 minutos de inactividad) es más representativa.

1-- Embudo con ventana de 7 dias desde la primera visita del usuario
2WITH primera_visita AS (
3    SELECT
4        user_id,
5        MIN(event_timestamp) AS ts_entrada
6    FROM eventos
7    WHERE event_name = 'page_view_home'
8    GROUP BY user_id
9),
10eventos_en_ventana AS (
11    SELECT e.*
12    FROM eventos e
13    JOIN primera_visita pv ON pv.user_id = e.user_id
14    WHERE e.event_timestamp >= pv.ts_entrada
15      AND e.event_timestamp < pv.ts_entrada + INTERVAL '7 days'
16)
17-- Ahora el embudo se calcula solo con eventos dentro de la ventana
18SELECT 'home' AS paso, 1 AS orden,
19    COUNT(DISTINCT user_id) AS usuarios
20FROM eventos_en_ventana WHERE event_name = 'page_view_home'
21UNION ALL
22SELECT 'producto', 2, COUNT(DISTINCT user_id)
23FROM eventos_en_ventana WHERE event_name = 'view_product'
24UNION ALL
25SELECT 'carrito', 3, COUNT(DISTINCT user_id)
26FROM eventos_en_ventana WHERE event_name = 'add_to_cart'
27UNION ALL
28SELECT 'checkout', 4, COUNT(DISTINCT user_id)
29FROM eventos_en_ventana WHERE event_name = 'begin_checkout'
30UNION ALL
31SELECT 'compra', 5, COUNT(DISTINCT user_id)
32FROM eventos_en_ventana WHERE event_name = 'purchase'
33ORDER BY orden;

### Patrones de diagnóstico: qué te dice la forma del embudo

Con experiencia aprendes a leer la "forma" del embudo como un médico lee una radiografía. Hay cuatro patrones clásicos:

1. 01.Cuello de botella arriba (gran caída entre paso 1 y 2): problema de relevancia. El tráfico que llega no encuentra lo que busca. Causas típicas: landing page genérica, segmentación de anuncios demasiado amplia, promesa del anuncio que no se cumple en la página.
2. 02.Cuello de botella en medio (gran caída en carrito o checkout): problema de fricción o confianza. El usuario quiere comprar pero algo le frena. Causas típicas: costes de envío sorpresa, formulario demasiado largo, falta de métodos de pago, "tengo que crear una cuenta".
3. 03.Embudo uniforme (la caída es parecida en todos los pasos): no hay un problema puntual sino una falta general de motivación. El producto no convence lo suficiente en ninguna etapa. Es el patrón más difícil de arreglar.
4. 04.Caída final (todo va bien hasta el último paso): problema técnico. Un botón que no funciona en móvil, un error al procesar el pago, una pasarela que se cae. Aquí el analista mira los logs antes que los datos.

### Errores que hacen que tu embudo mienta

Un embudo mal construido es peor que no tener embudo — porque te da confianza falsa. Estos son los errores que he visto en equipos reales:

1. 01.Contar eventos en lugar de usuarios. Si cuentas filas en vez de COUNT(DISTINCT user_id), un usuario que recarga la página 5 veces infla el paso. El embudo mide PERSONAS que avanzan, no clics.
2. 02.No definir la ventana temporal. Un embudo "del mes" cuenta como conversión a alguien que visitó el día 1 y compró el día 30 por un email de retargeting. Eso no es una conversión del flujo — es una conversión de marketing.
3. 03.Incluir bots y tráfico interno. Si el equipo de QA prueba el checkout 200 veces al día, ese paso aparece artificialmente inflado. Filtra IPs internas y user agents de bots.
4. 04.Mezclar embudos diferentes. Un e-commerce con app y web tiene dos embudos distintos: los pasos pueden ser diferentes y las tasas no son comparables. Mezclarlos da una media que no representa a nadie.
5. 05.No filtrar por periodo completo. Si comparas "esta semana" (que lleva 3 días) con "la semana pasada" (7 días completos), el embudo de esta semana parecerá peor solo por tener menos tiempo para convertir.

### Resumen de técnicas SQL usadas

• ▹COUNT(DISTINCT user_id): la base de todo embudo. Contamos personas, no eventos.
• ▹UNION ALL: apilar los pasos del embudo en una sola tabla consultable.
• ▹LAG() OVER (ORDER BY orden): comparar cada paso con el anterior para calcular la tasa paso a paso y el drop-off.
• ▹FIRST_VALUE() OVER (ORDER BY orden): el total del primer paso para la tasa acumulada.
• ▹PARTITION BY channel (o device, o cohorte): segmentar el embudo calculando cada corte de forma independiente.
• ▹CTE + ventana temporal: filtrar eventos dentro de un período desde la primera visita.
• ▹LAG para embudo estricto: verificar que el timestamp de cada paso es posterior al del paso anterior.