Cuando los números de Meta no cuadran con tu backend

Casi todo anunciante acaba notándolo: el administrador de anuncios de Meta reporta un número de compras y el propio backend de la tienda, Shopify, un CRM, un sistema de gestión de pedidos, reporta otro distinto. Ningún número está mal. Miden cosas diferentes por diseño.

Por qué divergen los dos números

Ventana de atribución. Meta atribuye una conversión a un anuncio si ocurrió dentro de una ventana definida tras un clic o una visualización (habitualmente por defecto 7 días de clic y 1 día de visualización, aunque es configurable). Un sistema de backend simplemente registra el pedido en el momento en que se realiza, sin ningún concepto de a qué anuncio corresponde el mérito. Una venta que se cierra nueve días después de un clic en el anuncio puede aparecer como pedido en el backend y quedar totalmente fuera de la ventana de Meta.

Crédito por visualización y modelado. Meta puede contar una conversión de alguien que vio un anuncio pero nunca hizo clic, basándose en atribución modelada. Un CRM no tiene forma de registrar que una persona simplemente vio un anuncio. De forma similar, cuando Meta no puede observar directamente un evento del lado del navegador, por exclusiones de ATT o bloqueadores de anuncios, a veces estima conversiones de forma estadística, y esas estimaciones aparecen en el total de la plataforma sin ningún registro equivalente en el backend.

Recorridos entre dispositivos. Alguien hace clic en un anuncio desde el móvil y compra más tarde desde un portátil. Meta puede enlazar parte de esto mediante el estado de sesión, pero no de forma perfecta, y un sistema de backend ligado a un esquema de ID de cliente distinto puede no conectar los dos eventos de la misma manera.

Deduplicación y sincronización horaria. Un backend cuenta un pedido una sola vez. Un evento de píxel y otro de la Conversions API para el mismo pedido pueden, sin una deduplicación correcta usando un ID de evento, contarse dos veces en el lado de la plataforma. Por separado, el día de reporte de Meta puede no alinearse con la zona horaria de la tienda, desplazando conversiones a un día adyacente al comparar ambos.

Reembolsos. Un total de backend normalmente refleja el ingreso neto tras reembolsos. El recuento de conversiones de Meta puede seguir incluyendo un pedido que después se reembolsó o canceló.

En qué número confiar para cada cosa

Usa el número del backend como fuente de verdad de cuánto ingreso entró realmente y qué se envió. Es el número para finanzas, inventario y cualquier conciliación con dinero real.

Usa el número de la plataforma, leído de forma consistente en el tiempo en vez de comparado con los totales del backend, para juzgar si un anuncio concreto va mejor o peor que la semana pasada. Es direccional, no absoluto.

Usa el ROAS combinado o MER, ingreso total del backend sobre gasto total en anuncios en todos los canales, cuando la pregunta es si el marketing en conjunto está funcionando. Evita el desajuste al no depender en absoluto de la atribución de la plataforma.

Cómo reconciliar la diferencia

Arregla primero la deduplicación: confirma que los eventos de píxel y de Conversions API para el mismo pedido comparten un único ID de evento. Compara totales por periodo, no día a día, y deja que la ventana de atribución transcurra por completo antes de comparar. Comprueba si las conversiones por visualización están inflando el número de la plataforma, y confirma que las zonas horarias coinciden. Espera que quede una diferencia incluso después de todo esto: una diferencia pequeña y estable es normal, una amplia o creciente señala una rotura concreta que merece investigarse.

Errores comunes

Comparar totales del mismo día entre plataforma y backend antes de que se haya cerrado la ventana de atribución. Asumir que el número de la plataforma está inflado en vez de comprobar primero la deduplicación y el conteo por visualización. Recortar el gasto en una campaña porque sus conversiones reportadas cayeron, cuando el ingreso del backend se mantuvo estable, sin comprobar si la caída es un artefacto de medición en vez de una caída real de la demanda.

Cómo ayuda YieldBI

La capa de atribución de YieldBI te permite fijar de forma explícita el modelo de atribución incremental y la ventana efectiva, y combina los datos de píxel con la Conversions API y la importación de conversiones offline para que los números de la plataforma se acerquen más al backend. Los Controles de crecimiento reportan el rendimiento a nivel de anuncio contra ese modelo configurado, manteniendo las decisiones de escalado ancladas a una vista coherente y reconciliada.