Pixel + CAPI bien configurados: deduplicación y Event Match Quality

Para no duplicar eventos y subir Event Match Quality necesitás Pixel (browser) y Conversions API (server) mandando el mismo evento con el mismo event_id, más customer info usable en CAPI, y verificación en Events Manager. Si solo tenés el Pixel o mandás CAPI sin dedup, Meta ve dos compras (o ninguna limpia) y la señal que usa para optimizar se ensucia.

Esto no es el checklist de tracking antes de escalar: aquel te dice qué tiene que estar vivo. Acá hablamos de cómo Pixel + CAPI trabajan juntos sin inflar conversiones.

¿Por qué necesito Pixel y CAPI juntos?

El Pixel vive en el navegador: cookies, clics, páginas vistas. Cada vez más se corta por ITP, adblock y restricciones de iOS. CAPI manda el mismo evento desde tu servidor (o middleware) con datos del pedido y del cliente. Juntos cubren lo que cada uno pierde solo.

Pixel solo: perdés eventos que el browser no dispara. CAPI solo: perdés contexto de sesión y a veces el match con el anuncio. El setup sano es las dos vías en paralelo, no reemplazar una por la otra. ## ¿Cómo evito duplicar eventos (event_id)?

Deduplicación = Meta recibe el mismo Purchase (o Lead, AddToCart) por browser y por server y los fusiona en un evento. La clave es:

1. Mismo nombre de evento en Pixel y en CAPI (Purchase, no purchase vs Compra).
2. Mismo event_id generado una vez (idealmente en el checkout / thank-you) y reutilizado en el Pixel y en el payload de CAPI.
3. Misma ventana temporal razonable: no mandar el server event horas después sin el mismo id.

Si el Pixel dispara Purchase y CAPI dispara otro Purchase sin el mismo event_id, Meta cuenta dos. Si solo mandás CAPI “por las dudas” sin alinear ids, el Ads Manager se infla y después no te cuadran las ventas reales (el problema de por qué no cuadran Meta y el backend empeora).

Práctica: generá el event_id en el servidor al confirmar el pedido, pasalo al front para el Pixel y usalo otra vez en la llamada CAPI. Un id por evento, no un uuid nuevo en cada hop.

¿Qué es Event Match Quality y cómo lo mejoro?

Event Match Quality (EMQ) es la lectura de Meta sobre qué tan bien puede asociar tu evento a una persona en su grafo. No es un “score mágico de conversión”; es calidad de match. Cuanta más info confiable mandás (hasheada según docs de Meta), mejor puede atribuir y optimizar.

Prioridad práctica en CAPI (cuando la tengas y el consentimiento lo permita):

• Email y/o teléfono del comprador (normalizados y hasheados como pide Meta)
• fbp / fbc si están disponibles (conectan con el clic del anuncio)
• External id estable de cliente, ciudad/CP, nombre cuando aporte
• Valor y moneda coherentes con el pedido real

Mejor pocos campos limpios (hasheados bien) que relleno inventado. El evento que optimizás (Purchase, no PageView) es el que debe llevar la customer info rica.

¿Cómo verifico que la config está bien en Events Manager?

En Events Manager mirá, para el evento crítico (casi siempre Purchase):

• Eventos recibidos por Browser y por Server
• Indicación de deduplicación (no dos compras por cada venta real)
• Diagnósticos de EMQ / parámetros faltantes (email, phone, fbp, etc.)
• Test events / payload de prueba antes de tocar producción a lo loco

Compará 20–50 pedidos reales de un día contra lo que muestra Meta: si ves ~2× compras en Ads Manager vs backend, casi seguro falla el event_id. Si ves menos eventos que ventas, falla cobertura (Pixel bloqueado o CAPI sin disparar).

¿Qué hago esta semana si ya pasé el checklist de tracking?

1. Confirmá que Purchase (o tu evento de optimización) sale por Pixel y por CAPI.
2. Generá un event_id único por conversión y usalo en ambas vías.
3. Enriquecé CAPI con email/phone/fbp-fbc reales del pedido.
4. En Events Manager: dedup OK + parámetros faltantes en baja.
5. Recién ahí pensá en escalar sin romper el aprendizaje: budget arriba con señal sucia solo amplifica el error.

Esta semana: limpiá la señal

1. Anotá si hoy Purchase llega solo por browser, solo por server, o por ambos.
2. Implementá o auditá event_id compartido en el thank-you / webhook.
3. Sumá customer info limpia al payload CAPI (sin inventar).
4. Verificá dedup y EMQ en Events Manager con pedidos reales.
5. Congelá subidas fuertes de presupuesto hasta que la señal deje de duplicar o perder eventos.

Pixel + CAPI bien alineados no reemplazan oferta ni creativo, pero son el piso para que Meta deje de optimizar sobre ruido. Si querés revisar deduplicación y EMQ con tu stack (Shopify, Woo, GTM o middleware), en Clica lo vemos con el equipo.