Privacy, Cookies & GDPR | Measr Help Center

What lives in the browser

Nothing about the visitor. As of v1.3.0 the Measr SDK sets no cookie and keeps no visitor state in localStorage or sessionStorage — no identifier, no session object, nothing to clear. On load it reads exactly one localStorage key, the developer debug toggle below, which only you ever write, while testing. Events are sent to an ingestion endpoint in your own Supabase project, and everything the browser used to remember is derived server-side (see "How sessions are counted" below). The single localStorage key the SDK can touch is a developer debug toggle that you set by hand while testing your integration; it is never written for a visitor and carries no data about anyone.

Key	Contents	Lifetime
Debug flag `measr_analytics_debug`	Set only if you enable debug mode while testing your integration. Developer-only; never set for a visitor. See the debugging guide for how to use it.	Until you disable it.

That is the complete list — and the visitor-facing part of it is empty. There is no client-side fingerprinting: no canvas probing, no font enumeration, no hardware signals. The one derived signal is the daily server-side visitor key described below. There is nothing on the device for a visitor to clear, because nothing was ever put there.

How sessions are counted — without storing anything

Older analytics tools stitch a visitor's page views into a session by leaving an identifier on the device. Measr does it on the server instead. When an event arrives, the ingestion function derives a daily visitor key: a one-way hash of the request's IP address and browser signature together with a secret that changes every day — hash(daily secret + site + IP + browser). The key is used for exactly two things: finding the visitor's live session (a session ends after 30 minutes of inactivity) and counting daily unique visitors.

The raw IP is never stored. It is hash input, used in memory and discarded. It does not land in analytics rows, and on this path even the abuse rate-limit counters are keyed by a day-scoped hash rather than the address itself.
No identifier links across days. The salt changes at each UTC calendar-day boundary and the old one is deleted, so the same visitor produces an unlinkable new key the next day; each day's key values remain in your analytics rows as per-day pseudonyms that cannot be joined across days. Recomputing a past key would require both a database backup that still holds the deleted salt and the visitor's raw IP and browser signature, which are never stored. A person seen on Monday and Tuesday counts as two visitors, and a session still open when the day boundary passes splits into two — the deliberate trade for not recognizing anyone across days.
No visitor data is stored on or read from the device. Storing and reading device information is what European ePrivacy rules (and the UK's PECR) regulate — the mechanism cookie banners exist to disclose. Measr's design leaves it unused for visitors; the sole localStorage touchpoint is the developer debug toggle described above.

This is the same architecture privacy-focused tools like Plausible and Fathom run without consent banners. Whether your specific deployment needs one remains a judgment for you or your counsel — this page is a precise technical description, not legal advice.

What is written to your database

All analytics rows land 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. Two small operational tables sit alongside them: the current day's random salt (deleted on rotation) and abuse rate-limit counters — day-scoped hashed buckets on the current ingestion path, while the legacy direct-write path still keys its counters by raw IP inside 60-second windows until it is retired.

Field	What it contains
Visitor key, session ID	The daily visitor key described above (a one-way hash shaped like a UUID) and a random session ID, plus a generated row ID per event. The key changes at each UTC day boundary; each day's values stay in your rows as unlinkable per-day pseudonyms.
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.
UTM parameters	Exactly the four UTM keys the dashboard reports — `utm_source`, `utm_medium`, `utm_campaign`, `utm_content` (the fourth added in v1.4.0) — captured once when the SDK initializes on a page load. Every other query parameter — emails, tokens, form prefills, and `utm_term` — is dropped in the browser and never transmitted. Nothing sits in your database that no report reads. Set `queryParams: false` to capture none at all.
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, stripped of any query string and fragment before transmission), 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 it contained (the stored event counter advances with page views), 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. On the current ingestion path the IP is used in memory as hash input (the daily visitor key and the abuse rate-limit bucket) and then discarded — the rate-limit table holds day-scoped hashed buckets, not addresses. The legacy direct-write path, kept for pre-v1.3.0 SDK copies, still keeps raw-IP rate counters inside fixed 60-second windows in a separate locked-down table that is never joined to analytics, until that path is retired. Your database provider's own infrastructure logs are a separate matter, governed by your agreement with them.
User agent strings. Never stored. Parsed in the browser to a device category and browser/OS names, and used once, in memory, on the server as input to the daily visitor hash — the string itself lands nowhere.
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 day-bounded deterministic hashed keys formatted as 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:

UTM values are stored verbatim. Capture is limited to utm_source, utm_medium, utm_campaign, and utm_content: every query parameter outside those four keys — an email in a booking link, a reset token, and utm_term (where campaign tools tend to put per-recipient values) — is dropped before transmission. The values of the four captured keys, though, are stored as-is for attribution: if a tool of yours writes personal data into them, that lands in your database. Use utm_content for per-variant values, never per-recipient identifiers; keep personal data out of UTM values, or set queryParams: false.
The banner question, answered precisely. European ePrivacy rules (and the UK's PECR) cover storing or reading information on a visitor's device — localStorage included, not just cookies. As of v1.3.0 Measr stores nothing about visitors and reads nothing visitor-related: the sole localStorage touchpoint is the developer debug flag, which the SDK reads on load and only you ever write, while testing. What remains is ordinary server-side processing of in-flight request data under GDPR, the same footing every server-side analytics tool stands on. 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 — and as of v1.3.0 it keeps no visitor state in the browser at all. The SDK never sets or reads a cookie, and localStorage holds no identifier and no session object. Sessions are stitched server-side from a daily-rotating hashed key. The one localStorage key the SDK reads is a developer debug toggle that only you ever write, while testing your integration.

Does Measr store IP addresses?

No IP address is ever written to analytics events, sessions, or video events. The ingestion function uses the IP once, in memory, as input to the daily visitor hash, then discards it. Region comes from the browser timezone at continent level, and language from the browser settings. On the current ingestion path even the abuse rate-limit counters are keyed by a day-scoped hash of the IP rather than the address itself. (The legacy direct-write path, kept so pre-v1.3.0 SDK installs keep working, still keeps raw-IP rate counters inside fixed 60-second windows until it is retired.)

Do I still need a consent banner with Measr?

Measr is built so that the honest answer can be no: no cookies, no visitor storage (the single localStorage key is a developer debug toggle — read on load, written only by you), no client-side fingerprinting (the one derived signal is a daily server-side key computed from IP and browser signature, which resets each day), no identifier linking across days, and no analytics vendor beyond the database provider you already trust. European ePrivacy rules regulate storing or reading information on a visitor's device, and Measr's design leaves that mechanism unused — the same architecture privacy tools like Plausible and Fathom run without banners. 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 day-bounded hashed keys 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.