{"id":1099,"date":"2026-09-26T08:57:16","date_gmt":"2026-09-26T11:57:16","guid":{"rendered":"https:\/\/clica.agency\/blog\/?p=1099"},"modified":"2026-09-28T17:28:27","modified_gmt":"2026-09-28T20:28:27","slug":"pixel-meta-capi-deduplicacion-event-match-quality","status":"publish","type":"post","link":"https:\/\/clica.agency\/blog\/pixel-meta-capi-deduplicacion-event-match-quality\/","title":{"rendered":"Pixel + CAPI bien configurados: deduplicaci\u00f3n y Event Match Quality"},"content":{"rendered":"

Para no duplicar eventos y subir Event Match Quality necesit\u00e1s Pixel (browser) y Conversions API (server) mandando el mismo evento con el mismo event_id<\/code>, m\u00e1s customer info usable en CAPI, y verificaci\u00f3n en Events Manager.<\/strong> Si solo ten\u00e9s el Pixel o mand\u00e1s CAPI sin dedup, Meta ve dos compras (o ninguna limpia) y la se\u00f1al que usa para optimizar se ensucia.<\/p>\n

Esto no es el checklist de tracking antes de escalar<\/a>: aquel te dice qu\u00e9 tiene que estar vivo. Ac\u00e1 hablamos de c\u00f3mo<\/strong> Pixel + CAPI trabajan juntos sin inflar conversiones.<\/p>\n

\u00bfPor qu\u00e9 necesito Pixel y CAPI juntos?<\/h2>\n

El Pixel vive en el navegador: cookies, clics, p\u00e1ginas vistas. Cada vez m\u00e1s 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.<\/p>\n

Pixel solo: perd\u00e9s eventos que el browser no dispara. CAPI solo: perd\u00e9s contexto de sesi\u00f3n y a veces el match con el anuncio. El setup sano es las dos v\u00edas en paralelo<\/strong>, no reemplazar una por la otra. ## \u00bfC\u00f3mo evito duplicar eventos (event_id)?<\/p>\n

Deduplicaci\u00f3n = Meta recibe el mismo Purchase (o Lead<\/a>, AddToCart) por browser y por server y los fusiona en un<\/strong> evento. La clave es:<\/p>\n

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

    Si el Pixel dispara Purchase y CAPI dispara otro Purchase sin<\/strong> el mismo event_id<\/code>, Meta cuenta dos. Si solo mand\u00e1s CAPI \u201cpor las dudas\u201d sin alinear ids, el Ads Manager se infla y despu\u00e9s no te cuadran las ventas<\/a> reales (el problema de por qu\u00e9 no cuadran Meta y el backend<\/a> empeora).<\/p>\n

    Pr\u00e1ctica: gener\u00e1 el event_id<\/code> 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.<\/p>\n

    \u00bfQu\u00e9 es Event Match Quality y c\u00f3mo lo mejoro?<\/h2>\n

    Event Match Quality (EMQ) es la lectura de Meta sobre qu\u00e9 tan bien puede asociar tu evento a una persona en su grafo. No es un \u201cscore m\u00e1gico de conversi\u00f3n\u201d; es calidad de match<\/strong>. Cuanta m\u00e1s info confiable mand\u00e1s (hasheada seg\u00fan docs de Meta), mejor puede atribuir y optimizar.<\/p>\n

    Prioridad pr\u00e1ctica en CAPI (cuando la tengas y el consentimiento lo permita):<\/p>\n