La propia guía de Meta, publicada en la página de inicio de la API de Conversiones (consultada el 2026-05-12), enmarca el píxel del navegador como un complemento de CAPI, no al revés. Ese cambio ocurrió alrededor de iOS 14.5: App Tracking Transparency redujo la calidad de la señal de Meta, ITP se comió otra porción y las instalaciones de bloqueadores de anuncios siguieron subiendo. Para 2026, los equipos que ejecutan anuncios de Meta contra audiencias intensivas en iOS están viendo rutinariamente el 30-40% de los eventos de conversión desaparecer antes de llegar a los informes.
CAPI es el canal del lado del servidor que pasa por encima de todo. Tu servidor habla directamente con la API de gráfico de Meta. ITP no se aplica. Los bloqueadores de anuncios no lo interceptan. La tasa de coincidencia sube porque puedes enviar correo y teléfono hasheados junto con el identificador de clic; debido a que tanto el evento del navegador como el del servidor comparten una clave de deduplicación, Meta cuenta la conversión una vez incluso cuando ambas rutas se disparan.
Este es el paso a paso para cablear CAPI a través de los enlaces cortos de Elido. La visión general del seguimiento de conversiones del lado del servidor cubre la arquitectura más amplia (GA4, TikTok, Mixpanel, semántica de reintentos). El tutorial UTM de extremo a extremo vale la pena leerlo primero si tu etiquetado de campaña sigue siendo informal.
TL;DR#
- Meta Pixel pierde el 30-40% de los eventos de conversión en tráfico intensivo en iOS por ITP y bloqueadores de anuncios; CAPI envía esos eventos directamente desde tu servidor, recuperando la mayoría de la brecha.
- La clave de deduplicación -
event_id- debe ser idéntica entre tu píxel del lado del navegador y tu evento CAPI. Faltar esto causa doble conteo, lo que rompe la asignación del presupuesto de optimización de Meta. - Una mayor densidad de claves de coincidencia (correo hasheado, teléfono, ID de clic
fbc, cookiefbp) mejora directamente la tasa de coincidencia de atribución; Elido capturafbcliden el momento del clic y lo asocia con cada conversión aguas abajo. - La validación lleva alrededor de 10 minutos: el Events Manager de Meta tiene un panel Test Events que muestra los eventos CAPI llegando en 30 segundos, mucho antes de que se llene el panel de tasa de coincidencia de 24 horas.
Lo que necesitas antes de empezar#
Tres cosas, todas de Meta Business Manager.
Pixel ID. Cada cuenta de anuncios de Meta tiene al menos un píxel. Encuéntralo en Events Manager bajo Data Sources. La cadena numérica - algo como 1234567890 - es lo que pegarás en la configuración de integración de Elido.
Token de acceso de System User. Esta es la credencial que autoriza a Elido a escribir eventos en tu píxel. Navega a Business Settings, luego Users, luego System Users. Crea un system user con acceso Standard, asígnalo al píxel (Manage permissions), y genera un token con los alcances ads_management y business_management. El token es de larga duración; rótalo cuando rotes otras credenciales de servicio, no en un horario. Almacénalo como un secreto de workspace - no en el código fuente, no en una hoja de cálculo.
Patrón de URL de fuente de evento. Cada evento CAPI lleva un event_source_url que le dice a Meta en qué página ocurrió la conversión. Para eventos de compra, esto suele ser la URL de confirmación de tu checkout. Para eventos de lead, es la página de envío del formulario. No los codificas; vienen del webhook de tu pedido o del contexto de solicitud de tu backend en el momento de la conversión.
Las claves de coincidencia: por qué importa la densidad#
Meta deduplica y empareja eventos de servidor con sesiones del navegador usando un conjunto de parámetros de información del cliente. Cuantos más envíes, mayor será la tasa de coincidencia. Una mayor tasa de coincidencia significa más conversiones atribuidas a tus campañas, lo que significa que el algoritmo de optimización tiene mejor señal, lo que significa mejor ROAS. La relación es directa.
Las cuatro claves que más importan:
em (correo hasheado SHA-256). La señal de mayor valor. Si tienes el correo del cliente en el momento de la conversión (casi siempre lo tienes para ecommerce), envíalo. La referencia de parámetros de información del cliente de Meta (consultada el 2026-05-12) especifica las reglas de normalización: minúsculas, recortado de espacios al inicio/final, sin modificaciones al dominio. Hashea la cadena normalizada. Enviar [email protected] hasheado directamente produce el valor incorrecto; [email protected] es lo que hay que hashear.
ph (teléfono hasheado SHA-256). La misma disciplina de normalización. Formato E.164: código de país, sin espacios, sin guiones, sin paréntesis. +4915123456789 hashea a algo que Meta puede emparejar; 015123456789 no.
fbc (ID de clic de Facebook). Cuando un usuario hace clic en un anuncio de Meta, la URL de destino recibe un parámetro de consulta fbclid. Tu landing page o el manejador de redirección de Elido lo lee y lo almacena. El campo fbc se construye a partir de esto: fb.{version}.{creationTime}.{fbclid}, donde la versión es 1 y el tiempo de creación es la marca de tiempo Unix en milisegundos. Elido captura el fbclid de la URL de redirección en el momento del clic y lo almacena contra el registro de clic. Cuando haces POST de una conversión con un click_id, el valor fbc ya está adjunto y se reenvía automáticamente.
fbp (cookie de píxel del navegador de Facebook). Esta es la cookie _fbp que el JS de Meta Pixel establece en tu dominio. Es una cookie de primera parte desde la perspectiva de tu dominio. Tu servidor la lee de los encabezados de la solicitud en el momento del checkout y la incluye en la carga útil de conversión. Sin ella, la tasa de coincidencia de Meta para la ruta de respaldo del lado del navegador se degrada.
El orden práctico de prioridad: em primero (casi siempre disponible), fbc segundo (Elido lo proporciona para conversiones provenientes de clics), fbp tercero (leído de la cookie en la página de confirmación), ph último (a menudo no capturado). Una carga útil con em + fbc coincidirá significativamente mejor que una con nada.
Cableado en Elido#
La integración vive en Workspace Settings, bajo /integrations, luego Meta CAPI.
Pega tu Pixel ID y el token de acceso de System User. Elido valida el token contra la API de gráfico de Meta inmediatamente - un 400 aquí significa que el token está mal formado o le faltan los alcances requeridos; verifica los permisos del system user antes de proceder. Una vez validado, la integración está activa para el workspace. Todos los enlaces rastreados en el workspace participan; no hay alternancia por enlace.
Cuando se hace clic en un enlace rastreado, el manejador del borde de Elido lee el fbclid de la cadena de consulta (si está presente) y lo escribe en el registro de clic. Esto sucede en la capa de redirección, antes de que el usuario llegue a tu sitio, por lo que la captura es fiable independientemente de si se ejecuta el JavaScript del sitio de destino.
Cuando se dispara un evento de conversión, hazle POST a /v1/conversions:
curl -X POST \
https://api.elido.app/v1/conversions \
-H "Authorization: Bearer $ELIDO_TOKEN" \
-d '{
"click_id": "clk_01HYZ7T8WV6KQX3M",
"event_name": "Purchase",
"event_id": "ord_98231",
"value": 89.50,
"currency": "EUR",
"user": {
"email": "[email protected]",
"phone": "+4915123456789"
}
}'
Al recibirla, Elido busca el registro de clic, lee el fbclid almacenado para construir fbc, normaliza y hashea email y phone, ensambla la carga útil CAPI completa y hace POST a https://graph.facebook.com/v21.0/{pixel_id}/events. La llamada a la API devuelve un ID de conversión inmediatamente; el fan-out a Meta es en segundo plano y observable vía GET /v1/conversions/{id}.
La carga útil CAPI en bruto que construye Elido se ve así:
{
"data": [
{
"event_name": "Purchase",
"event_time": 1747047600,
"event_id": "ord_98231",
"action_source": "website",
"event_source_url": "https://shop.example.com/checkout/thanks?order=98231",
"user_data": {
"em": ["a3b6e2f4...sha256 of [email protected]"],
"ph": ["c7d9f1a3...sha256 of +4915123456789"],
"fbc": "fb.1.1747040000.AbCdEfGhIj",
"fbp": "fb.1.1747040000.987654321",
"client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 ...)",
"client_ip_address": "203.0.113.42"
},
"custom_data": {
"currency": "EUR",
"value": 89.5,
"content_ids": ["sku-spring-jeans-32-blue"],
"content_type": "product",
"num_items": 1
}
}
],
"access_token": "EAAxxxxxxx"
}
Los campos event_source_url y action_source se derivan de la URL de destino del registro de clic y del parámetro source de la solicitud de conversión (por defecto website). Si estás reenviando conversiones del lado de la aplicación, pasa "source": "app" en el cuerpo POST.
Disciplina de deduplicación#
Lee la documentación de deduplicación de eventos de Meta (consultada el 2026-05-12) antes de tocar el tráfico de producción. La versión corta es esta: Meta empareja eventos del píxel del navegador y eventos CAPI usando event_id + event_name dentro de una ventana de 48 horas. Si ambos eventos llevan el mismo par, el segundo se descarta silenciosamente.
El requisito operativo que sigue: el evento Purchase de tu píxel del lado del navegador y tu evento CAPI del lado del servidor deben compartir el mismo event_id. La elección más fiable es tu ID de pedido: ambos lados lo ven, es estable, no se regenera en el reintento.
Donde esto se rompe en la práctica: el servidor genera un UUID en el momento del reenvío en lugar de usar el ID del pedido. O el píxel del navegador usa un esquema de ID (ord_98231) y el backend usa otro (order-98231). Ambos eventos se ingieren. Ninguno se deduplica. Tus conversiones reportadas se duplican. El algoritmo de Meta sobreasigna presupuesto a la campaña basándose en números inflados. La revisión del presupuesto tres semanas después revela "nuestro ROAS es de alguna manera 2,5× nuestro ingreso real" y la forense es desagradable.
El diagrama de secuencia a continuación muestra cómo viaja el event_id a través del sistema:
La llamada al píxel del lado del navegador ocurre del lado del cliente cuando se carga la página de confirmación. El reenvío CAPI del lado del servidor ocurre cuando se dispara el webhook de tu pedido. Ambos deben emitir event_id: ord_98231 (o cualquiera que sea tu identificador de pedido). La brecha de tiempo entre los dos es irrelevante siempre que ambos lleguen dentro de las 48 horas.
Si no estás ejecutando un píxel del lado del navegador (eliminado por razones de consentimiento GDPR, o porque tu audiencia es enteramente intensiva en bloqueadores de anuncios), la deduplicación es discutible. Envía solo CAPI. Pero la mayoría de los equipos ejecutan ambos; el píxel del navegador proporciona señal de respaldo para los usuarios donde los eventos CAPI no pueden llevar claves de coincidencia (sin correo capturado, sin fbclid).
Validación#
El bucle de validación es corto y debería ocurrir antes de que fluya cualquier tráfico de producción.
Paso uno: establece un código de evento de prueba. En la configuración de integración Meta CAPI de Elido, hay un campo de código de evento de prueba. Obtén un código del Events Manager de Meta bajo Test Events. Pégalo. Mientras este código esté establecido, cada evento CAPI que envíe Elido se enruta al panel de prueba - nunca entra en los informes de producción.
Paso dos: dispara una conversión de prueba. Haz clic en uno de tus enlaces rastreados desde un navegador (esto captura el fbclid si la URL del enlace vino de un anuncio de Meta, o de un enlace con fbclid añadido manualmente para pruebas). Haz POST de una conversión contra ese click_id con un ID de pedido realista, valor y dirección de correo.
Paso tres: verifica Test Events. En el Events Manager de Meta, el evento de prueba debería aparecer dentro de 30 segundos. Verifica que el event_name coincida con lo que está enviando tu píxel del navegador. Verifica que el event_id sea el ID del pedido, no un UUID. Verifica que em, fbc o fbp aparezcan en la sección user_data - al menos una clave de coincidencia debería estar presente.
Paso cuatro: elimina el código de evento de prueba. Una vez validado, borra el campo de código de evento de prueba y guarda. Los eventos de producción comienzan a fluir. El panel de tasa de coincidencia en Events Manager tarda 24 horas en llenarse con datos significativos.
Qué buscar en la marca de 24 horas: tasa de coincidencia por encima del 60% es viable; por encima del 75% es buena; por encima del 85% significa que tu densidad de claves de coincidencia es alta y la atribución será fiable. Si estás por debajo del 60%, la causa más probable es la falta de fbc (el fbclid no estaba en la URL de aterrizaje) o un error de normalización de hashing.
Modos de fallo comunes#
event_source_url faltante. Los eventos CAPI sin este campo se aceptan pero se penalizan en la lógica de coincidencia de Meta. El campo debería ser la URL de la página donde ocurrió la conversión - tu URL de confirmación de checkout, tu página de aterrizaje del formulario de lead, el equivalente de tu aplicación. Elido lo deriva de la URL de destino del registro de clic cuando no se anula; pásalo explícitamente en el POST de conversión si tu URL de confirmación difiere del destino de redirección.
Clave hasheada no en minúsculas-recortada. [email protected] y [email protected] producen valores SHA-256 diferentes. Los servidores de Meta hashean la forma canónica almacenada en su gráfico de usuario. Si tu hash no coincide, el evento aterriza como no emparejado. El requisito de normalización también se aplica a los números de teléfono: elimina las variaciones de formato del código de país, fuerza E.164. Enrutar a través del endpoint /v1/conversions de Elido significa que la normalización se maneja por ti; pasas el correo y teléfono en bruto, Elido hashea según la especificación.
Desajuste de action_source. Las conversiones originadas en la web usan "action_source": "website". Las conversiones de aplicaciones móviles usan "app". Si estás reenviando una compra que ocurrió en tu aplicación iOS pero envías action_source: "website", el modelo de atribución de Meta puede degradar la señal. Pasa "source": "app" en el POST de conversión de Elido para eventos del lado de la aplicación.
fbc ausente porque fbclid no estaba en la URL. Esto sucede cuando la URL de destino del anuncio no incluye fbclid - ya sea porque la campaña no tiene habilitado "Auto-advanced matching", o porque la URL fue construida a mano sin él, o porque el usuario llegó a través de una ruta de retargeting que no llevaba el parámetro. Cuando falta fbc, la conversión todavía se reenvía, pero la tasa de coincidencia cae a solo correo/teléfono. Verifica la configuración de la campaña en Meta Ads Manager; fbclid debería aparecer en las URLs de destino para campañas de tráfico estándar.
Esquemas dobles de event_id. El píxel del navegador y el evento CAPI usan formatos diferentes para el mismo ID de pedido. Esto casi siempre sucede cuando diferentes equipos poseen la configuración del tag manager del frontend y la integración del webhook de pedidos del backend. Acuerda un formato canónico antes del lanzamiento. ID de pedido como cadena (ord_98231) funciona. Solo numérico también funciona. El píxel emitiendo "ord_98231" y el servidor emitiendo "98231" se tratan como eventos diferentes: ninguno se deduplica.
Un resultado trabajado#
Una marca de ecommerce con sede en la UE que ejecuta anuncios de Meta en Alemania y Austria reportó una tasa de coincidencia del 38% con seguimiento solo con píxel. Safari en iOS representaba aproximadamente el 45% del tráfico del sitio; las tasas de opt-out de ATT en el grupo demográfico de 25-44 rondaban el 72%.
Después de cablear CAPI a través de Elido con em + fbc como las claves de coincidencia principales, la tasa de coincidencia subió al 76% dentro de la primera semana. fbc estaba ahora presente en cada conversión que se originó de un clic de anuncio de Meta (Elido captura fbclid en la capa de redirección, no en el nivel del navegador), y el reenvío de correo hasheado proporcionó una segunda ruta de coincidencia para conversiones donde la cookie _fbp había expirado.
El CPA cayó un 18% durante las siguientes cuatro semanas. El ROAS reportado se movió de 2,1 a 2,6. La reducción del 18% del CPA refleja una mejor atribución, no un mejor rendimiento de la campaña: las campañas siempre estaban rindiendo a 2,6 ROAS; solo el píxel estaba subreportando.
Dónde se sitúa esto en el pipeline de atribución#
CAPI es un canal en una configuración más amplia de reenvío del lado del servidor. La visión general del seguimiento de conversiones del lado del servidor cubre GA4 Measurement Protocol y TikTok Events API con la misma profundidad que este post aplica a Meta. Atribución sin cookies explicada vale la pena leerlo si quieres el por qué subyacente - ITP, protección de seguimiento de enlaces y los cambios del modelo de atribución que siguieron.
Para la superficie del producto: características de seguimiento de conversiones documenta la API completa, incluidos los eventos de reembolso, modos de atribución multitouch y la semántica de reintentos/backoff. Soluciones para marketers muestra cómo encajan las piezas en un flujo de campaña.
La configuración descrita arriba es alcanzable en una mañana. La inversión principal es tiempo en la validación - 30 minutos en Meta Test Events antes de cambiar el tráfico de producción. Esos 30 minutos valen la pena; la alternativa es descubrir una mala configuración tres días después cuando el algoritmo ya ha actuado sobre los números incorrectos.
Fuentes
- Meta Conversions API: Getting Started. developers.facebook.com/docs/marketing-api/conversions-api/get-started/ (consultado 2026-05-12)
- Meta Conversions API: Deduplicate Pixel and Server Events. developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events/ (consultado 2026-05-12)
- Meta Conversions API: Customer Information Parameters. developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/ (consultado 2026-05-12)
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Gratis, sin registro · 2 por día