¿Qué es el server-side tracking?

La medición en servidor es la forma española de nombrar el server-side tracking, y las dos formas conviven en el mismo sector. Se entiende mejor por contraste. En un montaje clásico, el navegador del visitante carga los scripts de cada proveedor y habla directamente con ellos. Cada herramienta recibe la petición en su propio dominio, ejecuta su código dentro de la página y escribe sus cookies desde ahí. El control real sobre qué sale de la página queda repartido entre proveedores que no se consultan entre sí.

El modelo en servidor cambia el punto de reparto. El navegador manda un único evento a una infraestructura que tú controlas, alojada bajo un subdominio de tu propia web. A partir de ahí la lógica de etiquetado vive fuera del navegador: allí se decide qué campos se conservan, cuáles se recortan y a qué destinos se reenvían.

Conviene separar dos cosas que se confunden a menudo. La recogida sigue empezando en el navegador, porque alguien tiene que observar el clic o la vista de página. Lo que se traslada es el procesamiento y la distribución. Por eso hablar de medición sin navegador es inexacto: el navegador sigue en el circuito, solo que con menos código ajeno y con un único interlocutor.

La consecuencia práctica es de gobernanza. Con el reparto en servidor puedes auditar en un solo sitio qué sale hacia cada proveedor, algo que resulta muy difícil cuando cada script decide por su cuenta.

El montaje tiene tres piezas. Primero, un subdominio de tu web apuntando a la infraestructura de etiquetado, con su propio certificado. Segundo, un contenedor de servidor con el mismo modelo de etiquetas, activadores y variables que ya conoces del lado cliente. Tercero, un componente llamado cliente, que escucha las peticiones entrantes, las reclama y las convierte en eventos que el contenedor puede leer.

El recorrido de una visita queda así. La etiqueta del navegador deja de llamar al dominio del proveedor y llama a tu subdominio. El cliente del contenedor reclama esa petición y construye un evento con sus parámetros. Los activadores deciden qué etiquetas se disparan, y cada etiqueta abre una llamada de servidor a servidor hacia el destino correspondiente. Entre medias puedes reescribir, enmascarar o descartar parámetros antes de que salgan.

El alojamiento es la parte que más se subestima. No es un ajuste dentro de la herramienta, sino un servicio que corre en tu cuenta de nube y que hay que dimensionar, vigilar y pagar. La documentación de configuración con App Engine recomienda un mínimo de tres servidores en producción para reducir el riesgo de pérdida de datos ante una caída, y sitúa cada servidor en torno a 40 dólares mensuales, con una instancia de 1 vCPU, 0,5 GB de memoria y 10 GB de disco. Existe además una configuración de pruebas que en la mayoría de los casos no genera coste, pensada para tráfico de prueba y para la vista previa, no para producción. También hay proveedores gestionados que alquilan el servidor con tarifa cerrada.

La decisión que depende de esto no es técnica, es de operación. Montar un servidor de etiquetado significa asumir un servicio más en producción, con su factura mensual, su monitorización y alguien responsable cuando deja de responder. Quien no pueda sostener eso terminará con un sistema peor que el anterior, porque una caída del servidor de etiquetado se lleva por delante toda la medición, no solo una herramienta.

A cambio se ganan dos cosas concretas. Una es el control del dato saliente: puedes recortar direcciones IP, quitar identificadores de la cadena de consulta o impedir que un proveedor reciba campos que nunca debió ver. Eso es casi imposible de demostrar en un montaje donde cada script hace su propia llamada. La otra es el peso de la página, porque buena parte del código ajeno deja de cargarse en el navegador.

También cambia la conversación con negocio. Si la dirección espera recuperar el cien por cien de los datos que hoy se pierden, conviene rebajar la expectativa antes de firmar el presupuesto. La mejora suele ser real y medible, pero es parcial y depende del navegador del visitante, del consentimiento que haya dado y de la calidad del montaje.

• Mantén la recogida del consentimiento en el lado cliente y haz que su estado viaje hasta el contenedor de servidor. El modo de consentimiento se configura en el contenedor web, y el estado llega al servidor como parámetros de la petición.
• Dimensiona producción antes de migrar: al menos tres instancias, alertas de disponibilidad y un plan de vuelta atrás escrito.
• Usa un subdominio propio de tu web con certificado válido, y documenta cómo resuelve el DNS.
• Mantén una tabla de qué parámetro sale hacia qué proveedor, y revísala cada trimestre con el responsable de privacidad.
• Migra por fases: duplica un evento, compara cifras durante dos o tres semanas contra la medición existente y solo entonces apaga la etiqueta antigua.
• Anota el coste mensual real en la ficha del proyecto, incluido el tiempo de mantenimiento.

• Venderlo como solución de cumplimiento. Trasladar el procesamiento no elimina la obligación de pedir permiso para leer o escribir información en el dispositivo del usuario.
• Prometer que desaparece la pérdida por bloqueadores. El efecto varía según el bloqueador y según cómo esté montada la ruta, y hay que medirlo en tus propios datos.
• Dar por hecha la duración de las cookies. Safari limita a siete días la caducidad de las cookies fijadas en respuestas que identifica como CNAME encubierto.
• Dejar el contenedor sin monitorización. Sin alerta de disponibilidad, una caída se descubre en el informe del lunes siguiente.
• Llevar a producción la configuración de pruebas, que está pensada para tráfico de prueba y no aguanta carga real.