Cómo configurar Google Analytics en WooCommerce (guía completa)

Cómo instalar Google Analytics en WooCommerce en 3 pasos

Antes de empezar: requisitos para configurar Google Analytics en WooCommerce

Versión de WordPress, plugins y tipo de tienda

Antes de tocar nada en Google Analytics, conviene revisar tres cosas:

Versión de WordPress y WooCommerce. Las versiones actuales de WooCommerce (6.x en adelante) trabajan bien con GA4 y GTM. Si la tienda es antigua, con temas muy personalizados o lleva años sin actualizarse, hay más probabilidad de que la instalación requiera ajustes manuales.

Plugins que ya están instalados. Plugins de Analytics, GTM, píxel de Meta, remarketing… Antes de instalar nada nuevo, revisamos si ya hay algo insertando códigos de seguimiento para no duplicar scripts. En WooCommerce es muy habitual encontrar cuatro o cinco plugins haciendo cosas parecidas a la vez.

Tipo de tienda. Una tienda pequeña con pocas referencias y tráfico moderado puede funcionar bien con el plugin oficial. Una tienda grande, con catálogo extenso, variantes complejas o integraciones con marketplaces, se beneficia más de un enfoque GTM + dataLayer bien estructurado y, en proyectos grandes, de plantear server-side tagging.

Crear propiedad y flujo de datos en Google Analytics

A nivel de Google Analytics, los mínimos que hay que preparar son:

• Crear una propiedad específica para la tienda (no mezclar proyectos distintos en la misma propiedad).
• Configurar el flujo de datos web con la URL correcta (dominio principal y, si aplica, subdominio de la tienda) y la moneda por defecto en EUR.
• Copiar el ID de medición (G-XXXX), que usaremos luego en GTM o en el plugin.

Para nosotros, Google Analytics 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 con cierta antigüedad seguimos encontrando Universal Analytics (UA) instalado: el antiguo plugin de Analytics, scripts analytics.js o gtag('config', 'UA-...') metidos a mano en el tema, o plugins que siguen insertando el código de UA sin que nadie se acuerde.

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

• Buscar «UA-» y «analytics.js» en el código, en el tema activo y en los plugins instalados.
• Desactivar o eliminar el plugin antiguo de UA si ya no aporta nada.
• Asegurarnos de que, al activar GA4, solo hay una implementación principal (idealmente vía GTM).

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

Métodos para instalar Google Analytics en WooCommerce

Plugin de Google para WooCommerce: cuándo usarlo y sus limitaciones

El plugin oficial de Google para WooCommerce (Google Listings & Ads o el antiguo WooCommerce Google Analytics Integration) es la opción más rápida:

Ventajas: configuración ágil, incluye integración básica de ecommerce (envía purchase, add_to_cart, etc.) y no hace falta tocar código.

Limitaciones que vemos a menudo: el plugin decide cómo se envían los eventos y no siempre sigue las recomendaciones estándar de GA4; si queremos añadir eventos personalizados o integraciones con otras plataformas, entramos en una caja negra; y las actualizaciones del plugin pueden cambiar la forma de medir sin avisar.

Lo usamos a veces como base rápida, pero sabiendo que en cuanto el proyecto crece, terminamos empujando hacia GTM + dataLayer más controlado.

Insertar el código de Google Analytics directamente en el tema

También podemos pegar el código de Analytics directamente en el tema: insertar la etiqueta global (gtag.js) en el archivo header.php o en el layout principal, y añadir algún fragmento para purchase en la página de confirmación de pedido.

El problema es que cada cambio supone modificar archivos del tema (poco ágil, poco escalable), y si actualizamos el tema o WordPress, es fácil que perdamos el código. Esta opción la reservamos para casos muy sencillos.

Instalar GA4 con Google Tag Manager en WooCommerce

Aquí es donde más cómodos trabajamos. Montamos GA4 en WooCommerce 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; y podemos reutilizar la misma lógica para otros tags (Meta Ads, Google Ads, etc.) sin duplicar esfuerzos.

El flujo típico:

1. Instalar el contenedor de GTM en el tema o mediante el plugin GTM4WP.
2. Dejar el tema limpio 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 podemos dar un paso más: montar un contenedor server-side de GTM y enviar los eventos de GA4 a través de un servidor propio en lugar de hacerlo directamente desde el navegador. También podemos complementar con Measurement Protocol para enviar compras desde el servidor cuando queremos garantizar que una compra se registra aunque el navegador se cierre.

No es obligatorio para cualquier WooCommerce, pero en proyectos grandes ayuda a mejorar el rendimiento (menos scripts en el cliente) y a tener más control sobre la gestión de datos y cookies.

Configurar Google Analytics con GTM en WooCommerce (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 el tema o mediante el plugin GTM4WP:
   • <head> → script principal.
   • <body> → noscript con el iframe.
3. Comprobamos que el contenedor carga abriendo la web con la extensión Tag Assistant de Google y verificando que GTM aparece sin errores.

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

Construir la capa de datos de ecommerce en WooCommerce

Para que GA4 entienda qué está pasando en la tienda (productos, carrito, pedidos…), necesitamos un dataLayer estructurado. En WooCommerce podemos generarlo mediante un plugin, mediante un hook de PHP en el tema o en un plugin personalizado. En la página de confirmación de compra debería quedar algo así:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "WC-12345",
    value: 99.90,
    currency: "EUR",
    items: [
      {
        item_id: "SKU-001",
        item_name: "Camiseta básica blanca",
        item_category: "Camisetas",
        price: 19.99,
        quantity: 2
      },
      {
        item_id: "SKU-002",
        item_name: "Vaquero slim azul",
        item_category: "Pantalones",
        price: 59.92,
        quantity: 1
      }
    ]
  }
});
</script>

En WooCommerce solemos mapear item_id al SKU del producto o al ID interno de WooCommerce (lo que sea más estable), item_name al nombre del producto, y añadimos categorías, variantes, etc. según la estructura interna de la tienda.

La clave es que la estructura sea consistente en toda la web: misma lógica para view_item, add_to_cart, begin_checkout y purchase.

Configurar los eventos básicos de GA4

En GTM montamos un tag de configuración de GA4 con el ID de medición (G-XXXX) y 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.). Usamos siempre los eventos estándar de ecommerce GA4 para aprovechar al máximo los informes nativos y evitar nomenclaturas raras.

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

Mapa de eventos estándar GA4 para una tienda WooCommerce

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 más habitual en WooCommerce es el evento purchase llegando a GA4 sin value, sin currency, o con un items[] mal montado (faltan productos o vienen mal de precio o cantidad). Para evitarlo:

• Usar un transaction_id único y estable por pedido (por ejemplo, el ID de pedido de WooCommerce).
• 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.

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

WooCommerce tiene dos tipos de IDs: el ID de producto simple y el ID de variación. Definir cuál usar y mantener esa decisión en todos los eventos es fundamental. Una buena práctica:

• Elegir un ID único y estable (el SKU comercial suele ser mejor opción que el ID interno de WooCommerce).
• Si trabajamos 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 en todos los eventos: si en view_item un producto es SKU-001, en add_to_cart y purchase debe ser el mismo identificador.

Errores típicos al medir Google Analytics en WooCommerce (y cómo arreglarlos)

El evento purchase no llega o llega sin valor / moneda

Este es el clásico que aparece una y otra vez. En GA4 no se ven compras, o aparecen pero sin value o sin currency, o solo se registra parte del catálogo.

Causas habituales en WooCommerce:

• El plugin solo dispara el evento en ciertos métodos de pago.
• La página de confirmación (thankyou) se comporta de forma distinta cuando el pedido se procesa vía pasarela externa y el usuario vuelve redirigido.
• El dataLayer se genera, pero el tag de GA4 en GTM no está bien mapeado.

Lo que hacemos: ir a DebugView de GA4 y lanzar pedidos de prueba. Revisar que el evento purchase aparece y ver qué parámetros llegan. Corregir en el plugin o en el código del dataLayer los campos que faltan (normalmente value, currency o items[]). Hasta que un pedido real no cuadra con el backoffice, no damos el proyecto por cerrado.

Transacciones duplicadas por recargas, scripts dobles o triggers mal hechos

GA4 reporta más compras de las que realmente hay en WooCommerce. Motivos comunes:

• El usuario recarga la página thankyou y el dataLayer vuelve a hacer push del purchase.
• Tenemos a la vez el plugin 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-received'»).

Cómo lo atacamos: revisamos si el plugin ya envía el purchase y, si es así, desactivamos la parte duplicada en GTM o viceversa. Ajustamos el trigger para que se dispare solo en condiciones muy concretas (presencia de un transaction_id en el dataLayer, una sola vez por sesión). Añadimos 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 WooCommerce, el botón de añadir al carrito funciona con AJAX por defecto en muchos temas: el usuario pulsa el botón, se actualiza el mini-carrito, pero no hay recarga de página. Si solo medimos vistas de página, no medimos nada.

También ocurre en el checkout de WooCommerce Blocks, donde el proceso es diferente al checkout clásico y los eventos de página no siempre coinciden con lo que esperamos.

Solución: escuchar los eventos de JavaScript del tema o del plugin de carrito para hacer un dataLayer.push:

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

Y 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 WooCommerce (RGPD 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 sirve con poner un banner cualquiera: si Analytics usa cookies, necesitamos consentimiento explícito antes de disparar los scripts.

Lo que vemos a menudo en tiendas WooCommerce:

• 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» con plugins de cookies que se anuncian como compatibles con GA4 pero rompen el flujo de datos.

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, y que al rechazar se respetan las preferencias.

Configurar Consent Mode v2 con GTM y GA4

Con el Consent Mode v2, los estados de consentimiento están en «denied» por defecto. 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 añadir una capa de datos inicial con el estado por defecto, integrar la CMP para que al aceptar/rechazar lance un dataLayer.push con los nuevos estados, y configurar GTM para que solo dispare GA4 cuando el consentimiento para analítica está en «granted».

Cuando esto se monta mal, 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 plugin de cookies.

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

• Navegar con navegador limpio / modo incógnito y 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 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.
• Repetir esta prueba cada vez que cambiamos de CMP, de tema o de plugin de cookies.

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

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

Antes de dar ninguna configuración por buena, 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:

• Todas las fichas de producto generan view_item con un item_id correcto.
• add_to_cart salta siempre que añadimos algo (botones normales y AJAX).
• begin_checkout y los pasos del checkout se registran bien.
• purchase llega con transaction_id, value, currency e items[].

Test con pedidos reales y cruce con el backoffice de WooCommerce

Una cosa es el entorno de test y otra los datos reales. Por eso siempre hacemos varios pedidos reales, anotamos el ID de pedido en WooCommerce, el importe total, la moneda y los productos, y esperamos a que Google Analytics los recoja para comprobar que los números cuadran.

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

Alertas y paneles útiles para detectar problemas en GA4

Una vez que todo funciona, dejamos montadas algunas «alarmas»:

• Informes o exploraciones que muestran ratio de conversión por dispositivo, productos más vendidos vs. más visitados, y caídas bruscas de purchase o de begin_checkout.
• Alguna alerta (por ejemplo, con Looker Studio) cuando el número de compras en GA4 cae en picado respecto a días anteriores o deja de llegar el evento purchase.

Así no tenemos que esperar a que alguien avise de que «Analytics marca menos ventas» semanas después.

Preguntas frecuentes