Meta Conversions API envía eventos desde un entorno de servidor hacia Meta. No reemplaza automáticamente al Pixel: suele trabajar junto a él, con deduplicación, consentimiento y calidad de datos como condiciones de diseño.
Define el evento de negocio, conserva un event_id compartido entre navegador y servidor, envía solo datos permitidos y prueba en un entorno controlado antes de usar la señal para optimización.
Ver índice del artículo
1. Entiende el recorrido completo del evento
El navegador observa la interacción; el servidor confirma o procesa parte del resultado; Meta recibe señales compatibles. La arquitectura exacta depende del sitio, CMS, backend, CMP y requisitos legales.
Evento, URL, timestamp y señales permitidas por consentimiento.
Valida payload, asigna event_id, registra respuesta y aplica reglas.
Deduplica, reporta calidad y utiliza eventos elegibles.
2. Diseña el evento antes del payload
Empieza con una acción verificable: envío exitoso, compra confirmada o registro completado. No dispares un evento de resultado al cargar una página si la acción todavía no ocurrió.
event_nameUsa un evento estándar cuando representa fielmente la acción; documenta eventos personalizados.event_timeTimestamp del momento real de la acción, no del reintento.event_idIdentificador estable compartido por Pixel y CAPI para deduplicar la misma acción.action_sourceDescribe el origen correcto, por ejemplo website cuando corresponde.event_source_urlURL pública donde ocurrió la acción, sin datos sensibles en query strings.
3. Minimiza y protege los datos de coincidencia
La coincidencia puede usar datos permitidos y normalizados, con hash cuando la especificación lo exige. No envíes categorías sensibles, contenido libre de formularios ni información que el negocio no necesita para el objetivo definido.
4. Haz explícita la deduplicación y los reintentos
Cuando Pixel y CAPI informan la misma conversión, deben compartir event_name y event_id. El servidor también necesita evitar duplicados internos si una cola reintenta el envío.
| Riesgo | Síntoma | Control |
|---|---|---|
| Doble conteo | Navegador y servidor parecen dos resultados | event_id común y mismo nombre de evento |
| Reintento duplicado | La cola vuelve a enviar una acción ya aceptada | Idempotencia y registro de estado |
| Evento adelantado | Se reporta resultado antes de confirmarlo | Disparo posterior a la validación del backend |
5. Prueba recepción, correspondencia y gobernanza
Valida en Test Events o la herramienta equivalente, revisa códigos de respuesta y conserva logs mínimos sin exponer datos personales. Después confirma volumen, deduplicación y relación con la fuente operativa.
- Probar cada evento con casos válidos y fallidos.
- Comparar la acción confirmada en backend con la señal enviada.
- Monitorear errores y cambios de esquema.
- Documentar propietario, versión y criterio de rollback.
Probar cada evento con casos válidos y fallidos.
