Google Analytics en PrestaShop: guía completa para configurar GA4

Si tenemos una tienda en PrestaShop y vendemos en España, Google Analytics (GA4) ya no es opcional: es la base para saber qué campañas traen ventas, qué productos funcionan y dónde estamos tirando presupuesto.

El problema es que, en la práctica, vemos siempre lo mismo: tiendas con scripts duplicados, compras que no llegan a GA4 o llegan sin valor, módulos que se quedan cortos y banners de cookies que directamente rompen la medición. Y claro, luego cuadrar cifras con el backoffice de PrestaShop es un drama.

En esta guía vamos a contar cómo lo solemos montar nosotros:

• Por qué casi siempre apostamos por GA4 + Google Tag Manager (GTM) en lugar de depender solo de un módulo.

• Cómo estructuramos los eventos de ecommerce en GA4 para no perder ni una venta.

• Los errores que más vemos en tiendas de España (y cómo los arreglamos).

• Cómo encajamos todo esto con RGPD, CMP y Consent Mode sin destrozar los datos.

La idea es que, cuando termines, tengas un plan claro para que Google Analytics mida de verdad tu PrestaShop y no sea solo un numerito de visitas.

Antes de empezar: requisitos para configurar Google Analytics 4 en PrestaShop

Versión de PrestaShop, módulos y tipo de tienda

Antes de tocar nada en GA4, nos aseguramos de tres cosas:

1. Versión de PrestaShop

   • PrestaShop 1.7 y 8.x suelen ir mejor servidas de módulos y themes compatibles con GA4 y GTM.

   • Si la tienda es más antigua (1.6 o con mil customizaciones), asumimos que habrá más “artesanía” y menos plug-and-play.

2. Módulos que ya están instalados

   • Módulos de Google Analytics, GTM, pixel de Meta, remarketing, etc.

   • Nuestro objetivo aquí es detectar si ya hay algo que esté insertando códigos de seguimiento para no duplicar scripts.

3. Tipo de tienda

   • Tienda pequeña con pocas referencias y tráfico moderado.

   • Ecommerce grande con catálogo enorme, marketplace, feeds, etc.
     Cuanto más compleja sea la tienda, más sentido tiene ir a un enfoque GTM + dataLayer bien hecho y, en proyectos grandes, plantear incluso server-side tagging.

Muddle recomienda: El módulo básico se queda corto, necesitamos más control y una capa de datos limpia.

Crear propiedad y flujo de datos en GA4

A nivel de GA4, los mínimos que solemos preparar son:

• Crear una propiedad GA4 específica para la tienda (no mezclar proyectos).

• Configurar el flujo de datos web con:

  • URL correcta (dominio principal y, si aplica, subdominio de la tienda).

  • Moneda por defecto en EUR.

• Copiar el ID de medición (G-XXXX), que usaremos luego en GTM o en el módulo.

A partir de aquí, para nosotros GA4 es el “cerebro”, pero la lógica de implementación la centralizamos casi siempre en Google Tag Manager.

Limpiar scripts antiguos de Universal Analytics

En tiendas antiguas seguimos viendo mucho Universal Analytics (UA) instalado:

• Antiguo módulo de Analytics.

• Scripts analytics.js o gtag('config', 'UA-...') metidos a mano en la plantilla.

• Algún tema o módulo que sigue insertando el código de UA sin que nadie se acuerde.

Siempre que hacemos una migración, lo primero es:

1. Buscar “UA-” y “analytics.js” en el código, en la plantilla y en los módulos.

2. Desactivar o borrar el módulo antiguo de UA si ya no aporta nada.

3. Asegurarnos de que, cuando activemos GA4, solo hay una implementación principal (idealmente vía GTM).

Si dejamos UA y GA4 activos sin control, nos podemos encontrar con eventos duplicados, datos inflados y una pesadilla para interpretar métricas.

Métodos para instalar Google Analytics en PrestaShop (módulo, código, GTM y server-side)

Módulo de Google Analytics / GA4 para PrestaShop: cuándo usarlo y limitaciones

Los módulos de Analytics/GA4 son la opción típica cuando queremos ir rápido:

Ventajas:

• Configuración “siguiente, siguiente, finalizar”.

• Suelen incluir alguna integración básica de ecommerce (envían purchase, add_to_cart, etc.).

• No hace falta tocar código.

Limitaciones que vemos a menudo:

• El módulo decide cómo se envían los eventos (nombres, parámetros…), y no siempre sigue las recomendaciones estándar de GA4.

• Si queremos añadir eventos personalizados, integraciones con otras plataformas o tocar el dataLayer… nos encontramos en una caja negra.

• Actualizaciones del módulo = posibles cambios en la forma de medir (sin avisar).

Nosotros los usamos a veces como “base rápida”, pero sabiendo que, en cuanto el proyecto crece, acabamos empujando hacia GTM + dataLayer más controlado.

Insertar el código de Google Analytics directamente en la plantilla

También podemos pegar el código de Analytics a pelo en la plantilla:

• Insertar la etiqueta global (gtag.js) en header.tpl o en el layout principal.

• Añadir algún fragmento para purchase en la página de confirmación de pedido.

¿Qué problema tiene esto?

• Cada cambio supone modificar archivos de plantilla: poco ágil, poco escalable.

• Si actualizamos el theme o PrestaShop, es fácil que perdamos el código.

• No hay una separación clara entre código de la tienda y código de medición.

Esta opción la solemos reservar para casos muy sencillos o proyectos donde no tiene sentido montar toda la infraestructura de tags.

Instalar GA4 con Google Tag Manager en PrestaShop

Aquí es donde más cómodos nos movemos.
Normalmente montamos GA4 en PrestaShop con GTM porque:

• Tenemos más control sobre qué se envía, cuándo y con qué parámetros.

• Es mucho más fácil de depurar con Tag Assistant y los previews.

• Podemos reutilizar la misma lógica para otros tags (Meta, Ads, etc.) sin duplicar esfuerzos.

El flujo típico:

1. Instalar el contenedor de GTM en la plantilla o mediante módulo.

2. Dejar la plantilla limpia de otros scripts sueltos.

3. Configurar los tags de GA4 dentro de GTM, usando un dataLayer bien definido.

Opciones avanzadas: GA4 con server-side tagging y Measurement Protocol

En tiendas con mucho volumen o necesidades avanzadas de privacidad y rendimiento, podemos dar un paso más:

• Montar un contenedor server-side de GTM.

• Enviar los eventos de GA4 a través de un servidor propio en lugar de hacerlo directamente desde el navegador.

• Complementar con Measurement Protocol para enviar compras o eventos desde el servidor (por ejemplo, cuando queremos garantizar que una compra se registra aunque el navegador se cierre).

No es obligatorio para cualquier PrestaShop, pero en proyectos grandes en España nos ayuda a:

• Mejorar rendimiento (menos scripts en el cliente).

• Tener algo más de control sobre la gestión de datos y cookies.

Configurar GA4 con Google Tag Manager en PrestaShop (paso a paso recomendado)

Instalar y probar Google Tag Manager en tu tienda

1. Creamos un contenedor web en Google Tag Manager.

2. Insertamos los fragmentos de GTM en la plantilla o vía módulo oficial:

   • head → script principal.

   • body → noscript con el iframe.

Después, comprobamos que el contenedor carga:

• Abrimos la web con la extensión Tag Assistant de Google.

• Vemos que GTM aparece y se pueden lanzar previews sin errores.

Hasta aquí solo hemos montado el “coche”. Ahora falta decirle qué eventos queremos recoger.

Construir la capa de datos de ecommerce en PrestaShop

Para que GA4 entienda qué está pasando en la tienda (productos, carrito, pedidos…), lo ideal es trabajar con un dataLayer estructurado.

En muchos proyectos acabamos con algo de este estilo en la página de confirmación de compra:

En PrestaShop solemos mapear:

• item_id → referencia del producto o ID estable de catálogo.

• item_name → nombre del producto.

• Categorías, variantes, etc. según la estructura interna de la tienda.

La clave es que el módulo o el desarrollo que haga el dataLayer sea consistente en toda la web: misma estructura para view_item, add_to_cart, begin_checkout y purchase.

Configurar los eventos básicos de GA4: page_view, view_item, add_to_cart, begin_checkout, purchase

En GTM, normalmente montamos:

1. Un tag de configuración de GA4 con el ID de medición (G-XXXX).

2. Tags de tipo evento GA4 para:

   • view_item en fichas de producto.

   • add_to_cart cuando el usuario añade al carrito.

   • begin_checkout al iniciar el checkout.

   • purchase en la página de confirmación.

Cada tag recoge los parámetros del dataLayer (item_id, value, currency, etc.).

Nuestra recomendación base siempre es medir usando los eventos estándar de ecommerce GA4; así aprovechamos mejor los informes nativos y evitamos inventarnos nomenclaturas raras.

Ecommerce en GA4 para PrestaShop: estructura de eventos y parámetros clave

Mapa de eventos estándar GA4 para una tienda PrestaShop

Para una tienda online típica, el flujo mínimo que buscamos cubrir es:

• view_item_list → listados de categoría, búsqueda, productos relacionados.

• view_item → ficha de producto.

• add_to_cart → producto añadido al carrito (botón normal o AJAX).

• view_cart → vista del carrito.

• begin_checkout → usuario inicia el proceso de compra.

• add_shipping_info / add_payment_info → pasos clave del checkout (opcional, pero muy recomendable).

• purchase → pedido completado.

Si estos eventos están bien definidos y a todos les llega la información correcta (items[], currency, value), ya tenemos el 80 % del valor de GA4 en un ecommerce.

transaction_id, value, currency e items[]: cómo montarlos bien

El error nº1 que vemos en PrestaShop es el evento purchase llegando a GA4:

• Sin value.

• Sin currency.

• Con un items[] mal montado (faltan productos o vienen mal de precio/cantidad).

Para evitarlo, nos aseguramos de:

• Usar un transaction_id único y estable por pedido (por ejemplo, el ID de pedido del backoffice).

• Enviar value con el importe total del pedido (impuestos incluidos, normalmente).

• Mantener la currency en “EUR” para España o, si la tienda es multi-moneda, enviar la moneda real del pedido.

• Rellenar items[] con una posición por cada producto comprado (no solo el primero).

Si nos acostumbramos a revisar estos cuatro campos, nos ahorramos muchos quebraderos de cabeza al cuadrar datos.

IDs de producto y variantes: buenas prácticas para item_id

Otra fuente de caos frecuente es el item_id:

• A veces se usa el ID interno de PrestaShop, otras la referencia, otras un SKU raro.

• En ocasiones, la variante (talla/color) no se distingue y luego es imposible analizar qué se vende realmente.

Buena práctica que solemos aplicar:

• Elegir un ID de producto único y estable (por ejemplo, la referencia comercial).

• Si trabajamos mucho con variantes, añadir parámetros como item_variant (talla, color…), o codificarlo en el propio item_id si tiene sentido.

• Mantener la misma lógica de IDs en todos los eventos: si en view_item un producto es REF-001, en add_to_cart y purchase debe ser igual.

Errores típicos al medir Google Analytics en PrestaShop (y cómo los solemos arreglar)

El evento purchase no llega o llega sin valor / moneda

Este es un clásico que nos encontramos una y otra vez:

• En GA4 no aparecen compras.

• O aparecen, pero sin value o sin currency.

• O solo se registra parte del catálogo.

Causas habituales:

• El módulo solo dispara el evento en ciertos métodos de pago.

• La página de confirmación se renderiza de forma distinta según el transportista y el script no se ejecuta.

• El dataLayer se genera, pero el tag de GA4 no está bien mapeado en GTM.

Lo que hacemos nosotros:

1. Ir a DebugView de GA4 y lanzar pedidos de prueba.

2. Revisar que el evento purchase aparece y ver qué parámetros llegan.

3. Corregir en el módulo o en el código del dataLayer los campos que faltan (normalmente value, currency o items[]).

Hasta que no vemos un pedido real cuadrar con el backoffice, no damos el proyecto por cerrado.

Transacciones duplicadas por recargas, scripts dobles o triggers mal hechos

Otra muy típica: GA4 reporta más compras de las que realmente hay en PrestaShop.

Motivos comunes:

• El usuario recarga la página de confirmación y el dataLayer vuelve a hacer push del purchase.

• Tenemos a la vez:

  • Un módulo enviando el purchase

  • Y un tag de GA4 en GTM disparando sobre el mismo evento.

• El trigger del tag en GTM es demasiado genérico (por ejemplo, “todas las páginas que contienen ‘order-confirmation’”).

Cómo lo atacamos:

• Revisamos si el módulo ya envía el purchase. Si es así, desactivamos la parte duplicada en GTM o al revés.

• Ajustamos el trigger para que se dispare solo en condiciones muy concretas (por ejemplo, presencia de un transaction_id en el dataLayer y una sola vez por sesión).

• Añadimos una lógica de “anti-duplicado” basada en transaction_id si hace falta.

add_to_cart y begin_checkout en botones AJAX y pasos intermedios

En muchas tiendas PrestaShop, los botones de añadir al carrito funcionan con AJAX:

• El usuario pulsa el botón, se abre un modal o se actualiza el mini-carrito.

• No hay recarga de página, así que si dependemos solo de “vistas de página”, no medimos nada.

También pasa con el inicio de checkout:

• Hay un paso intermedio vía AJAX antes de cargar la URL clásica /order.

Solución que solemos aplicar:

• Escuchar eventos de JavaScript del propio theme o del módulo de carrito para hacer un dataLayer.push del estilo:

  dataLayer.push({
event: "add_to_cart",
ecommerce: {
items: [ /* producto añadido */ ]
}
});


• Configurar en GTM un trigger de tipo evento personalizado (event = add_to_cart) en lugar de fiarnos solo de URLs.

Con esto conseguimos que add_to_cart y begin_checkout reflejen de verdad lo que hace el usuario, aunque todo vaya por AJAX.

Consentimiento de cookies y Consent Mode en PrestaShop (GDPR sin romper los datos)

Qué debe hacer tu CMP para no cargarse GA4

En España, entre RGPD, LSSI y las guías de la AEPD, no nos sirve con poner un banner cualquiera:
si Analytics usa cookies, necesitamos consentimiento explícito antes de disparar los scripts.

Lo que vemos a menudo:

• CMP que bloquea todo y nunca levanta el veto, ni siquiera tras aceptar.

• CMP que deja pasar Analytics incluso cuando el usuario rechaza cookies.

• “Integraciones automáticas” que se anuncian como compatibles con GA4 pero rompen completamente el flujo de datos.

En nuestro caso, cuando auditamos una tienda, siempre comprobamos:

• Que al entrar como usuario nuevo no se carga ningún tag de Analytics antes de aceptar.

• Que al aceptar, GA4 empieza a funcionar.

• Que al rechazar, se respetan las preferencias (podemos usar Consent Mode, pero sin colarnos).

Configurar Consent Mode v2 con GTM y GA4

Con el Consent Mode v2, la idea es que:

• Por defecto, los estados de consentimiento estén en “denied”.

• Cuando el usuario acepta o rechaza, la CMP actualiza esos estados.

• GA4 se adapta:

  • Si hay consentimiento, cookies normales.

  • Si no lo hay, medición limitada pero más respetuosa.

A nivel práctico, solemos:

1. Añadir una capa de datos inicial con el estado por defecto.

2. Integrar la CMP para que, al aceptar/rechazar, lance un dataLayer.push con los nuevos estados.

3. Configurar GTM para que solo dispare GA4 cuando el consentimiento para analítica está en “granted” o, si usamos Consent Mode, adaptarlo correctamente.

Cuando esto se monta mal, en España nos encontramos con tiendas donde, de repente, baja un 30–40 % el número de sesiones o compras en GA4 solo por un cambio de CMP.

Cómo probar que el consentimiento funciona y no distorsiona las ventas

Nuestra mini-checklist aquí:

• Navegar con navegador limpio / modo incógnito y probar:

  • Entrar sin tocar el banner → comprobar que GA4 no se dispara.

  • Aceptar todo → ver en DebugView que llegan eventos normales.

  • Rechazar analítica → ver que o bien no hay eventos, o se aplican las restricciones del Consent Mode.

• Hacer al menos un pedido de prueba aceptando cookies y otro rechazando, para ver qué llega a GA4.

• Mantener esta prueba cada vez que cambiamos de CMP, de theme o de módulo de cookies.

Checklist de QA: cómo comprobar que Google Analytics mide bien tu PrestaShop

DebugView y Tag Assistant: pruebas básicas que siempre hacemos

Antes de dar ninguna configuración por buena, nos pasamos por:

• Tag Assistant → para revisar qué tags se disparan en cada URL, si GTM carga bien y si hay scripts duplicados.

• DebugView de GA4 → para ver, en tiempo real, qué eventos se están registrando (y con qué parámetros) mientras navegamos la tienda.

Lo mínimo que validamos:

• Que todas las vistas de producto generan view_item con un item_id correcto.

• Que add_to_cart salta siempre que añadimos algo (botones normales y AJAX).

• Que begin_checkout y los pasos de checkout se registran bien.

• Que purchase llega con transaction_id, value, currency e items[].

Test con pedidos reales y cruce con el backoffice de PrestaShop

Una cosa es el entorno de test y otra los datos reales. Por eso siempre:

1. Hacemos varios pedidos reales (aunque luego los devolvamos o los marquemos como test).

2. Anotamos:

   • ID de pedido en PrestaShop.

   • Importe total, moneda, productos.

3. Esperamos a que GA4 los recoja y comprobamos que los números cuadran:

   • Mismo transaction_id.

   • Mismo value y moneda.

   • Misma lista de productos (items[]).

Si vemos desajustes, revisamos si la culpa es del dataLayer, de GTM o de algún módulo que retoca el proceso.

Nuestra norma interna es sencilla: si no cuadra con el backoffice, no está bien configurado.

Alertas y paneles útiles para detectar problemas en GA4

Una vez que todo funciona, nos gusta dejar montadas algunas “alarmas”:

• Informes o exploraciones que muestran:

  • Ratio de conversión por dispositivo.

  • Productos más vendidos vs. más visitados.

  • Caídas bruscas de purchase o de begin_checkout.

• Alguna alerta simple (por ejemplo, con Looker Studio o notificaciones internas) cuando:

  • El número de compras en GA4 cae en picado respecto a días anteriores.

  • Deja de llegar el evento purchase directamente.

Así no tenemos que esperar a que alguien diga “parece que Analytics marca menos ventas” semanas después.

Preguntas frecuentes

¿Es mejor usar el módulo de Google Analytics o Google Tag Manager en PrestaShop?
Para algo muy básico, el módulo puede servir. Pero en cuanto queremos medir bien el ecommerce, controlar eventos y evitar sorpresas, preferimos GTM: más flexibilidad, mejor depuración y más fácil de escalar.

¿Cómo configuro GA4 para medir compras en PrestaShop?
Necesitas que, en la página de confirmación de pedido, se genere un dataLayer.push con el evento purchase y todos sus parámetros (transaction_id, value, currency, items[]). Después, en GTM, creas un tag de evento GA4 que dispare sobre ese purchase y mapeas los campos.

¿Por qué mis pedidos de PrestaShop no aparecen en GA4?
Lo que vemos más a menudo es:

• El evento purchase nunca se dispara.

• El módulo solo dispara con ciertos métodos de pago.

• El CMP bloquea GA4 incluso cuando el usuario acepta cookies.

La solución pasa por revisar DebugView, el dataLayer y la configuración del banner de cookies.

¿Cómo evito transacciones duplicadas en Google Analytics?
Asegúrate de:

• No tener módulo + GTM enviando purchase a la vez.

• Controlar que la página de confirmación no lanza el dataLayer de nuevo al recargar.

• Usar transaction_id único y, si hace falta, una lógica de anti-duplicado basada en ese ID.

¿Puedo usar GA4 y Universal Analytics a la vez en PrestaShop?

Durante una migración se puede, pero siempre controlando qué envía cada uno para no duplicar eventos. A medio plazo, lo recomendable es quedarnos solo con GA4 bien configurado y retirar UA.

¿Cómo afecta el banner de cookies / CMP a GA4 en PrestaShop?

Si la CMP está mal integrada, puede dejarte GA4 totalmente “ciego” o, al contrario, hacer que dispares Analytics sin consentimiento (malo para datos y peor para cumplimiento). Lo ideal es que el banner controle los estados de consentimiento y, con Consent Mode, ajustes el comportamiento de GA4.

¿Cómo compruebo que Google Analytics está bien instalado en PrestaShop?

• Ver que GTM y GA4 se cargan en Tag Assistant.

• Navegar en modo debug y comprobar que los eventos de ecommerce aparecen con los parámetros correctos.

• Cruzar varios pedidos reales entre GA4 y el backoffice. Si todo cuadra, vamos por buen camino.

Conclusión

Configurar Google Analytics 4 en PrestaShop no es solo “pegar un código” o instalar un módulo. Si queremos tomar decisiones de negocio con datos fiables, tenemos que:

• Elegir bien el método de implementación (y entender sus límites).

• Construir una capa de datos sólida que describa lo que pasa en la tienda.

• Respetar RGPD y CMP sin cargarnos la medición.

• Y rematar con un QA serio: debug, pedidos reales y cruce con el backoffice.

Para rematar:
GA4 + GTM, ecommerce medido con eventos estándar y una rutina clara de QA.
A partir de ahí, es cuando Analytics deja de ser un lío de números y se convierte en una herramienta para vender más y mejor.