PECR and ePrivacy Analytics Review for HitKeep
Deze inhoud is nog niet vertaald.
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 opaque session ID and timestamp 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 retry queue, attribution values, and duplicate-pageview state are kept in JavaScript memory only
- 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
Deployment Choices
Section titled “Deployment Choices”Your deployment pattern affects the review:
| Pattern | PECR / ePrivacy point to review |
|---|---|
hk.js loaded immediately |
Public tracker writes sessionStorage, so assess consent before load |
hk.js loaded after consent |
Analytics starts only after the visitor has allowed it |
| Server-side tracking only | No browser storage from HitKeep tracker, but server logs and metadata still need privacy review |
| Dashboard login | Auth cookies and UI preferences belong to the logged-in service, not public visitor analytics |
If your legal basis or jurisdiction requires consent for analytics storage, gate the tracker script in your consent manager. Do not load it first and ask later.
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
Related
Section titled “Related”- Compliance Overview
- GDPR Analytics Review
- Privacy-First Web Analytics
- Tracker Architecture
- Server-Side Tracking