sesiones con al menos una vista de producto.
CASO 06 / PRODUCT ANALYTICS
¿Dónde se interrumpe la compra?
Reconstruí el recorrido desde la vista de un producto hasta la compra. El embudo muestra qué sesiones avanzaron de etapa, cómo se definió cada métrica y qué controles limitan la interpretación.
Google Merchandise Store · Muestra pública y ofuscada de GA4 · Noviembre 2020 a enero 2021
RECORRIDO DE COMPRA01 → 04
Vista de producto77.020
Carrito14.380
Checkout5.187
Compra2.778
SESIONES CON ETAPAS EN ORDEN3,61% vista → compra
de esas sesiones registró luego un agregado al carrito.
registró las cuatro etapas en orden dentro de la misma sesión.
01 / EMBUDO
Del interés a la compra.
Seleccioná una etapa para ver qué representa. Los valores son sesiones, no eventos ni transacciones únicas.
Ancho de barra: proporción respecto de las 77.020 sesiones que vieron un producto.
02 / DECISIÓN
Empezaría por el paso de producto a carrito.
Tomé las 77.020 sesiones con una vista de producto como punto de partida. Solo 14.380 registraron después un agregado al carrito: 18,67%. Entre quienes sí llegaron al carrito, 36,07% inició checkout; entre esos últimos, 53,56% registró una compra. Comparé cada etapa con la anterior, no con el total inicial, para localizar el tramo con menor avance.
Por eso investigaría primero las 62.640 sesiones que no muestran un add_to_cart posterior bajo esta definición. Antes de cambiar la ficha de producto, comprobaría que el evento se mida igual en todos los dispositivos y separaría el embudo por producto, categoría y origen de tráfico. Después revisaría precio, stock y condiciones de envío en los grupos donde la diferencia persista.
Ese recuento no equivale a 62.640 personas que abandonaron: una sesión puede continuar por otra ruta, registrar eventos con la misma marca temporal o quedar afectada por la ofuscación de la muestra. La comparación señala dónde mirar; no identifica la causa.
03 / CONTROL DE CALIDAD
Primero, confiar en la medición.
Los controles se ejecutaron sobre los cuatro tipos de evento usados en el análisis.
view_item, add_to_cart, begin_checkout y purchase.
En esta muestra, todos los eventos revisados tienen usuario y sesión identificables.
Eventos purchase sin transaction_id informado.
Eventos purchase adicionales que comparten un transaction_id con otro evento.
Hay 5.692 eventos purchase y 4.452 IDs distintos no vacíos. Como Google ofuscó la muestra, los IDs repetidos pueden reflejar limitaciones del dataset. No se interpretan como ventas duplicadas del negocio.
04 / MÉTODO Y FUENTES
Así construí el embudo.
Dejé en el SQL la unidad, el orden de eventos y los denominadores para que se pueda repetir el cálculo.
Identifiqué sesiones
Extraje ga_session_id de event_params y lo combiné con user_pseudo_id. Filtré los cuatro eventos de interés entre noviembre de 2020 y enero de 2021.
Exigí la secuencia
Para cada sesión tomé el primer view_item; luego busqué el primer add_to_cart con marca temporal mayor. Repetí el criterio para checkout y compra. Así no inflo el embudo con eventos repetidos o fuera de orden.
Calculé cada avance
Dividí 14.380 por 77.020, 5.187 por 14.380 y 2.778 por 5.187. El 3,61% final usa otra base: 2.778 sesiones con las cuatro etapas sobre 77.020 sesiones con vista.
Revisé la lectura
Contrasté claves de sesión y transaction_id. Encontré 23 eventos purchase sin ID y 1.217 eventos adicionales con ID repetido; por eso informo sesiones con secuencia completa, no ventas únicas.
SQL EN LA PRÁCTICA
De eventos sueltos a sesiones que avanzan.
La consulta en BigQuery primero extrae ga_session_id de event_params y lo une con user_pseudo_id. Esa clave define la unidad de análisis: una sesión, no cada evento.
Cómo evité contar pasos fuera de orden
En cada sesión elegí la primera vista de producto con MIN(event_timestamp). El siguiente CTE solo acepta un carrito posterior a esa vista. Repetí la condición para checkout y compra; cada paso conserva una fila por sesión.
Luego conté las sesiones de cada CTE y calculé el avance contra la etapa anterior con SAFE_DIVIDE y LAG. Una consulta aparte revisó claves de sesión e IDs de compra antes de interpretar el resultado.
WITH viewed AS (
SELECT session_key, MIN(event_timestamp) AS view_ts
FROM identified_events
WHERE event_name = 'view_item'
GROUP BY session_key
),
carted AS (
SELECT v.session_key, MIN(e.event_timestamp) AS cart_ts
FROM viewed AS v
JOIN identified_events AS e USING (session_key)
WHERE e.event_name = 'add_to_cart'
AND e.event_timestamp > v.view_ts
GROUP BY v.session_key
)Fuente original
Dataset público de GA4 para Google Merchandise Store. Datos ofuscados del 01/11/2020 al 31/01/2021. Consulta y controles ejecutados el 12/10/2026. Las marcas temporales iguales no cumplen el orden estricto del SQL.
HABLEMOS
¿Tu equipo necesita convertir eventos en decisiones?
Puedo definir métricas, revisar calidad de datos y construir una vista que haga visible dónde investigar.