Privacy Policy

Meterio is run by Matilda Abuabdou, an individual trading as Meterio, based in the Netherlands. You can reach us at [email protected].

For account data we are the controller. We decide what to collect about you as a customer and why, and this policy is our notice to you.

For product analytics data we are a processor. You decide what your application sends us and why; we act on your instructions. You are the controller towards your own end users, which means the notice and — where required — the consent they see is yours to provide. Our processing obligations to you are set out in the data processing terms in section 7 of the Terms of Service.

As a Meterio customer, we hold:

• your email address — sign-in is by magic link, so there is no password and we never store one
• your organisation name, your application names, and the key action you have chosen for each application
• hashed API keys. We store a SHA-256 hash and a short display prefix, never the key itself, which is why a lost key can only be replaced and not recovered
• short-lived sign-in tokens, and the email address a magic link was sent to, until the link is used or expires

We use this to authenticate you, run your dashboard, answer support questions, and send service email such as sign-in links. Our legal basis is performance of our contract with you. For keeping the service secure and preventing abuse, our basis is our legitimate interest in a working service.

Today the only email we send is transactional. If we introduce a recurring summary email, it will carry a one-click unsubscribe and this page will be updated before the first one goes out.

When the Meterio SDK is installed on your site, it sends us, for each event:

• the event name and the page it happened on — path, full URL and referrer, with query-string values stripped where they look sensitive
• session state — a session identifier, when the session started, when it was last active, how many sessions that browser has had, and why a new one began
• a pseudonymous device identifier, so that a returning visitor is counted as the same person
• the user identifier you pass to identify(), and any traits you attach to that call
• browser and device metadata — browser name and version, operating system, device type, screen and viewport size, language, page title
• for autocaptured interactions: the element clicked and its visible text, form identifiers, scroll depth, time on page, and for inputs the length of what was typed

We use this only to compute the metrics we show you and to keep the service running. We do not sell data, we do not build advertising profiles from it, and we never mix one customer's data with another's.

What you send is your decision. Anything you attach to an event property or a trait reaches us as-is. Do not send special categories of personal data, government identifiers or financial account numbers — the Terms prohibit it, and we have no way to detect it on the way in.

This list is as much a part of the design as the list above, and it is enforced in the SDK rather than by policy:

• No input values. Only the character count is recorded. Password, credit-card and other sensitive fields are skipped entirely, matched on type, name, id or autocomplete attribute
• No cookies. The SDK sets none. Nothing we place on your visitors' devices can be read by any other site
• No cross-site tracking. A device identifier is scoped to the site that generated it; we do not link identities across customers
• No session recording, no heatmaps, no keystroke capture, no screen capture. This is a property of the SDK, so it holds for your visitors. Our own dashboard is a separate matter and is covered in section 7
• No location data. We do not derive country, region or city, and store no geolocation field of any kind
• No IP addresses in storage. See the next section — the distinction matters
• Email addresses and long digit sequences are scrubbed out of captured URLs and visible text before the event leaves the browser

Your visitors' IP addresses reach our servers, because every HTTP request carries one. We want to be precise about what happens next, since “we don't collect IPs” is a claim people make loosely.

• We do not store IP addresses alongside events. There is no IP column on any analytics table, and nothing derived from an IP — no country, no region
• We do use the IP transiently to rate-limit our ingest endpoint. A counter keyed on the address is held in memory for at most 61 seconds and then expires
• Our servers and our network provider keep short-lived operational logs that include IP addresses, as any web server does. These exist to diagnose faults and investigate abuse, and are not used for analytics

The SDK checks two browser privacy signals before every capture. If Global Privacy Control or Do Not Track is set, the SDK stays silent, and a subsequent call to optIn() is ignored. The browser signal wins unconditionally and cannot be overridden by configuration.

By default the SDK begins capturing on load, which suits an opt-out posture. Setting requireConsent: true makes it dormant instead: no events, and not a single storage key written, until you call optIn(). If your visitors are in the EU or UK and you need consent before any non-essential storage, that is the mode to use — and the choice is yours to make, not ours, because we do not know what you have told your users.

Calling optOut() stops capture immediately and discards anything still queued, without a final beacon. That decision survives page reloads and survives reset(), so an opted-out visitor stays opted out.

On your site, the SDK writes a small set of meterio_-prefixed entries to local storage: a device identifier, session state, a session counter and date, the last identified user id, and consent state. No cookies, and no traits — an email or plan name you pass to identify() is held in memory for the page and sent with that event, never written to disk.

reset(), which you should call on logout, clears identity and session. A full erasure additionally sweeps every meterio_ key except consent, which is deliberately preserved — forgetting that someone opted out would silently opt them back in.

On meterio.app, the dashboard stores your sign-in token in local storage; without it you would be signed out on every page load, so it is essential and cannot be turned off while you are signed in. We also use a third-party product analytics provider to understand how meterio.app is used, and this one we ask about first: nothing is measured until you accept the consent banner, and declining costs you nothing — the dashboard works identically either way.

If you do accept, it applies to your whole visit, signed in or not, and it is broad. We record the pages you visit and the full URL of each, query strings included; clicks and other interactions with the interface, captured automatically rather than one event at a time; and a replay of your session in the browser. We may also show you in-product surveys, and we record when you leave a page as well as when you arrive on it. If you sign in later in the same visit, the activity recorded beforehand is linked to your account.

Accepting also means the provider writes its own identifiers into this browser — a durable visitor id, plus session and replay state, in cookies and local storage. Every visitor gets one, including a visitor who never signs in. That storage is the thing your consent is actually for: it is what lets separate visits be recognised as the same browser. Declining means none of it is written, because the provider is never loaded at all.

Whichever way you answer, we keep a record of it in your browser — the answer, when you gave it, and the version of this policy it was given against. That record is how we can show what you agreed to, and it is why a material rewrite of this section means we ask you again rather than relying on an older yes. Text you type is masked out of session replays.

You can change your mind at any time from Analytics preferences in the footer of any page, which reopens the banner. Withdrawing takes effect straight away — capture and any recording in progress stop on the spot, not at your next visit. If your browser sends a Global Privacy Control or Do Not Track signal when a page loads, we treat that as a refusal that overrides anything decided before: you are not asked, and analytics is not loaded.

The SDK can detect a signed-in user from a supported authentication provider rather than waiting for an explicit identify() call. Every one of these paths is off unless you turn it on, and each has its own flag: identifyFromJWT, captureIdentifiedEmail, identifyFromAuthEndpoint and identifyFromDomAttribute.

captureIdentifiedEmail deserves a specific mention: enabling it means email addresses found by any automatic detection path are sent to us as event properties. That is a decision to transmit personal data, and it should be a deliberate one. All of these flags remain subordinate to the consent rules in section 6 — a GPC signal suppresses them regardless of configuration.

Your analytics data is stored on servers in Germany. These are the providers that process personal data on our behalf, each under a contract limiting them to providing their service to us:

• Hetzner Online GmbH (Germany) — Application servers, database and queue — where your analytics data is stored
• Cloudflare, Inc. (United States, with a global network) — Serves the website, dashboard and SDK bundle; DNS and network protection
• Resend (Plus Five Five, Inc.) (United States) — Delivers sign-in links and service email
• PostHog, Inc. (EU Cloud) (European Union (Frankfurt)) — Usage analytics and session replay for meterio.app itself — only for visitors who accept the consent banner

Two of these are established in the United States, so some data leaves the European Economic Area. Where it does:

• Cloudflare — EU-U.S. Data Privacy Framework, with Standard Contractual Clauses as a fallback
• Resend — Standard Contractual Clauses

We will tell account holders before adding a sub-processor that stores analytics data. Beyond these, we disclose data only where we are legally required to, or where it is necessary to investigate abuse or protect the service.

Product analytics data is kept for six months from the date of each event, after which it is deleted. Your charts therefore cover a rolling window of six months rather than the whole life of your account.

When you close your account we delete your analytics data, without waiting for that period to run.

Account data is kept while your account is open. Unused magic-link tokens expire and are cleared.

Analytics about visitors to meterio.app — the measurement described in section 7, which only happens if you accept it — is kept for one month, session replays included, after which it is deleted. Withdrawing consent stops further collection but does not shorten that period for what was already recorded; ask us and we will delete it.

For the account data we hold about you, you can ask for a copy, ask us to correct it, ask us to delete it, ask us to restrict or object to how we use it, and ask for it in a portable format. Write to [email protected] and we will respond within one month.

There is no self-service export or account deletion in the product yet, so these requests are handled by hand today. That is a gap we intend to close, and stating it here is more useful to you than implying a button that does not exist.

If you think we have handled your personal data badly, you can complain to us first — we would prefer that — and you can lodge a complaint with a data protection supervisory authority. Ours is the Autoriteit Persoonsgegevens, and you may also go to the authority where you live or work.

If you reached this page because a site you visited uses Meterio, we hold data about you only on that site operator's behalf, and we are not permitted to act on it unilaterally. The operator of that site decides what is collected and is the right first contact for an access or deletion request.

Write to them, not us. If they come to us, we will action it promptly. If you cannot identify who to contact, email us and we will help you work out where the data came from.

Traffic is encrypted in transit. API keys are stored only as hashes. Every analytics query is scoped to a single organisation and application, so one customer's data cannot be read through another's account. Ingest is rate-limited. Revoking a key takes effect immediately.

The database is backed up nightly, encrypted, and kept off the server it came from. Nightly is not continuous, so a serious failure could still cost up to a day of recent data: treat Meterio as a view onto your product rather than a system of record, and do not let it hold the only copy of anything you would miss. When we delete data, copies can remain in a backup until that backup expires.

We will update this page when the practices it describes change, and move the “last updated” date at the top. Material changes will also be announced by email to account holders.

Questions about this policy, or about data we hold: [email protected].