Quienes llevan tráfico de pago a Shopify repiten la misma pregunta: ¿qué debe comprobar realmente una auditoría de tracking? La mayoría de las respuestas enumeran herramientas: instala este píxel, mira aquel panel. No explican qué demuestra la comprobación ni qué preguntas siguen abiertas después.
Una lista útil se organiza en torno a comprobaciones: una pregunta que merece hacerse, la fuente que consultarías para responderla, cómo verificarla y, la parte que suele faltar, qué sigues sin saber después. Esa cuarta columna es lo que hace que la lista valga la pena. Superar una fila acota un problema, no lo cierra.
Lee las columnas así: las dos primeras dicen qué compruebas y dónde; la tercera es la acción concreta, el informe que consultar, la herramienta que abrir o el campo que revisar; la cuarta recoge lo que realmente has podido concluir. Una lista de tres columnas permite marcar casillas sin saber qué deja pendiente cada marca verde. Todo lo siguiente es de solo lectura, en el mismo orden que uso en la metodología: revisar registros existentes y pruebas conservadas. Si una fila necesita pruebas nuevas, márcala como no verificada. Una prueba nueva de checkout o de interacción con el consentimiento es un paso separado, con autorización explícita, fuera de esta lista.
¿Qué alcance y accesos necesita una auditoría de tracking de Shopify?
Antes de comparar una plataforma con otra, la auditoría necesita saber qué puede consultar y para qué periodo. Saltarse este paso hace que el dictamen termine cubriendo un sistema que nadie había acordado incluir.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Pregunta | Fuente consultada | Cómo se verifica | Qué queda sin saber después |
|---|---|---|---|
| ¿El alcance es realmente una tienda, un problema y un conjunto acordado de sistemas? | La nota de alcance escrita y acordada antes de conceder acceso | Se comparan los sistemas nombrados en la nota con los que se están revisando | Si la causa real está en un sistema fuera del alcance acordado; esto solo confirma qué se está examinando |
| ¿El acceso es de solo lectura y cubre lo necesario? | Rol de lector de GA4, acceso de solo lectura de Google Ads, Meta Events Manager y cuenta de personal de Shopify | Se inicia sesión con el rol concedido y se consulta el nivel de permisos que muestra la plataforma | Si el acceso resultará insuficiente una vez iniciada la conciliación |
| ¿Qué periodo de pedidos está disponible para revisar? | Exportación de pedidos de Shopify, desde Admin u Orders API, para el periodo acordado | Se contrastan directamente el número de pedidos y el intervalo de fechas con el administrador de Shopify | Si el mismo patrón existía antes del periodo exportado; una referencia de 30 días no promete cubrir todo el historial |
| ¿Qué píxeles y etiquetas están instalados, más allá de lo que se recuerda? | Shopify admin → Settings → Customer events, además de cualquier contenedor GTM en uso | Se abre cada entrada de Customer events y se contrasta con lo que describió el comerciante | Por qué está cada entrada y quién la mantiene; se confirma qué existe, no quién lo añadió ni si sigue haciendo falta |
¿Llega el evento de compra desde una fuente que sigue funcionando?
Shopify ha cambiado varias veces dónde puede ejecutarse una etiqueta de compra. Una auditoría que solo mira la ubicación antigua no encuentra ningún fallo: allí ya no queda nada que encontrar. El píxel dentro del sandbox, el campo retirado Additional Scripts y las rutas de checkout express sin probar se recogen en la página de tracking de Shopify. Las filas siguientes indican qué caso se aplica.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Pregunta | Fuente consultada | Cómo se verifica | Qué queda sin saber después |
|---|---|---|---|
| ¿El evento de compra de un pedido real llega a GA4? | Pruebas existentes de DebugView de GA4, de un pedido de prueba previamente autorizado | Se revisan los parámetros guardados del evento de compra y se comparan con ese pedido; si no se conservaron las pruebas, se marca como no verificado | Si todas las rutas de pago, como Shop Pay y otros checkouts express, envían el mismo evento; las pruebas solo cubren el pedido probado |
| ¿La etiqueta de compra se ejecuta donde Shopify permite hacerlo? | Shopify admin → Settings → Customer events, tanto píxeles de apps como personalizados | Se abre cada píxel activo y se comparan los eventos a los que está suscrito con los que expone Web Pixels API | Si el píxel que aparece está configurado correctamente; estar presente no equivale a estar bien configurado |
| ¿Sigue habiendo una etiqueta de compra en un campo retirado? | Checkout settings → Additional Scripts | Se abre el campo directamente; Shopify lo dejó de solo lectura para tiendas no Plus y sus scripts no se trasladan a las páginas Thank you y Order status actualizadas, así que lo que queda ahí no se ejecuta en una tienda que ya se actualizó | Cuánto tiempo llevaba sin enviar datos antes de la revisión; nada avisa al comerciante cuando un script de ese campo deja de ejecutarse |
| ¿Existe una copia de servidor del mismo pedido? | Contenedor de servidor o registro de entrega de Conversions API, emparejado por pedido | Se compara la referencia del pedido en el evento de servidor con la del evento de navegador del mismo pedido | Si la ruta del servidor cubre también pedidos que el navegador pierde; para eso hace falta una muestra más amplia |
¿Se cuenta cada compra una sola vez en cada plataforma?
Si una plataforma informa de más pedidos de los que Shopify envió, primero hay que revisar la deduplicación. Cada plataforma usa su propio identificador, así que se comprueba por plataforma y no se da por hecha porque un total parezca razonable.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Pregunta | Fuente consultada | Cómo se verifica | Qué queda sin saber después |
|---|---|---|---|
| ¿GA4 cuenta una compra por pedido? | El parámetro transaction_id del evento de compra | Se compara el valor con el identificador real del pedido, en DebugView y en una exportación del día siguiente | Si una ruta de pago concreta genera un valor vacío o repetido que el pedido de prueba no puso de manifiesto |
| ¿Los eventos de Meta del navegador y del servidor de una compra se cuentan como una sola conversión? | Test Events y la pestaña Diagnostics de Meta Events Manager | Se confirma el mismo event_id y el mismo nombre de evento en ambas copias, recibidas dentro de la ventana de deduplicación indicada por Meta | Si ese uso de event_id se mantiene en todos los pedidos, no solo en la muestra revisada |
| ¿Solo hay una ruta de compra activa por pedido? | Canales de ventas de Shopify y configuración del píxel personalizado o de GTM | Se confirma por inspección que el canal nativo y el píxel personalizado no estén enviando ambos la misma compra | Si se encuentran ambos activos, si la deduplicación por transaction_id de GA4 está absorbiendo bien el solapamiento o se le escapa parte |
| ¿El número de pedidos conciliados coincide con el registro de Shopify? | Exportación de pedidos de Shopify unida a la exportación de compras de GA4 por transaction_id; Meta y Google Ads no exponen un flujo por pedido y se comparan de forma agregada | Se emparejan pedidos fila a fila mediante un identificador compartido, en vez de comparar totales | Por qué falta o se repite un pedido; la unión muestra qué filas no coinciden, no el mecanismo que lo provoca |
¿Qué explican el consentimiento y los informes, y qué no?
No toda diferencia entre una plataforma y los pedidos de Shopify es un defecto. Las decisiones de consentimiento, el tráfico modelizado y las plataformas que solo ofrecen datos agregados generan diferencias que, vistas desde un panel, parecen errores. Esto cubre la implementación técnica, no asesoramiento legal.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Pregunta | Fuente consultada | Cómo se verifica | Qué queda sin saber después |
|---|---|---|---|
| ¿El banner de consentimiento bloquea o permite etiquetas según su configuración? | Señales de Consent Mode v2, como ad_storage y analytics_storage | Se revisan capturas de solicitudes existentes para cada elección de consentimiento, distinguiendo pings sin cookies de cargas completas; si no hay capturas, se marca como no verificado | Si la modelización de Google recupera con precisión el tráfico sin consentimiento; ocurre dentro de sus sistemas y no es visible aquí |
| ¿El tráfico Unassigned está en un rango coherente con la configuración de consentimiento de la tienda? | Informe Traffic acquisition de GA4, fila Unassigned | Se consulta directamente el porcentaje del periodo revisado | No hay una cifra fija que haga que Unassigned sea «demasiado alto» en todas las tiendas; se informa del número, no se emite un dictamen sobre él |
| ¿La Event Match Quality de Meta refleja lo que envía esta tienda? | Overview de Meta Events Manager, puntuación EMQ y desglose de parámetros | Se consultan la puntuación y los parámetros ausentes o mal formados que aparecen para el píxel o conjunto de datos revisado | EMQ puntúa la integridad de los datos, no el rendimiento publicitario; una puntuación baja no significa que la campaña esté fallando |
| ¿Google Ads informa de conversiones para el mismo periodo en el que Shopify muestra los pedidos? | Informe de conversiones de Google Ads frente a pedidos de Shopify, con el mismo intervalo de fechas | Se comparan recuentos agregados del periodo, ya que Google Ads no expone un flujo por pedido que consultar | Qué pedidos concretos explican la diferencia; una comparación agregada indica que existe, no qué pedidos son |
Conclusión y siguiente paso
De una lista así salen dos respuestas honestas, y ambas son válidas.
No se ha encontrado ningún defecto en el alcance revisado. Las comprobaciones completadas no encontraron fallos en los sistemas, pedidos y periodo revisados. Registra también las filas no verificadas y los límites pendientes. No certifica todas las rutas de pago, la cobertura histórica ni la atribución, ni demuestra que todas las cifras de los informes sean correctas.
Hace falta investigar más. Una o varias filas dejan una diferencia que no se explica por consentimiento, modelización ni informes agregados: un transaction_id repetido, un píxel que dejó de enviar datos o un evento de servidor sin su correspondiente evento de navegador. Eso indica que hay una causa concreta que se puede encontrar; no demuestra que ya se haya encontrado.
En ambos casos, el informe que conservaría se parece al del ejemplo de este método de diagnóstico: qué se revisó, qué demostró y qué no, con una tienda ficticia y el mismo formato que se usaría con una real.
Si una fila muestra algo que no puedes explicar, el siguiente paso es describirlo: contacta conmigo con la URL de la tienda, qué fila falló y qué viste. Si la causa o el alcance necesitan una revisión más cercana, de solo lectura, que supere lo que puedes comprobar con los accesos anteriores, para eso está el Health Check. No es el siguiente paso por defecto, sino el que corresponde cuando has llegado al límite de tus propias comprobaciones.
