Hoy todos los proveedores de analítica dicen sin cookies. Pocos explican lo que su implementación hace realmente, y casi ninguno dice lo que no puede hacer. Este artículo explica la nuestra, incluida la parte que no funciona, porque si vas a confiar en los números de una herramienta, deberías saber exactamente cómo se producen esos números.
Por qué no queríamos nada en el dispositivo
Cuando empezamos a construir Zenovay, tomamos una decisión temprano: debía existir un modo de seguimiento que no almacene nada en el navegador. Sin cookies, sin localStorage, sin IndexedDB, nada que sobreviva a la pestaña. Es un ajuste por sitio y en los sitios recién creados está activado de forma predeterminada. Solo al desactivarlo el rastreador usa una cookie propia y almacenamiento del navegador. Si la ausencia de almacenamiento te importa, revisa el interruptor en lugar de darlo por hecho.
No porque el almacenamiento sea malo. Porque el almacenamiento es un compromiso. En el momento en que escribes un identificador en el dispositivo de alguien, asumes obligaciones de conservación y borrado, y normalmente un banner. Queríamos un modo en el que no haya nada almacenado que borrar. Eso no hace desaparecer la cuestión de la base jurídica. Si una visita necesita consentimiento es una regla distinta de una ley distinta, sigue aplicándose, y corresponde al propietario del sitio y no a nosotros.
Esa decisión suena limpia hasta que intentas responder la pregunta más básica de la analítica: esta vista de página viene de la misma persona que la de hace cinco minutos? Sin un identificador almacenado, la respuesta honesta es que tienes que adivinar. Así que la verdadera pregunta de diseño es: cómo adivinas bien, y cómo haces que la suposición caduque?
La función de identidad
Aquí está todo el mecanismo. Cuando un evento llega a nuestro edge, el servidor calcula:
visitor_key = sha256(
ip_subnet // not the full IP
+ user_agent // the browser's own header
+ daily_salt // rotates at midnight UTC
)
Las sesiones son una ventana de 30 minutos sobre esa clave. El hash se calcula en el servidor, en Cloudflare Workers, antes de guardar los registros analíticos. En el modo sin cookies, el rastreador envía ID aleatorios de visitante y sesión limitados a la ventana para agrupar los eventos de la pestaña abierta. Esos ID no se guardan en el navegador y, antes de persistir los datos, la ingesta sustituye la identidad del visitante por el hash diario del servidor. No se crea ninguna cookie ni entrada de localStorage o IndexedDB en el dispositivo.
Tres ingredientes, cada uno elegido por una razón.
La subred IP, no la IP completa. Usar la dirección completa haría la clave más precisa y más invasiva a la vez. La subred es deliberadamente borrosa. También absorbe parte de la variación de las redes móviles, donde el último octeto puede cambiar entre solicitudes mientras la subred permanece igual.
El user agent. Separa a las dos personas detrás de un router doméstico mejor que nada. Por sí solo es una señal débil, y está bien. Es una de tres entradas.
La sal diaria. La sal cambia a la medianoche UTC, así que una clave solo vale para el día en que se creó, y está limitada a un único sitio. Junto con un secreto del lado del servidor que nunca sale de nuestra infraestructura, eso significa que nadie con una copia de la base de datos puede convertir un identificador de nuevo en una persona. Y ahora el límite, dicho con precisión: la rotación se deriva de la fecha, no de un valor aleatorio que destruimos, así que nosotros mismos podríamos recalcular una clave antigua si nos lo propusiéramos. Preferiríamos que la frase más fuerte fuera cierta, así que estamos pasando la rotación a un valor diario aleatorio que se descarta. Hasta que eso se publique, esta es la descripción exacta.
El fallo
Esa rotación de la sal también es un fallo, y queremos ser precisos al respecto en lugar de esconderlo en una nota al pie.
A la medianoche UTC, cada clave de visitante del planeta cambia. La misma persona, en la misma red, en el mismo navegador, se convierte en un visitante completamente nuevo. Lo que significa:
- Los recuentos de visitantes únicos en rangos de varios días se sobrestiman. Un lector diario aparece como siete personas en una vista semanal.
- Una tasa de visitantes recurrentes a lo largo de los días no es algo que podamos calcular honestamente en modo sin cookies, así que no fingimos hacerlo.
- Un recorrido de consideración de cinco días, donde alguien lee tu página de precios el lunes y se registra el viernes, parece dos personas sin relación.
Si tu negocio depende de la estabilidad del visitante entre días, este diseño te molestará. No es un informe de error que podamos corregir. Es el precio de la propiedad descrita arriba, y creemos que el precio merece decirse con claridad.
Qué sigue funcionando, y por qué la atribución de ingresos sobrevive
Todo lo que ocurre dentro de un día funciona con normalidad: sesiones, recorridos, embudos, vista en vivo y atribución de canal para la visita que está ocurriendo ahora mismo.
El caso interesante son los ingresos. Si la identidad muere a medianoche, cómo podemos decirte qué canal produjo un cliente de pago tres semanas después de la primera visita?
Porque en la conversión, las suposiciones se detienen. Cuando alguien se registra o paga, se identifica ante tu producto, y tu producto puede decírnoslo. Desde ese momento el recorrido queda anclado a una cuenta real, y la pregunta de atribución vuelve a tener respuesta, hacia atrás desde la conversión. La fase previa a la conversión permanece seudónima. La fase de pago es precisa. Creemos que ese es el lugar correcto para la frontera: la precisión llega exactamente cuando una persona elige una relación contigo.
Lo que rechazamos
Un fingerprinting más pesado. Entropía de canvas, enumeración de fuentes, peculiaridades del contexto de audio. Haría la clave más estable y nos convertiría en una empresa de vigilancia con una página de inicio más bonita. No.
Una sal semanal. Mejor continuidad, historia de privacidad más suave. Una vez que rotas cada semana, estás a un cambio de configuración de la mensual, y a otro de la nunca. Diaria es una línea clara, y las líneas claras sobreviven a la presión del producto.
Un respaldo en localStorage. Almacenar una clave solo cuando una heurística decide que está bien significaría que la frase honesta de nuestra página de inicio necesita un asterisco. La frase vale más que la continuidad.
Colisiones, porque la honestidad va en ambos sentidos
El fallo anterior divide a una persona en muchas. 
El fallo opuesto también existe: dos personas en la misma oficina, en la misma subred, con versiones idénticas de navegador, pueden fusionarse en un solo visitante durante un día. Lo aceptamos. El subrecuento y el sobrerecuento son ambos distorsiones, pero están acotadas, caducan a diario, y ninguna de ellas requiere escribir en el dispositivo de nadie.
Si de todos modos necesitas estabilidad entre días
Sin cookies es un modo, no un dogma, y cada sitio en Zenovay tiene un interruptor. En los sitios recién creados está activado de forma predeterminada. Desactívalo y el seguimiento usa una cookie propia, los visitantes se mantienen estables entre días, y las obligaciones de consentimiento que vienen con ello son tuyas, como con cualquier herramienta. La repetición de sesión, los mapas de calor y el seguimiento entre dominios son funciones aparte, con su propio almacenamiento y sus propias implicaciones de consentimiento. Activarlas no es lo mismo que funcionar en este modo.
El punto
Escribimos esto porque la mayoría de las afirmaciones sin cookies son frases de marketing, y las frases de marketing no tienen modos de fallo. Los mecanismos reales sí. El nuestro divide a la gente a la medianoche UTC, fusiona a algunos compañeros de oficina, y se niega a responder preguntas que no puede responder con honestidad. Sabiendo eso, puedes decidir qué significan nuestros números.
Si has construido sistemas de identidad y ves un compromiso más afinado que pasamos por alto, de verdad queremos escucharlo.
