Privacy policy

We run WebMetric. Our registered address is KN 78 St, Nyarugenge, Kigali, Rwanda. You can reach us about privacy at [email protected].

We hold two kinds of personal data, in two different roles:

• About account holders, the people who sign in to WebMetric. For this data we are the controller, and this policy applies.
• About visitors to our customers’ sites. For this data our customer is the controller and we are its processor. The data processing agreement governs it, and the site’s own privacy notice tells visitors how it is used.

Paddle collects your payment details directly. We receive your subscription status from Paddle, never your card number.

When you are signed in, we set one cookie that holds an opaque session token. It contains no roles or personal details. A second cookie remembers the language you chose. Your light or dark theme choice is kept in your own browser’s storage and never sent to us. If you pick a paid plan before creating your account, your browser keeps that choice in its storage for up to seven days, so that confirming your email address brings you back to it.

• To provide the service you signed up for, which is our contract with you.
• To keep accounts secure and keep an audit trail, which is our legitimate interest.
• To meet legal duties, such as answering lawful requests.

We do not sell personal data and we do not use it for advertising.

This section describes how WebMetric treats the visitors to our customers’ sites, so that customers can describe it accurately in their own notices.

• Nothing is written to the visitor’s device. Our script sets no cookies and uses no local storage, session storage or IndexedDB.
• A visitor is identified by a pseudonymous hash that our collector computes with a secret that changes every half-year, on 1 January and 1 July (UTC). Each secret is deleted one day after its half-year ends, after which nobody, including us, can work out which address produced a hash.
• Visitors are counted per half-year. The same person on the same browser and network counts once from 1 January to 30 June and once from 1 July to 31 December, and their visits within a half-year share one visitor id. A new browser, device or network counts as a new visitor.
• Visits are not linked to a named person. Our script collects no name, email address, account id or device identifier. Once a half-year’s secret is deleted, nobody, including us, can recompute that half-year’s visitor ids or match them to visits in another half-year.
• A session is a run of activity with no gap longer than 30 minutes. Sessions are worked out on our servers.
• No IP address is stored. The collector uses it in memory to compute the half-year’s hash and to look up the country, region and city in a copy of the DB-IP geolocation database held on our own server. Then it discards the address.
• Do Not Track and Global Privacy Control are honoured by our script, which sends nothing for a visitor whose browser sends either signal. This cannot be turned off. The collector checks both signals again and discards any request that carries one. A site owner can turn off only this second check.
• Known bots are dropped at the collector.

If you visited a site that uses WebMetric and want to exercise your rights, contact that site. It is the controller, and it can ask us to delete your data. Because visits are not linked to a person, it will need details such as the date and pages of your visit to find them. If you write to us, we will pass your request on.

Everything our script collects is sent to our collector and kept on our servers, never on the visitor’s device. It collects:

• Events. Page views, clicks, scroll depth, form submissions and the custom events a site sends. Each carries the page address, the time and the viewport size. A click also carries its position, the element’s CSS selector and, when it lands on a button or link, the kind of control and its visible label, such as “Start free”. A label is never taken from a form field or from text the customer masks, and any email address or long number in it is removed. Form values are never part of an event.
• Device details. The device type, browser and operating system, read from the user agent, and the country, region and city, looked up from the IP address before the address is discarded.
• Heatmap page captures, where the customer turns them on. A copy of the page’s layout and styles, so a heatmap can be drawn over it. All text on the page is masked in the browser before the capture is sent, and so are form inputs and readable attributes such as alt and title. Images are not copied. A capture belongs to the page, not to a visitor, but it records which visitor id’s page load it was taken from.
• Session replays, where the customer’s plan and settings include them. The changes to the page during a visit, recorded as page structure rather than video. Masking happens in the browser before anything is sent: every form input is masked, password and payment fields are never captured, and the customer’s mask selectors hide any other text.

How long each of these is kept is in section 8.

Each event carries the address of the page. Before it is sent, our script removes anything after a #, any user name or password in the address, and every query parameter except the campaign tags utm_source, utm_medium, utm_campaign, utm_term and utm_content. The collector applies the same rule again before anything is stored. What remains is kept up to 2,048 bytes, and reports group pages by path.

The referrer is the page the visitor came from. It is sent and stored as its origin and path only, such as https://example.com/blog/post, with no query string and nothing after a #. Reports show only the referring site’s host name.

The campaign tags are read to show where visits came from.

A page path can still hold personal data if a site puts it there, for example /users/[email protected], so a site should keep personal data out of its paths. If such data reaches us, it is deleted when the visitor is erased, and otherwise when the plan’s history period ends.

We run WebMetric and send its email from our own servers, in a data centre in the European Union. The one outside provider we use is Paddle, which takes payment; it is listed with its purpose and region on the subprocessors page. Paddle takes payment as Merchant of Record, so for your payment details Paddle acts under its own privacy policy.

Each store has its own window. Expiry is enforced by the database or by a daily job, so these are the windows the system actually applies.

Raw visitor events are kept for the history period of the customer’s plan:

A customer can erase a visitor id from a project. Erasure deletes, for that id:

• its events and visit sessions;
• its session recordings, including the stored files;
• the heatmap page captures taken during its page loads, including the stored files;
• its share of the daily totals, click counts and scroll depth counts, which are recalculated from the remaining events for every day whose events are still stored.

Totals for older days hold counts only, with no visitor id, and stay as they are. The erasure is written to the customer’s audit log with what was deleted.

The visitor id changes every half-year, so one erasure covers a person’s visits in one half-year, from one browser and network. Erased data disappears from reports at once, leaves the live systems within 30 days, and leaves our backups within a further 35 days.

Depending on where you live, you can ask to see the data we hold about you, correct it, delete it, restrict or object to how we use it, or receive a copy in a portable format.

• You can change your name and password and sign out other devices yourself, on your profile page.
• For anything else, write to [email protected]. We answer within one month.
• You can also complain to a data protection authority, such as the one where you live or work.

We are based in Rwanda. The data we store is kept in the European Union: the website, the dashboard, our application and every database run on our own server, in a data centre in the European Union. Each provider and its region is listed on the subprocessors page.

Our team works from Rwanda, so when we reach that data, for example in a support session, it leaves the European Union. For that access, and wherever else data about people in the European Economic Area, the United Kingdom or Switzerland goes to a country without an adequacy decision, we rely on the Standard Contractual Clauses, as set out in the data processing agreement.

When you ask for help, someone on our support team may need to look at your workspace. This is tightly limited:

• Staff status is granted directly in our database. No form or invitation can grant it.
• A support session covers one organization, lasts one hour and cannot be extended.
• Staff must give a reason, and the reason is written into your audit log word for word.
• The start and end of every session appear in your audit log, with the staff member’s email.
• A support session is read-only. It cannot change settings, members, billing or anything else.
• It cannot open session recordings, and it cannot read your member list.

Passwords and read keys are hashed with Argon2id. Session tokens are stored only as hashes. Every request is checked against the organization that owns the data, so one customer cannot reach another’s. Session recordings are served through our API after that check, never through shareable links.

To report a security issue, write to [email protected]. We confirm that we received your report and tell you when the issue is fixed.

If we change this policy in a way that matters, we will email account holders before the change takes effect. The date at the top of this page shows the current version.