¿Qué es el seguimiento server-side? Cómo funciona, ventajas y límites
Descubre cómo funciona el seguimiento server-side, sus usos, límites y aspectos de consentimiento.
El seguimiento server-side envía datos de medición a través de un servidor antes de que lleguen a una plataforma de analítica o publicidad. El servidor puede recibir un evento del navegador o de una aplicación, procesarlo y enviar la información seleccionada a los destinos configurados. El recorrido exacto depende de la implementación.
Para una tienda, la pregunta práctica es: cuando se completa un pedido, ¿de dónde viene el evento y qué información lo acompaña? La respuesta ayuda a investigar pedidos ausentes y eventos duplicados.
Cómo funciona el seguimiento server-side
Imagina una compra ficticia. Una persona visita un producto, lo añade al carrito y paga. El navegador puede enviar eventos de página y carrito a un servidor de medición. Tras confirmar el pago, el backend de la tienda puede enviar el evento de pedido con el contexto permitido para relacionarlo con la visita. El servidor valida o transforma los datos y los envía a los destinos configurados.
No todas las implementaciones siguen este recorrido. En una configuración de etiquetas server-side, el navegador todavía puede recopilar y enviar la solicitud inicial. La introducción de Google describe cómo un contenedor de servidor recibe y procesa solicitudes.
Seguimiento en el navegador y en el servidor
| Pregunta | En el navegador | En el servidor |
|---|---|---|
| ¿Dónde se procesan los datos? | En el navegador de la persona | En un servidor o backend |
| Entrada habitual | Páginas e interacciones | Solicitudes del navegador, eventos del backend u otras fuentes configuradas |
| ¿Qué hay que vigilar? | Carga de etiquetas, navegador y consentimiento | Infraestructura, envío de datos, consentimiento y duplicados |
Ambos enfoques pueden funcionar juntos. El backend puede saber que el pago se confirmó, mientras que el contexto del navegador ayuda a identificar la visita. Hay que integrar esa información: mover un evento al servidor no añade automáticamente el contexto que falta.
¿Para qué puede ayudar?
El servidor ofrece un lugar para validar, transformar y dirigir los datos. Una tienda puede enviar un pedido confirmado desde su backend en lugar de depender únicamente de que el navegador llegue a la página de agradecimiento. La guía técnica de Google explica el control sobre los datos y sus destinos.
Ese control requiere trabajo: supervisión, acceso seguro, un esquema coherente de eventos y comprobación de errores. Un pago pendiente o rechazado no debería contarse como pedido completado solo porque la persona llegó al checkout.
Limitaciones antes de implementarlo
El seguimiento server-side no recupera todos los eventos. El navegador puede no enviar una solicitud, la conexión puede fallar, los identificadores pueden no estar disponibles y la persona puede cambiar de dispositivo. Incluso cuando un evento llega a una plataforma, puede no asociarse con una interacción publicitaria.
Si el navegador y el servidor envían la misma acción al mismo destino, revisa y prueba los requisitos de deduplicación de esa plataforma. De lo contrario, una compra puede aparecer dos veces. Las reglas varían según el destino.
El consentimiento y la privacidad siguen siendo relevantes. Define qué datos se recopilan y comparten, transmite las decisiones de la persona a los sistemas correspondientes y prueba los estados de consentimiento. La guía de Google muestra cómo pueden viajar las señales al contenedor de servidor; es un ejemplo técnico, no una revisión de las normas aplicables a tu negocio.
Cómo empezar
- Enumera los eventos necesarios y define qué significa cada uno. En una compra, decide cuándo se considera completado el pedido.
- Identifica origen, destino, identificadores y requisitos de consentimiento. Envía solo la información necesaria para la finalidad definida.
- Configura el servidor o la integración y conserva las credenciales en el servidor, fuera del código del navegador.
- Prueba un recorrido conocido: pedido aprobado, pago fallido o cancelado y los estados de consentimiento compatibles.
- Compara los eventos con los pedidos de prueba. Busca duplicados, contexto ausente, retrasos y errores; supervisa la integración después del lanzamiento.
En Clakta, la descripción del seguimiento explica cómo el script captura el contexto de la visita y la Orders API autenticada recibe pedidos completados desde el backend. La guía de envío de pedidos detalla los datos para una integración personalizada.
Preguntas frecuentes
¿Sustituye el seguimiento en el navegador?
No necesariamente. Muchas configuraciones usan ambos. Define el origen de cada evento y cómo se relacionarán y deduplicarán.
¿Elimina la necesidad de consentimiento o recupera eventos bloqueados?
No. Las decisiones de consentimiento deben respetarse y algunos eventos o identificadores pueden no estar disponibles. El servidor no puede enviar información que nunca recibió.
¿Los datos server-side son siempre más precisos?
No. El backend puede aportar un registro útil del pedido confirmado, pero el resultado depende de la integración, la asociación de eventos y la calidad de los datos. Compáralo con pedidos reales.
Empieza con un evento de compra bien definido. Cuando hayas comprobado su envío, contexto y gestión del consentimiento, amplía la configuración a otros eventos.