Los eventos purchase duplicados inflan ingresos y reducen la confianza en la conversión. Las causas habituales son dos integraciones, una etiqueta activada por page view y data layer, recargas de thank-you o medición de navegador y servidor sin coordinar.
No borres pedidos reales para corregir Analytics. Repara la recopilación, anota el periodo y usa tienda y pasarela como fuentes financieras.
Demuestra la duplicación
Usa una compra controlada y revisa DebugView, Tag Assistant y Network. Registra transaction_id, horas, valores y origen.
- dos requests en una carga
- uno en cada recarga
- navegador más servidor
- dos IDs distintos para una orden
- duplicación solo en informesNo envíes email, dirección o pago como parámetros.
Inventaría todas las fuentes
Lista plugins de analítica, snippets del tema, Google tag, contenedores Tag Manager, consentimiento y endpoints server-side.
Revisa scripts e IDs de medición duplicados. Una integración puede cargar Google tag directamente y otra mediante GTM. Elige un único propietario de purchase; otros sistemas pueden consumir un data layer compartido sin inventar otra transacción.
Inspecciona triggers de GTM
La etiqueta puede disparar con el evento purchase y también por URL /order-received/. Usa Preview y anota qué trigger activa cada tag.
Prefiere un evento ecommerce con campos obligatorios, no la URL. La confirmación puede recargarse, guardarse o abrirse sin un pago nuevo. Limita el trigger duplicado y publica una versión documentada.
Revisa también si el contenedor publicado coincide con Preview. Espacios sin publicar, entornos GTM y scripts cacheados pueden hacer que la prueba vea una regla y el cliente otra. Anota ID de contenedor, versión y hostname en cada request.
Prueba la recarga
Recarga la confirmación controlada. Si aparece otro request, falta protección de cliente.
GA4 puede deduplicar IDs iguales durante ciertos procesos, pero la colección debe enviar un evento intencionado. Los flags locales pueden fallar con caché u otro navegador. No uses la clave secreta del pedido como identificador.
Coordina navegador y servidor
La medición server-side mejora la cobertura cuando el cliente no vuelve de la pasarela. Si sigue activa la del navegador, ambas necesitan el mismo ID y una estrategia explícita.
Registra el origen en logs seguros y decide qué ruta manda según consentimiento. No generes un ID aleatorio en cada reintento: impediría deduplicar.
Prueba dos llamadas simultáneas con el mismo ID y otra minutos después. La protección debe ser atómica y persistir durante los reintentos. Una marca en memoria no sirve si la segunda petición llega a otro worker o servidor.
Revisa cambios de consentimiento
Al aceptar, una plataforma puede soltar etiquetas en cola después de que la compra ya se enviara o inicializar medición junto con GTM.
Prueba Aceptar, Rechazar e indeciso en perfiles nuevos. Tras rechazo, analytics opcional debe permanecer apagado; aceptar después no debería reproducir compras históricas sin diseño aprobado. Checkout debe funcionar aunque falle analytics.
Aplica la corrección mínima
Desactiva una fuente o trigger duplicado sin rehacer todo el data layer. Conserva view_item y add_to_cart si ya tienen dueño correcto.
Documenta versión, ID controlado y número de requests antes/después. Limpia assets pertinentes y verifica el contenedor publicado. Identifica transacciones de prueba para no confundir informes.
No elimines el plugin duplicado sin revisar qué otros eventos administra. Desactiva únicamente su compra si lo permite; si debes sustituirlo, usa una matriz de eventos para conservar la medición válida.
Verifica integridad
Prueba compra normal, recarga, revisita desde la pasarela y reintento del servidor. Cada pedido debe producir una compra lógica con ID, moneda y valor estables.
Comprueba DebugView además del informe agregado. Dos requests pueden deduplicarse en ingresos y aun activar dos conversiones publicitarias. La corrección debe reducir la emisión, no confiar en que GA4 oculte el síntoma.
Comprueba reembolsos por separado: no son purchases negativos duplicados. El mantenimiento recurrente debe comparar IDs GA4 únicos con pedidos pagados y alertar si los eventos exceden inesperadamente las órdenes.