ePrivacy Compliance

Disclaimer: The information below is not legal advice, and we don't accept any legal liability. We have received our own legal advice, and this page is our interpretation of the law. If you have any concerns regarding ePrivacy compliance, please forward this page to your legal team.

What is the ePrivacy Directive?

The Privacy and Electronic Communications Directive 2002/58/EC, commonly called the ePrivacy Directive or ePD, is an EU directive that protects the digital privacy of people within the European Economic Area. It governs the confidentiality of electronic communications, unsolicited messages, and (most relevant for analytics) the rules around cookies and similar technologies that access or store information on end-user devices.

Because it's a directive rather than a regulation, each EU member state has some flexibility in how it is implemented in national law. The UK transposed it as PECR. Germany, France, the Netherlands, and others each have their own implementation with varying degrees of strictness.

The planned replacement, the ePrivacy Regulation, was intended to arrive alongside the GDPR in May 2018, but remains unfinished. When it does come into force, it will apply uniformly across all EU member states without the nuance of national implementations. We are watching its progress closely.

What does the ePrivacy Directive require?

The key provision is Article 5(3):

"Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent..."

Two things trigger this rule:

1. Storing information in terminal equipment: writing to cookies, localStorage, sessionStorage, IndexedDB, or any other client-side storage mechanism.
2. Gaining access to information already stored in terminal equipment: reading device characteristics such as screen dimensions, installed fonts, WebGL capabilities, timezone, or any other property that identifies or characterises the user's device.

The term "terminal equipment" is deliberately broad. It covers not just cookies, but any technique that reads from or writes to a user's device, including the device fingerprinting practices used extensively by advertising technology and some analytics platforms.

There are two exceptions to the consent requirement: processing that is strictly necessary to deliver a communication over a network, and processing that is strictly necessary to provide a service explicitly requested by the user. Neither exception covers analytics.

What Clerion AI does, and does not, do

What we do NOT do

No cookies set by the tracking script. The Clerion Analytics SDK does not set any cookies for analytics purposes. No persistent cookies. No session cookies. No third-party cookies. No cookies are written to your visitors' browsers as part of event tracking.

No traditional device fingerprinting. We do not read canvas fingerprints, WebGL renderer strings, installed font lists, AudioContext hashes, browser plugin inventories, or any of the multi-point device signatures that advertising technology and some analytics platforms use to build persistent cross-site profiles. These are exactly the practices the ePrivacy Directive exists to prevent, and we do not engage in them.

No cross-site tracking. Session identifiers are scoped to a single origin and stored in sessionStorage, which is cleared automatically when the browser tab closes. They cannot be read by scripts on other websites. We do not link visitor activity across different websites.

No IP addresses stored. Raw IP addresses are never written to our database or any client-side storage. They are pseudonymised on the EU server immediately on receipt and discarded.

What we do

sessionStorage: session continuity. The SDK writes a session identifier to sessionStorage to group page events within a single browsing session. sessionStorage is cleared automatically when the tab is closed. It is not accessible to other origins, not shared across tabs, and does not persist between visits. We consider this use strictly necessary for the fundamental purpose of the service (correlating page events within a session), but we note that under the strictest readings of Article 5(3), sessionStorage is still "storage in terminal equipment" and we disclose it here accordingly.

Device characteristics for aggregate classification. The SDK reads a limited set of device properties from the browser environment: screen width and height, viewport dimensions, device pixel ratio, screen orientation, browser language, timezone, and basic network connection type. These are used exclusively to classify device type (mobile, tablet, or desktop) and to enrich aggregate audience intelligence. They are not combined into a fingerprint. They are not used to track individuals across sessions or websites. They are not linked to any persistent identifier without explicit user consent.

We are aware that reading these properties constitutes "gaining access to information in terminal equipment" under Article 5(3). This is why our SDK ships with a consent mechanism, detailed below.

Persistent visitor ID: consent-gated. The SDK can optionally create a persistent visitor identifier stored in localStorage. This is used to count returning visitors. This identifier is only created if the user has given explicit consent. It is strictly consent-gated in the SDK source code (if (this.consentStatus !== true) return null). Without consent, no persistent identifier is created, no localStorage is written, and each visit is treated as anonymous.

The built-in consent architecture

Clerion's SDK ships with a consent layer designed around ePrivacy Article 5(3) compliance. Here is how it works:

requireConsent: true is the default. Out of the box, the SDK requires consent before enabling persistent tracking. Site owners who have a documented legitimate interest basis may override this, but the default is consent-required.

Consent is stored in a first-party cookie. When a visitor grants or declines consent, their preference is stored in a first-party cookie (clerion_consent) scoped to the site's own domain. This is the consent record. Storing a consent preference in a cookie is considered strictly necessary and does not itself require consent.

Revoking consent clears all stored data. If a visitor revokes consent, the SDK immediately deletes the persistent visitor ID from localStorage. The next visit creates no persistent record.

Session-only tracking without consent. The SDK supports a allowWithoutConsent mode where session-level tracking (using sessionStorage only) continues without persistent consent. This allows aggregate analytics to function (bounce rate, pages per session, referrers) while respecting the visitor's preference not to be tracked across visits.

A consent banner component is included. The SDK ships alongside clerion-consent-banner.js, a ready-to-use consent UI that integrates directly with the SDK's consent API. Site owners do not need to build their own consent UI if they are using Clerion.

Browser privacy signals

The SDK honours browser-level privacy signals automatically:

Global Privacy Control (GPC). If a visitor's browser sends a navigator.globalPrivacyControl === true signal (a legally recognised opt-out signal under the CCPA and Colorado CPA), the SDK suppresses all tracking entirely. No events are sent. No storage is written.

Do Not Track (DNT). If navigator.doNotTrack === '1' is set, the SDK treats this as a privacy opt-out and suppresses tracking. DNT is not legally binding in the EU, but we honour it as a best-effort signal of visitor intent.

Both signals are checked before any tracking activity begins, and both override site configuration.

How this relates to cookie consent banners

The practical consequence of our architecture is that most Clerion customers do not need a cookie consent banner for analytics purposes.

Here is why:

• The SDK sets no analytics cookies.
• The persistent visitor ID in localStorage is only created with explicit consent, and if you choose not to use it, it is never written at all.
• Session tracking via sessionStorage is arguably strictly necessary (it only persists for the duration of a tab session and cannot be used to track across visits).
• The device properties we read are used for aggregate classification, not individual identification.

However, if you enable the persistent visitor ID feature (allowWithoutConsent: false is the default, meaning the visitor ID requires consent), you may need a mechanism to obtain that consent. Whether this requires a banner or can be satisfied through other means depends on your specific use case and your legal team's assessment.

We encourage you to share our GDPR Compliance and this page with your legal team so they can make an informed assessment.

The difference between Clerion and conventional analytics

The reason the ePrivacy Directive exists is to prevent the invasive practice of device fingerprinting at scale. Advertising technology companies access dozens of device properties (canvas rendering, installed fonts, WebGL capabilities, screen resolution, timezone, audio processing characteristics, and more) to build a persistent, unique fingerprint of each visitor's machine. This fingerprint can track a person across millions of websites without any cookies, without any consent, and without the person knowing.

Clerion does not do this. We read a small number of device properties for the narrow purpose of classifying device type in aggregate. We do not combine them into a fingerprint. We do not link them to a persistent identifier without consent. We do not share them with advertising networks. We do not use them across sites.

The letter of Article 5(3) requires consent for accessing terminal equipment, regardless of purpose. We acknowledge that. The spirit of Article 5(3) was to stop surveillance fingerprinting, and that we do not do.

Looking ahead: the ePrivacy Regulation

When the ePrivacy Regulation eventually replaces the Directive, it will apply uniformly across all EU member states. Early drafts suggest it will be more explicit about what counts as "strictly necessary" processing and may carve out privacy-respecting analytics from the blanket consent requirement. The regulation is expected to take a more proportionate approach, distinguishing between aggregate, non-identifying analytics and genuine surveillance technologies.

Clerion's architecture (cookieless, aggregate-first, consent-gated persistence, GPC/DNT-aware) is designed to sit comfortably within whatever proportionate standard the Regulation establishes. We do not depend on that change arriving: the same design is intended to comply with the Directive as it stands today.

Summary