Privacy & data

This page is the technical companion to the privacy policy: what the tracker actually collects, how visitors are counted without cookies, and where the hard limits are.

No cookies, no persistent identifiers

The tracking snippet sets no cookies and stores nothing on a visitor's device that outlives the browsing session, with one exception: the voluntary opt-out preference (below), which the visitor sets themselves. There is no fingerprinting library, no cross-site identifier, and no consent banner requirement created by the tracker itself.

What an event contains

• The page URL and the referrer.
• The event name and any custom properties the site owner sends (sanitized, see below), plus optional revenue.
• The browser and operating system family (Chrome, Firefox, Safari, Edge, Opera, Other; Windows, macOS, iOS, Android, Linux, Other) and the major version only, such as “Chrome 120”. The full build string a browser sends is not stored: it changes every few weeks and narrows a device far more than it informs a report.
• A screen-size bucket from the viewport width: Mobile (under 576px), Tablet (under 992px), Laptop (under 1440px), or Desktop. The exact width is not stored.
• How far the page was scrolled (a percentage) and how long it was on screen (in seconds), sent once when the page is left. Time accrues only while the tab is visible, so a page left open in a background tab does not inflate it. Neither field identifies the visitor.
• Approximate location derived from the IP at collection time.
• The daily visitor hash and a session id (both below).

Three further reports are sent to separate, unbilled endpoints. They carry the same visitor hash and session id as above and nothing new about the visitor:

• Clicks and form submissions. The element clicked, described as a tag/id/class selector plus its visible label, and for a form its authored name and field count. A value a visitor typed is never read: for input fields the label falls back to the aria-label, placeholder or field name, all authored by the page. See Click autocapture.
• Page speed. The browser's own timings for the page load, plus what caused them: the element that painted largest, the element that shifted, the control the slowest interaction hit, and the URL of the script that blocked longest. All structural, no page text. See Speed.
• JavaScript errors. The error type, its message and a capped stack trace with every URL stripped of its query string. See Error tracking.

A site can also attach page context its server knew - that the response was a 404, the term behind a search results page, a post's author, whether the reader was signed in. These are properties the site chooses to send, subject to the same limits as any custom property, and the same rule applies: do not put personal data in them.

The daily visitor hash

Visitors are counted with a one-way SHA-256 hash of the site id, IP address, and user agent, salted with a server secret. The salt is derived from the current date and the site, so it rotates every day and differs per site. The consequences:

• The hash cannot be reversed to recover an IP or user agent.
• The same visitor produces a different hash tomorrow: no cross-day tracking, no visit history per person.
• The same visitor produces a different hash on every site: no cross-site correlation.
• The raw IP and user agent are never stored with events. They are used transiently to compute the hash, classify bots, derive approximate location, and rate-limit, then discarded.

If the server secret is missing, the collector refuses to compute hashes at all rather than fall back to a weak salt. The guarantee fails closed.

Sessions

Sessions use a random id kept in the visitor's own sessionStorage, rotated after 30 minutes of inactivity and cleared when the tab closes. It exists only to order one visit's hits so bounce rate, visit duration, funnels, and flows can be computed. It identifies a tab, not a person.

Custom property limits

Custom event properties are sanitized server-side: at most 30 properties per event, keys and values truncated to 300 characters, string/number/boolean values only (nested objects and arrays are dropped). These are hard caps, but they do not decide what is appropriate to send: do not put emails, names, or other personal data in properties.

Bot filtering

Every event is classified server-side before storage, from the user agent and from signals that describe the environment rather than the visitor: automation flags a real browser never sets, a GPU-less renderer, a window with no browser chrome, a datacenter IP range. Those signals can only ever exclude the hit that carried them, never single a person out.

Major AI and search crawlers are additionally verified against the vendors' published IP ranges, so a visit labeled GPTBot or Googlebot can be marked as genuinely from that vendor rather than a spoofed user agent. Stored bot events are never billed: only human pageviews count toward the plan quota. The junk classes are dropped before storage entirely.

The page-signal fingerprint

For change detection, the snippet sends a small numeric hash of the page's own content (title, meta description, first heading, approximate text length). It describes the page, not the visitor: it contains no visitor data, is not an analytics event, and is not billed.

Visitor opt-out

Numative honors Do Not Track and Global Privacy Control. When a site turns on Respect Do Not Track in its settings, a visitor sending either signal is not counted at all: the collector drops the hit before anything is stored.

Because the data is already cookieless and carries no cross-site identifier, there is nothing stored in a visitor's browser to clear, and nothing to opt out of beyond that signal. Site owners excluding their own traffic use the site's excluded IP addresses instead.

Retention

Two horizons, deliberately different:

• Aggregated traffic history is kept forever, on every plan. Visitors, visits and pageviews over time go back to the site's first day and never expire.
• Raw, row-level detail - the individual events behind breakdowns, filters, journeys, per-visitor paths, page speed and error history - is kept for a per-plan window, from 12 months on the smallest plans up to 10 years on the largest. See Plans & billing for the table.

Older detail is rolled into the permanent aggregates rather than deleted outright, so long-range trends stay intact and only the deep drill-down for very old dates ages out. Deleting a site removes its analytics data, and deleting your account removes your account data.

GA4 mode

For sites that connect Google Analytics instead of installing the snippet, Numative reads reporting data from the GA4 API on your instruction and collects nothing from that site's visitors itself. Google's data practices apply to the collection; Numative is a read-only consumer of the reports.