El server-side tracking consiste en enviar los eventos de medición de tu web a un servidor propio, publicado en un subdominio tuyo, que los filtra y los reenvía a GA4, Google Ads o Meta. Merece la pena cuando la inversión publicitaria es relevante y necesitas medir ventas con fiabilidad. Mejora el control de los datos, la duración de las cookies propias y el peso de la página, pero no te exime del consentimiento. Es una de las piezas de nuestro servicio de tracking y analítica en Madrid.
La medición tradicional depende del navegador del usuario. Cada etiqueta de analítica o de publicidad se descarga como un script de terceros, envía sus datos directamente a su plataforma y escribe sus propias cookies. Los navegadores limitan cada vez más ese modelo, los bloqueadores impiden que parte de las etiquetas se carguen y tú no controlas qué información sale de tu web. A eso se suma el coste en velocidad de los scripts de terceros que lastran la carga.
Al terminar sabrás cómo funciona, qué mejora y qué no, cuánto cuesta la infraestructura según Google y en qué casos compensa frente a seguir solo con el contenedor web de Google Tag Manager.
Qué es el server-side tracking
El server-side tracking es una arquitectura de medición en la que el navegador envía los eventos a un servidor que controlas, y ese servidor decide qué datos reenvía a cada plataforma. En Google Tag Manager se implementa con un contenedor de servidor que se ejecuta en Google Cloud o en otro entorno, con su propio dominio.
La documentación de Google recomienda servir ese contenedor desde tu propio origen o desde un subdominio, por ejemplo `metrics.tuempresa.es`, porque así el servidor puede escribir cookies propias con las ventajas de seguridad y durabilidad que tienen las cookies definidas por el servidor. Si se queda en el dominio por defecto, funciona en un contexto de terceros. Es un trabajo de infraestructura web y tracking a medida en Madrid más que de configuración de etiquetas.
Cómo funciona en la práctica
En el navegador sigue habiendo una etiqueta, pero en lugar de varias etiquetas de terceros enviando datos por su cuenta, hay un único flujo de eventos hacia tu subdominio. El contenedor de servidor recibe cada petición, la interpreta con un cliente, por ejemplo el de GA4, y la reparte con etiquetas de servidor: una para GA4, otra para conversiones de Google Ads y otra para la API de conversiones de Meta.
En medio puedes transformar los datos: quitar parámetros que no deberían salir, añadir el margen de un producto o unir el evento con información de tu CRM. Es lo que permite, por ejemplo, completar el trabajo de conectar Google Ads con el CRM en Madrid con eventos que se generan en el servidor cuando una venta se cierra, sin pasar por el navegador.
Qué mejora el server-side tracking
Estas son las mejoras que justifican el proyecto, y todas dependen de una buena implantación de los datos propios de la empresa:
- Control de los datos: decides qué sale de tu infraestructura y hacia dónde. Puedes eliminar datos personales o direcciones IP antes de reenviar.
- Cookies propias más estables: con un subdominio propio, las cookies las escribe tu servidor en tu dominio, con las ventajas que describe Google.
- Menos código de terceros en la página: algunas plataformas dejan de necesitar su script en el navegador, lo que ayuda a las métricas Core Web Vitals de tu web.
- Secretos protegidos: las claves de la API de Meta o del Measurement Protocol de GA4 viven en el servidor.
- Datos de negocio en los eventos: margen, tipo de cliente o estado de la venta, que el navegador no conoce.
Qué no cambia: el consentimiento
El server-side tracking cambia por dónde viajan los datos, pero no la base legal para recogerlos. El artículo 22.2 de la LSSI exige consentimiento informado para usar dispositivos de almacenamiento y recuperación de datos en el equipo del usuario, y la guía de la AEPD sobre el uso de las cookies, actualizada en mayo de 2024, aclara que se aplica a cualquier tecnología de ese tipo y que las cookies de analítica no quedan exentas con carácter general. Una cookie que escribe tu servidor sigue siendo una cookie.
Además, enviar datos de navegación a Google o a Meta desde tu servidor sigue siendo un tratamiento de datos personales sujeto al RGPD. Por eso el servidor debe leer el estado del consentimiento que envía el banner y respetarlo, como hace el ejemplo de código más abajo. Usar el servidor para medir a quien ha rechazado las cookies es un riesgo legal y reputacional que ninguna mejora de datos compensa, y conviene dejarlo claro desde la estrategia de marketing digital.
Tampoco arregla una medición mal diseñada. Si los eventos están mal definidos en la web, el servidor reenviará los mismos errores con más eficiencia; antes del servidor va un plan de eventos ligado a la conversión.
Cuánto cuesta la infraestructura
La guía de Google para desplegar el contenedor en Cloud Run da una referencia: cada servidor cuesta unos 45 dólares al mes y recomienda un mínimo de dos instancias para reducir el riesgo de perder datos si una cae. Con esa referencia, la base ronda los 90 dólares mensuales antes de que el tráfico obligue a escalar. Google aconseja configurar una alerta de facturación para evitar sorpresas.
Hay otras opciones de alojamiento, desde Google Cloud o Cloudflare hasta una plataforma de despliegue gestionada, y cada una tiene su propia tarifa. A la infraestructura hay que sumar las horas de implantación y las de revisión periódica, porque las plataformas cambian sus API. Conviene presupuestarlo junto con el coste del mantenimiento técnico de una web en Madrid.
Meta Conversions API y Measurement Protocol de GA4
Las dos plataformas que más se alimentan desde el servidor tienen su propio canal. Meta recomienda usar la API de conversiones junto con el píxel, en lo que llama una configuración redundante, y eliminar duplicados con el identificador del evento: el `eventID` del píxel debe coincidir con el `event_id` del servidor y el nombre del evento también, y la deduplicación solo funciona si ambos llegan dentro de un plazo de 48 horas.
En GA4, el Measurement Protocol para enviar eventos desde el servidor acepta peticiones con el `client_id` del navegador, los eventos y las señales de consentimiento publicitario, y permite fechar eventos hasta 72 horas atrás. Está pensado para entornos de servidor, así que el `api_secret` nunca debe viajar al navegador. Si no quieres desplegar un contenedor completo, un pequeño backend en Node.js puede cubrir un caso concreto, como los eventos de un formulario.
CodeZone Pro Tip: reenvía a GA4 desde tu servidor solo los eventos con consentimiento y sin datos personales
// Endpoint mínimo en tu subdominio: recibe un evento de la web, valida el consentimiento y lo reenvía a GA4
const http = require("node:http");
const MP = "https://www.google-analytics.com/mp/collect";
const g = (v) => (v === "granted" ? "GRANTED" : "DENIED");
async function reenviar(ev, { measurementId, apiSecret }) {
// Sin consentimiento de analítica, el evento no sale de tu servidor
if (ev.consent?.analytics_storage !== "granted") return { enviado: false, motivo: "sin consentimiento" };
if (!ev.client_id || !/^[a-zA-Z][a-zA-Z0-9_]{0,39}$/.test(ev.name ?? "")) return { enviado: false, motivo: "evento no válido" };
const { email, telefono, ...params } = ev.params ?? {}; // GA4 no admite datos personales: se eliminan aquí
const cuerpo = {
client_id: ev.client_id,
consent: { ad_user_data: g(ev.consent.ad_user_data), ad_personalization: g(ev.consent.ad_personalization) },
events: [{ name: ev.name, params }],
};
// El api_secret vive solo en el servidor, nunca en el código del navegador
const r = await fetch(`${MP}?measurement_id=${measurementId}&api_secret=${apiSecret}`, { method: "POST", body: JSON.stringify(cuerpo) });
return { enviado: r.ok, estado: r.status };
}
if (require.main === module) http.createServer((req, res) => {
let datos = ""; req.on("data", (c) => (datos += c));
req.on("end", async () => {
let r; try { r = await reenviar(JSON.parse(datos), { measurementId: process.env.GA4_ID, apiSecret: process.env.GA4_SECRET }); }
catch { return res.writeHead(400).end(); } // cuerpo que no es JSON: se rechaza
res.writeHead(200, { "content-type": "application/json" }).end(JSON.stringify(r));
});
}).listen(8080);
module.exports = { reenviar };Este endpoint aplica en el servidor las dos reglas que más se olvidan: si el usuario no aceptó la analítica, el evento se descarta antes de salir, y si el formulario manda correo o teléfono, se eliminan antes de llegar a GA4. Las señales publicitarias viajan tal como las dio el usuario. Para el negocio significa medir con datos que puedes defender ante un cliente o ante la AEPD, con el secreto de la API fuera del alcance de cualquiera que inspeccione tu web, un requisito más en la arquitectura de tiendas online en Madrid.
Cuándo merece la pena y cuándo no
Compensa en estos casos, que suelen coincidir con campañas donde el rendimiento web para campañas en Madrid ya está resuelto y lo que falla es la medición:
- Inversión publicitaria relevante: cuando una mejora pequeña en la calidad de la señal mueve mucho presupuesto.
- Varias plataformas a la vez: GA4, Google Ads y Meta alimentadas desde un mismo flujo.
- Ventas que se cierran fuera de la web: eventos que nacen en el CRM o en el ERP.
- Control estricto de los datos: sectores donde debes poder demostrar qué sale de tu infraestructura.
No compensa en una web con poca inversión en anuncios y una sola plataforma. Ahí el contenedor web bien configurado, con el modo de consentimiento y unas landings rápidas, da casi todo el valor por una fracción del coste y del mantenimiento. Si más adelante lo necesitas, el servidor puede ir en contenedores Docker o en un servicio gestionado.
Medir Mejor sin Saltarse el Consentimiento
El server-side tracking es una mejora de infraestructura: más control, cookies propias más estables y menos código de terceros en la página. Sus límites también son claros. Exige consentimiento igual que antes, cuesta dinero cada mes y solo rinde si los eventos están bien definidos. Bien planteado, da a tus campañas una señal más limpia y a tu empresa la certeza de saber qué datos comparte. Un estudio de desarrollo web, apps y software en Madrid debería decirte también cuándo no lo necesitas.
En Codezone diseñamos la medición completa, del banner de cookies al servidor y a la conexión con tu CRM. Si estás valorando el salto a servidor, cuéntanos qué plataformas usas y cuánto inviertes al mes y te diremos si te compensa.
