A practical guide for site owners, developers, and privacy reviewers
HitKeep measures pageviews, sources, campaigns, events, goals, funnels, and ecommerce without analytics cookies in the public tracker. This guide explains what that does and does not mean, which data reaches HitKeep, and which decisions still belong to the site operator.
Cookieless analytics removes one common tracking mechanism. It does not automatically settle every privacy, consent, or ePrivacy question. HitKeep keeps the public tracker cookie-free by default, stores an opaque session tuple in sessionStorage, respects Do Not Track by default, and keeps deployment and retention choices visible.
“Cookieless” describes storage behavior in the browser. A useful privacy review goes further and checks identifiers, request data, purposes, retention, recipients, and deployment.
| Technical fact | HitKeep behavior | What the operator still checks |
|---|---|---|
| No analytics cookies | HitKeep’s public tracker does not create analytics cookies by default. | Verify the rest of your site separately. Login, commerce, embeds, chat, and advertising tools may still set cookies. |
| sessionStorage is separate | HitKeep can use sessionStorage for an opaque session tuple that expires with the browser session. | Depending on the jurisdiction and setup, access to browser storage can still be relevant under ePrivacy or PECR rules. |
| No advertising identity graph | HitKeep does not include retargeting audiences, cross-site advertising profiles, or ad-network synchronization. | Custom events can still contain sensitive data if you send it. Keep names and properties deliberate. |
| Do Not Track support | DNT is respected by default unless collection is explicitly configured otherwise. | Document any override and make sure it matches your public privacy explanation. |
The accepted hit contains reporting context, not a raw copy of the browser request. These are the fields a site owner should understand before writing a privacy notice.
| Area | Recorded or derived | Privacy boundary |
|---|---|---|
| Page and acquisition | Page path, referrer, landing and exit context, UTM campaign parameters | Useful for traffic sources and campaign reporting |
| Browser and device | Browser, device, operating system, and language context | Used for aggregate audience reports |
| Location and network | Derived country, region, city, provider, and ASN when IP metadata is available | The raw visitor IP is not stored as an analytics-hit field |
| Sessions | An opaque session tuple in sessionStorage | No analytics cookie is set by the public tracker |
| Automatic events | Outbound clicks, file downloads, and form submissions | Query strings, hashes, link text, form values, and request bodies are excluded from automatic-event content |
| Conversions | Custom events, goals, funnels, and ecommerce events you configure | You control event names and properties; do not send personal or secret values |
Privacy is also an operating-model decision. HitKeep keeps the managed and self-hosted paths on the same product foundation and provides open-format takeout.
| Choice | What HitKeep provides | Your responsibility |
|---|---|---|
| Managed EU Cloud | Managed operation in the EU region | Choose the EU region during signup and record the service in your privacy and processor documentation. |
| Managed US Cloud | Managed operation in the US region | Use when the US region fits your users and obligations; assess transfers when EU/UK data is involved. |
| Self-hosted | Run HitKeep on infrastructure you control | You control network, backups, retention, access, updates, and incident response. |
| Retention | Product retention and archive controls | Set periods that match the purpose you documented instead of keeping analytics indefinitely. |
| Takeout | Site data in JSON, CSV, Parquet, NDJSON, or XLSX | Export before a migration and test that the format fits your downstream use. |
Use this as a technical starting point, not as legal advice. Replace every bracketed passage and remove anything that does not match your configuration.
We use HitKeep to understand how our website is used. The analysis covers pageviews, traffic sources, campaigns, and the events or conversions that we configure. We do not use HitKeep to create advertising profiles, retarget visitors, or synchronize audiences with advertising networks.
Operation: [self-hosted on infrastructure we control / HitKeep Cloud in the EU region / HitKeep Cloud in the US region]. The public HitKeep tracker does not set analytics cookies. Depending on our configuration, an opaque session tuple may be stored in sessionStorage for session continuity.
The processed data can include page path, referrer, browser and device context, language, UTM parameters, and derived location and network metadata. Raw visitor IP addresses are not stored as an analytics-hit field, but may be processed transiently for location, security, trusted-proxy, exclusion, or spam-protection functions.
Our legal basis is [insert the basis confirmed for this deployment]. We retain analytics data for [period]. You can [object / withdraw consent / change privacy settings] by [method]. Further technical details are available in [link to this page or your own technical explanation].
The page is ready when the public wording and the deployed configuration say the same thing.
These pages are the current product references for the claims above.
Start in managed Cloud and choose the EU or US region before account creation, or install the open-source product on infrastructure you control.
Read the newest release first, then move through practical GA migration guidance for privacy-first and cookieless analytics.
Release v2.13.0
HitKeep 2.13.0 adds scheduled reporting, social sign-in, the typed @hitkeep/tracker SDK, prerender-safe collection, and isolated tenant analytics databases.
Read release notesFrom the blog
Stakeholders rarely need more Google data; they need clearer decisions. This playbook turns search visibility, web traffic, conversion, and AI-era signals into recurring reporting that leads to action instead of chart fatigue.
A practical 2026 guide to measuring visitors, sources, campaigns, search performance, conversions, and AI traffic without GA4.
A practical 2026 decision guide to GA4 and privacy-first analytics across consent, cookies, data control, AI traffic, and migration paths.
No. The public HitKeep tracker does not set analytics cookies by default. It can use sessionStorage for an opaque session tuple, which is a separate browser-storage mechanism.
Possibly, but “no cookies” is not enough to answer that for every site or jurisdiction. Review sessionStorage, the data and purpose, your legal basis, other page tools, consent or objection handling, and local ePrivacy or PECR rules.
Raw visitor IP addresses are not stored as an analytics-hit field. An address can be processed transiently for derived location and network metadata, trusted-proxy resolution, exclusions, security, or spam protection.
No product can make that universal promise. HitKeep reduces the default tracking surface, but the controller still decides purpose, legal basis, retention, access, processor terms, transfers, and public information.
Yes. HitKeep is open source and can run on your own infrastructure. Managed Cloud is also available in EU and US regions on the same product foundation.
HitKeep provides site takeout in JSON, CSV, Parquet, NDJSON, and XLSX. Review the takeout guide for the included analytics and control records.
No. It is a technical template. Replace the hosting model, legal basis, retention, processor, consent or objection path, and contact details so the text matches your deployment.
