GA4 en Shopify tiene dos vías de entrada habituales: la Google & YouTube app, o un píxel web personalizado en Customer Events con el que los envías tú. Ambas colocan datos de ecommerce en tu propiedad de GA4. Se diferencian en quién escribe el mapeo, quién lo mantiene y qué puedes cambiar.
Esta guía las compara a nivel de mecanismo: qué dispara el purchase, qué transporta el ID de transacción, cómo se respeta el consentimiento y qué se rompe. No declara un ganador, porque la respuesta correcta depende del control que necesites y del mantenimiento que puedas asumir. El reenvío server-side queda fuera de alcance; esa es otra capa.
¿Qué hace realmente la Google & YouTube app?
La Google & YouTube app es una app de canal de ventas de Shopify construida con Google. Carga las etiquetas de Google y mapea los eventos estándar de Shopify a los nombres de ecommerce recomendados por GA4, así que un purchase llega sin escribir código de píxel. Tú la configuras; Shopify y Google mantienen el mapeo.
Se suscribe a los eventos estándar de Shopify y los mapea a los nombres recomendados por GA4: product_viewed a view_item, product_added_to_cart a add_to_cart, checkout_started a begin_checkout y checkout_completed a purchase, con los eventos de carrito, listas, envío y búsqueda que los rodean también cubiertos.
El purchase es un evento de ecommerce completo de GA4: transaction_id, value, currency, tax, shipping, coupon, market_id y un array items con id, nombre, marca, variante, precio, cantidad y SKU. El value es el subtotal menos los descuentos, excluye envío e impuestos y usa USD por defecto como divisa cuando el evento no lleva ninguna. Cada evento lleva además shopify_event_name y un event_id. Los datos de cliente, como el email y el teléfono, solo se adjuntan donde el consentimiento y la configuración de Analytics lo permiten.
Lo que controlas es la configuración, no el código: conectas tu propiedad de GA4 o añades una etiqueta de Google manualmente, y puedes filtrar eventos dentro de GA4 por shopify_event_name. El mapeo, la fórmula del value y el conjunto de parámetros son fijos. Google indica que no todas las funciones de etiqueta basadas en código son compatibles, por las restricciones del sandbox de Shopify.
El purchase es a la vez la fortaleza y el techo de la app. Se dispara desde checkout_completed, así que no depende de que un script de la página de agradecimiento siga vivo, pero solo envía lo que define el esquema de Google: un evento de reembolso, un parámetro personalizado o tu propia definición de value quedan fuera de su superficie documentada.
¿Qué hace realmente un píxel web personalizado?
Un píxel web personalizado es JavaScript que añades en Customer Events del admin de Shopify. Se suscribe a los eventos estándar de Shopify y envía a GA4 lo que le indiques, mediante gtag o un contenedor de GTM cargado en el píxel. Eliges los nombres de evento, los parámetros, el array items, el transaction_id y el control de consentimiento.
El píxel se ejecuta en el sandbox de Shopify. Los píxeles personalizados se cargan en un sandbox permisivo —un iframe limitado a scripts y formularios— y no pueden llegar al frame superior, leer el DOM ni compartir el dataLayer del storefront. A cambio, obtienes un payload de evento estructurado y la Standard API de Shopify. El código que espera la página o window.dataLayer no encuentra ninguno de los dos, y por eso los fragmentos movidos desde un archivo del tema no hacen nada.
Dentro del sandbox decides todo lo que la app decide por ti: a qué eventos te suscribes, cómo los nombras, cómo construyes items y qué usas como transaction_id y value. Una suscripción de purchase puede parecerse a este esbozo:
analytics.subscribe('checkout_completed', (event) => {
const checkout = event.data.checkout;
gtag('event', 'purchase', {
transaction_id: checkout.order.id,
value: checkout.subtotalPrice.amount,
currency: checkout.currencyCode,
items: checkout.lineItems.map((item) => ({
item_id: item.variant?.sku ?? String(item.variant?.id),
item_name: item.title,
price: item.variant?.price?.amount,
quantity: item.quantity,
})),
});
});El consentimiento lo implementas tú. El píxel puede leer init.customerPrivacy y suscribirse a visitorConsentCollected, y después controlar lo que envía. Shopify ya ejecuta los píxeles solo después de que se concedan las finalidades requeridas en las regiones con consentimiento, y reproduce los eventos anteriores; tu control se suma a eso.
La contrapartida es la propiedad. Nada actualiza tu píxel cuando Shopify cambia un esquema, así que el mapeo, las pruebas y la corrección son tuyos. Y Google indica que las etiquetas de Google dentro de un píxel personalizado no son una configuración compatible, que no puede garantizar su comportamiento y que su soporte no puede arreglar problemas ahí. Eso no es motivo para evitar un píxel que necesitas. La fiabilidad, entonces, depende de ti.
¿Qué ocurre si ejecutas ambos a la vez?
Ejecutar la app y un píxel personalizado significa dos eventos purchase para el mismo pedido. GA4 deduplica los purchase que comparten un transaction_id idéntico, pero cuando las dos rutas envían IDs distintos o vacíos, GA4 cuenta el pedido dos veces. Un transaction_id vacío mezcla purchase que no tienen relación entre sí.
La regla de GA4 es concreta: colapsa los eventos purchase con el mismo transaction_id en los flujos web, y un transaction_id vacío hace que GA4 trate como duplicados entre sí purchase que no tienen relación. Solo ayuda cuando ambas rutas envían el mismo identificador no vacío. Cada una lo elige de forma independiente —la app deriva el suyo del pedido, tu píxel usa el que hayas elegido—, así que un desajuste es habitual y GA4 ve dos pedidos. La solución es estructural: ejecuta una sola ruta de compra, desactiva una antes de activar la otra y confirma en DebugView que un pedido de prueba produce un solo purchase.
Comparación lado a lado
La tabla compara las dos opciones según los criterios que deciden la mayoría de implementaciones. Es una descripción de contrapartidas, no una clasificación.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Criterio | Google & YouTube app | Píxel web personalizado (gtag o GTM) |
|---|---|---|
| Origen de los eventos | Eventos estándar de Shopify mapeados por la app | Tus suscripciones a los eventos estándar de Shopify |
| Cobertura de purchase y reembolsos | Mapeo documentado hasta purchase; el ajuste de reembolsos no está en su superficie configurable | Tú envías purchase y los eventos de reembolso que quieras; tú defines la cobertura |
| Deduplicación | La app genera su propio transaction_id y event_id | Tú eliges transaction_id y event_id |
| Gestión del consentimiento | Se ejecuta como píxel bajo la Customer Privacy API de Shopify y respeta las finalidades que declara | Tú lees el objeto de privacidad y controlas los eventos |
| Propiedad de los datos | El mapeo es de Shopify y Google; los datos llegan a tu propiedad de GA4 | La lógica es tuya; los datos llegan a tu propiedad de GA4 |
| Dependencia y lock-in | Depende de la app y del canal de Shopify por el que se ejecuta | Depende del sandbox de Shopify y de su esquema de eventos |
| Carga de mantenimiento | El proveedor mantiene el mapeo a medida que cambia la plataforma | Tú mantienes cada cambio de esquema y de parámetros |
| Para quién encaja | Tiendas que quieren el ecommerce de GA4 funcionando con código mínimo | Tiendas que necesitan parámetros, eventos o control que la app no expone |
Tabla de decisión
Relaciona tu situación con un punto de partida. Son valores por defecto para casos habituales, no reglas; una tienda con un desarrollador y necesidades de informes poco comunes puede acabar en el píxel personalizado incluso donde la app funcionaría.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Si tu situación es… | Elige… |
|---|---|
| Quieres los eventos de ecommerce estándar de GA4 funcionando y nadie escribe código de píxel | Google & YouTube app |
Necesitas un evento, un parámetro o un campo de items que la app no envía | Píxel web personalizado |
| Necesitas controlar exactamente qué se dispara bajo tu banner de consentimiento y cuándo | Píxel web personalizado, con tu propio control |
Estás migrando fuera de Additional Scripts o checkout.liquid y quieres la ruta compatible | Google & YouTube app |
| Ya tienes un píxel personalizado funcionando y solo quieres deshacerte del script heredado | Conserva el píxel y asegúrate de que no haya una segunda ruta de compra activa |
| Quieres que te mantengan el mapeo de eventos a medida que Shopify cambia el checkout | Google & YouTube app |
| Lo que pierdes son solicitudes bloqueadas o truncadas, no el mapeo | Ninguna por sí sola: consulta tracking server-side |
Cuándo no usar cada opción
Elegir en contra de una opción es más fácil cuando conoces sus límites duros. La app es la herramienta equivocada cuando necesitas configuración que no expone; el píxel personalizado lo es cuando nadie puede mantenerlo o cuando quieres la ruta compatible de Google. Ninguno de los dos arregla la pérdida de transporte.
No recurras a la Google & YouTube app cuando:
- Necesites un evento de reembolso, un parámetro personalizado o una definición de value distinta del subtotal menos los descuentos.
- Necesites enrutar el mismo purchase a destinos que su mapeo no cubre.
- Tu lógica de consentimiento tenga que diferir de las finalidades que declara la app.
No recurras a un píxel web personalizado cuando:
- Nadie vaya a hacerse cargo de él; cada cambio de esquema de Shopify se convierte en una caída esperando a que alguien la note.
- Quieras la configuración que Google admite. Google indica que las etiquetas de Google en un píxel personalizado no son compatibles y que su soporte no las arreglará.
- Dependas de Tag Assistant o GTM Preview, que depuran etiquetas en la página y no dentro del sandbox del píxel.
- El mapeo de ecommerce estándar sea todo lo que necesitas: asumirías mantenimiento sin ganancia.
No esperes que ninguno de los dos arregle:
- La señal perdida por bloqueadores de anuncios, pestañas cerradas o consentimiento denegado. Eso es transporte, y la respuesta es el envío server-side, no otra etiqueta de navegador.
- Una diferencia permanente entre GA4 y Shopify. Los dos sistemas cuentan de forma distinta; la conciliación es el método, no un píxel mejor.
Cómo verifico esto en implementaciones reales
Verifico contando. Una ruta de compra debería producir un purchase por pedido, visible en DebugView con un transaction_id que coincida y conciliable con una exportación de pedidos de Shopify. Todo lo demás —consentimiento, items, divisa— se comprueba contra ese mismo pedido.
- Confirma qué ruta es dueña del purchase. Settings → Customer events lista los píxeles registrados. Identifica todos los que puedan enviar un purchase; exactamente uno debería poder hacerlo.
- Observa un pedido real en DebugView. Pon un dispositivo en modo debug, completa un checkout entero y confirma que el
purchasellega con sutransaction_id,value,currencyeitems. Prueba más de una ruta de checkout antes de concluir que una etiqueta está muerta. - Comprueba la clave contra el pedido. El
transaction_idque recibió GA4 debería ser no vacío, único para ese pedido e idéntico en todas las rutas que lo envían. - Confirma que las plataformas de anuncios coinciden. Donde Meta esté en juego, Test Events de Events Manager debería mostrar una conversión para el pedido, no una por ruta de navegador.
- Concilia al día siguiente. Compara los purchase de GA4 por
transaction_idcon una exportación de pedidos de Shopify de un periodo cerrado: el mismo método de conciliación de pedidos que se usa en una auditoría de tracking. - Demuestra el consentimiento en ambos sentidos. Con el consentimiento denegado, confirma que las etiquetas siguen suprimidas; después concédelo y confirma que los eventos fluyen. Consulta consent mode v2.
Modos de fallo habituales
La mayoría de los fallos no son exóticos. Son una segunda ruta de compra que sigue activa, un transaction_id vacío, un value definido de forma distinta en cada lado o código en sandbox que daba por hecho que podía leer la página.
- Dos rutas de compra, dos IDs. La app y un píxel se disparan ambos y envían valores de
transaction_iddistintos, así que GA4 cuenta el pedido dos veces. - Un
transaction_idvacío. GA4 trata como duplicados entre sí todos los purchase que lo llevan, así que pedidos sin relación acaban fundidos en uno. - Un value definido sobre una base equivocada. La app envía el subtotal menos los descuentos, excluyendo envío e impuestos; un píxel escrito a mano que envíe un total bruto no cuadrará con los informes de GA4 ni con el neto de Shopify.
- Código en sandbox que daba por hecho que podía leer la página. Los fragmentos movidos desde un archivo del tema no hacen nada de forma silenciosa, porque el sandbox no tiene DOM ni dataLayer compartido.
- Depurar con la herramienta equivocada. Un contenedor de GTM dentro de un píxel puede parecer roto en GTM Preview o Tag Assistant, que depuran etiquetas en la página y no dentro del sandbox del píxel.
- Sin control de consentimiento en un píxel personalizado. Los eventos siguen disparándose para visitantes que lo rechazaron: un problema de cumplimiento, no una preferencia.
- Una etiqueta que sigue en Additional Scripts. Tras la actualización a checkout extensibility, el campo heredado deja de ejecutarse y el purchase se queda en silencio sin ningún error.
Limitaciones
Ninguna de las dos opciones arregla el transporte. Ambas dependen de que el píxel de Shopify se ejecute en el navegador, así que los pedidos perdidos por bloqueadores, pestañas cerradas o consentimiento denegado siguen perdidos salvo que el envío pase a server-side. Y ambas dejan a GA4 contando distinto de Shopify: GA4 atribuye sesiones y Shopify registra pedidos.
Ninguna elección de píxel cambia esa aritmética.
El píxel personalizado añade propiedad: cambios de esquema, pruebas y la falta de soporte declarada por el proveedor para las etiquetas de Google en ese entorno. La app añade un techo: el mapeo es fijo, así que los requisitos fuera de su superficie documentada necesitan otra ruta. Ninguna es un atajo para el consentimiento, y ninguna convierte en fiable una cifra sin conciliar.
Alternativas
Si tu problema no es «qué píxel», la respuesta puede estar en otra capa. El envío server-side manda el purchase desde el webhook de Shopify en vez del navegador, que es la respuesta duradera para la señal perdida por bloqueadores. Consulta la guía de tracking server-side. Las importaciones de conversiones offline cubren los pedidos que el navegador nunca vio.
Si estás arreglando un purchase roto en lugar de elegir una arquitectura, la implementación paso a paso está en Arreglar el evento purchase de GA4 en Shopify. Si el síntoma son compras ausentes, una diferencia que se amplía o un checkout roto, empieza por GA4 no registra las compras, discrepancia de ingresos entre GA4 y Shopify y tracking de checkout de Shopify roto. Para los conceptos subyacentes, consulta event ID, consent mode v2 y first-party tracking.
