Skip to content

What is stored

Derived from the database schema. Nothing here is inferred.

Not stored Note
IP address An input to the visitor hash and the geo lookup; discarded
Cookies or any browser-storage identifier The tracker writes nothing to the device
Full user-agent string Parsed into browser, version, OS and device type; the raw string is not kept
Raw screen resolution in reports Stored as width × height, reported as one of six buckets
Click identifiers fbclid, gclid, gbraid, wbraid, msclkid, ttclid are stripped from the query
Card numbers or payment credentials A revenue event carries an amount and a currency, nothing about how it was paid
Passwords, tokens, session cookies Never touched

One row per hit.

Column Contents
visitorId The daily hash, 32 hex characters
identityMode hash or cookie, recorded per event
type pageview, custom, outbound or revenue
name Event name, or the destination URL for an outbound click. 500 chars
path Pathname
query What is left of the query string after tracking parameters are stripped
title document.title. 500 chars
hostname Host of the page
referrer Full referrer URL, 2000 chars
referrerDomain Its host with www. stripped, null when it is your own site
utmSource/Medium/Campaign/Term/Content Campaign parameters
country, region, city See Geo
latitude, longitude The geo lookup’s city-level coordinates, so the realtime globe can place the visit. They locate the lookup’s answer, not the device
language navigator.language, 35 chars
browser, browserVersion, os, deviceType Parsed from the user agent
screenWidth, screenHeight window.innerWidth / innerHeight
durationMs Time on the page
revenueCents, currency Only for revenue events
props The property object as sent
createdAt Server time

Flattened so they can be grouped on: site, event id, event name, key, string value, number value, date value, type, timestamp. First 50 per event; keys 200 chars, string values 500.

Contents are entirely yours. See Custom events.

Written by tracing.identify(): site, visitor id, key, string value, number value, date value, type. Unique per (site, visitor, key), so a later call overwrites.

Traits are attached to a daily visitor id, so they expire with it. Contents are entirely yours — and this is where email addresses and user ids end up if you send them.

One row per visit, rolled up from its events: visitor id, identity mode, start, end, duration, pageviews, events, bounce flag, entry and exit path, hostname, referrer domain, UTM source/medium/campaign, country, region, city, language, screen string, browser, OS, device type, and revenue in the site currency.

There is no separate table. A revenue event is an event row with revenueCents and currency set, plus whatever properties you sent with it. Nothing about the payment method, the processor or the buyer is stored unless you put it in the properties yourself.

Site: name, domain, public key, timezone, currency, identity mode, share id, excluded IPs, excluded paths, timestamps.

Goals: name, event name or path pattern, optional value. Saved reports: name, description and a parameters object (funnel steps, retention settings and so on).

Table Contents
Accounts Authentication-provider id, optional organisation id, email, name, image URL, plan, events quota, Stripe customer id, billing email
API keys Name, SHA-256 hash of the key, last four characters, last used, revoked at
Subscriptions Provider, external id, customer, plan, interval, status, price, amount, currency, period, cancellation and trial dates
Invoices Provider, external id, number, status, amounts, currency, hosted and PDF URLs, period, paid at
Billing events Every accepted webhook delivery, keyed by the provider event id, with its payload

Authentication itself — passwords, sessions, MFA — is handled by the authentication provider and is not in this database.