El píxel instalado en el navegador solo ve ya una parte de tus conversiones. Bloqueadores de publicidad, rechazo de consentimiento, restricciones de los navegadores sobre las cookies de terceros: la pérdida es estructural y se agrava. La API de Conversiones existe para compensarla, a condición de montarla correctamente.
Los dos canales
El píxel de navegador se ejecuta en el equipo del visitante. Capta el contexto completo: identificadores publicitarios, cookies, comportamiento de navegación. Se bloquea en cuanto interviene un bloqueador, una extensión o un rechazo de consentimiento.
La API de Conversiones envía el evento desde tu servidor hacia la plataforma, sin pasar por el navegador. No se bloquea, pero solo dispone de lo que le transmites, y es ciega al recorrido de navegación.
Los dos no son alternativos. La configuración recomendada los hace funcionar juntos sobre los mismos eventos, con un mecanismo de deduplicación.
La deduplicación
Es el punto técnico central, y el que las implementaciones fallan con más frecuencia.
Si una compra se envía por el píxel y por la API sin mecanismo de emparejamiento, la plataforma cuenta dos conversiones. Tus informes muestran el doble de volumen, tu coste por adquisición aparece dividido por dos, y tus decisiones de arbitraje publicitario se apoyan en cifras falsas.
El emparejamiento se apoya en dos valores, que deben ser estrictamente idénticos en los dos envíos: el nombre del evento, y un identificador único generado para esa ocurrencia.
Tres reglas prácticas. El identificador debe generarse del lado servidor y transmitirse luego al píxel, no al revés. Debe ser estable si la página se recarga, lo que excluye un sorteo aleatorio en cada visualización: la referencia de pedido es el mejor candidato para la compra. Y debe ser único por ocurrencia, no por producto ni por sesión.
Facebook Dynamic Ads + Pixel PRO — Feed de productos, Píxel y API de Conversiones (PrestaShop 8 y 9)Vende tus productos en Facebook e Instagram y mide cada conversión€89,00
Lo que la API espera
A diferencia del píxel, que adivina mucho, la API solo conoce lo que le envías. Tres familias de informaciones.
Los datos de correspondencia de cliente. Correo, teléfono, nombre, apellidos, ciudad, código postal, país. Sirven para vincular la conversión a un usuario de la plataforma. Deben normalizarse y luego cifrarse mediante hash antes del envío, nunca transmitirse en claro.
Los datos de evento. Nombre, marca de tiempo, valor, divisa, contenido del pedido con los identificadores de producto.
Los datos de contexto. Dirección IP y agente de usuario del visitante, más los identificadores de clic publicitario si están presentes en la URL de llegada. Estos dos últimos mejoran netamente la correspondencia y se olvidan a menudo.
La calidad de correspondencia
La plataforma calcula una puntuación que mide su capacidad de vincular tus eventos a usuarios. Esa puntuación condiciona directamente el rendimiento de tus campañas, y es mucho más determinante que el volumen de eventos enviados.
Tres palancas para mejorarla. Enviar más parámetros de correspondencia: cada campo adicional aumenta la probabilidad de vinculación. Normalizar correctamente antes del hash: minúsculas, supresión de espacios, formato internacional para los teléfonos. Y transmitir los identificadores de clic, que son las señales más fiables.
Una puntuación baja no se ve en tus informes de conversión, se ve en el rendimiento de tus campañas. Es lo que la vuelve difícil de diagnosticar.
El consentimiento
Punto a tratar en serio, porque el envío servidor no dispensa de nada.
El hecho de que el evento salga de tu servidor en lugar del navegador no cambia su naturaleza jurídica. Si el visitante ha rechazado los rastreadores publicitarios, no debes transmitir sus datos a una plataforma publicitaria, sea cual sea el canal técnico.
La API de Conversiones compensa la pérdida debida a los bloqueadores y a las limitaciones técnicas de los navegadores, no la debida al rechazo de consentimiento. Presentar lo contrario es una lectura errónea que circula mucho.
En concreto, tu implementación servidor debe conocer el estado del consentimiento del visitante y condicionar el envío.
Los eventos a cubrir
Cinco bastan para pilotar campañas de comercio electrónico: visualización de contenido, adición al carrito, inicio del pago, compra, y registro si le das uso.
La compra es el único que debe imperativamente pasar por los dos canales con deduplicación. Los demás pueden conformarse con el píxel en un primer momento, y la cobertura servidor venir después.
Un punto de coherencia a vigilar: los identificadores de producto enviados en los eventos deben corresponder exactamente a los de tu flujo de productos. Una divergencia impide el funcionamiento de las campañas dinámicas, que se apoyan en esa correspondencia.
Verificar
Tres controles, en este orden.
La herramienta de prueba de la plataforma, que muestra los eventos recibidos en tiempo real con su fuente. Haz un pedido completo y verifica que la compra aparece una vez, con la mención que indica que ha habido deduplicación.
La puntuación de calidad de correspondencia, a leer tras algunos días de actividad y a comparar con las referencias de la plataforma.
El cotejo con tu back office, sobre una semana. Una diferencia del 10 al 20 % por debajo sigue siendo normal. Una diferencia positiva, con la plataforma contando más compras de las que has registrado, señala un fallo de deduplicación.
El módulo Facebook Dynamic Ads y Pixel PRO para PrestaShop pone en marcha esta doble cobertura en PrestaShop 8 y 9: píxel de navegador y API de Conversiones con deduplicación por identificador de evento, hash de los datos de correspondencia, consideración del consentimiento y generación del flujo de productos para las campañas dinámicas.