El tracking del lado del servidor lleva dos años dejando de ser una rareza técnica para convertirse en la vía que usan los equipos de analítica cuando el navegador ya no deja pasar los datos de siempre. Safari bloquea las cookies de terceros desde 2020 y Firefox aísla cada sitio en un compartimento separado por defecto, así que buena parte del tráfico llega a Analytics con huecos que ninguna campaña puede permitirse. Esta pieza es para quien decide presupuesto de medición: qué es exactamente, qué exige configurarlo bien y cuánto cuesta mantenerlo en marcha.
El tracking del lado del servidor consiste en enviar los datos de analítica y conversión a través de un contenedor propio, en lugar de que el navegador los mande directamente a Google o a Meta. Así esquiva el bloqueo de cookies de terceros de Safari y Firefox, y cuesta a partir de unos 50 dólares al mes por instancia en Cloud Run.
Por qué el navegador frena la medición actual
Safari fue el primer navegador mayoritario en bloquear por completo las cookies de terceros por defecto. Lo hizo en marzo de 2020, con Safari 13.1 en macOS e iOS 13.4, y desde entonces cualquier cookie de un dominio distinto al que visita el usuario se descarta sin preguntar, tal y como documentó WebKit al anunciarlo. Firefox fue detrás con la Protección Total contra Cookies, activada por defecto para todos los usuarios: cada sitio guarda sus cookies en un compartimento separado que ningún otro dominio puede leer, según anunció Mozilla.
Ninguna de las dos políticas distingue entre un anuncio y un píxel de medición: los tratan igual porque los dos son, técnicamente, terceros. Un contenedor de Google Tag Manager cargado desde el navegador del cliente pierde ahí una parte de los eventos, sobre todo en conversiones que tardan varios días entre el clic y la compra.
Qué es el tracking del lado del servidor
El tracking del lado del servidor traslada la recogida de datos a un contenedor que corre en un servidor propio, normalmente sobre Google Cloud Run, en vez de ejecutarse en el navegador del visitante. El sitio manda el evento a ese contenedor, alojado en un subdominio propio, y es él quien lo reenvía a Analytics, a Meta o a cualquier otra plataforma de medición.
Para el navegador esa llamada es de primera parte: sale hacia el mismo dominio que se visita, no hacia uno externo, así que ni Safari ni Firefox la tratan como rastreo. La lógica de las etiquetas sigue en Google Tag Manager; cambia dónde se ejecuta el último tramo. El paso a paso de la instalación ya lo cubrimos en nuestra guía práctica de etiquetado del lado del servidor.
Diferencia entre el contenedor web y el contenedor servidor
El contenedor web es el GTM de toda la vida: una etiqueta en el HTML que dispara scripts directamente desde el navegador del visitante. El contenedor servidor es una aplicación aparte, sin interfaz para el usuario, que recibe esas peticiones y decide qué hacer con ellas antes de reenviarlas.
La diferencia práctica es que el contenedor servidor puede limpiar, enriquecer o descartar datos antes de mandarlos a terceros: quitar un parámetro sensible, sumar el valor real de un pedido que solo conoce el backend, o frenar una conexión sin consentimiento. El contenedor web no tiene ese control: manda lo que trae la etiqueta.
Cuánto cuesta montar el contenedor en Cloud Run
La documentación oficial de Google cifra el coste de una instancia de Cloud Run para tagging del lado del servidor en unos 50 dólares al mes, según su guía de planificación de infraestructura. Esa cifra cubre solo el cómputo: la factura final depende de tres partidas que hay que revisar cada mes, no solo al contratar.
- Cómputo: el precio fijo por instancia activa, que sube si hacen falta varias para no perder datos en picos de tráfico.
- Red de salida: cada respuesta que el contenedor devuelve al navegador cuenta como tráfico saliente, y crece con el volumen de eventos.
- Registros: Cloud Logging tiene un nivel gratuito, pero un sitio con mucho tráfico lo agota y empieza a facturar por almacenamiento de logs.
Para un sitio con tráfico moderado, una sola instancia suele bastar al principio; el gasto se dispara cuando el negocio crece y hace falta redundancia para que una caída del contenedor no se lleve por delante la medición de un día entero. Conviene presupuestarlo como un servicio de infraestructura más, con su propia partida, no como un coste puntual de implementación.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Lo que necesita tu equipo para mantener el servidor
Montar el contenedor es la parte fácil: la guía de Google se sigue en una tarde. Mantenerlo exige a alguien que revise los registros cuando una etiqueta deja de disparar, que actualice las plantillas cuando Google Ads o Meta cambian su API, y que vigile la factura de Cloud Run cuando sube el tráfico. No es trabajo de un analista de marketing: es infraestructura, y como tal necesita perfil técnico o una consultoría que se encargue de sostenerla.
Si el equipo interno no tiene ese perfil, una consultoría de sistemas IT en Barcelona puede llevar el mantenimiento del contenedor con monitorización y alertas, no revisándolo solo cuando algo deja de cuadrar en el informe mensual.
Dominio propio, la pieza que decide si Safari confía
El contenedor solo cuenta como primera parte si vive en un subdominio propio, del tipo medicion.tudominio.com, con su certificado y su DNS apuntando al servidor. Publicarlo en el dominio genérico de Cloud Run deshace el trabajo: vuelve a ser, para Safari y Firefox, un dominio externo, y el bloqueo se aplica igual que antes.
Ese paso es el que más se salta en implementaciones hechas con prisa, y es también el único que determina si la migración sirve para algo. Sin dominio propio, la factura se paga igual y el problema de origen sigue sin resolverse.
Cuándo compensa migrar al servidor y cuándo esperar
No todos los negocios necesitan resolver esto ya. Compensa adelantarlo cuando se cumple más de una de estas condiciones.
- Gestionas presupuesto de anuncios en Google o Meta y las conversiones que ves en la plataforma no cuadran con las ventas reales.
- El ciclo de compra dura varios días y el visitante vuelve desde otro dispositivo, donde la cookie del primer clic ya no existe.
- El equipo técnico ya mantiene otros servicios en Cloud Run o similar, así que sumar uno más no es infraestructura nueva.
Cuando ninguna encaja —tráfico bajo, presupuesto de anuncios modesto y sin nadie que revise un servidor entre semana— el gasto mensual de Cloud Run no se recupera en mejor dato. En ese caso conviene cerrar antes lo básico del lado del navegador: consentimiento bien configurado, etiquetas que disparan en el evento correcto y un Consent Mode en GA4 puesto al día. El servidor no arregla una medición que ya falla antes de salir del navegador.
Preguntas frecuentes sobre tracking del lado del servidor
¿El tracking del lado del servidor evita pedir consentimiento?
No. El contenedor cambia por dónde viajan los datos, no si hace falta permiso para recogerlos: el RGPD y la Ley de Cookies siguen exigiendo el mismo consentimiento que con el contenedor en el navegador. Sin él, el servidor no debe reenviar nada a Analytics ni a Meta.
¿Hace falta contratar un servidor propio?
No. La opción más común es un servicio gestionado como Google Cloud Run, que factura por uso en lugar de por una máquina dedicada. También hay proveedores especializados que ofrecen el contenedor ya configurado por una cuota mensual fija.
¿Añade latencia a la carga de la página?
Un poco, aunque no debería notarse: el contenedor responde en milisegundos si está bien dimensionado. El problema de rendimiento aparece cuando se satura con una sola instancia y el tráfico crece por encima de lo que soporta.
¿Compensa para un negocio local con poco tráfico?
Depende del gasto en anuncios, no del tamaño de la ciudad donde opera. Un negocio local que invierte poco en Google Ads o Meta Ads recupera antes el dato revisando el consentimiento y las etiquetas del navegador que pagando un servidor todo el año.
Fuente: Google for Developers, guía de planificación de infraestructura para server-side tagging