Por qué GA4 no cuadra con tus pedidos y qué parte de la diferencia se puede recuperar

Abres el informe de compras de GA4, abres el listado de pedidos de PrestaShop, y no cuadran. Casi siempre GA4 marca menos. A veces, más. Y en las plataformas de anuncios la diferencia es todavía mayor.

La primera idea que conviene tener clara: no van a coincidir nunca al cien por cien, y no deben. La analítica mide lo que ve el navegador del visitante; el back-office registra lo que ha pasado de verdad. Lo útil es saber de dónde sale cada parte de la diferencia, cuál es legítima y cuál es un fallo que se puede corregir.

Causa 1: el consentimiento

Si tu banner de cookies funciona como debe, el visitante que rechaza la analítica no envía datos completos. Con Consent Mode v2, Google recibe señales sin cookies y puede estimar parte de esas conversiones, pero eso es un modelo, no un recuento.

Esta diferencia es legítima: es el precio de cumplir. Ninguna técnica debería saltársela. Si alguien te promete «recuperar» compras de quien ha rechazado el seguimiento enviándolas igualmente con sus datos, te está proponiendo un problema legal.

Causa 2: bloqueadores y navegadores restrictivos

Los bloqueadores de anuncios impiden que se carguen las etiquetas de analítica y de publicidad, aunque el visitante haya aceptado las cookies. Algunos navegadores, además, acortan la vida de las cookies que fija el navegador, de modo que un visitante que vuelve días después parece nuevo y su compra se atribuye mal.

Esta parte sí se puede mejorar respetando el consentimiento: enviando la conversión desde tu servidor, que el bloqueador no ve, y guardando los identificadores de campaña en una cookie fijada por el servidor.

Causa 3: el cliente no vuelve de la pasarela

En muchas tiendas el evento de compra se dispara en la página de confirmación. Pero hay clientes que pagan en la pasarela o en la app del banco y nunca vuelven a la tienda: cierran la pestaña, el móvil cambia de aplicación, la redirección falla. El pedido existe, porque la pasarela avisó al servidor, pero GA4 no se entera.

Es una de las causas más grandes y menos conocidas. Afecta sobre todo a métodos con autenticación fuera de la página (tarjeta con verificación en la app del banco, pagos desde el móvil). Solo se corrige enviando la compra cuando el servidor sabe que el pedido está cobrado, no cuando el navegador llega a una página.

Causa 4: compras de más

Cuando GA4 marca más que el back-office, mira:

• Recargas de la página de confirmación que disparan otra vez la compra.
• Dos módulos o una etiqueta de Tag Manager enviando el mismo evento.
• Pedidos con pago fallido que se cuentan al crearse aunque luego no se cobren.
• Navegador y servidor enviando la misma compra sin un identificador común para que la plataforma deduplique.

Causa 5: no estás comparando lo mismo

Antes de buscar fallos técnicos, comprueba que comparas cifras equivalentes:

Y los reembolsos: si no los envías a GA4, sus ingresos se quedan inflados mientras el back-office ya los ha descontado.

Cómo hacer la comparación, paso a paso

Para saber cuánto pierdes de verdad, haz esta comprobación con un periodo cerrado, por ejemplo el mes anterior:

1. Saca de PrestaShop los pedidos cobrados del periodo, sin cancelados ni reembolsados, con su referencia o su identificador.
2. Saca de GA4 las transacciones del mismo periodo con su identificador de transacción. Si tu etiquetado no envía el identificador del pedido como identificador de transacción, ese es el primer arreglo.
3. Cruza por identificador, no por totales. Los totales esconden compensaciones: diez compras perdidas y diez duplicadas dan una diferencia de cero.
4. Agrupa los pedidos que faltan por método de pago y por dispositivo. Si casi todos son de un método concreto o de móvil, ya sabes dónde buscar.
5. Agrupa los que sobran por número de veces que aparecen: los repetidos apuntan a recargas o a etiquetas duplicadas.

Repite la comprobación después de cada cambio en el etiquetado o en los módulos de pago. Una actualización de un módulo de pasarela que cambia la página de retorno puede romper la medición sin que nadie lo note.

Qué aporta el server side y qué no

Enviar las conversiones desde el servidor de la tienda (o desde un servidor intermedio) a GA4, Meta o Google Ads:

• Recupera las compras que se pierden por bloqueadores y por clientes que no vuelven de la pasarela.
• Permite enviar la compra al cobrarse, no al ver una página.
• Envía también reembolsos y cancelaciones, que el navegador nunca ve.
• No recupera lo que el visitante no ha consentido. El servidor tiene que respetar la misma decisión que el banner.
• No arregla un mal etiquetado: si el navegador envía la compra dos veces sin identificador común, el servidor solo añade una tercera.

Cómo resolverlo en PrestaShop

RKR API Conversions Pro envía las conversiones desde tu servidor a Meta, GA4, Google Ads, TikTok y otras plataformas, con el mismo identificador de evento que el navegador para que no se cuenten dos veces. Las compras se pueden enviar al cobrar el pedido (lo que traen por defecto las instalaciones nuevas), y viajan también los reembolsos parciales, las cancelaciones y los pedidos creados desde el back-office. Aplica Consent Mode v2 con el consentimiento restaurado antes de cargar las etiquetas, guarda los identificadores de clic en una cookie propia fijada desde el servidor, y tiene semáforos de salud por plataforma y una conciliación diaria de pedidos. Si no quieres montar ni mantener el servidor, RKR Relay (planes Esencial y Profesional) recibe los eventos que firma el módulo y los entrega a cada plataforma desde nuestro servidor, con cola, reintentos, credenciales cifradas, datos personales con hash y el estado de cada entrega visible en la tienda.