What tinyanalytics stores
For each event your site sends, tinyanalytics keeps the analytics context it needs to build your reports:- Page context — the path, hostname, referrer, page title, and any campaign (UTM) parameters.
- Derived attributes — an approximate location (country, region, city) from the IP, the marketing channel, and the device, browser, and OS from the user agent.
- A cookieless identifier — a one-way server-derived ID, not an anonymous ID stored in the browser.
- What you choose to send — custom events and their properties, plus any user ID and traits you set with
identify(). - Connected Stripe revenue — when you connect Stripe, the amount, currency, adjustment type, Stripe event and charge IDs, live/test mode, and any analytics IDs resolved for attribution.
What core anonymous analytics never stores
- No analytics cookies. Core anonymous analytics does not set a cookie.
- No anonymous browser ID. Anonymous visitor identity is derived on the server instead of written to the browser.
- No raw IP addresses. A visitor’s IP is used only, in memory, to derive the hashed identifier and approximate location — it’s never written to your analytics data.
- No personal data by default. tinyanalytics stores no names, emails, or other identifying details unless you deliberately send them as an identified ID, a trait, or an event property.
What optional features store in the browser
Some features need continuity between page loads and visits:identify()persists the user ID you provide.- Feature flags persist a random, site-specific visitor ID so variations stay consistent.
- Group analytics persists the group associations you provide.
- Surveys persist eligibility, impression, and completion markers.
- Browser opt-out persists a disabled marker.
How is a Stripe connection handled?
tinyanalytics retains the restricted key and webhook signing secret needed to keep receiving Stripe events. The dashboard and API return only a masked key fingerprint, never the full restricted key. Stripe revenue rows do not store customer emails, names, card details, or free-form Stripe metadata. If you turn on the optional Email fallback, tinyanalytics processes the charge email long enough to match an existing identified user, then stores only the matched analytics ID in the revenue row. The email is not written to the analytics event store.A Stripe charge ID linked to a session or identified-user ID is pseudonymous linkage, not anonymous data. Deleting the corresponding user profile is the erasure path for the identity mapping.
Your data stays isolated and yours
Each site’s data is separate, and access is gated by organization membership and teams — one organization can never read another’s analytics. You can export your data as CSV or PDF, or query it directly with the SQL query builder and the read API, at any time. Retention is applied at read time: a retention limit bounds how far back you can query, rather than deleting your event data.Related
Privacy & GDPR
How this design supports privacy compliance.
How cookieless identity works
The one-way hash behind “users.”
Export data
Take your data out any time.
Roles & permissions
Who can see and manage your data.