Cómo recuperar el 20-30% de ventas que GA4 no está viendo.
En un ecommerce de retail farmacéutico chileno, entre el 20% y el 30% de las ventas reales del backend nunca aparecían como eventos purchase en GA4. No era un problema de tráfico, ni de campañas mal configuradas: era un problema de arquitectura. El evento dependía de algo que la analítica nunca debería depender — de que el usuario volviera al navegador.
El problema: medir en el momento equivocado
El flujo típico de checkout con Webpay (Transbank) es así: el usuario completa su compra en el sitio, es redirigido a Webpay para pagar, y Webpay lo redirige de vuelta a una página de confirmación. El evento purchase se disparaba en esa página de confirmación, vía GTM, en el navegador del cliente.
El problema: si el usuario cierra la pestaña después de pagar, pierde la conexión, o su sesión expira antes de completar el redirect de vuelta, la venta ocurrió pero GA4 nunca se entera. El dinero llegó a la cuenta de la empresa. La analítica, el reporting de campañas y la atribución de Google Ads, no.
Por qué esto rompe Google Ads
Cuando una conversión real no se registra, el algoritmo de puja automática de Google Ads —Target ROAS, Maximize Conversions— optimiza con información incompleta. Cree que ciertas campañas rinden peor de lo que realmente rinden, y les retira presupuesto a favor de otras que, en los datos, parecen mejores. El resultado: el motor de optimización aprende de una realidad distorsionada y toma peores decisiones de inversión, de forma silenciosa.
La solución: medir desde donde la venta es un hecho, no una promesa
La solución fue mover la fuente de verdad del evento purchase del navegador al backend, usando el Measurement Protocol de GA4: una API que permite enviar eventos directamente desde un servidor, sin depender de que ningún usuario esté navegando en ese momento.
La arquitectura final usa dos canales, no uno:
- Measurement Protocol (backend) — se dispara cuando el sistema de pagos confirma la transacción, sin importar qué hizo el navegador del cliente. Es la fuente de verdad.
- dataLayer push (frontend) — se mantiene como respaldo para casos donde el usuario sí vuelve y se puede enriquecer el evento con contexto de sesión.
Los dos identificadores que hacen que esto funcione
Para que un evento enviado desde el backend "cuente" para la misma sesión de usuario que inició la compra —y no cree una sesión fantasma desconectada de la campaña que la originó— GA4 necesita dos identificadores:
client_id— identifica al dispositivo/navegador. Vive en la cookie_ga, que es first-party (del propio dominio del sitio), por lo que no la afecta el bloqueo de cookies de terceros de Safari o Chrome.ga_session_id— identifica la sesión específica dentro de ese dispositivo. Cambia con cada nueva sesión, incluso del mismo usuario.
El punto crítico: ambos deben capturarse antes del redirect a Webpay, no después. Si se capturan después del regreso, el navegador puede haber iniciado una sesión nueva —perdiendo los parámetros UTM originales— y la venta termina atribuida como (direct) en vez de a la campaña que realmente la generó.
El payload, en código
Una llamada simplificada al endpoint de Measurement Protocol desde el backend se ve así:
// POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=*** { "client_id": "1234567890.1234567890", "events": [{ "name": "purchase", "params": { "ga_session_id": "1785798403", "transaction_id": "OC-2026-88213", "currency": "CLP", "value": 34990, "shipping": 2990, "affiliation": "paymentId: Redcompra" } }] }
Antes de tocar producción, este mismo payload se valida contra el endpoint de debug de GA4 (/debug/mp/collect), que devuelve errores de validación de esquema sin generar una transacción real ni contaminar los datos del proyecto — la forma correcta de hacer QA de un evento server-side.
Cómo se validó
La validación se hizo en tres capas: pruebas de payload en Postman contra el endpoint de debug; compras reales con tarjetas de prueba de Transbank en ambiente QA, verificando en GA4 Tiempo Real que cada parámetro llegara correcto (transaction_id, paymentId, value, affiliation, ga_session_id); y finalmente, el mismo seguimiento en producción, confirmando cientos de eventos purchase llegando en tiempo real desde el primer día del deploy.
Conclusión
Un evento de conversión que depende de que el usuario complete una acción en el navegador —volver de una pasarela de pago, no cerrar la pestaña, no perder la sesión— no es una medición confiable, es una medición optimista. Cuando la venta ya es un hecho en el backend, la medición debería registrarse ahí, no esperar a que el frontend se entere. Esa es la diferencia entre reportar ventas y adivinarlas.