Diagnóstico del código de seguimiento publicitario para ecommerce (2026)

Cómo utilizar esta guía

Esta guía está dirigida a especialistas en marketing de resultados, responsables de comercio electrónico, analistas, desarrolladores y equipos que necesitan auditar el seguimiento instalado por una agencia, un complemento, una aplicación o una implementación interna. Realice las pruebas en un entorno de ensayo o con un pedido de prueba que pueda cancelarse y reembolsarse. No haga pruebas repetidas con pedidos de clientes reales.

Después de completar esta guía, debería poder

• Distinguir entre la presencia del código, la activación de la etiqueta, la entrega de la solicitud, la recepción en la plataforma y la aptitud de una conversión para las pujas.
• Validar campos esenciales como el ID del pedido, los ingresos, la moneda, el ID del producto y el ID del evento.
• Diagnosticar compras duplicadas o ausentes, conversiones con valor cero, pérdida de atribución entre dominios y problemas de configuración de consentimiento.
• Elegir el enfoque de diagnóstico adecuado para Shopify, WordPress, WooCommerce o una infraestructura de comercio electrónico personalizada.
• Elaborar un informe de diagnóstico claro para los equipos de marketing, desarrollo, analítica o dirección.

Por qué un seguimiento instalado puede seguir generando datos poco fiables

Cuando una tienda independiente de comercio electrónico empieza a anunciarse en Google Ads, Meta Ads, Microsoft Ads o TikTok Ads, cada plataforma solicita una etiqueta o píxel de seguimiento. Encontrar ese código en el código fuente de la página no demuestra que el seguimiento de conversiones funcione correctamente.

• La plataforma publicitaria muestra la etiqueta como no verificada, inactiva o sin actividad reciente.
• GA4 registra pedidos, pero Google Ads no muestra conversiones.
• El sistema interno de la tienda contiene un pedido, mientras que la plataforma publicitaria informa de dos compras.
• El número de conversiones parece razonable, pero los datos de ingresos, moneda o productos son incorrectos.
• El píxel se detecta en la página de inicio, pero desaparece durante el pago o en la página de confirmación del pedido.
• Se envían eventos tanto del navegador como del servidor, pero no se deduplican correctamente.
• El seguimiento publicitario no respeta la elección de consentimiento del visitante: se sigue escribiendo o leyendo el almacenamiento publicitario, o se siguen enviando identificadores publicitarios o datos de usuario después de que el consentimiento de marketing sea denied. En el modo avanzado de consentimiento pueden seguir enviándose pings de consentimiento sin cookies mientras ad_storage o analytics_storage esté denied; ese comportamiento por sí solo no constituye un fallo de implementación.
• Las etiquetas no se reanudan después de que un visitante otorgue su consentimiento.

Una auditoría completa no puede limitarse a la pregunta «¿Está presente el código?». Confirme que cada acción comercial real llega a la plataforma correcta con el nombre de evento, los parámetros, el valor, la moneda y el ID de pedido correctos, y que la entrega desde el navegador y el servidor se resuelve en una única conversión lógica tras la deduplicación.

1. Qué comprueba realmente un diagnóstico de seguimiento publicitario

El seguimiento publicitario puede evaluarse en cinco capas. Los datos solo son adecuados para analizar el rendimiento, calcular el ROAS y automatizar las pujas cuando las cinco capas son satisfactorias.

Un mensaje «Tag Fired» en GTM solo demuestra que se cumplió una condición de activación. No demuestra que la conversión sea correcta. Continúe comprobando la capa de datos, la solicitud de red, las herramientas de prueba de la plataforma y el pedido correspondiente en el sistema interno.

2. Cree primero un plan de seguimiento de eventos de comercio electrónico

Antes de solucionar problemas, defina las acciones del cliente que el sitio realmente necesita medir. Una implementación típica de comercio electrónico debe abarcar al menos las vistas de productos, las adiciones al carrito, los inicios del pago y las compras.

En la versión de agosto de 2026 de esta guía, TikTok utiliza Purchase como evento estándar de comercio electrónico purchase y Lead para los envíos de clientes potenciales. CompletePayment y SubmitForm son nombres heredados compatibles asignados a Purchase y Lead; no cambie el nombre de una implementación heredada que funciona sin un plan de migración. Utilice Contact solo para una acción de contacto auténtica. GA4 utiliza purchase y recomienda parámetros como transaction_id, value, currency y una matriz items.

Datos mínimos necesarios para un evento purchase

3. Prepare la prueba de diagnóstico

No utilice un pedido de un cliente real como prueba principal. Cree un pedido de prueba que pueda cancelarse o reembolsarse y anote los datos siguientes antes de empezar.

Desactive las extensiones del navegador que bloquean anuncios durante la prueba principal de implementación, pero no desactive el banner de consentimiento del sitio. Las pruebas de bloqueo de anuncios y las pruebas de consentimiento deben ejecutarse por separado; de lo contrario, no podrá saber si la etiqueta fue bloqueada por la extensión del navegador o por la configuración de consentimiento.

Pruebe al menos tres situaciones de consentimiento

• Un visitante nuevo que todavía no ha elegido una opción de cookies.
• Un visitante que acepta todas las cookies pertinentes.
• Un visitante que rechaza las cookies de marketing.

Para el modo de consentimiento de Google, establezca el estado predeterminado de consentimiento antes de que se ejecuten las etiquetas pertinentes y actualícelo de inmediato en la misma página después de que el visitante elija una opción. Verifique por separado ad_storage, analytics_storage, ad_user_data y ad_personalization. El modo avanzado de consentimiento puede enviar pings sin cookies mientras el almacenamiento está denied; confirme que no se envían almacenamiento publicitario, identificadores publicitarios ni datos de usuario en contra de la elección del visitante.

Conjunto de herramientas de diagnóstico

1. Tag Assistant y GTM Preview de Google

La vista previa de Google Tag Manager muestra los eventos de página, las etiquetas activadas y no activadas, las condiciones de activación, las variables y el estado de consentimiento. Responde a dos preguntas esenciales: qué ocurrió en el sitio y por qué GTM activó o no pudo activar una etiqueta.

2. DebugView de GA4

DebugView de GA4 confirma si GA4 recibió realmente el evento y muestra sus parámetros. Ayuda a distinguir un problema de implementación de GTM de un problema de entrega o recopilación de GA4.

3. Panel Network de Chrome DevTools

El panel Network muestra las solicitudes que el navegador envía realmente. Puede filtrar por dominio de plataforma, tipo de solicitud, nombre de archivo, ID de etiqueta o ID de medición. Es la herramienta clave para responder «¿Envió el navegador los datos?».

4. Herramientas de prueba específicas de cada plataforma

Utilice Test Events y diagnóstico en Meta Events Manager; Pixel Helper, Test Events y diagnóstico para TikTok; UET Tag Helper para Microsoft Advertising; y Shopify Pixel Helper para los píxeles personalizados de Shopify.

4. Flujo de trabajo completo para diagnosticar el seguimiento publicitario

Paso 1: Haga un inventario de todas las implementaciones de seguimiento

Las conversiones duplicadas suelen deberse a varias instalaciones de la misma plataforma, no a una única etiqueta defectuosa.

• GTM está instalado una vez en el tema y de nuevo mediante un complemento.
• La aplicación oficial de Meta para Shopify instala un píxel y también existe un Meta pixel personalizado independiente.
• Un complemento de WordPress envía Purchase mientras GTM vuelve a enviar el mismo Purchase.
• Una acción de compra nativa de Google Ads y una acción de compra importada de GA4 están configuradas como objetivos principales.
• Meta Pixel y Conversions API envían la misma compra sin una deduplicación funcional.
• Una aplicación de TikTok, GTM y el código del tema instalan el mismo píxel.

Cree un inventario de implementación. Para facilitar la lectura, reúna en un solo campo de notas el método de instalación, la ubicación de la etiqueta base, el origen del evento de compra y el estado de los eventos del servidor.

Busque cada ID en el código fuente de la página, la lista de etiquetas de GTM, los complementos de WordPress, las áreas de código personalizado del tema, Shopify Customer Events, las aplicaciones de Shopify, Cloudflare Zaraz, GTM del lado del servidor y cualquier integración personalizada con el sistema interno.

Paso 2: Confirme que la etiqueta base se carga correctamente

Para GTM, no empiece abriendo directamente la página de confirmación del pedido. Conecte la vista previa desde la página de inicio o la página de destino publicitaria y siga después el recorrido real del cliente por la vista del producto, el carrito, el pago y el abono.

• Confirme que la vista previa esté conectada al dominio correcto.
• Confirme que el contenedor GTM esperado aparezca al cargar la página.
• Compruebe que el ID del contenedor coincida con la cuenta y el entorno activos.
• Confirme que el Google tag base se cargue en todas las páginas necesarias.
• Compruebe si la página de pago correcto permanece en la misma sesión de depuración.
• Compruebe si la sesión se interrumpe tras una redirección o una transición entre dominios.
• Revise Consent Initialization y cualquier estado de consentimiento que bloquee la etiqueta.

Al mismo tiempo, abra Chrome DevTools y busque en el panel Network el ID del contenedor GTM, el ID de medición GA4, el ID de conversión Google Ads, el ID Meta pixel, el ID de píxel de TikTok o el ID de etiqueta UET de Microsoft. Buscar el ID real es más fiable que depender de un único punto de conexión fijo, ya que las rutas de solicitud pueden cambiar.

Si no aparece ninguna solicitud, compruebe primero lo siguiente

• Falta el código o el ID configurado es incorrecto.
• El contenedor GTM no se publicó o se cargó el entorno equivocado.
• La configuración de consentimiento impide que se ejecute la etiqueta.
• La Política de Seguridad de Contenido bloquea el script externo o el punto de conexión.
• Un bloqueador de anuncios o una opción de privacidad del navegador bloquea la solicitud.
• Se produce un error de JavaScript antes de que se ejecute el código de seguimiento.
• Una caché o CDN sigue sirviendo una versión anterior del código del sitio.

Paso 3: Valide la capa de datos o el evento del cliente

La capa de datos es el puente entre la actividad de comercio electrónico y las etiquetas publicitarias. Google Tag Manager y gtag.js leen eventos y variables de esta capa estructurada. Utilice datos predecibles y estructurados en lugar de obligar a las etiquetas a extraer valores de elementos de página no relacionados.

Un evento purchase simplificado al estilo de GA4 puede tener este aspecto:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-10086",
    value: 129.90,
    currency: "USD",
    tax: 8.20,
    shipping: 0,
    items: [
      {
        item_id: "SKU-001",
        item_name: "Portable Coffee Grinder",
        price: 64.95,
        quantity: 2
      }
    ]
  }
});
</script>

En el comercio electrónico de GA4, el valor a nivel de evento normalmente debe ser igual a la suma del precio multiplicado por la cantidad de la matriz items y no debe incluir el envío ni los impuestos, salvo que su definición documentada de informes y la plataforma de destino exijan expresamente otro valor.

Utilice el comando siguiente en la consola de Chrome para una inspección inicial:

window.dataLayer

Para mostrar solo los eventos purchase:

window.dataLayer?.filter(item => item.event === "purchase")

Valide estos seis puntos

1. El evento se produce en el momento correcto: Purchase debe generarse cuando el pedido haya finalizado correctamente, no solo cuando el cliente haga clic en Pagar ahora o Enviar pedido.
2. El ID de pedido es único: el mismo pedido debe conservar el mismo ID después de una actualización, mientras que dos pedidos distintos nunca deben compartir el mismo ID.
3. El valor es numérico: utilice 129.90, no «$129.90», «USD 129.90» ni una cadena que contenga un separador de miles.
4. La moneda coincide con el pedido: en tiendas multidivisa, compare la moneda mostrada, la moneda de liquidación y la moneda enviada a la plataforma.
5. La matriz items está completa: los ID de producto, precios, cantidades y descuentos deben conciliarse con el pedido del sistema interno.
6. No se conservan valores antiguos: las aplicaciones de página única, los cajones de carrito y los pagos de AJAX pueden reutilizar accidentalmente datos de un evento anterior.

Paso 4: Inspeccione los activadores y las variables de GTM

Complete un recorrido de prueba real en GTM Preview, seleccione el evento purchase e inspeccione Tags Fired, Tags Not Fired, Variables, Data Layer y consentimiento.

El activador es demasiado amplio

Una regla como Page URL contiene thank-you puede volver a activarse cada vez que el visitante actualiza, guarda en sus marcadores o visita de nuevo la página de confirmación. Es preferible que las compras de comercio electrónico utilicen un evento real de finalización del pedido y un ID de pedido único.

El activador es demasiado restrictivo

La URL real podría ser /en/checkout/success mientras que el activador solo permite /checkout/success. Las carpetas de idioma, las cadenas de consulta y las rutas de pago alternativas pueden invalidar una regla demasiado estricta.

Los nombres de los eventos personalizados no coinciden

La capa de datos envía event: «checkout_completed», pero GTM escucha purchase. Los nombres de los eventos deben coincidir exactamente, incluidas las mayúsculas y los guiones bajos.

La etiqueta se activa antes de que lleguen los datos

La etiqueta se ejecuta al cargar la página, pero el valor, la moneda y el ID de pedido entran en la capa de datos varios cientos de milisegundos después. La etiqueta parece activarse correctamente aunque envía parámetros vacíos.

AJAX o una aplicación de página única no produce una carga de página tradicional

Los cajones de carrito, los pagos modales y las aplicaciones React o Vue pueden no generar una vista de página normal. Active el seguimiento a partir de eventos comerciales, no solo de cargas de página o cambios de URL.

Paso 5: Utilice Network para confirmar que se envió una solicitud

Abra Chrome DevTools -> Network, habilite Preserve log y repita toda la prueba. Filtre por ID o dominio de la plataforma. Abra la solicitud correspondiente e inspeccione Headers y Payload.

• Verifique la plataforma de destino y el ID de la etiqueta o del píxel.
• Verifique el nombre del evento, el valor, la moneda y el ID del pedido.
• Confirme que estén presentes los ID de producto, las cantidades y la matriz items.
• Confirme que los eventos del navegador y del servidor compartan los identificadores de deduplicación específicos de la plataforma: Meta y TikTok requieren el mismo nombre o tipo de evento junto con event_id, mientras que las compras de GA4 y Google Ads utilizan transaction_id.
• Compruebe si la solicitud se canceló, se bloqueó o devolvió un error.
• Compruebe si la solicitud se produjo antes o después de la redirección de la página.

Una solicitud observada con una carga útil plausible solo demuestra que el navegador intentó entregarla o que un punto de conexión aceptó una solicitud. No demuestra el procesamiento de la plataforma, la atribución, la aptitud para las pujas ni la exactitud de los datos comerciales. Una solicitud Purchase con valor 0 puede seguir transmitiéndose correctamente.

GTM indica que la etiqueta se activó, pero Network no muestra ninguna solicitud

• El estado de consentimiento y las comprobaciones integradas de consentimiento.
• Bloqueo de anuncios u opciones de privacidad del navegador.
• Restricciones de la Política de Seguridad de Contenido.
• Una plantilla de etiqueta defectuosa o un error de ejecución de JavaScript.
• Una solicitud cancelada por una navegación inmediata.
• Limitaciones del Pixel Sandbox de Shopify.

Paso 6: Confirme la recepción dentro de cada plataforma publicitaria

GA4

Abra DebugView, seleccione el dispositivo de prueba y confirme que la secuencia de eventos sea razonable:

page_view
view_item
add_to_cart
begin_checkout
purchase

Abra purchase y verifique transaction_id, value, currency e items.

Google Ads

Abra Goals -> Conversions -> Summary y revise el estado de seguimiento de la acción pertinente. Si aparece Unverified, Tag inactive o Needs attention, inicie Tag Assistant desde la acción de conversión. El estado de la cuenta puede tardar en actualizarse después de una corrección, por lo que debe usar Tag Assistant y la solicitud real como capa de validación inmediata.

Meta Ads

En Events Manager, seleccione la fuente de datos correcta y revise Overview, Test Events, diagnóstico, Event Deduplication y Event Match Quality. Test Events confirma la entrega desde el navegador y el servidor; diagnóstico identifica eventos duplicados, parámetros no válidos o problemas de calidad de los datos.

TikTok Ads

Utilice TikTok Pixel Helper para inspeccionar etiquetas, eventos y parámetros del navegador; Events Manager -> Test Events para la recepción en tiempo real; y Events Manager -> diagnóstico para errores de implementación persistentes.

Microsoft Advertising

Utilice UET Tag Helper para validar el ID de etiqueta UET, el evento de carga de página, los eventos personalizados, los ingresos variables, la moneda y las condiciones del objetivo de conversión. El estado de UET en Microsoft Advertising puede tardar más en actualizarse. Si también se utiliza Microsoft Advertising Conversions API, verifique su event_id y confirme que la entrega desde el navegador y el servidor no genere informes duplicados. Para ingresos variables, conserve revenue_value y currency exactamente como exige el destino.

5. Diagnostique Conversions y Event Deduplication duplicados

Las compras duplicadas inflan el ROAS registrado y aportan señales incorrectas a las pujas automáticas. Revise conjuntamente el navegador, el servidor, los complementos, las aplicaciones, GTM y los objetivos importados, en lugar de auditar una sola capa.

Deduplicación de Google Ads

Google Ads recomienda enviar un ID de transacción único con cada compra. Si se actualiza la página de confirmación y el mismo pedido vuelve a enviarse a la misma acción de conversión, Google Ads puede utilizar el ID de transacción coincidente para identificar el duplicado. Un ID de transacción no deduplica automáticamente acciones de conversión Purchase independientes.

• Los pedidos distintos no deben compartir el mismo ID de transacción.
• El ID de transacción no debe estar vacío.
• No utilice la dirección de correo electrónico ni el número de teléfono del cliente como ID del pedido.
• Las etiquetas del navegador y las cargas del sistema interno deben utilizar el mismo ID de pedido para la misma transacción.

Deduplicación de Meta Pixel y Conversions API

Cuando el mismo Purchase se envía mediante Meta Pixel y Conversions API, los eventos del navegador y del servidor deben compartir los mismos event_name y event_id. Los pedidos distintos deben utilizar valores event_id diferentes. De lo contrario, un solo pedido puede contarse como dos eventos.

• ¿Utilizan los eventos del navegador y del servidor el mismo event_name?
• ¿Utilizan ambas versiones del mismo pedido el mismo event_id?
• ¿Recibe cada pedido distinto un ID de evento diferente?
• ¿Un reintento del servidor crea un nuevo ID de evento y genera accidentalmente un segundo evento?
• ¿Están enviando la misma compra tanto una aplicación Shopify como una implementación CAPI personalizada?

Deduplicación de TikTok Pixel y Events API

Cuando TikTok Pixel y Events API envían el mismo evento, ambos lados deben utilizar el mismo nombre o tipo de evento y el mismo event_id para que TikTok reconozca el par y conserve un único evento lógico.

Actualizaciones de la página de confirmación del pedido

Es muy arriesgado utilizar solo una vista de la página de confirmación para activar Purchase. Actualizar, guardar en marcadores o volver a abrir la página puede activar de nuevo el evento. Utilice un ID de pedido único y, cuando sea posible, active el evento a partir de la finalización real del pedido, no de una carga de página normal.

6. Revise la Goals de conversiones, el pago entre dominios y la atribución

Acciones de conversión Primary frente a secundarias

En Google Ads, las acciones de conversión principales suelen aparecer en la columna Conversions y pueden utilizarse para las pujas cuando la campaña usa el objetivo correspondiente. Las acciones Secondary sirven principalmente para observación y suelen aparecer en All conversions. Sin embargo, una acción secundaria puede utilizarse para pujar cuando se incluye en un objetivo personalizado que la campaña usa activamente.

Si el evento aparece en la cuenta pero la campaña no optimiza en función de él, verifique que la acción sea principal y que la campaña utilice el objetivo correspondiente.

Every frente a One

Por lo general, las acciones Purchase deben contar todas las transacciones. Los formularios Lead suelen utilizar One porque varios envíos procedentes del mismo clic en el anuncio quizá no representen varios clientes potenciales valiosos. Para las ventas, use un ID de transacción único que elimine los pedidos duplicados.

Objetivos principales de compra duplicados

Una cuenta puede contener un Purchase Google Ads nativo, un Purchase GA4 importado y un Purchase creado por una aplicación Shopify. Si los tres son principales y la campaña los utiliza, la columna Conversions puede contener varias señales de compra para un solo pedido.

Conversions mejoradas

Después de habilitar Conversions mejoradas, confirme que los datos propios aptos del cliente se envíen realmente en el formato exigido. Que una etiqueta Purchase base funcione no demuestra que Conversions mejoradas estén en buen estado.

Pago entre dominios y redirecciones de pago

Algunas tiendas trasladan a los visitantes del dominio principal a un dominio de pago independiente, un proveedor de pagos externo, un sistema de reservas, un servicio de formularios, un subdominio o un sitio regional. Una configuración incorrecta entre dominios puede causar:

• Que una sola sesión del cliente se divida en varias sesiones.
• Que desaparezca la fuente publicitaria original.
• Que el proveedor de pagos se convierta en la fuente de referencia registrada.
• Que el ID de clic se pierda antes del pago.
• Que haya eventos en la tienda, pero ninguno después de que el pago se complete correctamente.

Utilice la medición entre dominios de GA4 solo entre dominios que controle y en los que pueda implementarse la misma etiqueta GA4. Para dominios de pago externos en los que no pueda implementar esa etiqueta, revise List unwanted referrals para impedir que el proveedor sustituya la fuente original; esto no sustituye a la medición entre dominios. Pruebe toda la redirección desde una página de destino, en lugar de abrir directamente la página de pago correcto.

7. diagnóstico de seguimiento específicas de Shopify

Los píxeles de Shopify Customer Events se ejecutan en entornos aislados. Los píxeles de aplicaciones usan un entorno aislado Strict, mientras que los píxeles personalizados usan uno Lax; sus capacidades no son idénticas. Ambos deben basarse en Shopify Customer Events y Web Pixels API en lugar de extraer datos mediante DOM tradicional.

1. No dependa únicamente de Tag Assistant de Google

Tag Assistant de Google no es compatible con los píxeles personalizados GTM en Shopify. Utilice Shopify Pixel Helper para confirmar que los eventos del cliente entran en el entorno aislado y valide después la solicitud Network resultante y el Test Events o los diagnósticos de la plataforma de destino.

Shopify Pixel Helper
-> dataLayer del píxel personalizado
-> etiqueta GTM
-> solicitud Network
-> Test Events de la plataforma publicitaria

2. Evite extraer datos de DOM dentro del entorno aislado

Los Web Pixels de Shopify funcionan en un entorno aislado. Las implementaciones que leen o modifican DOM de la tienda pueden fallar o comportarse de forma incoherente. Prefiera los datos proporcionados por Shopify Customer Events y Web Pixels API, en lugar de extraer precios de productos, botones o datos de pedidos con selectores CSS.

• Un activador de clic que escucha directamente un botón del tema.
• Una variable de elemento DOM que extrae el precio de producto mostrado.
• Uso directo de document.querySelector.
• Utilizar la URL del entorno aislado como si fuera la URL de la tienda.
• Suponer que la medición mejorada de GA4 puede descubrir automáticamente todas las interacciones aisladas.

3. Compruebe si el píxel está esperando consentimiento

Abra Settings de Shopify -> Customer events -> Custom pixels e inicie una prueba. Si Pixel Helper indica Pixel is awaiting consentimiento, revise:

• Los permisos de privacidad del cliente asignados al píxel personalizado.
• La configuración del banner de cookies para el mercado activo.
• Si el visitante granted Analytics o Marketing consentimiento.
• Si la plataforma de gestión de consentimiento se integra con la Customer Privacy API de Shopify.

4. Utilice checkout_completed correctamente

checkout_completed de Shopify normalmente se activa una vez por proceso de pago y suele observarse en la página de agradecimiento. Si existe una venta adicional poscompra, puede activarse en la primera página de venta adicional y no de nuevo en la página de agradecimiento. También puede no activarse si la página esperada no se carga correctamente.

Pruebe el pago estándar con tarjeta, Shop Pay o el pago acelerado, los pedidos con descuento, los pedidos gratuitos, las ventas adicionales poscompra, los pedidos multidivisa y los casos en que la página de agradecimiento no se carga por completo.

8. Problemas habituales de diagnóstico en WordPress y WooCommerce

El problema más habitual de WordPress no es la imposibilidad de instalar el seguimiento, sino instalar el mismo seguimiento en demasiados lugares. Revise las ubicaciones siguientes en este orden:

• Complementos de instalación de GTM.
• Complementos de GA4 o de conversión publicitaria.
• Complementos independientes de Meta, TikTok o Microsoft Advertising.
• Áreas de código personalizado de la cabecera y el pie del tema.
• Código personalizado del maquetador de páginas.
• Personalizaciones de la página de agradecimiento de WooCommerce.
• Configuración de CDN, caché, combinación de scripts y retraso de JavaScript.

Los flujos de añadir al carrito, pago y abono de WooCommerce suelen ser modificados por AJAX o por complementos externos. No presuponga que una regla estándar de clic en botón o de página de confirmación siga funcionando. Utilice la capa de datos real y el evento de finalización del pedido como fuente fiable.

Comprobaciones adicionales para complementos de rendimiento y caché

• ¿Retrasan la carga de GTM o del píxel?
• ¿Cambian los scripts combinados el orden de ejecución?
• ¿Se almacena en caché una página de confirmación que contiene datos del pedido?
• ¿Se produce la actualización de consentimiento después de que ya se hayan ejecutado las etiquetas publicitarias?
• ¿Se bloquean o se canalizan incorrectamente mediante proxy las solicitudes de seguimiento de terceros?
• ¿El problema solo aparece cuando el administrador ha cerrado sesión?

9. Matriz de solución de problemas

10. Criterios de aceptación para una implementación fiable

Una compra de prueba correcta debe cumplir todas las condiciones siguientes:

• Purchase solo se activa después de que el pedido finalice realmente con éxito.
• One pedido de prueba se resuelve en una única conversión lógica tras la deduplicación.
• El ID de pedido coincide con el sistema interno de comercio.
• El valor de conversión se ajusta a la definición acordada y la moneda es correcta.
• Los ID de producto, los precios y las cantidades son exactos.
• GTM Preview muestra el evento completo y las variables con valores.
• La solicitud correspondiente existe en Network.
• La plataforma de destino reconoce el evento en su herramienta de prueba.
• Los eventos del navegador y del servidor están deduplicados.
• Los estados aceptado y rechazado de consentimiento producen el comportamiento previsto.
• La configuración de Primary, Secondary y Count en Google Ads es correcta.
• El pago entre dominios conserva la fuente original.
• Actualizar la página de confirmación no crea otra conversión independiente.

Estándar de aceptación final
One pedido comercial real -> una conversión publicitaria lógica tras la deduplicación -> ID de pedido, valor, moneda y datos de producto correctos -> verificación en la plataforma -> conciliación con el sistema interno de comercio.

11. Plantilla de informe de diagnóstico del seguimiento publicitario

Utilice la estructura siguiente para registrar la auditoría. Guarde como pruebas adjuntas capturas de pantalla de la ruta de prueba, la carga útil de Network, el Test Events de la plataforma y el pedido del sistema interno.

1. Sitio web y entorno

2. Inventario de instalaciones de seguimiento

3. Pedido de prueba

4. Resultados del diagnóstico

5. Problema y corrección

6. Pruebas de regresión

Cadena de pruebas completa

Acción comercial
-> Evento del cliente / Data Layer
-> Activador GTM
-> Etiqueta publicitaria
-> Solicitud Network
-> Evento de prueba de la plataforma
-> Objetivo de conversión
-> Conciliación con el sistema interno

Los datos de conversión solo deben utilizarse para evaluar campañas, informar sobre ROAS y automatizar las pujas cuando todas las capas de esta cadena sean correctas.