El debate sobre el «tracking del servidor frente al tracking del cliente» lleva años siendo uno de esos temas cuya respuesta es, de verdad, «depende», para desesperación de todo el mundo. Esta es la explicación clara, sin discursos comerciales y con una tabla honesta que puedes enviar a tu CTO.
Qué es realmente cada enfoque
El tracking del lado del cliente se ejecuta en el navegador del visitante. Un pequeño script se ejecuta, lee lo sucedido (vista de página, clic, profundidad de desplazamiento) y envía esa información directamente a un endpoint de recopilación. El tracking del lado del servidor se ejecuta en tu infraestructura. El navegador envía un mínimo de datos a tu servidor (o a un edge worker ligero), que después decide qué reenviar y adónde.
Ninguno de los dos es intrínsecamente más «respetuoso con la privacidad» o «preciso» que el otro. Ambos pueden serlo o no, según cómo se configuren. Lo que cambia es dónde se encuentra el punto de control y cuánta información real llega hasta ti.
La tabla honesta de ventajas e inconvenientes
| Aspecto | Lado del cliente | Lado del servidor |
|---|---|---|
| Esfuerzo de configuración | Bajo: basta con pegar un fragmento de código | Mayor: requiere un servicio y una pequeña capa de enrutamiento |
| Resistencia a los bloqueadores de anuncios | Débil: el script se bloquea en origen | Fuerte: endpoint propio en tu propio dominio |
| Pérdida de datos en navegadores modernos | Considerable (ITP de Safari, bloqueadores y modos de protección contra el seguimiento) | Pequeña: tú controlas el entorno |
| Latencia en el primer renderizado | Añade una solicitud a un tercero | No añade nada si el recopilador utiliza caché en el edge |
| Control sobre lo que sale de tu infraestructura | Lo que decida el script del proveedor | Lo que tú decidas |
| Facilidad de depuración | Pestaña de red de DevTools | Registros del servidor: requiere otras habilidades, pero son más completos |
| Coste a escala | Bajo, hasta que el proveedor te cambia de nivel | Una pequeña factura de edge o funciones que puedes ver de forma directa |
| Identificación B2B de empresas | Funciona, pero es frágil | Encaje ideal: el servidor puede resolver de forma privada IP → empresa |
Esa última fila es la que los equipos B2B deberían examinar con más detenimiento. La identificación del lado del cliente depende de un script que una proporción cada vez mayor de visitantes bloquea por completo o limita de forma agresiva. El enfoque del lado del servidor sitúa la lógica de identificación en tu propia infraestructura, donde una actualización del navegador no puede desactivarla de forma silenciosa.
Dónde encaja la identificación de empresas
La identificación de empresas es una carga de trabajo natural para el lado del servidor. El navegador solo tiene que realizar una solicitud muy pequeña a un endpoint propio en tu dominio. Ese endpoint se ejecuta en el edge (normalmente en <20 ms en Europa), resuelve de forma privada la correspondencia entre IP y empresa y no devuelve al cliente nada que revele lo ocurrido. La experiencia de usuario no cambia. Se evita el ecosistema de bloqueadores. La ruta de los datos permanece dentro de unos límites que tú controlas.
No es un truco. Es la consecuencia directa de trasladar la pregunta «¿qué empresa nos visita?» del cliente a un servicio que tú gestionas. No cambia nada en la navegación del visitante; lo que cambia es tu capacidad para conocer la respuesta.
Lo que no es el tracking del lado del servidor
El tracking del lado del servidor no sirve para eludir el consentimiento. Si una actividad de tratamiento requiere consentimiento, lo requiere con independencia de dónde se ejecute el código. Lo que sí cambia el enfoque del lado del servidor es la pérdida de datos y el control, no la base jurídica.
Una nota sobre el rendimiento
A menudo preocupa que el «tracking» sea lo que ralentiza una página. En las implementaciones modernas, ese temor es cosa del pasado. Un cargador bien desarrollado ocupa unos pocos kilobytes, se carga de forma diferida y se activa cuando la página ya es interactiva; un endpoint de servidor bien desarrollado responde en unos pocos milisegundos desde el edge más cercano. Ninguno de los dos hará que tus Core Web Vitals sean malos. Lo que sí los empeora es un gestor de etiquetas con catorce scripts de terceros que nadie ha auditado en tres años. Disponer de menos rutas de datos y controlarlas mejor casi siempre ofrece más velocidad.
Cuándo sigue ganando el lado del cliente
El lado del cliente no es un enfoque equivocado. Para analítica de menor importancia en la que ya aceptas la pérdida de datos provocada por los bloqueadores (muestreo del uso del producto, eventos de UX dentro de la aplicación o pruebas rápidas y básicas de páginas de destino), el lado del cliente permite desplegar más rápido y cuesta menos. La cuestión no es que un enfoque sea universalmente mejor, sino que, si tu trabajo depende de los datos —el pipeline B2B es un buen ejemplo—, la vía del servidor es más resiliente y más transparente respecto a lo que hace.
La pregunta adecuada no es «¿cuál es mejor?», sino «¿qué decisión se alimenta con estos datos y cuánta pérdida de datos puede tolerar?». Para responder a «¿qué empresas nos visitaron esta semana?», lo ideal es que ninguna. La respuesta arquitectónica se deduce de ahí.
Published by
lead.box Team
More articles
Vea lead.box sobre su propio tráfico
Empiece gratis, sin tarjeta ni llamada comercial obligatoria. O reserve una demo guiada de 20 minutos si prefiere un recorrido acompañado.