La API de conversiones de Meta se envía en paralelo al píxel, no en su lugar. Meta recomienda compartir los mismos eventos por los dos caminos y deduplicarlos con el mismo `event_id` y el mismo `event_name`. El navegador aporta contexto de sesión, el servidor fiabilidad cuando el píxel no llega. Montar esa doble vía entra en cómo monta Codezone la capa de medición.
Con solo píxel pierdes eventos por bloqueadores, por pestañas que se cierran antes de que el script acabe y por navegadores que limitan el almacenamiento. Con solo servidor pierdes los parámetros que mejor identifican al usuario. Las dos pérdidas se pagan en coste por adquisición sin que nada avise.
Al terminar sabrás qué evento manda cada capa y qué identificador los une. El caso equivalente en Google está en el mismo problema resuelto fuera de Meta.
Qué es la deduplicación de eventos
Es el mecanismo por el que Meta reconoce que un evento del navegador y otro de tu servidor son la misma acción, y conserva solo uno. Exige idéntico `event_name` e idéntico `event_id`, y Meta solo deduplica si llegan dentro de las 48 horas siguientes al primero, según la documentación oficial de deduplicación de píxel y servidor.
Hay una segunda vía, por `event_name` combinado con `fbp` o `external_id`, para cuando no puedes generar un identificador compartido. Meta advierte que esa variante solo descarta el evento de servidor si antes llegó uno de navegador en esas 48 horas.
Por qué el píxel y el servidor van en paralelo
El píxel corre en el dispositivo y recoge `fbp`, `fbc` y el user agent, parámetros que Meta no puede reconstruir desde tu backend. La API de conversiones corre en tu infraestructura y conoce lo que el navegador nunca ve: el pedido confirmado, el importe final, la devolución. Mandar la compra solo desde el navegador es contar carritos que no se cobran.
El envío duplicado y deduplicado es el único montaje que conserva las dos fuentes. Si tu contenedor de servidor no está publicado, el orden de trabajo está en poner el contenedor de servidor en producción, y el porqué del enfoque en qué resuelve el tracking en servidor.
Qué datos de usuario viajan y cómo se hashean
Meta separa los parámetros en dos grupos, y confundirlos es el error que más veces hemos encontrado al auditar integraciones:
- Se hashean con SHA-256: email, teléfono, nombre, apellido, ciudad, provincia, código postal y país. Antes del hash hay que normalizar, según los parámetros de información de cliente de Meta: email en minúsculas y sin espacios, teléfono sin símbolos ni ceros iniciales y con prefijo de país, país en ISO 3166-1 alfa-2 minúsculas.
- No se hashean: `client_ip_address`, `client_user_agent`, `fbp` y `fbc`. Si los hasheas, dejan de servir.
- Opcional: `external_id`, tu propio identificador de cliente. Meta recomienda hashearlo, y es el puente natural con tu gobierno del dato propio en la empresa.
Esa misma página avisa de que la Graph API 13.0 endureció qué combinaciones valen: un evento con solo geografía y agente de usuario se rechaza.
Calidad de la coincidencia de eventos: qué la sube
Es una puntuación sobre 10, según la API de calidad del conjunto de datos, de lo bien que tus datos de cliente casan eventos con una cuenta de Meta. Solo los eventos casados sirven para atribución y optimización de entrega, así que no es cosmética.
Sube al añadir identificadores válidos como email e IP, al compartir la clave de deduplicación, al pasar de IPv4 a IPv6 y al hacer que la IP de tu servidor coincida con la que ve el píxel. Baja cuando no respetas el consentimiento, porque sin él no deberías mandar esos parámetros. El criterio de consentimiento previo se gestiona en la capa de etiquetas, como explicamos en control del consentimiento en el contenedor de etiquetas.
CodeZone Pro Tip: genera el `event_id` una sola vez por pedido y reutilízalo en el píxel y en el servidor, para que Meta deduplique en lugar de contar la misma compra dos veces.
import { createHash } from 'node:crypto';
// Normalizamos antes de hashear: Meta compara hashes, asi que "Ana@Mail.com "
// y "ana@mail.com" deben producir exactamente el mismo digest.
const sha256 = (v) => createHash('sha256').update(v, 'utf8').digest('hex');
const email = (v) => sha256(v.trim().toLowerCase());
const tel = (v) => sha256(v.replace(/\D/g, '').replace(/^0+/, ''));
export function payloadCompra(pedido, nav) {
return {
data: [{
event_name: 'Purchase',
// Unix en segundos. El mismo valor que ya usa el pixel en el navegador.
event_time: Math.floor(pedido.confirmadoEn.getTime() / 1000),
// Clave de deduplicacion derivada del id de pedido, nunca aleatoria,
// para que un reintento del webhook no genere un evento nuevo.
event_id: `purchase-${pedido.id}`,
action_source: 'website',
event_source_url: pedido.urlConfirmacion,
user_data: {
em: [email(pedido.email)],
ph: [tel(pedido.telefono)],
country: [sha256(pedido.paisIso2.toLowerCase())],
// Estos cuatro van en claro: hashearlos los invalida.
client_ip_address: nav.ip,
client_user_agent: nav.userAgent,
fbp: nav.fbp,
fbc: nav.fbc,
},
// El importe cobrado, no el del carrito: es lo que optimiza Meta.
custom_data: { currency: pedido.moneda, value: pedido.importeCobrado },
}],
};
}La consecuencia de negocio es directa. Con el `event_id` derivado del pedido, un reintento del webhook de tu pasarela no infla las conversiones, y el importe que optimiza Meta es el cobrado y no el del carrito. Dejas de pujar por compras que no existieron, que es la base de cualquier analítica de ecommerce que sirva para escalar.
Los Errores que Rompen la Deduplicación
Cuatro fallos explican casi todos los casos que vemos. Generar el `event_id` por separado en navegador y servidor, con lo que Meta recibe dos eventos y cuenta dos. Enviar solo desde servidor, perdiendo los parámetros de navegador. Mandar email o teléfono sin hashear o sin normalizar, que equivale a no mandarlos. E ignorar el consentimiento, que convierte un problema de medición en uno legal.
Antes de tocar presupuesto, comprueba en el gestor de eventos que la compra aparece una sola vez y que la coincidencia se mueve al añadir parámetros. Esto aguanta mejor cuando la medición entra desde el principio, como en cualquier integración de sistemas empresariales en Madrid. Si panel y negocio no cuadran, el diagnóstico está en por qué los paneles no cuadran con el CRM, y el cierre del círculo en la unión de GA4 con la venta registrada.
Si sospechas que cuentas compras dos veces o que tu coincidencia está baja, revisamos tu integración de Conversions API con tus eventos reales antes de proponerte cambios.
