Meta Conversions API: setup paso a paso y dedup con Pixel

Por qué CAPI ya no es opcional en 2026

Cuando Apple lanzó iOS 14.5 en abril de 2021 con App Tracking Transparency, Meta perdió de golpe la capacidad de medir buena parte del tráfico móvil que generaban sus propios anuncios. El Pixel del navegador siguió funcionando, pero con un agujero estructural: cualquier evento disparado desde Safari iOS sin consentimiento ATT no puede asociar el clic en el anuncio con la conversión posterior. Cinco años después, esa pérdida sigue ahí, ampliada por Safari ITP (que borra cookies first-party a los 7 días sin interacción), por la expansión de ad blockers (DuckDuckGo, Brave, extensiones de uBlock) y por el endurecimiento de las políticas de cookies third-party en todos los navegadores.

La respuesta de Meta fue Conversions API: en lugar de depender del navegador del usuario, el evento se envía desde tu servidor directamente a la Graph API de Meta. Tu backend ve el lead cuando se crea, captura el fbclid de la URL original, hashea email y teléfono, y empuja todo a graph.facebook.com/v22.0/{pixel_id}/events. El evento llega aunque el usuario tenga un ad blocker. Llega aunque Safari haya borrado el _fbp. Llega aunque iOS 14.5+ haya bloqueado el Pixel del navegador completamente.

El error típico en 2026 es uno de los dos extremos. Cuentas que no han activado CAPI y siguen viendo cómo el reporting cae trimestre a trimestre sin entender por qué. O cuentas que activaron CAPI sin dedup correcto y ahora cuentan cada conversión dos veces, sesgan el CPA reportado a la baja artificialmente, y el algoritmo de Meta optimiza con señal duplicada.

Las dos situaciones se ven en la pestaña Overview de Events Manager. Si tu reparto entre Browser, Server y Browser+Server tiene desequilibrios grandes (más del 60 % en una sola categoría), hay un problema técnico que arreglar antes de optimizar nada más.

Lo que pierde un Pixel sin Conversions API

En auditorías de cuentas que llegan a VIDIKA con Pixel solo, sin CAPI, encontramos pérdidas consistentes en cuatro vectores:

1. Tráfico iOS sin consentimiento ATT

Apple obliga a cada app (incluida Meta Ads y la web Mobile Safari) a pedir consentimiento explícito antes de hacer cross-app tracking. El opt-in agregado se sitúa entre el 20 y el 35 % según vertical. El resto del tráfico iOS (entre 65 y 80 %) genera eventos Pixel sin información atribuible al clic. Meta no puede asociar el evento a la subasta original y la conversión queda fuera del aprendizaje del algoritmo.

2. Ad blockers y privacy-first browsers

Brave bloquea el Pixel por defecto. DuckDuckGo igual. Las extensiones uBlock Origin, AdBlock Plus y Privacy Badger lo bloquean en Chrome y Firefox. Según estudios sectoriales, entre un 15 y un 25 % de los usuarios B2B y entre un 8 y un 12 % de los usuarios B2C llevan algún tipo de bloqueo activo. Esos eventos no salen del navegador. Llegan al server (el formulario sí se envía), pero Meta no los ve porque el Pixel no disparó.

3. Cookies borradas por Safari ITP

Safari ITP (Intelligent Tracking Prevention) borra cookies first-party a los 7 días si no hay interacción nueva. La cookie _fbp que identifica al navegador desaparece. Si el usuario vuelve más tarde y completa el formulario, el Pixel dispara con un _fbp nuevo, distinto al del clic original. Meta no puede unir ambos eventos y atribuye la conversión a "tráfico orgánico" o la pierde directamente.

4. Errores intermitentes de red en el cliente

El Pixel es JavaScript. Si la conexión del usuario se cae justo cuando se dispara el fbq('track','Lead'), el evento no llega. Si el cliente cierra la pestaña antes de que el script termine, tampoco. En entornos con conectividad pobre (móvil 3G en zonas rurales, congestión de WiFi en eventos) este vector aporta entre un 3 y un 8 % adicional de pérdida.

Sumados, los cuatro vectores producen pérdidas observadas del 30-50 % del volumen real de conversiones en cuentas medianas. Esa diferencia es la que recupera CAPI. No la recupera al 100 % (CAPI también tiene límites de match cuando el user_data es pobre), pero sí entre el 60 y el 85 % de lo que el Pixel solo no veía.

Cómo es el dedup mal hecho (y por qué duplicas)

El error más común cuando un equipo activa CAPI por primera vez es no implementar el dedup. Meta dedupea eventos cuando coincide event_name + event_id entre Pixel y CAPI dentro de una ventana de 7 días. Si no envías un event_id propio, Meta genera uno automáticamente para cada lado por separado, y los dos eventos se cuentan como independientes.

Síntomas operativos del dedup mal hecho:

• El número total de Leads en Events Manager se dispara entre un 30 y un 80 % cuando activas CAPI. Si el negocio no ha cambiado, eso significa duplicación, no captación nueva.
• El CPA reportado baja artificialmente. Tu cuenta empieza a parecer una mina de oro en panel, pero la facturación real no se mueve.
• El algoritmo de subasta empieza a pujar más agresivamente porque ve doble señal. El CPC real sube, el CPA real sube, pero el reportado en panel sigue mintiendo.

El dedup correcto requiere tres condiciones simultáneas:

1. event_id propio compartido. Generas un UUID en el cliente cuando ocurre el evento. Pasas ese mismo UUID al Pixel como eventID y a CAPI como event_id.
2. event_name idéntico. Si el Pixel dispara Lead y CAPI envía Purchase, Meta no dedupea (son eventos distintos).
3. event_time cercano. Meta acepta hasta 7 días de ventana, pero idealmente envías el evento CAPI dentro de los primeros minutos del Pixel. Si tu pipeline batchea los eventos del día y los envía a medianoche, el dedup sigue funcionando pero pierdes velocidad de aprendizaje del algoritmo.

Setup paso a paso: las 4 piezas

Una implementación CAPI completa tiene cuatro piezas trabajando en paralelo. Ninguna sustituye al resto.

Pieza 1: Pixel del navegador

El Pixel sigue siendo necesario. Lo que cambia es cómo se dispara: incluyes eventID en el segundo argumento de fbq('track', ...). Ejemplo de un evento Lead disparado desde un formulario:

const eventId = crypto.randomUUID();

fbq('track', 'Lead', {
  currency: 'EUR',
  value: 1.00,
  content_name: 'Formulario landing'
}, {
  eventID: eventId
});

// Y enviamos el mismo eventId al server-side
fetch('/api/capi-event', {
  method: 'POST',
  body: JSON.stringify({ event_id: eventId, ...formData })
});

El eventID en el Pixel y el event_id en el payload server-side son la misma cadena. Eso es lo que permite a Meta dedupear.

Pieza 2: Endpoint server-side

Necesitas un endpoint propio que reciba el payload del cliente (event_id, datos del lead, fbp y fbc) y llame al endpoint de Meta. La estructura mínima del payload que envías a la Graph API:

POST https://graph.facebook.com/v22.0/{PIXEL_ID}/events
Headers: Authorization: Bearer {SYSTEM_USER_TOKEN}

{
  "data": [{
    "event_name": "Lead",
    "event_time": 1715680800,
    "event_id": "uuid-compartido-con-pixel",
    "action_source": "website",
    "event_source_url": "https://tu-landing.com/?fbclid=...",
    "user_data": {
      "em": ["sha256(email_normalizado)"],
      "ph": ["sha256(telefono_E164)"],
      "fbp": "fb.1.{ts}.{rand}",
      "fbc": "fb.1.{ts}.{fbclid}",
      "client_ip_address": "1.2.3.4",
      "client_user_agent": "Mozilla/5.0..."
    },
    "custom_data": {
      "currency": "EUR",
      "value": 1.00
    }
  }],
  "access_token": "{SYSTEM_USER_TOKEN}"
}

Pieza 3: System User Access Token

El token que usas para llamar a la API debe ser de un System User, no de una persona física. Los tokens de usuario caducan a los 60 días y rotan con el login. Los tokens de System User no caducan mientras el System User exista y tenga permisos sobre la app y la cuenta publicitaria. Se generan desde Business Manager → System Users → Generate Token, con permisos ads_management y opcionalmente ads_read.

Pieza 4: Verificación en Test Events

Antes de poner en producción, Events Manager tiene una pestaña Test Events donde puedes simular eventos y ver el resultado. Lanza un evento real desde la landing y verifica:

• Aparecen ambos lados (Browser + Server).
• El badge muestra Deduplicated.
• El Event Match Quality es superior a 7.
• Los parámetros user_data que aparecen están correctos (Meta los muestra hasheados pero al menos sabes que llegaron).

El event_id compartido entre Pixel y CAPI

Esta es la pieza más confundida. El event_id es solo un identificador único para el dedup, no un identificador del lead ni del usuario. Tres reglas operativas:

• UUID por evento, no por usuario. Cada vez que el usuario hace una acción nueva (segundo lead en sesión, segundo purchase), generas un UUID nuevo. No reutilizas el mismo entre eventos.
• Generado en el cliente, no en el server. Si lo genera el server después de recibir el formulario, el Pixel ya disparó con otro UUID antes. Tienen que coincidir, así que se genera en el cliente antes de disparar el Pixel y se envía al server adjunto al resto de datos.
• Persiste durante el ciclo del evento, no más. No guardes el UUID en localStorage para reutilizarlo. Cada evento es independiente.

En la práctica, el patrón limpio en JavaScript es:

function trackLead(formData) {
  const eventId = crypto.randomUUID();

  // 1. Dispara Pixel con eventID
  if (window.fbq) {
    fbq('track', 'Lead', {
      currency: 'EUR',
      value: 1.00
    }, { eventID: eventId });
  }

  // 2. Envía al server-side con el mismo eventId
  return fetch('/api/capi/lead', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      event_id: eventId,
      email: formData.email,
      phone: formData.phone,
      fbp: getCookie('_fbp'),
      fbc: getCookie('_fbc')
    })
  });
}

Cómo hashear user_data correctamente

Meta especifica un formato concreto para cada campo antes de aplicar el SHA-256. Si te saltas la normalización, el hash es distinto al que Meta calcula del lado clic, y el match falla silenciosamente. El error es el más común en cuentas auditadas: la implementación parece correcta, pero el Event Match Quality nunca pasa de 4 porque algún campo se hashea con formato distinto.

Normalizaciones obligatorias antes del hash:

• Email: minúsculas, sin espacios al principio o final. sha256("juan.perez@gmail.com".trim().toLowerCase()).
• Teléfono: formato E.164 sin el símbolo +, sin espacios, sin guiones, sin paréntesis. Un número español 634 12 34 56 se normaliza a 34634123456 y luego se hashea. NO se hashea +34 634 12 34 56.
• Nombre y apellido: minúsculas, sin acentos, sin espacios. Juan → juan. Pérez → perez.
• Ciudad: minúsculas, sin acentos, sin espacios. Bilbao → bilbao. San Sebastián → sansebastian.
• Código postal: solo dígitos (o letras en países donde aplique, pero sin guiones). 28029 se queda como 28029.
• País: código ISO 3166-1 alpha-2 en minúsculas. España → es. Perú → pe.

Campos que NO se hashean (van en claro al server, Meta los procesa internamente):

• client_ip_address
• client_user_agent
• fbp, fbc, fb_login_id
• lead_id (si lo usas)

5 errores que vemos en cuentas auditadas

Patrones recurrentes en las cuentas que llegan a VIDIKA pidiendo revisión de su Meta Ads:

1. event_id generado en el server después de recibir el formulario

El Pixel ya disparó con un UUID propio (o sin él) cuando el usuario llega al "Gracias". Tu server genera un UUID nuevo y lo envía a CAPI. Resultado: los dos eventos llegan a Meta con event_id distintos. No hay dedup, hay duplicación. Fix: generar el UUID en JavaScript antes del Pixel y reenviarlo al server.

2. fbp y fbc no se envían al server

El equipo de backend asume que CAPI funciona solo con email y teléfono. Sin las cookies _fbp y _fbc Meta tiene mucho peor match rate porque pierde la unión navegador-anuncio que sí tenía el Pixel. Fix: el cliente lee document.cookie, extrae _fbp y _fbc, y los pasa al server con cada evento.

3. Token de usuario en lugar de System User

El token se generó desde el Graph API Explorer con la cuenta personal del developer. Caducó a los 60 días, los webhooks empezaron a devolver 401, nadie se enteró durante semanas. Fix: System User con token que no caduca, monitoreo del endpoint para alertar si Meta devuelve error.

4. event_name distinto entre Pixel y CAPI

Pixel dispara Lead y server-side envía SubmitApplication. Meta no dedupea porque considera que son eventos diferentes. Fix: mismo event_name exacto en ambos lados. Si quieres distinguir tipos de lead, usa custom_data.content_category, no inventes nombres distintos.

5. user_data sin normalización antes del hash

Email se hashea con mayúsculas. Teléfono se hashea con espacios. Ciudad se hashea con acentos. Meta hashea internamente con la normalización oficial, los hashes no coinciden, y el match rate se queda en 30-40% cuando debería estar por encima del 85%. Fix: aplicar las normalizaciones de la sección anterior antes de cada SHA-256.

Cómo lo resolvemos en VIDIKA con WinTracker

En VIDIKA llevamos haciendo CAPI server-side para nuestros clientes desde 2024. Lo hicimos primero a mano, cliente por cliente, hasta que vimos que el patrón era el mismo en todos: capturar lead → hashear user_data → generar event_id compartido → enviar a CAPI con fbp/fbc → registrar match rate. Lo extrajimos en una pieza interna que llamamos WinTracker.

WinTracker es nuestra plataforma propia de atribución end-to-end. Captura el lead en la landing (junto con GCLID, fbclid, UTMs, GBRAID, TTCLID), lo persiste con un identificador único, dispara los pixels del lado cliente con event_id compartido, y reenvía el mismo evento server-side a Meta Conversions API, Google Ads Conversion Upload API, TikTok Events API y LinkedIn CAPI. Cuando el CRM del cliente marca la venta cerrada, WinTracker dispara también los eventos de Purchase con el valor real, hasheando user_data con la normalización oficial de cada plataforma.

Lo construimos primero para nosotros. En 2026 lo usan también los clientes de VIDIKA en operaciones de telco, salud, B2B y SaaS. Próximamente lo lanzamos como producto independiente en wintracker.es. La auditoría gratuita ya incluye una mirada al estado de tu CAPI usando los mismos checks que aplicamos internamente.

Preguntas frecuentes

¿Tengo que mantener el Pixel si activo Conversions API?

Sí. CAPI no sustituye al Pixel, lo complementa. El Pixel sigue siendo necesario para tracking del lado cliente, y CAPI envía el mismo evento desde el server cuando el Pixel del navegador podría haberse bloqueado (iOS 14.5+, Safari ITP, ad blockers). La combinación dedupeada da el match rate completo.

¿Cómo evito que un evento se cuente dos veces si lo envío por Pixel y por CAPI?

Con un event_id compartido. Generas un UUID en el cliente cuando ocurre el evento, lo pasas al Pixel como parámetro eventID, y lo envías también al payload server-side a CAPI como event_id. Meta dedupea cuando coinciden event_name + event_id + fbp/fbc dentro de 7 días.

¿Qué campos de user_data hay que hashear y cuáles no?

Hay que hashear con SHA-256: email, teléfono (formato E.164), fn, ln, ct, st, zp, country, ge, db, external_id. NO se hashean: client_ip_address, client_user_agent, fbp, fbc, fb_login_id, lead_id. La normalización previa (minúsculas, sin acentos, E.164 sin +) es obligatoria; si te la saltas, el hash no coincide con el de Meta y el match falla.

¿Qué es fbp y fbc, y de dónde los saco para enviarlos al server?

Son dos cookies que pone el Pixel del navegador. fbp identifica el navegador (persiste 90 días). fbc guarda el fbclid del último clic en un anuncio Meta. Las lees con document.cookie en JavaScript y las pasas al server con cada evento. Sin ellas, el match rate cae mucho.

¿Qué match rate es razonable y cómo lo veo?

En Events Manager, cada evento muestra el Event Match Quality (EMQ) del 0 al 10. Por encima de 8 está bien. Por debajo de 6 hay margen de mejora. El reparto Browser/Server/Browser+Server lo ves en la pestaña Overview: "Browser + Server" alto es lo que quieres.

¿Cuándo se nota el efecto en optimización y costes?

Semanas 1-2: el reporting de conversiones sube 15-40% (señal que antes se perdía por iOS y ad blockers). Semanas 3-4: el algoritmo de subasta empieza a tener más señal y el CPA reportado mejora 10-25%. Mes 2-3: si subes Purchase con valor real en lugar de Lead simple, Smart Bidding optimiza por leads que cierran venta. Es ahí donde se nota en facturación, no solo en panel.

Sigue leyendo en el cluster de atribución