Si GA4, Shopify y tu pauta no cierran entre sí, el problema suele estar en cuatro puntos: compras duplicadas, revenue mal enviado, eventos del embudo que faltan y atribución rota.
Yo lo resumiría así: si no controlo esos frentes, termino leyendo mal el ROAS, el CAC, el ticket y hasta los ingresos del negocio. Y no hace falta una falla enorme para que eso pase: con una diferencia de 5% a 10% ya miro de cerca. Además, en tiendas Shopify se vio que el 88% tiene errores de configuración en analytics.
Lo primero que reviso es esto:
purchase más de una vez.value, currency o items mal enviados.add_to_cart o begin_checkout, el embudo queda roto.También hay una regla simple que me ahorra muchos problemas: una compra, un transaction_id, un solo trigger. Y para reportes comerciales, conviene que mande una sola fuente de verdad, casi siempre la plataforma de ecommerce, no GA4.
En pocas palabras, este artículo baja todo eso a tierra: qué revisar, cómo detectarlo y qué dejar documentado para que los números no se desordenen con el tiempo.
Checklist de Control de Analytics para Ecommerce
El doble conteo aparece cuando un mismo pedido entra más de una vez en analytics. La señal más clara es simple: GA4 muestra más compras que la plataforma porque el evento se disparó dos veces.
Y eso no pega solo en el conteo de pedidos. Si una compra se duplica, también se infla el ROAS y la lectura de rentabilidad queda torcida.
Las causas más comunes suelen verse así:
| Causa | Señal de detección | Acción correctiva |
|---|---|---|
| Integración nativa + tag personalizado en GTM | Analytics duplica las compras de la plataforma de forma constante | Dejar una sola fuente de disparo |
| Recarga o nueva visita a la página de confirmación | El mismo transaction_id aparece varias veces en logs, con minutos de diferencia | Usar una cookie o flag que impida volver a disparar el evento para ese mismo ID |
| IDs de transacción no únicos | Distintas órdenes comparten el mismo transaction_id | Alinear transaction_id con el order_id de la plataforma en todos los sistemas |
Con estas causas sobre la mesa, el paso siguiente es detectar el duplicado cuanto antes.
La forma más directa es comparar el conteo de compras en analytics contra el conteo de órdenes del sistema de pedidos, usando el mismo rango de fechas y la misma zona horaria: America/Argentina/Buenos_Aires. Si la diferencia se repite y además es marcada, hay una señal fuerte de doble conteo.
Dentro de analytics, conviene armar un análisis con Transaction ID como dimensión y Purchases como métrica. Después, filtrar por valores mayores a 1. Eso deja ver qué IDs se están contando más de una vez.
Para chequearlo en tiempo real, GA4 DebugView y el modo Preview de GTM ayudan mucho. Hacés un pedido de prueba y mirás si aparece un solo evento purchase o dos. Sin vueltas.
Si el conteo da bien pero el revenue no cierra, entonces el problema ya no está en la duplicación. Está en el payload.
Cuando analytics toma una compra sin revenue, o con valor nulo, casi siempre el problema está en cómo se envió el evento. Los fallos más comunes son estos: value ausente o enviado como texto en vez de número, currency omitido o con un código incorrecto, y el array items incompleto o vacío.
En Argentina, currency tiene que enviarse como "ARS" con formato ISO 4217. Y el campo value debe guardarse de forma interna como número con punto decimal, por ejemplo 1234.56. Después, en dashboards y reportes comerciales, ese mismo monto se muestra con formato local: $ 1.234,56.
Parece un detalle menor, pero no lo es. Si esos dos formatos se mezclan dentro del mismo sistema, aparecen errores de suma y totales que no cierran.
El camino más seguro tiene una lógica simple: primero inventariar, después consolidar y recién ahí validar.
transaction_id único y un event_id compartido si conviven navegador y servidor: el transaction_id debe ser siempre el order_id de la plataforma. No conviene usar el ID del carrito ni valores truncados. Si hay envío desde browser y server, el event_id compartido ayuda a que la plataforma descarte el duplicado.value, currency ("ARS") e items, con precio y cantidad por producto.purchase, que el transaction_id coincide con el order_id de la plataforma y que el value en ARS está bien enviado.Si compras y revenue ya cierran, toca revisar eventos faltantes y atribución. El próximo error suele ser más silencioso: eventos que no llegan y canales mal asignados.
Con compras y revenue bajo control, el próximo foco es el embudo y la atribución.
Cuando add_to_cart o begin_checkout no se disparan, el embudo muestra una caída brusca en el paso anterior al evento que falta. El equipo suele leer eso como un problema de UX o de copy, y termina metiendo mano en páginas que en verdad andan bien. Pero el problema está en otro lado: el tag nunca se ejecutó.
Los eventos clave son view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info y purchase. Si falta uno, el análisis de conversión queda cortado desde ese punto. Y si el nombre no coincide con el estándar, GA4 lo toma como evento personalizado y lo deja afuera de los reportes nativos de ecommerce.
Para detectar brechas, andá a Informes > Interacción > Eventos y compará los eventos activos contra el esquema completo del embudo. Si un paso muestra un abandono fuera de lo normal o ni siquiera aparece, casi siempre pasa una de estas dos cosas:
La forma más directa de validarlo es recorrer todo el flujo - producto, carrito, checkout y página de gracias - con GA4 DebugView abierto y chequear que cada evento aparezca en orden.
Si el embudo cierra, pero las campañas igual pierden crédito, entonces el problema está en la fuente.
Cuando el tráfico pago aparece como (direct)/(none), la atribución se rompe. En la práctica, eso hace que campañas que sí generan ventas queden sin crédito. Después viene el efecto en cadena: el equipo recorta presupuesto en canales que sí estaban funcionando. No es un detalle menor. Te desordena el ROAS, el CAC y toda la lectura por canal.
| Problema de atribución | Impacto en el negocio | Solución |
|---|---|---|
| Tráfico pago aparece como Direct (sin UTMs, auto-tagging desactivado o redirección que elimina query strings) | ROAS y CAC quedan distorsionados | Verificar UTMs en todas las URLs finales y activar auto-tagging en Google Ads |
| Autorreferencias de pasarelas de pago, como Mercado Pago | La conversión se le atribuye a la pasarela y no a la campaña original | Agregar el dominio de la pasarela en la lista de exclusiones de referencia |
| Cross-domain roto entre tienda y checkout | Infla usuarios nuevos y oculta el recorrido real de compra | Configurar la medición entre dominios con el mismo Measurement ID |
Ver dominios como checkout.shopify.com o mercadopago.com en el reporte de fuente/medio es una señal directa de que la configuración de exclusiones de referencia quedó incompleta.
La mayoría de estos problemas se arreglan en la configuración de analytics, no en las URLs de los anuncios.
Hay otro punto que suele pasarse por alto: los links internos nunca deben llevar UTMs. Si un carrusel de productos recomendados o un botón de navegación tiene UTMs, GA4 lo interpreta como una sesión nueva y pisa la atribución original. Los clics internos se miden con parámetros de evento, no con UTMs.
Con estos ajustes, la validación después de cada campaña lleva pocos minutos.
Antes de publicar, hacé una validación de 15 a 20 minutos.
Si el equipo usa canales conversacionales como campañas de marketing en WhatsApp o Instagram para cerrar ventas, la rutina también tiene que incluir una conversación de prueba que llegue hasta la compra. La idea es chequear que el punto de entrada quede registrado como corresponde y que esas ventas asistidas no terminen apareciendo como Direct en los reportes.
Cuando el embudo y la atribución ya están ordenados, aparece otro dolor de cabeza bastante común: GA4 dice una cosa, Shopify otra, y la pasarela de pago una tercera.
Y ojo: eso no siempre significa que haya un error. Muchas veces, cada sistema está usando cortes y reglas distintas. Entonces, cuando los números no cierran, el problema puede estar en cómo se está mirando el dato, no en la implementación. Esto no arregla el tracking; simplemente evita comparar métricas que no miden lo mismo.
La diferencia más común suele ser la zona horaria. Si tu tienda en Shopify está configurada en UTC-3 (hora de Buenos Aires) y GA4 usa otra zona horaria, una venta hecha a las 23:30 del martes puede figurar en Shopify como del martes, pero en GA4 como del miércoles. En un informe semanal, eso alcanza para mover órdenes de un día a otro sin que exista ningún fallo de tracking.
Después aparece otro punto clave: la definición de ingresos. Shopify descuenta devoluciones, cancelaciones y chargebacks en sus reportes de ventas. GA4, en cambio, mantiene el evento purchase original salvo que reciba un evento de reembolso con el mismo transaction_id. ¿Qué pasa entonces? GA4 suele mostrar ingresos brutos más altos que los ingresos netos que usa finanzas.
También están las órdenes canceladas o con pago pendiente. En el backend de la tienda pueden figurar como órdenes creadas, mientras que analytics solo toma compras exitosas. A eso se suman los filtros de bots y tráfico interno: analytics puede limpiar sesiones de prueba que igual aparecen en los logs crudos. Y, como si fuera poco, no todos los sistemas entienden igual qué es una conversión. Algunos cuentan una compra cerrada; otros, un checkout finalizado.
La reconciliación funciona cuando todos miran la misma ventana, la misma zona horaria y la misma definición.
| Métrica | Dónde suelen diferir los sistemas | Cómo estandarizarla |
|---|---|---|
| Órdenes | La plataforma incluye canceladas y pendientes; analytics solo cuenta compras exitosas | Usar solo órdenes pagas en todos los sistemas |
| Ingresos brutos | Incluye impuestos y envío; la pasarela puede reportar otra base | Valor de la orden con impuestos y envío |
| Ingresos netos | Finanzas aplica devoluciones; analytics no ajusta sin evento de reembolso | Valor de la orden con devoluciones aplicadas |
| Devoluciones | Registradas en la pasarela y el ERP, no siempre en analytics | Enviar eventos de reembolso a GA4 o reconciliar vía export del ERP |
| Ticket promedio | Se calcula sobre bases distintas | Ingresos netos / órdenes pagas |
El proceso, en la práctica, es simple: exportás los datos de la semana desde Shopify o Tiendanube, GA4 y la pasarela de pago usando exactamente la misma ventana en UTC-3. Después comparás órdenes, ingresos y ticket promedio.
Si GA4 muestra 950 órdenes y Shopify 1.000, el siguiente paso es mirar esas 50 que faltan. Tal vez sean tests internos. Tal vez sean órdenes fallidas. O tal vez haya flujos de WhatsApp que no están disparando el evento purchase. Ese tipo de chequeo semanal ayuda a ver el problema antes de que se vuelva un lío más grande.
Cuando hay conflicto entre sistemas, uno solo tiene que mandar. De eso se trata la reconciliación: no de forzar que todo dé igual, sino de dejar en claro qué sistema gobierna el reporte.
Para la mayoría de las marcas, la plataforma de ecommerce es la fuente de verdad para órdenes e ingresos comerciales. Tiene la vista más limpia de órdenes pagas, devoluciones aplicadas y montos en AR$. GA4 y las plataformas de ads sirven mucho mejor para análisis de comportamiento y atribución, no para el P&L.
Esto pesa más cuando hay canales conversacionales, como WhatsApp o Instagram, que también generan ventas. Si usás una plataforma como Burbuxa para recuperar carritos abandonados o cerrar ventas por WhatsApp, lo importante es que esas órdenes queden grabadas en la plataforma principal con IDs y estados consistentes. Así, los ingresos totales salen de un solo lugar y las métricas de Burbuxa quedan para medir el aporte de esos canales. De esa forma, las ventas asistidas entran en el sistema sin romper el reporte.
Una vez que definiste qué sistema manda, hace falta dejar por escrito cómo se nombra y cómo se calcula cada KPI.
El problema más silencioso no suele ser técnico. Muchas veces, finanzas, growth y operaciones usan la misma palabra - "ingresos" - para hablar de cosas distintas. La salida es un diccionario de métricas compartido, simple y mantenido.
Para cada KPI, ese documento tiene que decir con claridad:
Por ejemplo: "Ticket promedio = ingresos netos / órdenes pagas en GMT-3, excluyendo pedidos test." Si alguien del equipo de growth dice que el ticket promedio subió a AR$ 24.000, finanzas tiene que poder cruzar ese dato contra su propio reporte sin dudas ni dobles lecturas.
Con las métricas ya reconciliadas, el paso que sigue es bajar el margen de error en la integración.
Para cada evento comercial crítico, conviene usar una sola fuente de disparo. Si hay una integración nativa, usala como fuente única y apagá los tags duplicados. Menos capas, menos chances de que algo falle. Cada capa extra que dispara el mismo evento suma otra posibilidad de volver a inflar ingresos o duplicar órdenes.
Las integraciones nativas las mantiene la propia plataforma y suelen trabajar con un esquema de datos estándar. Eso ayuda a enviar bien los IDs de orden, los montos en AR$ y el tratamiento de reembolsos. En cambio, los tags personalizados en GTM dejan más margen para errores si se usan en eventos de compra. Por eso, conviene reservarlos para eventos no comerciales, como:
Tener una sola fuente por evento baja los duplicados. El próximo control es que los datos lleguen completos y a tiempo.
La sincronización en tiempo real permite revisar órdenes y descuentos con timestamps locales, sin tener que esperar exportaciones manuales. Si una campaña muestra un pico de conversiones, el equipo puede cruzar ese dato con el backend de la tienda en ese mismo momento, sin dejar la reconciliación para el cierre de semana.
Cuando esa sincronización funciona de forma estable, el foco pasa a otro punto: cómo ese flujo ordena el reporte comercial.
Burbuxa unifica órdenes, clientes, inventario y descuentos con IDs consistentes para que las ventas por WhatsApp e Instagram no dupliquen compras en analytics.
Después de corregir el doble conteo, los eventos faltantes, la atribución y las diferencias entre sistemas, aparece otro problema: la deriva.
Los errores de analytics no se arreglan una sola vez y listo. Hay que seguirlos de cerca. Cada cambio en el checkout, en los medios de pago o en las campañas puede romper el tracking sin dar señales claras. Ahí es donde cambia todo: no por la herramienta, sino por la rutina de control. Quién revisa, qué revisa y cuándo lo hace.
Tener un solo esquema de eventos, junto con validaciones automáticas, baja las discrepancias y ayuda a detectar fallas antes de que se vuelvan un dolor de cabeza.
La gobernanza también pide algo muy concreto: un responsable, un esquema de eventos bien documentado y QA antes de confiar en cualquier cambio. Y sí, eso incluye validar compras, revenue y atribución después de cada modificación.
Si no querés que los errores vuelvan, dejá al menos este control base para cada cambio.
| Control | Qué verificar | Frecuencia |
|---|---|---|
transaction_id único | Un solo ID por orden, sin duplicados entre browser y servidor | Tras cada cambio de checkout |
Un único trigger de purchase | El evento se dispara solo después del pago confirmado | Tras cada cambio de gateway |
| Moneda consistente en ARS | Todos los eventos de compra con currency: ARS y valor final correcto | Revisión mensual |
| Exclusiones de referencia | Pasarelas de pago y dominios propios validados antes de excluirlos | Tras cambios y auditorías programadas |
| Reglas UTM documentadas | Convención de nombres en minúsculas, sin espacios, compartida con agencias | Por cada lanzamiento de campaña |
| Tracking de reembolsos | Devoluciones registradas como eventos negativos o ajustes explícitos | Revisión mensual |
| Reconciliación de métricas | Comparar órdenes y revenue en ARS entre el backend y analytics | Semanal |
Asignale un dueño y una fecha a cada control.
Es normal que haya una pequeña diferencia entre GA4 y Shopify, porque usan métodos de medición distintos. No hay un número fijo para todos los casos: la discrepancia cambia según la configuración del seguimiento, los bloqueadores de anuncios, la latencia de red y la zona horaria.
Lo que importa no es que los datos cierren perfecto, sino mantener consistencia. Si la brecha es grande, revisá los UTM, los eventos que faltan y la integración del seguimiento de conversiones.
Usá DebugView para simular una compra completa y revisar que el evento se registre una sola vez, sin errores de tipeo ni parámetros inconsistentes.
Además, compará tus ventas reales con los reportes de GA4 por fuente y medio. Si encontrás diferencias grandes o números inflados, lo más probable es que haya un problema en los webhooks o en el tracking de conversiones.
La fuente de verdad tiene que ser un sistema centralizado, como un ERP o un CRM, preparado para sincronizarse en tiempo real con ventas, logística y marketing. De esa forma, toda la organización trabaja sobre los mismos datos de inventario, clientes y pedidos.
En marcas de e-commerce, Burbuxa puede ocupar ese lugar al centralizar ventas, soporte, campañas y reseñas, y ayudar a bajar problemas como el doble conteo o la atribución fragmentada.