Acelera Server side tracking: qué es y por qué no es solo cookies
El server side tracking envía los datos de medición desde un servidor en lugar de hacerlo desde el navegador del visitante. Suele explicarse como una solución a las cookies, pero su valor más interesante es otro: permite conectar el anuncio con la venta, que ocurre mucho después y lejos del navegador.
Actualizado: 2026-11-08
Qué es el server side tracking
En el seguimiento tradicional (client side), un código JavaScript se ejecuta en el navegador del visitante y manda los datos directamente a Meta, Google y las demás plataformas. En el server side, el navegador manda los datos a un servidor tuyo (o de tu proveedor) y es ese servidor el que los envía a las plataformas.
No es un único producto. Entran en la categoría desde un contenedor de servidor de Google Tag Manager hasta una integración directa entre tu CRM y la API de conversiones de Meta. Lo que tienen en común es que el dato pasa por un sistema que tú controlas antes de salir.
Por qué se pierden datos en el navegador
- Bloqueadores y navegadores con protección: algunos bloquean scripts de medición o recortan la vida de las cookies.
- Restricciones de privacidad: los visitantes que rechazan el consentimiento no deberían ser medidos por cookies y esos datos desaparecen.
- Cambio de dispositivo: ve el anuncio en el móvil y compra desde el ordenador; el navegador no sabe que son la misma persona.
- La conversión no ocurre en la web: una llamada, una reunión, un pago posterior. Ningún script del navegador la ve.
- Fallos del propio script: carga lenta, el visitante cierra la pestaña antes de que se envíe el evento.
Importante: no hay una cifra universal de pérdida. Depende de tu audiencia, tu web y tu banner de cookies; mídelo en tu caso comparando lo que registra el navegador con lo que registra tu CRM.
Píxel más servidor: no es uno u otro
Las plataformas recomiendan combinar ambas vías. El píxel en el navegador aporta señales que solo existen allí (cookies de clic, página visitada). El servidor aporta fiabilidad y datos que el navegador no tiene: los de tu CRM. Cuando el mismo evento llega por las dos vías, hay que evitar que cuente doble. En Meta se hace con el mismo event_name y event_id en ambos; la plataforma conserva el primero que recibe. Detalle en la guía de conversiones offline en Meta.
| Solo navegador | Navegador y servidor | |
|---|---|---|
| Ve la visita y el clic | Sí, si no se bloquea | Sí |
| Ve la venta cerrada por teléfono | No | Sí, si el CRM la envía |
| Control de qué datos salen | Poco: lo decide el script | Más: pasa por tu servidor |
| Mantenimiento | Bajo | Mayor: hay que alojar y vigilar el servidor |
El ángulo que importa: atribuir a la venta
Gran parte de lo que se publica sobre server side tracking se centra en recuperar medición perdida por las cookies. Es cierto y útil, pero si tu negocio vende por teléfono o con comerciales, recuperar algún formulario más no te dice cuáles acabaron en venta. El cambio de fondo es otro: el servidor puede recibir lo que pasa en el CRM.
Eso permite cerrar el círculo: el visitante llega con un identificador de clic, se guarda en el lead, el lead avanza por el embudo y, cuando se cobra, la venta vuelve a la plataforma de anuncios con ese identificador y con datos del cliente cifrados. Es lo que describen las guías de conversiones offline en Google Ads y de conversiones offline en Meta. Y es lo que alimenta cualquiera de los modelos de atribución con la venta real, no con el formulario.
Privacidad y consentimiento
Que los datos pasen por un servidor no los hace invisibles ni los exime de la ley. Si envías datos personales (correo, teléfono), aunque sea con hash, sigues tratando datos personales. Esto exige, como mínimo:
- Una base legal clara y un aviso de privacidad que explique qué datos se envían y a qué plataformas.
- Respetar la elección del visitante en tu banner de consentimiento: si dice que no, el servidor tampoco debe enviar sus datos para publicidad.
- Cumplir las políticas de datos de cada plataforma. Google exige aceptar su política de datos de clientes para las conversiones mejoradas, por ejemplo.
- Minimizar: enviar solo los campos necesarios, y cifrados con SHA-256 los que lo requieren.
Esto no es asesoramiento legal; valídalo con tu asesor en protección de datos, sobre todo si operas en la UE.
Qué cambia en la práctica para un negocio de servicios
Si vendes con comerciales, la conversión que te interesa casi nunca ocurre en la web. Un proyecto de reformas, un tratamiento, una matrícula o un contrato B2B se cierran después de una llamada o una reunión. Un servidor que solo reenvía lo que ve el navegador te da la misma foto, con algo más de nitidez. Un servidor conectado al CRM te da una foto distinta: qué campañas traen clientes que pagan, y cuáles solo traen formularios. Esa diferencia es la que justifica el esfuerzo de montarlo.
Cómo empezar sin complicarte
- Empieza por lo que más vale: la venta cobrada del CRM, no el evento de cada visita.
- Guarda los identificadores del clic (GCLID,
fbc,fbp) en el lead desde el primer contacto. - Elige la vía: contenedor de servidor, integración directa del CRM o una herramienta que lo haga por ti.
- Define un identificador de evento estable para deduplicar.
- Verifica en el Administrador de eventos de Meta y en el diagnóstico de conversiones de Google que los eventos llegan y coinciden.
- Revisa el consentimiento antes de activarlo en producción.
Errores típicos
- Pensar que server side es «saltarse» el consentimiento.
- Duplicar eventos por mandar la misma conversión desde navegador y servidor sin
event_id. - Montar un servidor y no enviar nunca datos del CRM: se queda en una versión cara del píxel.
- No guardar el identificador de clic y perder la atribución cuando llega la venta.
- No vigilar el servidor: si cae, se pierde medición sin avisar.
Cómo lo hace Acelera Sales
Acelera Sales mide tu publicidad hasta la venta cobrada en el CRM: cada venta vuelve al anuncio, la campaña y el canal que la originaron. Después devuelve esa venta a Meta con la API de conversiones; la devolución a Google como conversión offline es una capacidad del producto que se activa y se prueba en la implantación. Así los algoritmos aprenden de ventas y no solo de formularios. Los conectores listos son Meta, Google Ads/YouTube, Zoho CRM y HubSpot; cualquier otro CRM se conecta en la implantación.
El píxel mide en la web y guarda los identificadores en el lead; el vínculo con el CRM asocia cada venta a su anuncio y la optimización de algoritmos la manda de vuelta a Meta (API de conversiones); la devolución a Google se activa y se prueba en la implantación. Consulta el glosario o reserva una demo.
Fuentes
Preguntas frecuentes
¿Qué es el server side tracking en pocas palabras?
Es enviar los datos de medición desde un servidor, en lugar de desde el navegador del visitante, hacia plataformas como Meta o Google.
¿El server side tracking sustituye al píxel?
No. Lo habitual es combinarlos: el píxel aporta señales del navegador y el servidor aporta fiabilidad y datos del CRM. Se deduplican con un identificador común.
¿Necesito consentimiento si uso server side tracking?
Sí. Que el dato salga desde un servidor no cambia que se traten datos personales. Debes respetar la elección del visitante y cumplir la normativa y las políticas de cada plataforma.
¿Qué diferencia hay entre server side tracking y API de conversiones?
La API de conversiones de Meta es una forma concreta de server side tracking. El término server side abarca cualquier envío de datos desde el servidor.
¿Sirve para medir ventas por teléfono?
Sí, ese es su uso más valioso: el CRM envía la venta al servidor y este la manda a la plataforma de anuncios, aunque nunca ocurriera en el navegador.
¿Es obligatorio montar un servidor propio?
No necesariamente. Puede ser un contenedor de servidor, una integración directa del CRM con las APIs de las plataformas o una herramienta de terceros.