PECR and ePrivacy
The current tracker story for HitKeep is:
- cookie-free by default
- not storage-free
That difference matters for PECR and similar ePrivacy-style rules.
Why “Cookie-Free” Is Not The Same As “PECR-Exempt”
Section titled “Why “Cookie-Free” Is Not The Same As “PECR-Exempt””The public tracker does not set analytics cookies by default.
But it does currently store a short-lived session identifier in browser sessionStorage to keep pageviews within one browser session tied together.
That matters because PECR-style rules are generally not limited to cookies. They also cover:
- storing information on a device
- accessing information from a device
- similar technologies such as local storage or session storage
So the defensible current claim is:
- HitKeep reduces consent and tracking surface compared with cookie-based analytics
- but you still need to assess PECR / ePrivacy consent rules for the current tracker behavior
What Helps
Section titled “What Helps”HitKeep improves the PECR picture compared with many analytics tools because:
- no analytics cookies are set by default
- the public tracker omits third-party ad-tech integrations
- DNT is respected by default
- dashboard auth cookies are limited to the logged-in app
What Still Triggers PECR Analysis
Section titled “What Still Triggers PECR Analysis”The relevant PECR / ePrivacy question for HitKeep is not:
“Do we use cookies?”
It is:
“Are we storing or accessing information on the user’s device for analytics?”
For the current public tracker, the answer is yes because of sessionStorage.
That means:
- you should document it in your cookie/privacy notice
- you should assess whether consent is required in your jurisdiction
- if consent is required, load
hk.jsonly after consent
Dashboard Cookies and Service State
Section titled “Dashboard Cookies and Service State”HitKeep also uses browser-side state for the logged-in dashboard, including:
- HTTP-only session cookies for authentication
- dashboard-side local storage or similar browser state for UI preferences and passkey UX hints
Those are a different category from the public analytics tracker. Authentication/session cookies for a logged-in service are often easier to justify as strictly necessary, but you should still disclose them clearly.
Conservative Recommendation
Section titled “Conservative Recommendation”If you want the most defensible current position, treat HitKeep like this:
- Public tracker: cookie-free, but still subject to PECR / ePrivacy assessment because of
sessionStorage - Logged-in dashboard: uses service-related auth/session state that is usually easier to justify as strictly necessary
- Public claims: do not market the current tracker as automatically “banner-free” in all jurisdictions