Going further

Cookies & privacy

One script, three modes. Swap data-mode to change the trade-off between attribution accuracy, storing anything on the device, and who handles the asking.

Which mode

The third mode, consent, is cookie mode with the asking handled: it behaves as cookieless until the visitor accepts a small built-in popup — shown only where the law requires one — and as cookie mode everywhere else. See consent mode below.

Cookie mode

numberhill.js stores a random 128-bit ID in the numberhill_visitor_id cookie — first-party, SameSite=Lax, Secure over HTTPS, expiry refreshed on each visit. Returning visitors are recognised for months, which is what makes long attribution windows accurate.

<script defer data-website-id="YOUR_SITE_ID"
  src="https://numberhill.com/js/numberhill.js"></script>

Cookieless mode

numberhill-cookieless.js derives the identifier in memory from coarse browser attributes plus the current UTC date. No lasting identifier is written to the device, and because the date is part of the input the identifier rotates every 24 hours.

<script defer data-website-id="YOUR_SITE_ID"
  data-mode="cookieless"
  src="https://numberhill.com/js/numberhill-cookieless.js"></script>

The trade-off is real: a visitor who returns after two days looks like a new person, so multi-week attribution is less precise. For short consideration cycles that rarely matters.

Consent mode

data-mode="consent" starts every visit cookieless, so nothing is stored and no visit is lost while the question is open. The script then asks the server which country the visitor is in (resolved at the CDN edge — no lookup service, no IP stored):

<script defer data-website-id="YOUR_SITE_ID"
  data-mode="consent"
  src="https://numberhill.com/js/numberhill.js"></script>

• Outside a consent country — the visitor is switched to cookie mode silently. Nothing is asked, so nothing is remembered; a visitor who travels into a consent country next week gets the question then.
• Inside one — a small popup offers Accept and Decline. Accept writes the cookie from that moment on. Decline keeps the visit cookieless — it is still counted, the visitor just looks new next time. Closing the popup answers nothing and it is asked again on the next visit.
• If the country cannot be determined — the popup is shown. The failure direction is always an unnecessary question, never an unconsented cookie.

The countries currently treated as requiring consent: the EU-27, Iceland, Liechtenstein, Norway (ePrivacy), the United Kingdom (PECR), Switzerland (nLPD) and Brazil (LGPD). The list lives on the server, so it can be corrected without waiting out script caches.

The choice is remembered in localStorage under numberhill_consent — storing the answer to "may we store things?" is the one write that needs no asking. The landing pageview of a visitor's very first visit stays on the rotating identifier; everything after acceptance uses the cookie.

The outbox

Both modes keep a short-lived outbox in localStorage under numberhill_q. It holds only events that failed to send — a dropped request, a tunnel, a blocked beacon — so a visit is not lost to one bad moment on the network. Entries are discarded after 30 minutes, at most 50 are kept, and the outbox is empty the rest of the time. Nothing ever reads it to recognise a visitor.

What gets collected

• Path and hostname of the page, plus the referrer and any UTM parameters.
• Ad-platform click identifiers when present in the URL — gclid, fbclid, msclkid and their equivalents. These are advertising identifiers, put on the link by the ad network rather than by us, and they are what makes a paid click distinguishable from an organic one.
• Screen size, window size and browser language.
• How the page was used: how long it was visible, and how far down it was scrolled. Both are measured in the browser and reported once, when the page is left.
• The destination of outbound link clicks and file downloads — where somebody went, not what they did after they got there.
• The browser's user-agent string, truncated to 256 characters. It is what distinguishes 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 when the event is received.
• Country, resolved at the CDN edge — the IP address itself is never stored.
• The visitor and session IDs described above.

No visitor IP addresses, no fingerprint hashes beyond the cookieless identifier, and no cross-site tracking — NumberHill only ever sees traffic on the sites you install it on.

The one exception: crawler IPs

Hits already classified as bots store their source IP in the bot table. That address is the only way to tell a real GPTBot from something wearing its name, and a verdict with no evidence behind it is worth nothing — see bots & AI crawlers.

This is crawler infrastructure, not people: the address belongs to a datacentre operated by OpenAI, Google or whoever is impersonating them. Nothing on the human side of the product changes — events, which is what every visitor, conversion and revenue number is built from, still stores no IP at all.