docsPrivacidadCómo recoge datos Limecount
Cómo recoge datos Limecount
Dos modos: el básico cuenta páginas vistas; eventos, campañas y tiempo de interacción requieren el modo ampliado habilitado y aceptación válida. Consulta modos de medición y consentimiento.
Limecount utiliza un script JavaScript propio, no una librería que tengas que instalar con npm en tu web. El nombre de su API es window.limecount; no window.timeCount.
Qué instala el cliente
En la pantalla de instalación de cada web hay una etiqueta <script> con su clave pública. El navegador descarga s.js, un archivo compilado desde nuestro paquete interno packages/tracker. No tiene dependencias ni carga librerías externas. La clave identifica la web, no al visitante, y no es una contraseña.
El script registra páginas vistas, cambios de ruta, enlaces salientes y descargas. Para acciones propias de tu aplicación, utilizas un atributo HTML o window.limecount.track(). Consulta eventos personalizados.
El panel usa ECharts para dibujar gráficas. Esa librería pertenece al panel y no se instala en la web del visitante ni recoge sus datos.
Cómo llegan los eventos
Web del cliente → script s.js → POST /api/e
↓
Validación y minimización
↓
Almacenamiento de eventos
↓
Consultas y estadísticas
El script envía la clave pública, un nombre de evento fijo, una ruta declarada o agrupada, una categoría de ancho de ventana y, cuando se han permitido, categorías de campaña y propiedades. La limpieza se aplica en el navegador antes de cada envío. Usa únicamente fetch, sin credenciales ni cabecera Referer; en producción requiere HTTPS. Consulta la política de limpieza antes del envío para configurar los catálogos y conocer sus límites.
No se leen campos de formularios para hacer estadísticas ni se crea un identificador persistente del visitante. El script no usa cookies de seguimiento. Solo guarda la preferencia de exclusión en el almacenamiento local cuando el visitante la activa.
Qué hace el servidor antes de guardar
- Valida el formato, el tamaño y la clave pública; comprueba que el dominio pertenece a la web configurada.
- Aplica exclusiones, filtros de bots, límites de tráfico y cuota. Si está activada la opción correspondiente, respeta las señales Do Not Track y Global Privacy Control.
- Normaliza la ruta: elimina fragmentos y parámetros no permitidos, conserva las UTM de campañas y sustituye determinados segmentos que parecen identificadores. Redacta valores que parecen emails. Estas reglas no detectan todos los datos personales.
- Deduce el país a partir de la IP y obtiene categorías de dispositivo, navegador y sistema operativo a partir del User-Agent. La IP y el User-Agent completo no se incluyen en los registros de eventos.
- Agrupa la fecha en horas y guarda únicamente los campos técnicos preparados para las estadísticas.
El limitador de tráfico utiliza una clave derivada de la IP, con una sal de proceso, solo en memoria y durante su ventana de control. No se usa como identificador analítico ni se almacena en los eventos.
Qué almacenamos y dónde
Los eventos incluyen web, hora, tipo y nombre, ruta normalizada, procedencia y campañas, país aproximado, categorías técnicas y propiedades permitidas. Las filas analíticas no contienen un ID de persona o sesión. En ampliado aceptado y con sesiones habilitadas, el token aleatorio recibido solo sirve para deduplicación temporal; en los eventos queda un contador de inicio. Consulta sesiones medidas. Los eventos se conservan como registros técnicos; mostrar una gráfica agregada no convierte por sí solo todos esos registros en datos anónimos.
En el modo de demostración actual, MongoDB es efímero y los eventos se guardan en un archivo local NDJSON. Esta demo no acredita un despliegue de producción en la UE.
La arquitectura de producción prevista utiliza ClickHouse para los eventos y MongoDB para webs, organizaciones, permisos y cuentas del SaaS. Las cuentas de los clientes necesitan datos de acceso; se mantienen separadas de la analítica de sus visitantes. La ubicación real de las bases de datos, proveedores y copias debe verificarse antes del lanzamiento.
Las visitas son una estimación a partir de entradas a páginas. No contamos usuarios únicos ni construimos recorridos personales entre visitas o entre webs.
Qué queda por cerrar para producción
El código ya contiene las reglas descritas, pero todavía es necesario verificar estas condiciones en el entorno publicado:
- Alojamiento, bases de datos y copias en la ubicación prevista, con control de acceso y configuración del transporte.
- Proxy, balanceador y herramientas de monitorización sin registros de IPs, cuerpos de eventos o URLs sensibles. Los ajustes del proxy están documentados en el repositorio, pero no acreditan que se hayan aplicado en un servidor real.
- Desplegar la nueva limpieza antes del envío y actualizar todas las etiquetas y cachés. El código ya contiene la política de listas permitidas; las versiones anteriores o integraciones directas no tienen esa protección. Revisar que ninguna categoría declarada tenga significado personal o sensible.
- Revisión de los valores libres y del riesgo de identificación con categorías poco frecuentes. Las reglas automáticas actuales no garantizan una anonimización completa.
- Finalidad, información al visitante, plazo de conservación, mecanismos de exclusión y la evaluación de si corresponde consentimiento para cada configuración y jurisdicción.
- Identidad del prestador, contrato de encargo y subencargados definitivos. Los textos que aún figuren como borrador deben completarse y validarse.
La ausencia de cookies y el alojamiento previsto en la UE son decisiones de diseño, no un certificado de cumplimiento. La AEPD condiciona la exención de consentimiento para medición de audiencia a su finalidad y configuración. La Comisión Europea distingue entre anonimización real y datos que todavía permiten reidentificar a una persona.
Consulta también el texto para la política de privacidad, la página de exclusión y el contrato de encargo. Todas estas páginas pueden consultarse desde el panel.