Seguimiento del lado del servidor

Lo que realmente cambia: dónde se ensambla y se envía el evento

Con un píxel de navegador, un script que se ejecuta en el dispositivo del comprador ensambla el evento. Lee la página para obtener el valor y el contenido del pedido, lee sus propias cookies para los identificadores de clic y de navegador, y envía la carga útil al dominio de la plataforma desde el dispositivo. Todo en esa cadena está fuera de su control: el script tiene que cargarse, ejecutarse y completar su solicitud antes de que el comprador navegue a otra página, en un dispositivo que puede estar ejecutando un bloqueador de anuncios y un navegador que limita la duración de las cookies.

Con la entrega del lado del servidor, su servidor construye el evento a partir de los registros que ya posee —el pedido, el cliente, los artículos de línea— y lo envía al endpoint de conversiones de la plataforma como una llamada de servidor a servidor autenticada con un token de acceso. El navegador del comprador no interviene en el momento del envío. El evento se dispara porque se escribió un pedido en su base de datos, que es la señal más fiable del negocio.

Los identificadores también cambian de forma. En lugar de depender de una cookie que el navegador podría haber expirado, el servidor envía claves de coincidencia hash —dirección de correo electrónico normalizada, número de teléfono, nombre, código postal— junto con cualquier identificador de clic capturado cuando el comprador llegó y almacenado con el pedido, además de la dirección IP y el agente de usuario. La calidad de la coincidencia depende entonces de lo que usted recopiló en la caja en lugar de lo que el navegador conservó.

Lo que soluciona y lo que no

Soluciona la entrega. Los eventos de compra que se perdieron debido a un script bloqueado, una solicitud fallida o un comprador que cerró la pestaña durante la redirección de pago ahora llegan, y lo hacen con claves de coincidencia extraídas del registro del pedido en lugar de lo que haya sobrevivido en el navegador. También desbloquea una clase de eventos que el navegador nunca puede ver: reembolsos, renovaciones de suscripciones, contracargos, cancelaciones y pedidos fuera de línea o por teléfono, todos los cuales ocurren mucho después de que la sesión haya terminado y todos los cuales cambian materialmente hacia qué debería optimizar la plataforma.

No soluciona el consentimiento. Este es el malentendido más común y el más costoso. La obligación se adjunta al procesamiento de datos personales, no al cable por el que viajan. Enviar un evento sobre un comprador que denegó el consentimiento es el mismo procesamiento con una ruta más larga, y la decisión de consentimiento ahora debe trasladarse del navegador a su registro de pedidos para que el servidor sepa si está permitido enviarlo —un trabajo que el píxel solía hacer implícitamente.

No crea una identidad que nunca recopiló. Una compra como invitado sin correo electrónico y sin identificador de clic almacenado no tiene coincidencia, ya sea que el evento provenga de un navegador o de un servidor. Tampoco reemplaza las señales de comportamiento en la página: si desea la profundidad de desplazamiento o las interacciones de añadir al carrito del lado del servidor, el navegador aún tiene que informárselas primero.

Y no mejora el rendimiento, solo los informes. Activarlo aumenta las conversiones reportadas y disminuye el costo por adquisición reportado inmediatamente, porque los eventos que siempre estaban ocurriendo ahora se están contando. Eso es una interrupción en la serie temporal, no un resultado. Marque la fecha en el gráfico y no permita que nadie compare el mes posterior con el mes anterior como si las campañas hubieran cambiado.

Deduplicación: el contrato del ID de evento

Una vez que ambas rutas están activas, cada conversión que el navegador informó con éxito también es informada por el servidor. La plataforma contará ambas a menos que usted le diga que son el mismo evento, y la forma de decírselo es un identificador de evento compartido: ambas partes envían el mismo nombre de evento y el mismo ID, la plataforma conserva el que llega primero y descarta el otro dentro de su ventana de deduplicación.

Calcule el riesgo con un ejemplo. Suponga 1,000 compras reales en un mes y que el 30% de los eventos del navegador se pierden —el navegador informa 700, el servidor informa los 1,000. Sin deduplicación, la plataforma registra 1,700 conversiones frente a 1,000 reales, una sobreestimación del 70%, y el costo por adquisición reportado cae a aproximadamente el 59% de la verdad. El optimizador aprende entonces de una señal en la que algunos pedidos se cuentan dos veces y otros una, lo cual es peor que cualquiera de las rutas por sí sola.

• Derive el ID de algo que ambas partes ya conocen —el ID del pedido es la opción obvia. Generar un ID aleatorio de forma independiente en cada lado garantiza que nunca coincidirán.
• Mantenga el ID estable en los reintentos. Un reintento que regenera el identificador convierte su propio manejo de errores en una máquina de doble conteo.
• Haga coincidir el nombre del evento exactamente, incluyendo mayúsculas/minúsculas y tipo. Las plataformas deduplican por el par, por lo que un evento de navegador y un evento de servidor que difieran solo en el nombre se mantendrán ambos.
• Envíe también los identificadores de clic del navegador y del navegador con el evento del servidor. Son lo que permite a la plataforma reconocer los dos informes como del mismo usuario, no solo del mismo pedido.
• Respete la ventana de deduplicación. Un evento entregado días después —un webhook retrasado, una retroalimentación— está fuera de ella y se contará de nuevo.
• Pruebe con pedidos reales antes de confiar en los números, y concilie el recuento de conversiones reportado por la plataforma con su propio recuento de pedidos para el mismo período. Deberían ser cercanos; una brecha sistemática en cualquier dirección es un fallo de cableado.

El costo operativo para el que nadie presupuesta

Un píxel es una etiqueta que alguien pega una vez. La entrega del lado del servidor es un servicio que ahora usted posee, con un token de acceso, un esquema, una política de reintentos y un modo de fallo, y cada uno de ellos falla silenciosamente. Un token caducado, una versión de la API de la plataforma que dejó de aceptar la carga útil que envía, un despliegue que eliminó la captura del identificador de clic en la página de destino, un error de hashing donde las direcciones de correo electrónico no se convirtieron a minúsculas y se recortaron antes del hashing — ninguno de estos arroja un error que el equipo de marketing verá. Se presentan como una disminución gradual en la calidad de la coincidencia o una caída repentina en las conversiones que se parece exactamente a una mala semana de publicidad.

Por lo tanto, la monitorización no es opcional y es simple: compare los eventos del servidor enviados con los pedidos creados, todos los días, y alerte sobre cualquier divergencia. Observe los diagnósticos de eventos o la puntuación de calidad de coincidencia de la propia plataforma, porque una tasa de coincidencia decreciente suele ser un problema de datos más que de audiencia. Registre la respuesta a cada envío en lugar de enviar y olvidar, ya que una carga útil rechazada es, de otro modo, indistinguible de una exitosa.

Presupueste también para la infraestructura de consentimiento. La decisión debe ser capturada en el navegador, persistida con el pedido y leída por el servidor antes de que envíe — tres componentes que deben estar de acuerdo, en un sistema donde el fallo es silencioso en una dirección y un problema de cumplimiento en la otra.

El resumen honesto es que el seguimiento del lado del servidor intercambia una categoría de falta de fiabilidad que no se puede solucionar por una categoría de mantenimiento que sí se puede. Ese suele ser el intercambio correcto, y deja de ser el intercambio correcto si nadie va a ser dueño de la infraestructura después del trimestre en que se construyó.