Furia Reports
GTM server-side: cuándo compensa y cuándo es sobreingeniería
GTM server-side: qué arregla de verdad, qué cuesta cada mes y a partir de qué inversión sale a cuenta. Y las tres cosas que yo arreglaría antes en una pyme.
Me escribió un cliente en marzo con una pregunta de una línea: «¿montamos GTM server-side?». Le pregunté por qué. «Porque en un webinar dijeron que recuperas un 30% de conversiones perdidas».
Ese 30% no existe. Existe en la cuenta de otro, con otro tráfico, otra web y otro stack, y alguien lo convirtió en titular de LinkedIn.
Vamos al grano, porque esto lo he montado, lo he mantenido y en un caso lo he desmontado. El etiquetado del lado servidor funciona y es buena infraestructura. Lo que pasa es que resuelve un problema que la mayoría de pymes españolas con las que trabajo todavía no tiene, porque tienen otros tres por delante haciendo mucho más ruido.
Qué hace, sin humo
En el montaje de toda la vida —lado cliente— el navegador del usuario carga el contenedor de Google Tag Manager y desde ahí salen disparadas las etiquetas: una petición a Meta, otra a Google Analytics, otra a la herramienta de turno. Todo ocurre en el navegador y todo va directo a terceros.
Con server side tagging montas un segundo contenedor, el contenedor servidor, en infraestructura tuya. Lo habitual es Cloud Run dentro de Google Cloud, o un proveedor gestionado que te lo hospeda y te lo actualiza. Lo apuntas a un subdominio de tu propio dominio, el navegador manda un único paquete ahí, y es tu servidor el que reparte hacia Meta, hacia GA4 y hacia donde haga falta.
¿Qué ganas de verdad? Las cookies pasan a ser de primera parte con vida larga, cosa que importa porque Safari le corta a siete días las que se escriben desde JavaScript. La web carga menos scripts de terceros y va más rápida. Los bloqueadores tienen menos que bloquear. Y sobre todo: tú decides qué dato sale de tu servidor y cuál se queda dentro, lo cual para consent mode y para no andar mandando correos en claro por ahí vale su peso en oro.
Eso es control sobre tu medición. Es real y es bueno. Ahora la otra parte.
La frase que nadie pone en el titular
El server side tracking no mide mejor. Envía mejor. Son dos cosas distintas y confundirlas te cuesta dinero.
Mandarle más señal a un sistema que ya se sobreatribuye solo consigue que se equivoque con más confianza.
Te cuento el caso de casa, que lo tengo en capturas y lo he enseñado en reuniones incómodas. Una cuenta nuestra: el píxel declaraba 40.420 € de ingresos atribuidos. La tienda, en el mismo periodo y con los mismos pedidos delante, decía 22.608 €. Casi 18.000 € de diferencia que no estaban en ningún sitio salvo en el panel de Meta.
Y ojo con esto: ese hueco no se cerraba con más eventos. Una parte eran ventas de email que Meta reclamaba porque el usuario había visto un anuncio nueve días antes. Otra parte, clientes recurrentes. Otra, pedidos devueltos que nadie descontaba. Si en ese momento hubiéramos metido un contenedor servidor, la única consecuencia habría sido que Meta se apuntara los 40.420 € con menos pérdida de señal. Lo conté con detalle en el post del caso de los 40.000 declarados y la conclusión es la misma que aquí.
Mejorar el canal de envío no cambia el modelo de reparto. Si te sobran ventas en el panel, te van a seguir sobrando, solo que mejor registradas. Lo desarrollé en por qué la CAPI no arregla la sobreatribución.
Lo que cuesta mantenerlo
El montaje inicial no es el problema. Un técnico decente te levanta el contenedor servidor, configura el subdominio, valida el certificado y migra las etiquetas principales en una semana de trabajo. Eso lo pagas una vez.
El coste está en el mes 7, cuando nadie se acuerda de aquello.
Está el servidor: en Google Cloud pagas por tener instancias encendidas, y la configuración que Google recomienda para producción no es la de pruebas. Según el tráfico, eso se va a decenas de euros al mes sin despeinarse. Si tiras de gestionado, los precios que publican proveedores como Stape arrancan bajos y escalan con las peticiones, así que un pico de tráfico en Black Friday también te escala la factura.
Está el dominio. Un subdominio, su DNS, su certificado y la posibilidad de que alguien toque el DNS por otro motivo y te deje el seguimiento muerto sin enterarse.
Y está el tiempo, que es lo caro. La imagen del contenedor se actualiza. Las plantillas de etiquetas cambian. Los proveedores rompen cosas. Y cuando el etiquetado lado servidor deja de enviar, no salta ninguna alarma: simplemente te encuentras un hueco en los datos tres semanas después, cuando ya has tomado decisiones de presupuesto sobre ese hueco.
Pregúntate quién lo toca cuando el que lo montó ya no está en el proyecto. Si la respuesta es «nadie», la decisión está tomada.
¿A partir de qué volumen sale a cuenta?
Mi regla, que es discutible y me la han discutido:
| Perfil | ¿Compensa? | Por qué |
|---|---|---|
| Ecommerce con menos de 15.000 €/mes de inversión | No | El coste fijo se come casi toda la mejora y nadie va a mantenerlo |
| Entre 15.000 y 40.000 €/mes | Depende | Solo si UTMs, cruce con la tienda y duplicados ya están limpios |
| Más de 40.000 €/mes o varios mercados | Sí | Recuperar un 3% de señal ya paga servidor y mantenimiento |
| Captación de leads B2B con CRM | Casi nunca primero | El agujero está entre el CRM y la campaña, no en el navegador |
En ese último caso me mojo más todavía: he visto empresas de leads montar server-side mientras seguían sin poder decirte qué campaña trajo al cliente que firmó 12.000 € en abril. Eso se arregla cruzando Meta Ads con el CRM, no con infraestructura de medición.
Las tres cosas que yo arreglaría antes
Las UTMs
Suena a poco y es lo que más dinero mueve. Si cada campaña lleva una nomenclatura distinta porque la puso un becario en 2024 y otra persona en 2025, no hay contenedor servidor que te salve: los datos llegarán perfectos y seguirán siendo inservibles. Media mañana de trabajo y un documento de convenciones. Aquí lo tienes montado.
El cruce con la tienda o el CRM
Esta es la que cambia conversaciones. Mientras el ROAS que enseñas sea el del píxel, estás construyendo sobre una cifra que nadie ha contrastado con facturación. El día que pones el declarado al lado del real, dos columnas, mismo periodo, se acaban las discusiones raras. Es exactamente lo que hacemos con Furia Reports, y es también la razón por la que lo construí: me cansé de exportar CSVs a mano para llegar a esa comparación. Lo explico entero en ROAS real frente a ROAS de plataforma.
Los duplicados y la ventana de atribución
Eventos de compra que se disparan dos veces, ventana de 7 días de visualización activada por defecto, devoluciones sin descontar. Tres revisiones de una tarde que suelen explicar más desviación que todo lo que te va a recuperar el lado servidor.
Si hoy tu cliente te pide la cifra de ventas reales atribuidas a Meta este mes y tardas más de cinco minutos en dársela, tu problema no es el navegador. Es que no tienes el dato.
Entonces, ¿merece la pena?
A partir de cierto tamaño, sí, y sin dramas: si mueves volumen serio, quieres cookies de primera parte, quieres controlar qué sale hacia terceros y tienes a alguien que lo mantenga, móntalo. Es la evolución lógica y dentro de dos años será lo normal.
Lo que no compro es venderlo como el arreglo de un problema de atribución. GTM server-side es una tubería mejor. Si el agua que le metes viene turbia, sale turbia y más rápido.
Y si me tengo que mojar del todo: yo nunca escalaría presupuesto con el ROAS del píxel, tenga contenedor servidor o no lo tenga, y he visto agencias facturar durante meses sobre esa cifra sin haberla contrastado ni una vez con la tienda del cliente. Cuando le enseñas a alguien que lo que él creía que eran 40.000 € son 22.600, la conversación cambia — y más te vale llegar tú con el dato antes de que lo descubra él.
Preguntas frecuentes
¿GTM server-side arregla el ROAS inflado de Meta?
No. El etiquetado del lado servidor mejora cómo llegan los eventos, no cómo se los reparte Meta. Si el píxel ya se apunta ventas que venían de email, de directo o de un cliente recurrente, mandarle señal más limpia hace que se las apunte con más seguridad todavía. Para ver el ROAS real necesitas comparar el gasto de la cuenta con los pedidos de tu tienda o CRM, no un contenedor nuevo.
¿Cuánto cuesta mantener un contenedor servidor al mes?
Depende de si lo autoalojas o lo contratas. En Google Cloud pagas por instancias que conviene tener siempre encendidas, y eso en producción se va a decenas de euros al mes según el tráfico. Los proveedores gestionados tipo Stape, según su web, arrancan en planes de precio bajo y suben con el volumen de peticiones. A eso súmale el subdominio, el certificado y las horas de quien lo revise cuando deje de enviar.
Si ya tengo la API de Conversiones, ¿necesito server-side?
No necesariamente. La API de Conversiones ya te da un canal servidor hacia Meta y muchas tiendas la tienen resuelta con la integración nativa de Shopify o WooCommerce. GTM server-side aporta cuando quieres un único punto de recogida para varias plataformas, control fino sobre qué datos salen del navegador y cookies de primera parte con más vida. Si tu problema es que las cifras no cuadran, ninguno de los dos lo va a resolver.
Furia Reports conecta tu Meta Ads (solo lectura) con la tienda o el CRM del cliente y te enseña el ROAS real al lado del que declara el píxel. Desde 15 €/mes, 5 días de prueba sin tarjeta.
