Privacy Policy

NumberHill handles two kinds of data, and your rights differ depending on which one you are asking about.

• Your account. If you sign up for NumberHill, we are the controller of your account data — your email address, your name if you gave one, your sites, and your subscription record.
• Your visitors and buyers. When you install the script, the data it collects about the people using your website is yours. You decide what to collect and why; we store and process it on your instructions. You are the controller, we are the processor.

That second relationship means the legal basis for collecting your visitors' data, any consent banner it requires, and your own privacy policy are your responsibility. We cannot give you a lawful basis you do not have.

The script records what is needed to attribute a payment back to the visit that produced it, and nothing beyond it:

• Page path and hostname, the referrer, and any UTM parameters on the URL.
• Ad-platform click identifiers already present on the URL — gclid, fbclid, msclkid and their equivalents. These are placed on the link by the advertising network before the visitor ever reaches your site; we read what is there so a paid click can be told apart from an organic one. We do not create them, and they are not used to follow anyone across sites.
• Screen size, browser window size and browser language.
• How the page was used: the time it was actually visible, and the furthest point scrolled. Measured in the browser and sent once, when the page is left.
• The destination of clicks on links leading away from your site, and of file downloads. We record where the link pointed, never anything about the page it led to.
• The browser's user-agent string, truncated to 256 characters. It is what separates a customer from a crawler, so bot filtering is only honest if it is recorded. Browser, operating system and device class are derived from it on receipt.
• A two-letter country code. This is resolved by our hosting platform's edge from the connection — we never read or store the visitor's IP address for ordinary traffic. There is no IP column on the events table at all.
• A visitor identifier and a session identifier, described below.

NumberHill only ever sees traffic on the sites the script is installed on. There is no cross-site profile and no data sharing between customers. The click identifiers above are the one advertising-related value recorded, and only when an ad network has already put one on the URL — nothing is added, and none of it leaves your account.

Two modes are available and the site owner chooses one per site. Both are served by the same script, which reads its mode from the tag.

• numberhill.js stores a random 128-bit identifier in a first-party numberhill_visitor_id cookie — SameSite=Lax, Secure over HTTPS, expiry up to 365 days and refreshed on each visit. This is what makes long attribution windows accurate, and it is the mode that usually requires a consent banner.
• numberhill-cookieless.js stores no lasting identifier. The identifier is derived in memory from coarse browser attributes plus the current UTC date, so it rotates every 24 hours and a returning visitor looks like a new person the next day.

Both modes keep a short-lived outbox in localStorage under numberhill_q, holding only events that failed to send — a dropped request, a lost connection. Entries are discarded after 30 minutes and the outbox is empty the rest of the time. It is never read to recognise a visitor. Note what this means in cookieless mode: while an event is waiting there, that day's rotating identifier is on the device inside it. That is a change from earlier versions of this script, which stored nothing at all, and it is why this paragraph exists.

The scripts do not manage consent for you. The cookie script sets its cookie as soon as it loads, so if your jurisdiction requires prior consent, you must gate the script yourself. Storage rules in some jurisdictions cover localStorage as well as cookies, so if you rely on cookieless mode to avoid a consent banner, confirm the outbox above with your own counsel. The technical detail is in the docs.

Two features let you attach your own data to a visitor, and both write whatever you give them into the event record:

• window.numberhill.identify(traits) stores the traits object as-is.
• The data-autoidentify attribute reads an email address out of form submissions on your site and sends it as a trait automatically.

When you connect Stripe, LemonSqueezy, Polar, Shopify or Dodo Payments, their webhooks send us each successful payment so it can be matched to a visit. We store the amount, currency, processor, transaction id, the landing page and traffic source, and — because the processors include them — the buyer's email address and name.

That is your customers' personal data held on your behalf. We do not email those people, market to them, or use their records for anything other than producing your reports.

Hits classified as bots — GPTBot, ClaudeBot, PerplexityBot, Bytespider, scrapers, headless browsers — are excluded from your visitor and revenue metrics and recorded separately. Those bot records do store the source IP address, which is the only way to tell a real crawler from something wearing its name.

Classification is a judgement made from the user-agent string. It is good, but it is a heuristic, so a misidentified human visitor could have their IP recorded in the bot table. Ordinary traffic is never affected: the events table has no IP column to write to.

Signing up stores your email address and, optionally, your name. Authentication is handled by Supabase — including passwords, which are set and verified there and never pass through NumberHill's own code. You can sign in with Google instead, in which case Google confirms your identity to Supabase and we receive your email address.

If you subscribe, we store your plan, billing interval, status, period end, and the customer and subscription identifiers from our payment provider. Card details are handled by that provider and never reach us.

Your payment processors are not subprocessors — they send data to us, not the other way around. If you configure a webhook automation, NumberHill will post event data to whatever URL you specify; that destination is your choice and your responsibility.

Reports can be queried up to roughly two years back. That is a limit on what the dashboard will read, not a statement that older rows have been erased.

We would rather say this plainly than advertise a retention window we do not enforce. If that changes, this section changes with it.

You can export payment records and every report as CSV from the dashboard at any time. That export covers your reports and payments; it does not include raw event rows, bot records or your account record.

There is currently no self-service button to delete your account and its data. Email [email protected] and we will do it by hand — account, sites, events, payments and bot records — and confirm when it is done. The same address handles access, correction and portability requests, including ones forwarded from your own users.

Data is held in Postgres with row-level security, so a query can only reach rows belonging to the account that made it. Sessions are cookie-based and verified server-side on every request. Payment-processor signing secrets are encrypted at rest when an encryption key is configured for the deployment.

No system is perfectly secure. If you find a vulnerability, email [email protected] and we will respond.

NumberHill is a business tool and is not directed at children. We do not knowingly create accounts for anyone under 16.

When this policy changes materially we will update the date at the top and, for changes that affect how account data is handled, email account holders. Continuing to use NumberHill after a change means the updated policy applies.