¿Cuál es la diferencia, en una línea?
El tracking client-side ve el contexto; el tracking server-side ve la verdad. El navegador conoce los parámetros UTM, el referrer, el dispositivo y la página, y pierde eventos por los bloqueadores. Tu back end sabe lo que de verdad pasó —una suscripción empezó, un pago falló— y no sabe nada de cómo llegó el usuario hasta ahí. Esta guía trata de dónde instrumentar. Para qué registrar —los nombres y la lista de eventos iniciales—, consulta el plan de tracking de eventos para startups; para saber por qué los datos deberían ser first-party, consulta datos y tracking first-party. Las dos mitades caben en un mismo plan de tracking.
¿Qué ve el tracking client-side y qué se le escapa?
El lado del cliente es donde vive el contexto. El SDK del navegador captura los parámetros UTM, el referrer, la página de entrada, el dispositivo y el comportamiento de la sesión: todo lo que necesitan la atribución y el análisis de embudos. Lo que se le escapa son usuarios enteros: según datos de GWI agregados por Backlinko, el 29,5 % de los usuarios de internet de todo el mundo usaba un bloqueador de anuncios al menos a veces en el segundo trimestre de 2025, unos 1.770 millones de personas. Muchos bloqueadores frenan los scripts de analítica junto con los anuncios, así que una parte medible de tus eventos client-side nunca llega a enviarse.
Incluso sin bloqueador, Safari hace que el tracking client-side pierda datos. Según la documentación del ITP de WebKit, Safari limita a siete días la caducidad de las cookies creadas con JavaScript y borra todo el resto del almacenamiento accesible por script —localStorage, IndexedDB— tras siete días de uso de Safari sin interacción con tu sitio. Cuando pasa esa ventana de siete días de uso, un visitante que vuelve parece totalmente nuevo y la identidad se rompe. La pérdida se puede medir: cuando Plausible comparó sus propios recuentos con los de Google Analytics en un sitio que era tendencia en Hacker News y Reddit, en una prueba de finales de agosto de 2021, Google Analytics no registró el 58,67 % de los visitantes. Es un caso extremo, con mucho público tecnológico; Plausible cita estudios anteriores que sitúan el bloqueo por debajo del 10 % en sitios de estilo de vida y por encima del 25 % en sitios centrados en tecnología.
¿Qué ve el tracking server-side y qué se le escapa?
El tracking server-side es tu back end informando de cambios de estado a la API de eventos: subscription_started, payment_failed, plan_changed. Estos eventos ocurren en tus servidores, no en el navegador; registrarlos ahí no es un apaño, es la fuente honesta. Ningún bloqueador se interpone, ningún límite de almacenamiento los hace caducar y el recuento coincide con tu base de datos porque sale de tu base de datos. Un evento server-side es fiable porque registra lo que hizo tu sistema, no lo que un navegador consiguió reportar. El punto ciego es el contexto: tu back end no tiene ni idea de qué campaña, referrer o dispositivo trajo al usuario, porque ese contexto solo existió en el lado del cliente.
Cliente o servidor: ¿qué eventos van en cada lado?
| Tipo de evento | Dónde registrarlo | Por qué |
|---|---|---|
| Páginas vistas y atribución de campañas | Cliente | El UTM, el referrer y la página de entrada solo existen en el navegador. |
| Uso de funcionalidades en el producto | Cliente (también servidor si es crítico) | El contexto de la interfaz importa; añade una copia en el servidor cuando una métrica dependa de ello. |
| Registro e inicio de sesión | Ambos | El punto de unión de la identidad: el mismo ID de usuario en las dos vías. |
| Ingresos y estado de la suscripción | Servidor | Los eventos de dinero ocurren en tu back end; el recuento debe coincidir con tu base de datos. |
| Eventos de email, webhooks e integraciones | Servidor | Llegan como webhooks de tus proveedores: no hay nada que capturar en el lado del cliente. |
¿Cómo debería repartirlo un equipo pequeño?
- Todo lo que tenga que ver con dinero —pruebas, suscripciones, pagos, reembolsos— va en el servidor. Cuando el churn o el MRR tienen que ser exactos, el servidor es la fuente de verdad.
- Todo lo que tenga que ver con atribución —páginas vistas, campañas, referrers— se queda en el cliente. Ese contexto no se puede reconstruir después.
- Identifica en las dos vías con el mismo ID de usuario, para que los embudos se unan y los tests A/B con poco tráfico asignen cada usuario a una sola variante en todos sus dispositivos.
- Acepta la diferencia. Los recuentos del cliente se quedan cortos por diseño; úsalos para ver la tendencia, y los eventos del servidor para todo lo que reportes.
¿Por qué las dos cifras nunca coinciden?
Usa los dos y los recuentos no coincidirán, nunca. La cifra del cliente se queda corta porque los bloqueadores y el ITP se comen eventos; la del servidor carece del contexto para decir de dónde vinieron los usuarios. No es un error que arreglar, sino una característica que hay que reconocer: cuenta con una diferencia permanente entre la analítica del cliente y la verdad del servidor, conoce su tamaño aproximado para tu audiencia y deja de perseguirla. Reporta cada cifra desde su lado honesto: la atribución y la tendencia de los embudos, con los datos del cliente; todo lo que acabe en una presentación para inversores o en una factura —la tasa de churn, el MRR, las suscripciones activas—, calculado a partir de los eventos del servidor. Plataformas de engagement como Iterable y Ortto aceptan las dos fuentes por la misma razón.
¿Cómo lo resuelve fromHello?
fromHello trata el reparto como la opción por defecto. El SDK JS/TS registra en el lado del cliente y mantiene una cola offline respaldada por localStorage —los eventos disparados durante una pérdida de conexión se conservan y se reintentan cuando el navegador vuelve a estar en línea—, mientras que la misma API de eventos acepta envíos desde el servidor, así que subscription_started llega directamente desde tu back end con una clave de API. Las dos vías escriben en un único perfil: la atribución que capturó el SDK y los eventos de ingresos que envió tu servidor describen a la misma persona. Los segmentos, los journeys y la analítica leen de ese único perfil: divides la instrumentación, no la identidad.