Cada venta contada dos veces: la deduplicación rota entre el píxel y la API de conversiones

Meta recomienda enviar los mismos eventos por dos vías: el píxel, desde el navegador, y la API de conversiones (CAPI), desde el servidor. Si una de las dos falla (un bloqueador de anuncios, una cookie rechazada, una página de confirmación que no llega a cargar), la otra cubre el hueco. Pero esa redundancia tiene una condición: Meta tiene que saber que el Purchase del navegador y el del servidor son la misma compra. Si no puede emparejarlos, se queda con los dos.

Cómo se ve una compra duplicada en Meta

Se confirma un pedido y llegan a Meta dos eventos Purchase: uno con la conexión del navegador y otro con la del servidor. Como cada uno lleva un identificador distinto, Meta no los fusiona. Los síntomas típicos:

• Las compras de Events Manager y de Ads Manager superan claramente a los pedidos reales del backend, a veces casi el doble.
• El ROAS y el coste por compra mejoran de golpe tras activar la API de conversiones, sin que las ventas hayan cambiado.
• Las campañas optimizan sobre conversiones que no existen, y las audiencias de compradores se llenan de duplicados.

Por qué Meta no deduplica el evento

Meta deduplica un evento del navegador y uno del servidor cuando coinciden dos pares de claves: el eventID del píxel con el event_id de la API de conversiones, y el nombre del evento del píxel con el event_name del servidor. Además, tienen que llegar al mismo píxel en un plazo de 48 horas desde el primero. Si coinciden, Meta descarta el que llega después. Si falla cualquiera de esas condiciones, cuenta los dos. Las causas más frecuentes:

• Cada lado genera su propio ID. El navegador crea un identificador aleatorio y el servidor, otro. Es el caso más habitual: los dos eventos llevan ID, pero nunca coinciden.
• El píxel no envía el eventID, o lo envía mal. Va en el cuarto argumento de fbq, no dentro de los parámetros del evento: fbq('track', 'Purchase', {value: 49.90, currency: 'EUR'}, {eventID: 'T-10482'}). Si se mete en el tercer objeto, viaja como un parámetro personalizado más, no como la clave de deduplicación.
• El ID se pierde por el camino. En configuraciones con GTM web y GTM server-side, el contenedor web genera el ID para el píxel, pero no lo pasa en la petición al servidor, y la etiqueta de la API de conversiones crea uno nuevo.
• El nombre del evento no coincide. Por ejemplo, Purchase en el píxel y un evento personalizado en el servidor: aunque el ID sea el mismo, para Meta son eventos distintos.
• El evento del servidor llega más de 48 horas tarde. Fuera de esa ventana, Meta ya no deduplica.

Existe un método alternativo que empareja por fbp o external_id en lugar de por ID de evento, pero tiene límites: en general solo funciona cuando el evento del navegador llega antes que el del servidor, y no deduplica cuando solo hay una fuente. No conviene apoyarse en él para las compras.

Cómo encontrar la compra duplicada

1. En Events Manager, abre el conjunto de datos del píxel, entra en Overview y abre los detalles del evento Purchase. En la pestaña Event Deduplication, revisa el porcentaje de eventos deduplicados y el uso de las claves de deduplicación por fuente. Un solapamiento bajo indica que las claves no coinciden o que solo una fuente las envía; Meta muestra un aviso cuando la tasa de deduplicación es demasiado baja.
2. Compara las compras de Events Manager de un día con los pedidos del backend del mismo día. Si las de Meta se acercan al doble, el duplicado es casi seguro.
3. Haz una compra de prueba. En las herramientas de desarrollo, pestaña Red, filtra por facebook.com/tr y busca el parámetro eid de la petición Purchase: es el eventID del píxel. Compáralo con el event_id que envía el servidor, en sus logs o en la vista previa de GTM server-side.
4. Si usas la herramienta Test events de Events Manager, comprueba que el Purchase del navegador y el del servidor llevan el mismo ID.

Cómo enviar un único ID desde el píxel y el servidor

La regla es una: el ID se crea una sola vez y viaja a los dos lados.

• Para compras, usa un identificador que ya exista y que conozcan los dos: el número de pedido o de transacción. Es lo que sugiere la propia documentación de Meta.
• Para eventos sin un identificador natural (un Lead, un AddToCart), genera un valor aleatorio en el navegador y envíalo también al servidor: en el dataLayer, en la petición a GTM server-side o en la llamada a tu backend. Meta admite un valor aleatorio siempre que sea el mismo en el navegador y en el servidor.
• Usa exactamente el mismo nombre de evento en los dos lados.
• Envía el evento del servidor en el momento, no horas después, para quedarte siempre dentro de las 48 horas.

Documentación de Meta sobre la deduplicación de eventos del píxel y de la API de conversiones y sobre los parámetros del evento de servidor (en inglés).

Cómo comprobar que cada compra cuenta una vez

• En una compra de prueba, el eid de la petición del píxel y el event_id del servidor son idénticos, y el nombre del evento también.
• En la pestaña Event Deduplication, el porcentaje de eventos deduplicados y el solapamiento de claves suben en los días siguientes.
• Las compras de Events Manager vuelven a una distancia razonable de los pedidos del backend. Los eventos ya duplicados no se corrigen: si comparas periodos, anota la fecha del cambio.

Los ID, las cifras y los valores del ejemplo son ilustrativos. Los nombres de las pestañas de Events Manager son los de la interfaz en inglés.