En la mayoría de tiendas Shopify con unos años encima no hay una medición: hay
varias a la vez. Lo que nos solemos encontrar al entrar es alguna combinación
de llamadas a GTM desde theme.liquid, un custom pixel a medias que alguien
montó solo para el checkout, la app de Google & YouTube, y apps de terceros
que — sin que nadie lo recuerde — también envían algún evento a GA4. Cuando el
mismo purchase entra por dos o tres vías, ninguna cifra vuelve a cuadrar, y
da igual lo bien hecha que esté cada vía por separado.
Este artículo explica la alternativa que instalamos nosotros: un custom pixel que mide toda la tienda, checkout incluido, y sustituye al resto de vías. También lo que el sandbox no permite hacer y los casos en los que no te compensa montarlo.
Por qué el custom pixel es la única vía completa
Un custom pixel es un bloque de JavaScript que Shopify ejecuta en un sandbox
propio, suscrito a los eventos estándar de la tienda (page_viewed,
product_added_to_cart, checkout_completed…). La diferencia decisiva:
ve el storefront y el checkout.
Desde Checkout Extensibility, el checkout de Shopify no admite scripts
propios. Todo lo que midas desde theme.liquid se queda ciego justo donde
ocurre la venta. El custom pixel es la única vía en la que una sola pieza de
código, con el criterio a la vista, cubre el recorrido entero.
El inventario de vías, y dónde falla cada una
| Vía | Qué cubre | El problema |
|---|---|---|
gtag/GTM en theme.liquid | Solo storefront | Ciega en el checkout; sobrevive de la era anterior a Checkout Extensibility |
Custom pixel “solo checkout” + theme.liquid | Todo, en teoría | Dos fuentes con criterios distintos: duplicados y valores que no casan |
| App Google & YouTube | Todo | Caja negra: no puedes editar nada ni explicar por qué no cuadra |
| Apps de terceros | Eventos sueltos | Casi nunca son apps de medición: son apps de otra cosa (un visor 3D, reseñas) que además disparan eventos a GA4 sin que nadie lo sepa |
| Custom pixel completo | Todo | Exige montarlo bien: GTM, consentimiento y verificación sin Preview |
¿Cuánta discrepancia provoca cada combinación? Nos encantaría darte una tabla de rangos, pero sería inventada: no hay un número típico por vía — depende de cada implementación, de cada theme y de cada CMP. La única referencia estable que tenemos es la de salida: con el custom pixel bien implantado, y solo él, la diferencia con Shopify queda en torno al 5 %.
Qué mide el nuestro
La versión que instalamos cubre los 12 eventos estándar de GA4: navegación,
búsqueda y formularios en el storefront, y el embudo ecommerce completo desde
view_item_list hasta purchase. El purchase va entero: transaction_id,
descuentos por línea, cupones, envío, impuestos, método de pago y los datos
para enhanced conversions. GTM se carga dentro del propio sandbox, así que las
etiquetas se configuran como siempre.
El código completo, con la guía de instalación y verificación paso a paso, lo regalamos como descarga. Es la misma base que usamos en proyectos, sin las piezas que dependen de cada cliente.
Lo que el sandbox no deja hacer
Antes de migrar conviene saber qué se pierde, porque se pierde algo:
- No hay acceso al DOM. Los triggers de GTM que leen la página — clics por selector CSS, visibilidad de elementos — no existen dentro del sandbox. Para medir interacciones propias del theme hay que publicar eventos custom desde el theme, que es justo el tipo de pieza a medida que la versión descargable no incluye. Métricas que se apoyan en observar la página, como afinar la duración media de sesión, también quedan fuera.
- No funciona el modo Preview de GTM. La verificación clásica desaparece: hay que publicar y comprobar con método (logs en consola, tiempo real de GA4, un pedido de prueba). El paso a paso está en la guía.
- Cookies: sin problemas reseñables; el sandbox da una API para leerlas.
El consentimiento es la parte difícil
La ruta estándar para el consent es la Customer Privacy API de Shopify: el pixel lee el estado al cargar y se suscribe a los cambios. Es la que usa nuestra versión descargable, porque funciona sin depender de un CMP concreto.
Ahora, la opinión impopular: esa API falla más de lo que debería. Nos hemos encontrado varios casos en los que la señal no llega o no llega a tiempo, y la solución fue ir a algo más custom: leer la cookie de la CMP directamente desde el pixel, sin intermediarios. Es exactamente lo que acabamos haciendo en este ecommerce de calzado, donde el consentimiento mal propagado disfrazaba de “directo” un tercio del tráfico. La moraleja de verdad: el pixel es la parte fácil; saber qué herramienta de consentimiento hay implementada y cómo escribe es donde se rompe todo. Y lo que hagas aquí no se queda en el pixel: ese mismo estado es el que alimenta Consent Mode en tus etiquetas de Google.
Cuándo no te compensa
Dos casos en los que no montaríamos esto:
- Tienda pequeña, con poca inversión en captación. La app de Google & YouTube te da más que suficiente. El custom pixel empieza a compensar cuando el volumen y la inversión crecen y necesitas fiarte de los datos para decidir.
- Como excusa para irte a server-side. Segunda opinión impopular: server-side está muy vendido y la mayoría de tiendas no lo necesita. Primero una medición en cliente bien hecha — que ya te deja en ese ~5 % —, y el salto a server-side solo cuando el caso lo justifique de verdad.
Qué hacer mañana
- Inventario de vías activas. Configuración → Eventos de cliente (custom
pixels y apps con pixel), la app de Google & YouTube, el
theme.liquidy sus snippets, y las apps de terceros. Apunta todo lo que envía a GA4. - Deja una sola. Si va a ser un custom pixel, descárgate el nuestro: trae el código y el orden correcto de instalación, que empieza por desactivar lo demás.
- Valida contra Shopify. Con la tabla de equivalencias: en torno a un 5 % de diferencia es normal; por encima del 10 %, algo sigue roto.