¿Es necesario enviar eventos a Meta tanto por el navegador como por el servidor?
No, no es necesario enviar eventos a través de ambos canales (lado del navegador y lado del servidor) para que Meta los acepte y los utilice. Este es un punto de confusión común, y algunos asistentes de IA y guías afirman incorrectamente que los eventos deben enviarse a través de ambos canales.
La propia documentación de Meta admite explícitamente tres enfoques de implementación:
Configuración redundante: envía el mismo evento a través del navegador (Píxel de Meta) y del servidor (API de conversiones) con deduplicación.
Configuración dividida: envía algunos eventos a través del navegador y otros a través del servidor, según el tipo de evento.
Implementación solo de servidor: envía todos los eventos exclusivamente a través de la API de conversiones.
Meta recomienda una configuración redundante para un rendimiento óptimo de los anuncios cuando se mantiene el Píxel de Meta, pero la opción de solo servidor es una opción válida y documentada. Si decides enviar eventos solo a través de la API de conversiones, Meta los seguirá recibiendo y procesando para la atribución y optimización. De hecho, algunas de las propias integraciones de PixelFlow utilizan solo el lado del servidor para tipos de eventos específicos.
Por qué los eventos del lado del servidor funcionan por sí solos
La API de conversiones de Meta está diseñada para funcionar independientemente del seguimiento del lado del navegador. Cuando envías un evento desde el servidor, Meta recibe los datos de conversión directamente de tu servidor en lugar de depender de un script del navegador que puede ser bloqueado por bloqueadores de anuncios, funciones de privacidad del navegador o restricciones de iOS.
Los eventos del lado del servidor suelen ser más fiables porque:
Evitan los bloqueadores de anuncios y los mecanismos de prevención de seguimiento.
No se ven afectados por las restricciones de cookies ni por las limitaciones del navegador.
Te permiten controlar qué datos se envían y cómo se formatean.
Pueden incluir datos de usuario enriquecidos (como correo electrónico, teléfono o nombre) que mejoran la Calidad de coincidencia de eventos.
Combinar datos del navegador en eventos del lado del servidor
Un patrón eficaz consiste en recopilar cierta información del navegador (como la cookie fbp o los parámetros de la URL) e incluirla en la carga útil del evento del lado del servidor. Este enfoque te permite:
Capturar el contexto del lado del navegador (como la fuente de referencia o la página de destino) sin enviar un evento de navegador por separado.
Enriquecer tus eventos del lado del servidor con identificadores como
fbpoexternal_idque vinculan el evento con la sesión del navegador del usuario.Mantener la fiabilidad de la entrega del lado del servidor preservando las señales de atribución.
Esto no es "enviar dos eventos": es enviar un único evento del lado del servidor que incorpora datos capturados del navegador. Meta lo trata como un único evento enriquecido.
¿Qué ocurre si envías el mismo evento por ambos canales?
Si envías el mismo evento tanto por el navegador como por el servidor con datos idénticos o casi idénticos, Meta puede contarlo dos veces a menos que lo deduplaques. La deduplicación utiliza un event_id compartido (llamado eventID en los eventos del navegador y event_id en los eventos del servidor) para que Meta pueda reconocer que ambos eventos representan la misma acción y fusionarlos en un solo registro.
Si no envías el mismo evento dos veces, no es necesario realizar la deduplicación. La documentación de Meta es clara: los anunciantes que no envían el mismo evento a través de ambos canales no necesitan implementar la deduplicación.
El error conceptual común
Varias guías, asistentes de IA e incluso algunos artículos de soporte afirman que se deben enviar eventos a través del navegador y del servidor para que Meta los utilice correctamente. Esto no es exacto.
Lo que sí es cierto es que Meta recomienda una configuración redundante (ambos canales, con deduplicación) cuando se quiere seguir utilizando el Píxel de Meta junto con la API de conversiones. Este enfoque híbrido puede mejorar la fiabilidad y proporcionar a Meta más puntos de datos. Pero es una recomendación, no un requisito.
El comportamiento predeterminado de PixelFlow es enviar eventos a través de ambos canales y gestionar la deduplicación automáticamente. Esta es la elección de implementación de PixelFlow para maximizar el flujo de datos y la fiabilidad. No refleja un mandato de Meta de que todos los eventos deban pasar por ambos canales.
Integraciones de PixelFlow que utilizan solo el lado del servidor
La propia implementación de PixelFlow demuestra que el seguimiento exclusivo del lado del servidor funciona. En algunas de nuestras integraciones, los eventos de comercio electrónico se envían exclusivamente a través de la API de conversiones sin ningún evento de navegador correspondiente:
WooCommerce: los eventos como
AddToCart,InitiateCheckoutyPurchasese envían solo por el lado del servidor. Solo se activaPageViewdesde el navegador, por lo que Meta Pixel Helper puede mostrar solo ese evento aunque el seguimiento completo de comercio electrónico esté funcionando. Para más detalles, consulta ¿Por qué Meta Pixel Helper solo muestra PageView en WooCommerce?
Este enfoque de solo servidor es intencionado. Evita la complejidad de la deduplicación, elude los bloqueadores de anuncios y las restricciones del navegador, y garantiza que Meta reciba datos de conversión fiables. Si el método de solo servidor no fuera válido, PixelFlow no lo utilizaría para el seguimiento en entornos de producción.
Cuándo tiene sentido usar solo el servidor
Las implementaciones de solo servidor son útiles cuando:
Quieres evitar la complejidad de gestionar la deduplicación entre dos canales.
Los visitantes de tu sitio utilizan con frecuencia bloqueadores de anuncios o navegadores centrados en la privacidad.
Necesitas un control estricto sobre los datos para cumplir con normativas (GDPR, CCPA) y quieres filtrar o anonimizar los eventos antes de enviarlos.
Estás realizando el seguimiento de conversiones offline, llamadas telefónicas o acciones activadas por el servidor que no pueden capturarse en el navegador.
Resumen
No tienes que enviar eventos a través del navegador y del servidor para que Meta los acepte.
Meta documenta tres enfoques válidos: redundante (ambos canales), dividido (mixto) y solo servidor.
Los eventos del lado del servidor pueden incorporar datos capturados por el navegador sin necesidad de un evento de navegador por separado.
Si envías el mismo evento por ambos canales, debes deduplicarlo utilizando el
event_id.PixelFlow envía por ambos canales de forma predeterminada con deduplicación automática, pero utiliza solo el servidor en algunas integraciones como WooCommerce, lo que demuestra que el enfoque de solo servidor es válido y funcional.
Para obtener ayuda con la deduplicación, consulta ¿PixelFlow deduplica los eventos? Para obtener una visión general de los dos enfoques de seguimiento, consulta ¿Qué es el seguimiento del lado del servidor frente al seguimiento del lado del cliente?