TL;DR, Respuesta rápida
9 min de lecturaEl server-side tracking envía eventos desde un servidor que tú controlas a plataformas de analítica y publicidad, en lugar de enviarlos desde el navegador del visitante. Recupera la duración de los identificadores que Safari recorta, sobrevive a las listas de filtros que nombran hostnames de proveedores y necesita un ID de evento compartido para que la misma conversión no se cuente dos veces. No elimina el requisito de consentimiento del artículo 5, apartado 3, de la Directiva ePrivacy ni la necesidad de una base jurídica según el GDPR.
¿Qué es el server-side tracking?
Un sitio web usa server-side tracking (seguimiento del lado del servidor) cuando el navegador envía un evento a un servidor que controla el propio sitio, y ese servidor reenvía el evento a las plataformas de analítica y publicidad en lugar de hacerlo el navegador. Lo que se traslada es el tramo de salida: el payload, los identificadores y la lista de destinos quedan en una infraestructura que puedes inspeccionar y registrar. Haz una lista de los eventos que tu backend puede confirmar por sí solo, porque son los que más ganan con el cambio.
La alternativa es el client-side tracking, donde un script del proveedor habla directamente con el endpoint del proveedor. El intercambio es control a cambio de visibilidad: tu servidor ve un pedido verificado, pero la analítica del lado del cliente y del lado del servidor difiere en si alguien ve el rage click que nunca llegó a tu backend.
¿Por qué los equipos llevaron el tracking al servidor?
Los navegadores acortaron la vida de los identificadores de los que dependen las etiquetas del lado del cliente. Intelligent Tracking Prevention 2.1 de WebKit, publicado el 21 de febrero de 2019, estableció que "all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry". WebKit siguió el 24 de marzo de 2020 bloqueando por completo las cookies de terceros en Safari 13.1 e iOS 13.4, con la afirmación de que "cookies for cross-site resources are now blocked by default across the board". Ese límite de cookies de 7 días trunca cualquier medición de visitantes recurrentes o de atribución que guarde su ID con JavaScript.
Chrome fue en la dirección contraria. Google anunció el 22 de abril de 2025 que había "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies". Las cookies de terceros siguen funcionando en Chrome con la configuración por defecto, así que la presión viene de Safari, de los bloqueadores de contenido y de las tasas de consentimiento, no de una única fecha de retirada.
¿Cómo funciona una configuración de server-side tracking?
Dos piezas hacen el trabajo: un servidor de etiquetado que recibe los eventos y una API de destino que los acepta. El Tag Manager del lado del servidor de Google ejecuta el servidor de etiquetado en Google Cloud Run o App Engine, o en "a platform of your choice", y reutiliza "the same tag, trigger, and variable model" del contenedor web. Un cliente dentro del contenedor de servidor reclama una petición HTTP entrante y la convierte en un objeto de evento, que las etiquetas del contenedor reenvían.
La Conversions API de Meta es uno de esos destinos, con o sin gestor de etiquetas. Meta la describe como una conexión que lleva datos de marketing "from an advertiser's server, website platform, mobile app, or CRM to Meta systems" y afirma que "server events are linked to a dataset ID and are processed like events sent using the Meta Pixel". Revisa primero las reglas de parámetros de Meta, porque un campo rechazado se convierte en una coincidencia que se pierde sin aviso.
¿El server-side tracking restaura la duración de las cookies en Safari?
No cuando el servidor de etiquetado está detrás de un CNAME. WebKit anunció el 12 de noviembre de 2020 que "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days", lo que deja un endpoint de proveedor apuntado por CNAME bajo los mismos siete días que una cookie de JavaScript. Un servidor de etiquetado en tu propio subdominio, que escribe su cookie con una cabecera Set-Cookie en lugar de hacerlo a través de document.cookie, queda fuera del límite de ITP 2.1, y ese es el mecanismo detrás de la mayoría de las promesas del tracking con cookies de origen propio.
| Regla del navegador | Fuente y fecha | Qué cambia un servidor de etiquetado |
|---|---|---|
Límite de siete días para cookies de document.cookie | WebKit ITP 2.1, 21 de febrero de 2019 | El servidor escribe la cookie con Set-Cookie, así que el límite no la alcanza |
| Todas las cookies de terceros bloqueadas por defecto | WebKit, 24 de marzo de 2020 | Nada. La cookie del proveedor desaparece de todos modos |
| Límite de siete días para cookies de respuestas camufladas con CNAME | WebKit, 12 de noviembre de 2020 | Nada si un CNAME apunta a un proveedor. Aloja tú mismo el endpoint |
| La elección sobre cookies de terceros queda en manos del usuario | Google, 22 de abril de 2025 | Nada. Chrome las sigue permitiendo por defecto |
¿El server-side tracking elimina la necesidad de consentimiento?
No. El artículo 5, apartado 3, de la Directiva ePrivacy exige consentimiento para "el almacenamiento de información, o la obtención de acceso a la información ya almacenada, en el equipo terminal de un abonado o usuario", con excepciones para efectuar una transmisión y para lo que sea "estrictamente necesario" para prestar el servicio solicitado. La norma se refiere al acto de leer o escribir en el dispositivo, no al hostname que lo realiza, así que trasladar el paso de reenvío a tu propio servidor deja la lectura en el dispositivo, donde estaba. Mantén la capa de consentimiento de tracking y trata el servidor de etiquetado como un cambio de transporte.
La cuestión del GDPR va encima de esa. En cuanto un evento llega a tu servidor, estás tratando datos personales, lo que requiere una base jurídica según el artículo 6 y una vía lícita para cualquier transferencia fuera de la UE. Los equipos que usan consent mode mantienen el mismo cableado tras el cambio, porque el estado de consentimiento viaja con el evento a cada destino.
¿Cómo evitas el doble conteo cuando disparan tanto el navegador como el servidor?
Envía un mismo ID en ambas copias y deja que la plataforma descarte el duplicado. La documentación de deduplicación de Meta indica que "a Meta Pixel's eventID must match the Conversion API's event_id" y "a Meta Pixel's event must match the Conversion API's event_name", y que los eventos "are only deduplicated if they are received within 48 hours" desde el primer evento con ese ID.
reported conversions = browser events + server events - matched duplicates
Toma un día con 1.000 checkouts completados. El Pixel llega a Meta en 700 de ellos, el servidor envía los 1.000, y cada evento del servidor lleva el event_id que usó su gemelo del navegador. Los duplicados coincidentes suman 700, así que las conversiones reportadas son 700 + 1.000 - 700 = 1.000, la cifra real. Quita event_id del payload del servidor y los duplicados coincidentes caen a 0, así que Meta reporta 700 + 1.000 = 1.700 compras frente a 1.000 pedidos, un sobreconteo del 70 por ciento que hereda cada cifra de coste por adquisición.
¿Qué eventos van en el servidor y cuáles se quedan en el navegador?
Pon en el servidor los eventos que tu backend puede verificar y deja las señales de comportamiento en el navegador.
Flowsery
Prueba gratuita
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
| Evento | Dónde va | Por qué |
|---|---|---|
| Compra, reembolso, cambio de suscripción | Servidor | El procesador de pagos lo confirma, y el navegador puede cerrarse antes |
| Registro, inicio de prueba, mejora de plan | Servidor | Tu base de datos es el registro, así que una petición bloqueada no puede borrarlo |
| Pageview y cambio de ruta del lado del cliente | Navegador | El servidor nunca ve una navegación que no se le pidió |
| Rage click, dead click, profundidad de scroll | Navegador | Solo existen como interacciones dentro del DOM |
| Error de JavaScript y flujo roto | Navegador | El fallo es la razón por la que ninguna petición llegó al servidor |
¿La analítica privacy-first necesita un servidor de etiquetado?
No. Un servidor de etiquetado repara un stack basado en cookies: realoja identificadores que los navegadores siguen acortando y desvía llamadas a hostnames que las listas de filtros siguen nombrando. Una analítica construida sin esos identificadores no tiene nada que realojar. Flowsery no usa cookies y está alojado en la UE, carga un único script de menos de 10 KB y no aplica muestreo de datos, así que la analítica privacy-first funciona sin un proxy delante, junto con la atribución de ingresos de Stripe, Paddle, Polar, Lemon Squeezy y Shopify.
Usa un servidor de etiquetado cuando una plataforma publicitaria necesite eventos de servidor que no puede obtener de la página. Medir tu propio producto es una decisión aparte.
Preguntas frecuentes
¿El server-side tracking es lo mismo que el server-side rendering?
No. El server-side rendering construye el HTML en el servidor antes de que el navegador lo pinte, y el server-side tracking reenvía eventos de analítica desde un servidor que tú controlas. Comparten la ubicación y nada más. Un sitio puede renderizar todas sus páginas en el servidor y aun así enviar sus eventos directamente desde el navegador.
¿El server-side tracking funciona sin JavaScript en la página?
En parte. Los eventos que pertenecen a tu backend, como un pago completado o un webhook entrante de Stripe, no necesitan código en el navegador. Los eventos que describen lo que alguien hizo en una página necesitan un script que los observe y los envíe a tu endpoint.
¿Un servidor de etiquetado burla a los bloqueadores de contenido?
Cambia aquello en lo que se fija el bloqueador. Las listas de filtros nombran hostnames conocidos de analítica y publicidad, y una petición a tu propio subdominio no aparece en esas listas. Los bloqueadores también comparan rutas de petición y nombres de archivo de scripts, así que una ruta de proveedor copiada tal cual en tu dominio sigue siendo detectada.
¿Qué datos de clientes puedo enviar a través de la Conversions API de Meta?
Meta acepta campos de contacto y demográficos, entre ellos email, teléfono, nombre, apellido, fecha de nacimiento, género, ciudad, estado y código postal, y exige hashing SHA256 en ellos. Meta afirma que client_ip_address y client_user_agent "must never be hashed". Un email con hash sigue identificando a una persona ante cualquiera que tenga el mismo hash, así que necesitas una base jurídica antes de enviarlo.
¿Sigo necesitando el Meta Pixel si uso la Conversions API?
La guía de deduplicación de Meta asume que ambos están activos, ya que compara el eventID del Pixel con el event_id de la Conversions API. Si quitas la parte del navegador, pierdes el ID de navegador fbp y el ID de clic fbc que establece el Pixel. Usa ambos y deduplica.
¿El server-side tracking reduce el peso de la página?
Reduce peso cuando sustituyes varios scripts de proveedores por una sola llamada a tu propio endpoint, y lo aumenta cuando mantienes todas las etiquetas de proveedores y duplicas sus eventos en el servidor. Google incluye "improve page performance" entre las razones para usar el etiquetado del lado del servidor. Mide la página antes y después en lugar de dar por hecho que la configuración lo consiguió.
¿Dónde puedo ejecutar un contenedor de Tag Manager del lado del servidor?
El Tag Manager del lado del servidor de Google se ejecuta en Google Cloud Run, en App Engine o en "una plataforma de tu elección". El contenedor reutiliza "el mismo modelo de etiquetas, activadores y variables" que el contenedor web, así que la lógica de etiquetas existente se conserva. La elección del hosting no cambia lo que ocurre dentro, un cliente sigue tomando la solicitud entrante y convirtiéndola en un objeto de evento.
¿Chrome limitará las cookies de terceros como lo hace Safari?
No según el calendario que fijó Safari. Google anunció el 22 de abril de 2025 que mantendría su enfoque actual sobre la elección de cookies de terceros en Chrome y que no lanzaría un nuevo aviso independiente para ellas. Las cookies de terceros siguen funcionando en Chrome por defecto, así que la presión para mover el tracking al servidor viene de Safari, los bloqueadores de contenido y las tasas de consentimiento, no de Chrome.
¿Cuánto tiempo tengo para enviar el evento de servidor equivalente y que la deduplicación funcione?
Meta solo deduplica eventos recibidos dentro de las 48 horas posteriores al primer evento con ese event_id. Si se pierde esa ventana, se cuentan tanto la copia del navegador como la del servidor de la misma conversión, el mismo sobreconteo que provoca un event_id faltante. Envía el píxel y la solicitud de servidor lo bastante cerca en el tiempo para que ambos queden dentro de esa ventana de 48 horas.
¿Necesito un tag manager para usar la Conversions API de Meta?
No hace falta un tag manager. Meta describe la Conversions API como una conexión que lleva datos de marketing "desde el servidor de un anunciante, la plataforma del sitio web, la app móvil o el CRM hasta los sistemas de Meta", y una sola integración puede llamarla directamente. Los eventos de servidor enviados así siguen "vinculados a un ID de conjunto de datos y se procesan como los eventos enviados mediante el Meta Pixel".
¿Te resultó útil este artículo?
¡Cuéntanos qué opinas!
Vernos más en Google
Un clic marca Flowsery como fuente preferida y nuestros artículos aparecen más arriba en tus Noticias destacadas, el modo IA y los resúmenes con IA.
Antes de irte...
Flowsery
Analítica orientada a ingresos para tu sitio web
Rastrea cada visitante, fuente y conversión en tiempo real. Simple, potente y sin cookies.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
Términos relacionados del glosario
Cómo una ventana de atribución decide qué puntos de contacto cobran
Mueve la ventana de atribución de 7 a 90 días y un pedido de $1,800 paga a tres conjuntos de canales distintos. Mira la aritmética y los valores por defecto.
Google enumera siete causas distintas de not set en GA4
Google da a not set en GA4 una causa distinta por dimensión, desde un session_start ausente hasta un content_group vacío. Aquí cada causa y su arreglo.
Estas cifras muestran la tasa de rebote media por industria
Nueve industrias registradas muestran una tasa de rebote media por industria documentada, entre 35.76% y 48.38%, según datos de Databox de septiembre de 2024.
Cómo aplicar la fórmula del valor promedio del pedido paso a paso
La fórmula del valor promedio del pedido divide los ingresos entre pedidos, y un código de descuento puede distorsionar en silencio cada cifra reportada.
Cómo se comparan los sitios B2B y B2C en los benchmarks de duración media de sesión
Los datos propios de Databox sitúan los benchmarks de duración media de sesión en 77.61 segundos para B2B y 92.33 para B2C, por industria y dispositivo.
Lo que realmente mide la duración media de sesión
En analítica clásica, la duración media de sesión da cero tiempo a la última página vista de cada sesión, arrastrando el promedio hacia abajo en silencio.
Artículos relacionados
Por qué beforeunload vs pagehide decide si tus analíticas sobreviven
Comparar beforeunload vs pagehide muestra por qué el móvil se salta beforeunload, bloquea el bfcache y pagehide envía datos de forma fiable con sendBeacon.
Qué registra la analítica de comportamiento que las páginas vistas no ven
A diferencia de un conteo de páginas vistas, la analítica de comportamiento registra lo que un visitante hace en una página, como eventos vinculados a él.
Cómo la huella digital del navegador te identifica sin una cookie
Canvas, fuentes instaladas, tamaño de pantalla y zona horaria, combinados por la huella digital del navegador en un identificador que sobrevive al borrado.