Configuraste la Conversions API (CAPI) pensando "ahora sí voy a recuperar lo que iOS y los bloqueadores de anuncios estaban perdiendo" — pero ¿ya confirmaste que los eventos realmente están llegando a Meta desde tu servidor? Puedes creer que CAPI está configurado, y aun así un token de acceso vencido o un servidor que nunca dispara pueden hacer que ni un solo evento esté llegando a Meta. Peor aún: como tu pixel de navegador sigue funcionando, puede parecer que "el tracking en general está bien" — y ese es el caso más difícil de detectar.
¿Te suena alguno de estos síntomas?
- En Events Manager, los eventos de servidor siguen apareciendo como "no recibidos", o el conteo es sospechosamente bajo
- El pixel de navegador aparece, pero no encuentras el evento del lado del servidor por ningún lado
- Te avisan que el Event Match Quality es bajo, pero no sabes por qué
- Desde que agregaste CAPI, tus conteos de conversión parecen haberse duplicado
Esta guía organiza cómo confirmar que CAPI realmente está funcionando, por qué los eventos pueden enviarse desde el servidor y aun así no llegar a usarse, y cómo pensarlo sin adivinar.
Antes de verificar: CAPI no reemplaza al pixel — lo complementa
Empecemos por dejar clara la premisa. CAPI no es un mecanismo que reemplaza al pixel de navegador (el que fbevents.js envía a facebook.com/tr); es un mecanismo que envía eventos directamente a Meta desde tu servidor para complementarlo. El objetivo es cubrir, mediante envíos del lado del servidor, la parte que el pixel de navegador pierde por ITP, bloqueadores de anuncios, pérdida de señal en iOS, etc.
Justo por eso, lo que necesitas verificar es distinto a una configuración de solo pixel. Separar estos tres niveles hace el diagnóstico muchísimo más fácil.
| Nivel | Significado | Trampa común |
|---|---|---|
| ① Envío del servidor | Tu servidor envía el evento a la API de Meta | Token vencido / el servidor nunca dispara |
| ② Recepción de Meta | Meta acepta el evento del servidor | Faltan parámetros / destino incorrecto (ID de pixel) |
| ③ Match y deduplicación | Se cruza con el lado del navegador, se vincula a una persona, se eliminan duplicados | Un event_id que no coincide causa doble conteo, EMQ bajo |
El punto clave: ① enviar y ③ hacer match son cosas distintas. Aunque las solicitudes salgan de tu servidor, problemas con la deduplicación frente al lado del navegador o con la calidad del match pueden hacer que los eventos no queden en una forma utilizable para optimización. La mayoría de las verificaciones se quedan en ①.
Cuando ejecutas CAPI junto con el pixel de navegador, Meta deduplica los dos eventos que comparten el mismo nombre de evento y el mismo
event_id. Unevent_idfaltante o que no coincide causa doble conteo o pérdida de eventos. Para más detalles, revisa Verificación de la deduplicación (event_id).
Paso 1: Revisa el "método de conexión" en Events Manager
Primero, en Events Manager → tu dataset (pixel) → el detalle de cada evento, verifica desde dónde está llegando el evento.
- Cada evento muestra un método de conexión como "Servidor", "Navegador" o "Servidor y navegador"
- ¿Tu evento objetivo (
Purchase,Lead, etc.) muestra Servidor? - ¿La hora de recepción del evento de servidor es reciente (es decir, no se ha detenido)?
Lo que te dice: si existe un historial de eventos llegando desde el servidor (la verificación más cercana a ① y ②). Lo que no te dice: si el código que estás configurando ahora mismo está enviando correctamente (eso lo cubre el Paso 2).
Trampa común: asumir "configuré CAPI, así que está funcionando". No es raro que alguien simplemente haya guardado la pantalla de configuración mientras el código del lado del servidor o el conector nunca ha disparado ni una vez. Revisa siempre el historial real de eventos recibidos.
Paso 2: Test Events + test_event_code
La herramienta oficial de Meta, Test Events (Events Manager → tu dataset → Test Events), muestra en tiempo real los eventos que están llegando en ese momento. Para CAPI, el truco es adjuntar un test_event_code a tu envío desde el servidor.
- Toma el
test_event_codeque se muestra en la pantalla de Test Events (una cadena tipoTEST12345) - Incluye ese
test_event_codeen el payload de tu envío desde el servidor y envía un evento de prueba - En cuestión de segundos debería aparecer en el stream de Test Events como un evento de Servidor
Lo que te dice: que tu código de servidor, específicamente, puede enviar un evento en un formato que Meta recibe (la prueba más cercana a ③).
Trampa común: darse por satisfecho con solo una acción en el navegador. Que un evento del navegador aparezca en Test Events es prueba de que el pixel funciona — no prueba de que CAPI (el servidor) funcione. Confirma siempre que aparezca una fila originada en el servidor.
Revisa las respuestas de la API en el servidor
Un detalle que los competidores suelen destacar y que es fácil pasar por alto: tu servidor recibe una respuesta HTTP cada vez que llama a la Conversions API de Meta. Registrar y revisar esas respuestas es una de las formas más rápidas de detectar problemas.
| Código HTTP | Significado | Acción |
|---|---|---|
| 200 | Meta aceptó el evento | Confirma que el conteo events_received del cuerpo de la respuesta coincida con lo que enviaste |
| 400 | Solicitud incorrecta — payload mal formado o faltan campos requeridos | Lee el mensaje de error; las causas comunes son que falte event_time, action_source, o un user_data mal hasheado |
| 401 / 403 | Falla de autenticación o de permisos | Tu access token expiró, fue revocado o no tiene el scope requerido — regenéralo en Events Manager |
Si hoy no registras las respuestas de la API, estás volando a ciegas. Una tasa de error de más de unos pocos puntos porcentuales significa que hay eventos que se están perdiendo silenciosamente.
Tip: antes de desplegar cambios, pega tu payload JSON en el Payload Helper de Meta (dentro de Events Manager → Conversions API → Payload Helper). Valida los campos requeridos, el hasheo correcto y los errores más comunes — sin llegar a enviar el evento a tu pixel.
Paso 3: ¿Están presentes navegador y servidor — y se deduplican?
Cuando ejecutas CAPI junto con el pixel, el estado saludable es que ambos aparezcan y luego se deduplicen. En Test Events, confirma lo siguiente.
- Para la misma conversión, ¿puedes ver tanto el evento de navegador como el de servidor?
- ¿Ambos comparten el mismo nombre de evento y el mismo
event_id? - ¿Meta los reconoce como "deduplicados" y no los cuenta doble?
Lo que te dice: no solo que los eventos llegan, sino que se están cruzando correctamente y que se previene el doble conteo.
Trampa común: que el navegador y el servidor construyan el
event_idde forma distinta (solo uno de los dos lo define, o usan valores diferentes). Entonces Meta los trata como eventos separados y tus conversiones se inflan al doble. Alinea la lógica de generación deevent_iden ambos emisores.
Paso 4: Event Match Quality (EMQ) y parámetros de información del cliente
El valor de CAPI no es solo "que llegue" — es que el evento se vincule a una persona. Lo que muestra esto es el Event Match Quality (EMQ).
- En el detalle de cada evento en Events Manager, revisa el puntaje de calidad de match y qué parámetros de información del cliente se están enviando
- ¿Se envían el email (
em), el teléfono (ph), el nombre (fn/ln), el ID externo (external_id), etc., después de hashearlos? - Mientras más parámetros envíes — y más precisos sean — la calidad de match generalmente sube
Lo que te dice: si los eventos que llegan se vinculan a una persona en Meta de una forma utilizable para optimización y atribución.
Trampa común: intentar enviar información personal tal cual (en texto plano). Campos como
emyphdeben estar hasheados (SHA-256). Si envías valores sin procesar, Meta no puede manejarlos correctamente y no habrá match. Confirma siempre que el hasheo ocurra del lado del servidor.
No olvides fbp, fbc y las señales del dispositivo
Más allá de campos PII como email y teléfono, hay varios parámetros no-PII que mejoran significativamente la calidad de match — y que las guías de la competencia señalan de forma consistente:
fbp(ID de navegador de Facebook): el valor de la cookie_fbpque establece el pixel de Meta. Reenviarlo desde el navegador hacia tu envío del servidor le permite a Meta vincular el evento del servidor con esa misma sesión de navegador.fbc(ID de clic de Facebook): el valor de la cookie_fbc, que se genera cuando un usuario llega a través de un clic en un anuncio. Enviarlo es fundamental para atribuir los eventos del servidor al anuncio que generó la visita.client_ip_addressyclient_user_agent: Meta los usa para hacer match entre el evento del servidor y el del navegador. Sin ellos, la calidad de match cae notablemente incluso cuando ya se envía PII hasheado.
Estos cuatro campos no requieren consentimiento del usuario más allá del que ya necesita el pixel, y aun así omitirlos es una de las razones más comunes de un EMQ bajo. Para más sobre la pérdida de señal en el navegador, revisa Safari ITP y pérdida de conversiones.
Por qué los eventos pueden enviarse desde el servidor y aun así no contarse
Confirmaste el envío (①), pero la conversión no se usa como esperabas. Razones comunes:
- Token de acceso vencido: el access token de CAPI expiró o fue revocado, por lo que el envío se rechaza
- Deduplicación defectuosa: el navegador y el servidor no comparten
event_id, causando doble conteo o pérdida - Parámetros hasheados insuficientes: poca información del cliente implica baja calidad de match, así que se subutiliza en la optimización
- El servidor no está disparando: el envío del lado del servidor simplemente no se ejecuta en el momento de la conversión
- Destino incorrecto (ID de pixel): estás enviando a un dataset distinto o a un destino inválido
En resumen, confirmar que el servidor "puede enviar" no es prueba de que Meta lo recibió, hizo match y deduplicó en producción.
Lo que verificar por tu cuenta no te puede decir
Verificar una vez, a mano, en tu propia máquina tiene dos límites estructurales.
- Tu entorno no es el entorno de tus visitantes. Tu envío de prueba con un
test_event_codepuede pasar, pero eso no significa que el mismo envío se dispare en la ruta real de producción del servidor en el momento en que un visitante real compra o consulta. Un envío de prueba exitoso no es lo mismo que un flujo de producción exitoso. - Las conversiones que involucran un clic en anuncio son difíciles de verificar. Para ver correctamente "¿de verdad se rastrea y optimiza vía un anuncio?", en teoría necesitarías hacer clic en un anuncio activo para recrear la ruta — lo cual conlleva el riesgo de una violación de política publicitaria por autoclic.
Concluir "el envío de prueba funcionó, así que está bien" tiende a pasar por alto el problema de que los eventos del servidor se pierden en la ruta real que siguen tus visitantes.
Una checklist para verificar con confianza
- En Events Manager, ¿el evento objetivo muestra un método de conexión de Servidor?
- ¿La hora de recepción del evento de servidor es reciente, no detenida?
- ¿Un envío de servidor con
test_event_codeaparece en Test Events como Servidor? - Para la misma conversión, ¿son visibles tanto navegador como servidor y están deduplicados con el mismo
event_id? - ¿El access token de CAPI es válido (no está vencido)?
- ¿La información del cliente (
em,ph, etc.) se envía hasheada, con una calidad de match en un rango aceptable? - Más allá de tu propio envío de prueba, ¿los eventos del servidor no se están perdiendo en la ruta real de los visitantes en producción?
Preguntas frecuentes
P. Si el pixel de navegador funciona, ¿no es redundante CAPI? R. No. CAPI complementa, del lado del servidor, la parte que el pixel de navegador pierde por ITP, bloqueadores de anuncios, pérdida de señal en iOS, etc. Con solo el pixel, esa parte perdida simplemente se pierde. Para la verificación de disparo, revisa también Verificación del disparo del pixel de Meta.
P. Los eventos aparecen en Test Events, pero no dicen "Servidor".
R. Es probable que solo esté funcionando el pixel de navegador. Envía un evento desde tu servidor con un test_event_code adjunto y confirma que aparezca una fila originada en el Servidor en el stream. Si no aparece, sospecha que el código del servidor no está disparando o que el token es inválido.
P. Desde que agregué CAPI, mis conversiones parecen haberse duplicado.
R. Lo más probable es que los eventos de navegador y servidor no compartan event_id y no se estén deduplicando. Alinea el nombre del evento y el event_id en ambos. Para más detalles, revisa Verificación de la deduplicación (event_id).
P. ¿Cómo subo el Event Match Quality (EMQ)? R. Envía más parámetros de información del cliente hasheados — y más precisos. Enviar email, teléfono, nombre, ID externo, etc., correctamente hasheados (SHA-256) en el servidor, generalmente sube el puntaje.
P. Usé la configuración de CAPI de un clic de Meta (CAPI Gateway). ¿Igual necesito verificar? R. Sí. La CAPI de un clic (lanzada en abril de 2026) elimina la complejidad de configuración, pero de todas formas necesitas confirmar que los eventos lleguen con un método de conexión de Servidor, que la deduplicación funcione y que el EMQ sea aceptable. Como Meta aloja la infraestructura, no tendrás acceso directo a los logs del servidor — por lo que las verificaciones de los Pasos 1 a 4 anteriores se vuelven aún más importantes. Ten en cuenta que la CAPI de un clic solo cubre eventos web estándar; los eventos personalizados o las conversiones offline todavía requieren una implementación manual que deberás verificar por separado.
P. ¿Cuánto tarda en expirar el access token? R. La expiración depende del tipo de token y de cómo se emitió. Como un vencimiento detiene silenciosamente tus envíos del servidor, lo más seguro es revisar el historial de eventos recibidos con regularidad y, para una operación a largo plazo, definir de antemano una política de renovación de tokens.
Conclusión: no te quedes en "se envía" — confirma que "Meta lo recibió y lo hizo match"
Trabajar el Paso 1 (método de conexión) → 2 (test_event_code) → 3 (deduplicación) → 4 (calidad de match) te permite aislar todo, desde el envío hasta el match. Lo que importa es el panorama completo: si los eventos del servidor están recibidos, cruzados y deduplicados contra el lado del navegador, y registrados en la ruta real de los visitantes en producción. Para el panorama completo del tracking de conversiones de Meta, revisa La guía completa del tracking de conversiones de Meta.
ConversionOK ejecuta tu página en vivo en un navegador real, independiente y aislado, e intercepta los eventos que realmente se envían para verificarlos — sin necesidad de hacer clic en tu propio anuncio y sin interferencia de tu entorno de oficina. Empieza con una verificación estática gratuita para confirmar el punto de entrada de tu medición.