Privacy-first product analytics should be inspectable in plain language. This page describes the current Cloud application's data flow, including limits that a “cookie-free” label alone does not explain.
Application behavior reviewed 27 September 2026. This is an architecture description, not a blanket legal compliance guarantee or a claim that the Cloud codebase is public.
- Browser or SDKActivity and configured event fields
- CollectorValidate, derive location and pseudonymous identifiers
- Analytics storageEvent records, retained for up to the configured TTL
- Dashboard / local AIAggregated metrics and optional browser inference
1. Collection without tracking cookies
The browser visitor tracker does not set cookies or use localStorage or sessionStorage. It records page paths, referrer origin, supported campaign tags, screen size, and available engagement and performance measurements. Custom events and optional automatic events add the fields configured by the site owner.
Page-instance IDs and sample sequences associate engagement and Web Vitals updates with a pageview. They are not persistent account identifiers. The browser tracker skips collection when Do Not Track is enabled; the collector also drops requests carrying DNT: 1. Native applications must apply their own consent and opt-out choices.
2. IP addresses and identifiers
The server receives the network IP address and user agent. It can derive country and city using its local GeoIP database before analytics storage. Trusted-proxy settings determine whether it sees the visitor address or the reverse proxy's address.
The collector stores a truncated SHA-256 hash of the IP plus a per-site salt, and a separate visitor hash of the salt, IP and user agent. The site salt does not rotate daily. The same inputs can therefore link activity across days. Daily session IDs add the UTC date to the visitor hash; they are not a conventional inactivity-based session boundary.
These are pseudonymous identifiers, not proof of anonymity or verified individuals. Shared networks can merge observations, while changes to an address or browser can split them. Separate site salts limit automatic cross-site linkage, but hashing is not a substitute for access control or careful retention.
3. What is stored
ClickHouse holds event-level analytics records as well as the fields needed to calculate aggregates: pseudonymous identifiers, timestamps, page paths, sources, technology categories, location when available, and configured event properties and values. The dashboard is not backed only by pre-aggregated counters.
Raw IP addresses are not written to the analytics tables by the collector. Normal visitor user agents are parsed into categories; bot records retain the user-agent string. Reverse-proxy logs and optional collector debug logs can contain raw IP addresses and have separate operational lifecycles.
SQLite holds account and application data, including email addresses, password hashes, site configuration, salts, goals and saved settings. It is separate from analytics event storage.
4. Access and sharing
Authenticated dashboard requests verify site ownership. A site can be explicitly shared as a public read-only dashboard. Anyone with that URL can inspect the analytics made available through its public views and exports, including pseudonymous session detail. Share only sites whose data is appropriate for that audience.
5. Retention and deletion
The supplied analytics schema sets a 365-day TTL for visits, events and bot records. ClickHouse removes expired rows during background processing, so expiration is not an immediate deletion deadline. Account data, logs and backups have separate lifecycles determined by the deployment.
Deleting a site or account removes its application configuration and dashboard access. Existing analytics rows are not immediately purged by that action; they remain until retention expiry. This page does not promise immediate erasure from database backups or infrastructure logs.
6. The local AI boundary
Reports and chat fetch a selected aggregate snapshot from Nanolytica. Inference runs in a browser worker using WebGPU or a CPU fallback. The application does not send that snapshot or your questions to an external AI service.
Model and runtime assets come from external hosts, including Hugging Face and the WebLLM model distribution. Those hosts can observe download-request metadata. Model files can be cached by the browser; model preferences and dashboard preferences use browser storage. Chat lives in page memory and resets when its analytics scope changes.
AI task markers and technical diagnostics use tab-local session storage for recovery after interruption. Copyable diagnostics contain model and runtime settings, browser capability readings and an error category; analytics, prompts, answers, account details and raw error text are excluded. Diagnostics are not uploaded automatically.
7. Visitor tracking and account storage differ
The signed-in dashboard uses session and security cookies. Registration and account recovery use account information and may send transactional email. Cookie-free visitor tracking does not mean the hosted application has no cookies or account data.
8. Keep sensitive data out
The browser tracker uses paths rather than full page query strings. Automatic outbound and download URLs remove query strings, fragments and credentials. Explicitly supplied paths, campaign tags and custom properties can still contain personal information or secrets: avoid names, emails, account IDs and sensitive values in them.
There is no session replay recorder or advertising identifier added by the tracker. Product analysis should focus on aggregate activity, not identifying people. Small segments, retention cohorts and session timelines need careful interpretation.
For configuration and measurement details, see privacy documentation. Infrastructure location, log retention, backup schedules and access practices must be confirmed for the specific deployment; they cannot be inferred from the collector code.