GDPR, cookieless tracking & tracking modes

How XPmetric's cookieless mode works (daily-rotating server-side hash), what the optional cookie mode changes, and when you need a consent banner.

XPmetric offers two tracking modes per site — you choose one when you create the site and can switch anytime in Settings → Sites:

  • Cookieless (default) — the XPmetric tracker stores no identifier on the visitor's device. A banner is usually unnecessary for XPmetric analytics alone; your other tools and local rules may still require one.
  • Cookie (opt-in) — a single first-party cookie for maximum accuracy; depending on where your visitors are you may need a consent banner.

Each mode has its own script, so switching modes changes your snippet — re-copy it from Settings → Sites → Get Script and redeploy.

For XPmetric's own legal terms, see the Privacy Policy.

Cookieless mode (default)

The cookieless script (p.js) writes nothing to the visitor's device and reads nothing from it:

  • Sets no cookies on your domain
  • Uses no local or session web storage — not for a session id, not for anything
  • Computes no fingerprint on the visitor's device — the script sends no identity signals at all
  • Uses no cross-site identifiers

This matters beyond cookies. German § 25 TDDDG also covers storing or accessing information in other storage on a visitor's device. p.js does neither. Check the rest of your site's technology and the rules applying to your visitors before deciding whether a banner is needed.

Both the visitor id and the session are derived on our servers: a hash of the visitor's IP address, user agent, and your site, salted with 32 random bytes that change each UTC day. Each salt expires after up to 48 hours. The identity used by analytics is day-scoped. Hashing includes your site's id, so the same person on two XPmetric-tracked sites does not share an identifier.

A session is the same thing seen over a 30-minute window: consecutive pageviews from the same daily identity, with the window sliding on each event. It lives in our server-side cache, never on the device, and it cannot span a day boundary because the identity itself rotates. Two tabs open on your site are therefore one session, and a visitor who wanders off for half an hour and comes back starts a second one.

The default mode has no persistent visitor identifier across days. Optional cookie mode has a different retention and consent tradeoff.

The honest tradeoff

Because identity rotates daily, a visitor who returns tomorrow looks like a new visitor:

  • No new-vs-returning breakdown (it would be meaningless)
  • Visitor journeys are day-scoped — multi-day activity appears as separate visitors
  • First-touch attribution is scoped to each UTC-day visitor ID — a delayed payment carrying that ID can still match the day's visit, but a return visit on another day gets a new ID and cannot recover the original source
  • Visitor-scoped funnels can't complete across days (use session scope or a ≤24h window)

Daily aggregates — pageviews, visitors per day, top pages, channels, countries, goals — stay fully meaningful.

The cookie script (p.cookie.js) stores a random visitor id in a first-party cookie (_xpm_id, 1 year) on your domain. It is never used across sites and contains no personal data — just a random id.

You get:

  • Accurate multi-day visitor journeys and returning-visitor stats
  • Reliable revenue attribution for delayed conversions
  • Visitor-scoped funnels with long windows

The tradeoff: a cookie used for analytics may require visitor consent depending on where your visitors are (e.g. under the ePrivacy rules). That consent banner is your responsibility — XPmetric does not ship one.

Switching modes

Settings → Sites → Tracking mode. A confirmation dialog explains what changes. After switching, re-copy the snippet and redeploy — the old script keeps running in the previous mode until you swap it. Identity continuity resets at the switch (existing visitors get new ids).

No raw IP storage

In both modes, IP addresses are used only transiently at ingest — for country/city geolocation and (in cookieless mode) as hash input — and are never stored in analytics tables.

What you collect as site owner

Per pageview, XPmetric stores:

  • HTTP(S) page origin and pathname, with utm_source, utm_medium and utm_campaign when their values are safe
  • Referrer origin only; path and query details are discarded
  • Device type, browser, OS
  • Country and city (from geoip)
  • Custom events you explicitly fire

You are the data controller for your visitors' analytics. XPmetric processes this data on your behalf as a processor — see our Data Processing Agreement, Privacy Policy and Terms. Sub-processors: /subprocessors.

URL credentials, fragments and other query parameters are not stored. Sign-in, verification, callback and password-reset routes are omitted because their paths may contain authentication tokens.

GDPR rights

Your visitors can exercise rights through you as the site owner. XPmetric account holders can export or delete their own account data from Settings.

In cookieless mode (the default) — no, for XPmetric analytics alone. You may still need consent for other tools (ads, embedded widgets, other analytics).

In cookie mode — possibly. You opted into a first-party analytics cookie; whether that requires consent depends on where your visitors are. If in doubt, stay on cookieless mode — it's the whole point.