Privacy, Cookies & GDPR | Measr Help Center

What lives in the browser

The Measr SDK never sets or reads a cookie. It keeps its state in localStorage, which browsers scope to a single origin: other websites cannot read what Measr stores under your domain, the SDK transmits it only to the Supabase endpoint you configure, and there is no cross-origin synchronization of any kind. The anonymous ID exists once, on your origin, and Measr never attempts to match it with anything outside your site. One honest boundary note: origin scoping is a browser boundary between sites, not an access control within your own pages. Like any localStorage entry, other scripts you choose to run on your site could read it, so keep the usual care with third-party script includes.

Key	Contents	Lifetime
Anonymous ID	A random UUID generated by the browser's `crypto.randomUUID()`. Not derived from the device, the IP, or any personal attribute.	Persists until the visitor clears site data.
Session	The full current-session object: its random ID, the anonymous ID, your site ID, start and last-activity timestamps, page and event counters, bounce state, and entry and exit page names.	Not self-deleting: after 30 minutes of inactivity, the next SDK activity finalizes it and replaces it with a new session.
Current page	The last page name, so the next page view can record where the visitor came from within your site.	Overwritten on every page view.
Debug flag	Set only if you enable debug mode while testing.	Until you disable it.

That is the complete list. There is no fingerprinting of any kind: no canvas probing, no font enumeration, no hardware signals. A visitor who clears their browser data becomes a brand-new anonymous visitor, which is exactly what you should expect from privacy-respecting analytics.

What is written to your database

Everything lands in three tables in your own Supabase project: events, sessions, and video events. This is the field inventory; the authoritative reference is the migration files shipped in the repo, which are short enough to read in full:

Field	What it contains
Anonymous ID, session ID	The random UUIDs described above, plus a generated row ID per event.
Site and event type	Your site identifier and which kind of event fired (page view, interaction, video, download, and so on).
Page names	The page title (or your `data-measr-page-name` override), capped at 100 characters, plus the previous page within the visit and the session's entry and exit pages. Names, not full URLs.
Referrer	The referring website, or Direct when there is none.
Query string	The URL query parameters, captured when the SDK initializes on a page load and re-encoded by the browser (parameter order is preserved, encoding is normalized). Kept for UTM campaign attribution.
Region and language	A continent-level region derived from the browser timezone (Europe, North America, Asia, and so on) and the browser language. No IP-based geolocation, no city, no coordinates.
Device category	Desktop, mobile, or tablet, derived from the user agent.
Browser and operating system	The browser and OS name (Chrome, Firefox, macOS, Windows, and so on), derived in the browser from the user agent. The user agent string itself is never stored.
Event data	What happened: which element was clicked (by its label or name), which outbound link was followed (its destination URL), which video reached which milestone and how many seconds in, which file was downloaded, how deep the visitor scrolled, which form was started or completed. Auto-tracking records element names, labels, and URLs, not what a visitor typed. The manual tracking APIs accept whatever you pass them, including free-text names and custom event-data objects, so keep personal data out of anything you send.
Timestamps and counters	When the session started and ended, how long it lasted, how many pages and events it contained, whether it bounced.

What is deliberately never collected

Cookies. None set, none read, first-party or otherwise.
IP addresses. Never written to analytics events, sessions, or video events. The one place the toolkit's schema records an IP is a rate-limit counter that protects your ingestion endpoint from abuse: one row per IP holding a request count inside a fixed 60-second window, in a separate locked-down table that is never joined to analytics. Your database provider's own infrastructure logs are a separate matter, governed by your agreement with them.
User agent strings. Parsed in the browser to a device category, then discarded.
Form field values. The forms module records viewed, started, completed. What the visitor typed never leaves the page.
Names, emails, accounts. There is no identify API and no identity graph: Measr ships no call that links a visitor to who they are. The flip side of the manual APIs accepting free text and custom event data is that not sending personal data in anything you pass them is your side of the contract.
Precise location. Region stops at continent level, from the timezone, not the IP.
Error message secrets. Automatically captured errors are scrubbed in the browser before sending: email addresses, JWT-shaped tokens, and standalone digit runs of ten or more (word-bounded, so runs embedded inside longer tokens are not matched) are replaced with a redaction marker, and messages are truncated at 500 characters. Messages you pass to the manual trackError() call are sent as you provide them, so apply the same care there.

Bot filtering is on by default (and configurable via excludeBots): automated browsers that expose the webdriver flag and clients matching a list of known crawler user agents are detected at init and write no rows. Detection is pattern-based, so a bot that fully impersonates a regular browser can slip through, which is true of every analytics tool.

The GDPR view: no analytics vendor in the picture

Most analytics compliance work is about the vendor: where they process, what their DPA covers, which subprocessors they use, what happens to the data when you leave. Measr removes the analytics vendor from that picture. The SDK on your pages writes directly to your own Supabase project: Creative Data Engineers never receives, stores, or can access your analytics data. One infrastructure party remains, and it is one you already have: your database provider hosts the data as your processor under your existing agreement with them, exactly as it does for the rest of your application. And since visitor UUIDs and captured URLs can still qualify as pseudonymous personal data under GDPR, the controller obligations, lawful basis, and retention decisions stay yours to assess. Measr's design makes that assessment short, not unnecessary.

Obligation	With a hosted vendor	With Measr
Data residency	Vendor's regions, vendor's terms	You pick the Supabase region (EU and UK regions available); residency and backups then follow your provider agreement
Processor agreement	DPA with the vendor plus their subprocessor list	Your existing agreement with your database provider; no separate analytics processor is added
Erasure requests	Ticket to the vendor, their timeline	A `DELETE` statement on your own tables, on your timeline
Access requests	Vendor export tooling	A `SELECT` on your own tables
Retention	Vendor-defined windows	You define retention on tables you control, within your provider agreement

In practice, erasure and access requests are often short: visitors are random UUIDs, so the question is usually whether any record can be attributed to the person asking at all. That assessment is still yours to make for each request, but you make it on data you can fully query, on your own timeline.

The honest fine print

Two things a careful reader should know, because precision beats marketing:

The query string is captured and stored. That is how UTM attribution works with zero configuration. If your site places personal data in URLs (an email in a newsletter link, for example), that would land in your database. The fix belongs at the source: keep personal data out of your URLs.
Cookieless does not automatically mean consent-free. European ePrivacy rules (and the UK's PECR) cover storing or reading information on a visitor's device, which includes localStorage, not just cookies. Measr's design gives you the strongest possible starting position: no cookies, no fingerprinting, no directly identifying data by default, no analytics vendor, and an anonymous ID that exists only to count sessions and returning visitors. Whether your specific deployment needs a consent banner is a judgment for you or your counsel. This page is a precise technical description, not legal advice.

Comparing tools on privacy grounds? The privacy analytics comparison puts Measr, Plausible, Fathom, Matomo, Simple Analytics, and Umami side by side on exactly these criteria.

Frequently asked

Is Measr really cookieless?

Yes. The SDK never sets or reads a cookie. The browser stores a random anonymous ID and a session object in localStorage, which browsers scope to your origin: other websites cannot read it, and the SDK transmits it only to the Supabase endpoint you configure. There is no cross-origin synchronization of any kind.

Does Measr store IP addresses?

No IP address is ever written to analytics events, sessions, or video events. Region comes from the browser timezone at continent level, and language from the browser settings. The toolkit's one IP use is a rate-limit counter that guards the ingestion endpoint against abuse inside fixed 60-second windows; it lives in a separate locked-down table and is never joined to analytics data.

Do I still need a consent banner with Measr?

Measr is built so that the honest answer can be no: no cookies, no fingerprinting, no directly identifying data by default, and no analytics vendor beyond the database provider you already trust. Whether your specific deployment requires consent under GDPR, UK GDPR, or PECR is a legal judgment that depends on how you use it, so treat this page as a precise technical description rather than legal advice.

How do I handle a GDPR erasure request?

Your analytics live in your own Supabase project, so erasure is a DELETE statement on tables you own. Visitors are random UUIDs with no name or email attached by default, so the practical question is usually whether any record can be attributed to the person asking at all. That assessment is yours to make, on data you can fully query.

No cookies. No analytics vendor. Here is exactly what that means.