Primero, qué es esto y qué no es
Todo lo que en este artículo parece un caso —la tienda, el número de pedidos, las cifras de ingresos, el resultado— es ficticio. Existe para demostrar el método de diagnóstico y la forma de los documentos que recibirías. No es el resultado de un cliente y no pretende serlo.
Construí los tres informes de muestra enlazados más abajo exactamente para esto. Cada página de cada informe lleva la etiqueta «Illustrative sample · Fictional business, data and outcomes» (muestra ilustrativa; negocio, datos y resultados ficticios). Cuando cito cifras de ellos aquí, son esas cifras ficticias, y no he añadido ninguna.
Una divulgación, una sola vez: soy el fundador de Fixel Pixel, un producto de tracking para Shopify. Este artículo trata del método de consultoría, no del producto. Nada de lo que sigue depende de él, y un diagnóstico nunca tiene el producto como resultado obligatorio.
La tarea
Las plataformas publicitarias de un comerciante de Shopify y su propio libro de pedidos no coinciden en cuánto se vendió ni en cuántas compras se dispararon. Desde dentro de cualquier panel no hay forma de saber qué cifra, si alguna, es la correcta.
Esa es toda la tarea, y es más difícil de lo que parece, porque los paneles no mienten de forma evidente. GA4 y Meta pueden parecer correctos mientras reportan de menos o de más lo que Shopify vendió realmente. La discrepancia solo se hace visible cuando pones cada plataforma al lado de los datos de pedidos.
Las restricciones
Tres restricciones condicionan todo lo que sigue, y ninguna es opcional.
No se cambia nada antes de que el diagnóstico esté completo. Editar un pipeline antes de entenderlo significa diagnosticar un sistema que acabas de alterar. Así que el trabajo empieza con acceso en solo lectura —un rol de lector en GA4, Google Ads en solo lectura, Meta Events Manager y una cuenta de personal de Shopify con permisos de solo lectura— y no se edita nada hasta que el diagnóstico está hecho y el comerciante lo ha visto.
El veredicto termina en un precio fijo, no en una estimación. Un comerciante que ya ha pagado por un «arreglo» que no arregló nada necesita una afirmación comprobable, no otra promesa. Un precio fijo solo es posible para un alcance definible, así que el diagnóstico tiene que producir uno, o decir claramente que todavía no puede, y por qué.
«Coincide» no puede significar lo mismo en todas las plataformas. GA4 lleva el id del pedido de Shopify como transaction_id, así que un evento de compra puede vincularse al pedido que lo produjo. Meta expone su propio event_id, que vincula un evento de compra a un pedido y muestra que se contó una vez, pero Meta no expone ingresos a nivel de pedido. Google Ads informa en agregado, sin un feed por pedido que leer. El paquete de evidencia tiene que etiquetar cada fila según lo que realmente puede demostrar.
Por qué el camino obvio no encajaba
El movimiento obvio es reinstalar un píxel, activar el etiquetado server-side y darlo por hecho. Trata el síntoma —una cifra del panel parece baja, o alta— sin establecer nunca qué cifra era la verdadera desde el principio.
Tampoco sobrevive a que el comerciante pregunte «demuéstralo». No hay un rastro de evidencia pedido a pedido detrás de «ya debería estar arreglado», así que la siguiente discrepancia entre plataformas te devuelve al punto de partida, con una capa más de tracking que desenredar.
Lo que hago en su lugar
El método es una secuencia fija, y el orden importa.
-
Una conciliación en solo lectura, pedido a pedido, en todas las plataformas activas —el Health Check—, que termina en un veredicto por escrito: la causa confirmada de cada diferencia material dentro del alcance, o lo que queda sin confirmar, por qué, y cómo verificarlo. Los defectos, las diferencias normales de medición y las hipótesis sin confirmar se mantienen separados. El veredicto se entrega dos días laborables después de completar el kickoff y de confirmar que el acceso es suficiente (hora de Europa/Madrid, fines de semana excluidos). Si faltan datos, el reloj no ha empezado, y lo digo en lugar de alargar el plazo en silencio. Te quedas con el informe en cualquier caso, también cuando la respuesta es «no hay nada roto».
-
Un alcance por escrito y un único precio fijo, presupuestado antes de cualquier cambio de código, para un alcance definido con la precisión suficiente para poder presupuestarlo. La implementación es un encargo separado.
-
La corrección, construida en paralelo a la configuración existente. El tracking antiguo sigue funcionando hasta que la nueva ruta se demuestra con un pedido de test real, en la secuencia en que los eventos deben dispararse: consentimiento, luego deduplicación, luego el payload específico de cada plataforma. Un evento de compra que se dispara correctamente pero fuera de secuencia sigue estando roto.
-
Un paquete de evidencia de conciliación como entregable. Una tabla pedido a pedido, cada plataforma alineada con Shopify como fuente de verdad, con la diferencia mostrada claramente y cada fila etiquetada según lo que puede y no puede demostrar. Si las cifras siguen sin cuadrar, el encargo sigue abierto.
El resto de este artículo recorre esa secuencia en la tienda ficticia.
Parte 1: la auditoría (ilustrativa, datos ficticios)
El primer documento es Sample 01 — Measurement Audit (PDF; ilustrativo, datos ficticios). Supón una tienda de nutrición por suscripción, que opera en dólares estadounidenses, con un feed de compras a medida que envía las ventas a un conjunto de datos de reporting.
En una ventana de revisión de una semana, la tienda creó 1.000 pedidos pagados elegibles. El conjunto de datos receptor contiene 1.120 filas de compra.
Esa diferencia es el hallazgo, pero todavía no es un diagnóstico. La auditoría cruza los pedidos de origen con las filas de destino mediante una referencia de pedido estable e inspecciona lo que no coincide uno a uno antes de sumar nada:
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Paso del puente | Filas de compra | Ingresos por producto |
|---|---|---|
| Conjunto de datos receptor, sin corregir | 1.120 | $134,400 |
| Menos filas repetidas de 120 pedidos | −120 | −$14,400 |
| Pedidos elegibles únicos | 1.000 | $120,000 |
| Menos reembolsos sobre esos mismos pedidos hasta el corte | sin cambio en el número de pedidos | −$5,000 |
| Ingresos netos por producto al corte | 1.000 pedidos pagados | $115,000 |
Dos cosas distintas se escondían dentro de una sola queja de «los ingresos son demasiado altos». Las 120 filas repetidas son un defecto confirmado: el destino aceptó una compra, el emisor nunca recibió la respuesta de éxito, y el reintento generó una nueva identidad de venta que se aceptó como otra compra. Cruzar por la referencia de pedido revela las repeticiones; cruzar solo por la identidad de la entrega las oculta. Los $5,000, en cambio, no son un defecto en absoluto. Son la diferencia entre ingresos por producto e ingresos netos por producto tras reembolsos, dos definiciones que nadie había puesto por escrito.
Un tercer punto queda abierto a propósito: 60 pedidos carecen del historial de cliente necesario para clasificarlos como primera compra o compra repetida. La auditoría indica mantenerlos como «desconocido», no tratarlos como clientes nuevos.
La auditoría también declara su propia cobertura —qué se revisó, qué se probó, y que el hallazgo se aplica al feed a medida auditado, no a todas las plataformas publicitarias—. Después entrega una lista de trabajo con un responsable y una condición de aceptación por punto, un plan de despliegue y de vuelta atrás, y criterios de cierre: la cohorte original concilia a 1.000 pedidos y $120,000 de ingresos por producto, y una ventana posterior al despliegue, separada, también concilia.
Parte 2: la documentación (ilustrativa, datos ficticios)
Un arreglo que nadie encuentra seis meses después es un arreglo esperando a que lo deshagan. Por eso el segundo documento, Sample 02 — Tracking Documentation (PDF; ilustrativo, datos ficticios), es un registro de sistemas: cada componente, dónde vive, quién es su responsable, de qué se encarga y, no menos importante, qué no hace.
La ficha del evento de compra es la parte que impide que el defecto vuelva. En el ejemplo define una identidad de venta estable por pedido y destino que se conserva en los reintentos, de modo que un timeout seguido de un reintento produce una sola fila de venta; una hora del evento que no se mueve cuando hay un reintento; ingresos después de descuentos y antes de reembolsos, con impuestos y envío excluidos; un estado de cliente de primera compra, repetida o desconocido; y ajustes por reembolso como registros separados, vinculados al pedido, que nunca envían una segunda compra.
También enumera las comprobaciones rutinarias: qué ejecutar tras un cambio en el recolector o en el feed, qué compara una conciliación programada, qué registrar cuando una cifra parece incorrecta, y qué hay que adjuntar antes de cerrar un cambio.
Parte 3: la resolución y la validación (ilustrativa, datos ficticios)
El tercer documento, Sample 03 — Issue Resolution & Validation (PDF; ilustrativo, datos ficticios), cierra los dos hallazgos por separado, porque son cosas de distinta naturaleza.
La pregunta de los $5,000 se resuelve sin tocar ninguna configuración de tracking. Ambos informes contienen los mismos 1.000 pedidos; la vista de compras corregida suma $120,000; finanzas descuenta $5,000 de reembolsos sobre esos mismos pedidos hasta el corte; y $120,000 − $5,000 = $115,000 deja una diferencia sin explicar de cero. La resolución son dos vistas guardadas, «ingresos por producto» e «ingresos netos por producto», con el corte de reembolsos visible.
El defecto de entregas duplicadas se trata en el orden que uso para cualquier defecto:
- Cruzar pedidos con filas de destino. 880 pedidos tienen una fila, 120 tienen dos, y cada fila repetida coincide con el valor del pedido original.
- Trazar el mecanismo. La primera entrega fue aceptada, su respuesta expiró por timeout, y el reintento usó una nueva identidad de venta.
- Reproducir antes de cambiar código. Un fixture de 1.000 pedidos con 120 casos de aceptado-y-timeout produce 1.120 filas.
- Reparar y repetir la misma prueba. 1.000 filas, y los pedidos realmente distintos siguen creando ventas separadas.
- Desplegar y corregir el reporting. Excluir las 120 filas repetidas demostradas de la vista de reporting; conservar las filas en bruto y los motivos de exclusión.
- Verificar en producción y cerrar. Una cohorte posterior al despliegue, separada y asentada, de 250 pedidos pagados concilia con 250 filas de destino sin ninguna diferencia de valor de producto sin explicar.
La tabla de cierre pone el antes y el después uno al lado del otro, la lista de aceptación dice qué pasó, y un punto se traslada: las 60 clasificaciones de cliente «desconocido», que no reabren el defecto resuelto.
Cómo lo verifico en implementaciones reales
El ejemplo ficticio es ordenado. Las tiendas reales no lo son, y el método está construido para eso.
El cruce es siempre contra el libro de pedidos de Shopify, una fila por pedido con sus ingresos. Lo primero que miro son las filas que no coinciden uno a uno —ausentes, repetidas o con un valor distinto— antes de sumar nada, porque un agregado puede ser correcto por casualidad.
Un pedido de test real pasa por cualquier ruta de eventos nueva antes de que entre en producción, y la aceptación depende de que la conciliación de cada plataforma coincida con ese pedido, no de que un despliegue termine sin errores.
La implementación antigua se retira solo cuando la nueva se ha demostrado con tráfico real, con una vía de vuelta atrás en cada cambio. Si algo dentro del alcance se desvía en el mes posterior a la aceptación de la corrección, lo reviso.
Lo que el método puede y no puede demostrar
La limitación declarada está en el propio método, no en la letra pequeña.
Google Ads informa en agregado, así que la comparación ahí es entre los pedidos que deberían haber producido una conversión y las conversiones reportadas para la misma ventana; la evidencia por pedido solo existe donde tú controlas las subidas de conversiones. El emparejamiento por evento de Meta muestra qué eventos de compra llegaron y se contaron una vez, pero no puede ver ingresos a nivel de pedido. El paquete de evidencia dice qué comparación admite cada fila en lugar de dar a entender una paridad entre plataformas que no existe.
La propia conclusión del ejemplo es la honesta. El defecto documentado está resuelto en la prueba de fallo y en la cohorte posterior al despliegue comprobada. Eso no demuestra una atribución universal, ni la completitud en todas las plataformas publicitarias, ni un ROAS mejor; eso requiere su propia validación por destino.
La ventana de 30 días del Health Check es una base, no una promesa de historial completo. Un veredicto nombra la causa confirmada donde la hay, y donde no la hay, dice qué queda sin confirmar y cómo verificarlo.
Una vez más, para que no pueda malinterpretarse
La tienda, las cifras y el resultado de arriba son ficticios, construidos para mostrar el método. Este artículo demuestra cómo trabajo. No es evidencia de un resultado para ningún cliente, y los tres PDF son muestras de formato y razonamiento, no registros de un encargo.
Si quieres que aplique el método a tu propia tienda, empieza en solo lectura, y el veredicto es tuyo diga lo que diga.
Fuentes de este artículo
El método es el que se describe en este sitio; el ejemplo práctico es la serie de tres informes de muestra. No se ha usado nada más.
- Metodología — Diagnosticar, corregir, demostrarlo: el recorrido del encargo, el estándar de entrega y «cómo funciona el emparejamiento».
- Sample 01 — Measurement Audit (PDF): ilustrativo, datos ficticios.
- Sample 02 — Tracking Documentation (PDF): ilustrativo, datos ficticios.
- Sample 03 — Issue Resolution & Validation (PDF): ilustrativo, datos ficticios.
