El server-side tracking es medir desde un servidor tuyo en lugar de desde el navegador: la web envía los eventos a un subdominio propio y ese servidor decide qué reenvía a Google, Meta o TikTok. Compensa en tiendas con inversión relevante en anuncios repartida en varias plataformas. En una web de servicios con poco tráfico, casi nunca.
Este artículo es para quien ha recibido un presupuesto de server-side y no sabe si lo necesita, y para quien gasta en anuncios y ve que GA4 registra menos pedidos que la tienda. Vas a encontrar cómo funciona, qué arregla, qué no arregla aunque se venda así, cuándo hace falta, cuándo no y qué cuesta mantenerlo.
Es una pieza que valoramos dentro de datos y dashboards para marketing, y casi nunca es la primera. El servidor reenvía lo que le llega del navegador: si la medición de base está mal hecha, reenvía los mismos errores, más caros y más difíciles de ver.
¿Qué es el server-side tracking y cómo funciona?
El server-side tracking, o etiquetado del lado del servidor, es una forma de medir en la que el navegador del visitante envía los eventos a un servidor que tú controlas, en un subdominio de tu web, y ese servidor los transforma y los reenvía a cada plataforma. El navegador deja de hablar con Google, Meta o TikTok; habla con tu servidor.
Google lo implementa en Tag Manager con un contenedor de servidor, documentado en su guía de etiquetado del lado del servidor. La guía resume para qué sirve en tres puntos: mejorar el rendimiento de las páginas, dar controles de privacidad más detallados y mejorar la calidad de los datos. El servidor puede vivir en Google Cloud, con Cloud Run o App Engine, o en otra plataforma configurada a mano.
Dentro del contenedor hay tres piezas. Los clientes reciben las peticiones del navegador y las convierten en eventos; las etiquetas envían esos eventos a cada destino, sea GA4, Google Ads o la API de conversiones de Meta; y entre unos y otras decides qué parámetros pasan y cuáles se quitan. El servidor se instala en un subdominio propio, del tipo medicion.tudominio.es, antes de recibir tráfico real.
| Medición en el navegador | Medición en tu servidor | |
|---|---|---|
| A quién envía el navegador los datos | A cada plataforma por separado | A tu subdominio |
| Quién decide qué datos salen | El código de cada plataforma | Tú, en el contenedor de servidor |
| Qué ve un bloqueador de anuncios | Peticiones a dominios conocidos de publicidad | Peticiones a tu propio dominio |
| Quién escribe las cookies de medición | El JavaScript de cada etiqueta | Tu servidor, como cookie de tu dominio |
| Coste | El de las herramientas | Un servidor que se paga cada mes y alguien que lo mantenga |
| Consentimiento | Obligatorio | Igual de obligatorio |
¿Qué resuelve el server-side tracking?
Resuelve tres cosas: que los bloqueadores de anuncios se lleven parte de la medición, que las cookies de medición duren poco en algunos navegadores y que no sepas qué datos de tus visitantes acaban en cada plataforma. Además permite enviar conversiones que el navegador no conoce, como un pedido pagado días después o un lead que el comercial marca como cualificado en el CRM.
Los bloqueadores trabajan con listas de dominios y rutas de publicidad y analítica. Si el navegador envía los eventos a tu subdominio, la petición no coincide con esas listas y llega. No es infalible: algunos bloqueadores reconocen también el formato de la petición.
Los navegadores con más restricciones, Safari el primero, limitan sobre todo las cookies que escribe un script; una cookie que escribe tu servidor desde tu dominio puede durar más. Eso hace que un cliente que vuelve a las tres semanas se reconozca como el mismo y no cuente como nuevo. Cuánto se gana depende del navegador, de su versión y de cómo esté montado el subdominio.
El control de los datos es el beneficio menos vendido y el más útil. El contenedor es un punto de paso: puedes quitar la IP antes de reenviar, recortar URL que lleven parámetros con datos personales y no mandar a Meta lo que solo necesita GA4. Es lo que la guía de Google llama controles de privacidad más detallados. Las conversiones del CRM, por su parte, llegan al servidor desde tu sistema y salen hacia cada plataforma con el mismo identificador que la del navegador, para que no se cuenten dos veces.
¿Qué no resuelve, aunque se venda así?
No resuelve el consentimiento. Si un visitante rechaza las cookies, no se le puede medir con identificadores ni en el navegador ni en el servidor, y lo que el servidor envíe sobre él tiene que respetar esa decisión. Tampoco arregla una medición mal planteada, un banner que no cumple ni el conflicto entre plataformas que se atribuyen la misma venta.
La obligación de pedir permiso no depende de dónde se ejecute la etiqueta. El artículo 22.2 de la LSSI exige consentimiento para guardar o leer información en el dispositivo del usuario, y una cookie que escribe tu servidor se guarda en el mismo dispositivo que la que escribe un script. La guía de cookies de la AEPD añade el matiz que más afecta al server-side: una cookie servida desde tu dominio deja de ser propia si la información la gestiona un tercero para sus propias finalidades, como la publicidad. Tu subdominio no cambia eso.
Lo correcto es que el contenedor reciba el estado de consentimiento que envía el navegador y lo respete. El Consent Mode funciona igual con un servidor en medio: si el usuario rechaza, las etiquetas envían avisos sin cookies y Google modela lo que falta. Cómo comprobarlo con las herramientas del navegador está en Consent Mode v2. Hay quien ofrece el server-side para medir a quien rechaza: es ilegal y produce el mismo dato falso que medir sin banner.
Tampoco arregla los errores de base. Eventos de clic marcados como conversión, la pasarela de pago como fuente del pedido o la retención de datos en dos meses se reenvían igual desde el servidor. Son los errores de GA4 que se corrigen gratis en la configuración, y van antes.
| Problema | ¿Lo resuelve? | Por qué |
|---|---|---|
| Bloqueadores de anuncios | En parte | Las peticiones van a tu dominio; algunos bloqueadores las reconocen igual |
| Cookies que caducan pronto en Safari | En parte | La escribe tu servidor; depende del montaje y de la versión del navegador |
| Qué datos salen hacia cada plataforma | Sí | Se decide en el contenedor qué se reenvía y qué se quita |
| Conversiones del CRM o pagos diferidos | Sí | Tu sistema avisa al servidor y el servidor a cada plataforma |
| Usuarios que rechazan las cookies | No | El consentimiento no depende de la tecnología |
| Banner que no cumple la guía de la AEPD | No | Es un problema legal previo |
| Eventos mal definidos en GA4 | No | El servidor reenvía lo que recibe |
| Plataformas que se atribuyen la misma venta | No | Cada una sigue aplicando su propia regla |
¿Cuándo hace falta el server-side tracking?
Hace falta en una tienda con inversión relevante en anuncios, repartida en dos o más plataformas, cuando la diferencia entre los pedidos de la tienda y las compras que registran GA4 y Ads sigue siendo grande después de descontar a quien rechazó las cookies. Ahí cada conversión perdida empeora cómo optimizan las campañas, y el servidor puede pagarse con el gasto que deja de malgastarse.
La prueba previa es comparar, para el mismo mes, los pedidos de la tienda con las compras de GA4 y con las conversiones de cada plataforma. La diferencia tiene dos partes. Una es la gente que rechazó las cookies: no se recupera ni debe recuperarse, y el Consent Mode la modela. La otra son bloqueadores, cookies caducadas y etiquetas que fallan en el último paso: esa sí se recupera en parte desde el servidor.
Las plataformas de anuncios usan las conversiones que reciben para decidir a quién enseñar el anuncio y cuánto pujar. Si les llega solo una parte de las ventas, aprenden con una muestra incompleta. Con una plataforma el problema es menor; con Google Ads, Meta y TikTok a la vez, cada una con su píxel, el servidor junta en un punto lo que antes eran tres scripts y tres formas de fallar. Es el perfil de marca que vende en Shopify o WooCommerce con campañas en varias redes, el que atendemos en ecommerce: margen por producto y recuperación de carritos.
Hay un segundo motivo, de velocidad. Cada píxel de terceros es un script que el móvil descarga y ejecuta, y las Core Web Vitals miden justo eso: LCP, cuánto tarda en pintarse lo principal, bueno por debajo de 2,5 segundos; INP, cuánto tarda en responder a un toque, por debajo de 200 milisegundos; y CLS, cuánto se mueve la página, por debajo de 0,1. Sacar cinco píxeles del navegador y dejar una sola etiqueta hacia tu servidor puede mejorar la respuesta en la ficha de producto y en el pago. Qué medimos en el pago antes de abrir una tienda está en checkout que convierte.
| Señal de que sí | Cómo se comprueba |
|---|---|
| Inversión en anuncios en dos o más plataformas | Facturas de Google Ads, Meta y TikTok del último trimestre |
| Diferencia grande de pedidos tras descontar rechazos | Pedidos de la tienda frente a compras de GA4, mes a mes |
| Ventas que se cierran fuera de la web | Pagos diferidos, leads cualificados en el CRM, pedidos por teléfono |
| Varios píxeles de terceros en la ficha y el pago | Pestaña Red del navegador en una ficha de producto |
| Necesidad de controlar qué datos salen | Política interna o tipo de cliente que lo exige |
¿Cuándo es tirar el dinero?
Es tirar el dinero en una web de servicios con poco tráfico, un formulario de contacto y, como mucho, una campaña de Google Ads. Los leads que se pierden por bloqueadores son pocos en números absolutos, el CRM ya dice cuántos contactos entraron y el coste mensual del servidor y de su mantenimiento supera lo que se recupera.
Con pocos leads al mes, la diferencia entre lo que ve GA4 y lo que entra en el CRM son unos pocos contactos, y el CRM es la cifra cierta. Para saber qué canal funciona hace falta que cada lead llegue con su fuente y su campaña en un campo del CRM, no un servidor intermedio. El server-side no añade ninguna información que cambie una decisión.
También es tirar el dinero montarlo antes de arreglar lo de abajo: un banner que no cumple, un GA4 con quince eventos clave o campañas sin criterio de etiquetado. Y lo es cuando nadie mira los datos, porque medir mejor un panel que no se abre no cambia nada.
Antes de montarlo, mira lo que ya tienes. Algunas plataformas de tienda y de anuncios ofrecen conexiones propias de servidor a servidor para enviar las compras; si la tuya ya las usa y la diferencia de pedidos es pequeña, un contenedor propio aporta poco.
| Situación | ¿Server-side? | Qué hacer antes o en su lugar |
|---|---|---|
| Web de servicios, poco tráfico, un formulario | No | Guardar fuente y campaña de cada lead en el CRM |
| Tienda pequeña con una sola plataforma de anuncios | Casi nunca | Consent Mode bien montado y la conexión de la propia plataforma |
| Banner que no cumple o GA4 mal configurado | Todavía no | Arreglar consentimiento y eventos primero |
| Tienda con anuncios en dos o más plataformas | Sí, si la diferencia de pedidos lo justifica | Medir la diferencia y montar el contenedor |
| Ventas o leads que se cierran fuera de la web | Probablemente | Enviar la conversión del CRM a través del servidor |
¿Cuánto cuesta mantener un servidor de medición?
Cuesta tres cosas: el servidor, que se paga cada mes según las peticiones que recibe; el montaje, con el subdominio, el contenedor y las etiquetas de cada plataforma; y el mantenimiento, porque las plataformas cambian sus formatos y alguien tiene que comprobar que todo sigue llegando. La tercera es la que más se olvida en los presupuestos.
El servidor no tiene un precio fijo. En Google Cloud se paga por instancias y por uso, y la factura crece con el tráfico, porque cada visita genera varias peticiones. Para producción conviene más de una instancia: si el único servidor se cae, la medición se pierde mientras está caído. Hay proveedores que alojan el contenedor por una cuota mensual; son un tercero más por el que pasan los datos de tus visitantes, que va en el registro de tratamientos y con su contrato de encargado.
No voy a dar una cifra de memoria, porque depende del tráfico, de cuántas plataformas reciben eventos y de la región del servidor. Se calcula antes con la calculadora de precios de Google Cloud y el número de peticiones que hoy recibe GA4 en un mes.
Las horas de mantenimiento son las que deciden. Un cambio en la web, en el banner o en una plataforma puede romper un evento, y en el servidor el fallo no se ve: la web funciona y la medición no. Hace falta una alerta que avise cuando las compras de GA4 se separan de los pedidos de la tienda.
En nuestra auditoría de medición, desde 490 euros, el server-side es de lo que sube el precio, porque añade montaje y una pieza más que mantener. Primero se audita y, si la diferencia de pedidos no lo justifica, se dice. El orden completo, de la medición al panel, está en la guía de datos y dashboards para marketing.
Hay más sobre esto en la sección de datos para decidir del blog.
Preguntas frecuentes
¿El server-side tracking es legal en España?
Sí, si respeta el consentimiento igual que la medición en el navegador. La LSSI y la guía de cookies de la AEPD no distinguen por dónde se ejecuta la etiqueta: si la cookie o los datos acaban en manos de una plataforma para sus fines, hace falta el permiso previo del usuario.
¿Con server-side puedo medir a quien rechaza las cookies?
No con identificadores. Puedes recibir los avisos sin cookies que envía el Consent Mode, que Google usa para modelar las conversiones que faltan, pero convertirlos en un usuario identificado es ilegal y además mezcla dos poblaciones en el mismo dato.
¿Hace falta server-side para Consent Mode v2?
No. Consent Mode v2 se monta con el banner y Google Tag Manager en el navegador. El servidor es opcional y, si se monta, tiene que recibir y respetar el mismo estado de consentimiento.
¿Cuánto tráfico hace falta para que compense?
No hay un umbral de visitas. Lo que lo justifica es la diferencia entre los pedidos de la tienda y los que ven GA4 y Ads después de descontar los rechazos, multiplicada por lo que inviertes en anuncios.
—
Juan Martínez es el fundador de We Love SEO, en Zaragoza, ingeniero y data scientist. Monta paneles de datos para marketing con GA4, BigQuery, Power BI y Data Studio (antes Looker Studio). Más en el equipo.
