Privacy first, by default
Most analytics tools start from the same place: collect everything you can, keep it forever, and figure out what it means later. Clerion starts from the opposite end. We ask what a website owner actually needs to make good decisions, and then we collect only that. The result is analytics you can run without a cookie banner, without a consent popup, and without quietly building a profile of every person who visits your site.
This post is a walk through how that works in the code, not a list of promises. Where we make a tradeoff, we say so.
No cookies, no persistent ID, by default
When you install Clerion and leave the defaults alone, we count visits without ever setting a tracking cookie or storing a persistent identifier. A visitor is counted for their visit and nothing is written that would let us recognize them the next day.
That single choice is what removes the cookie banner. Under GDPR and ePrivacy, the banner exists because sites store identifiers on a visitor's device. If nothing is stored, there is nothing to ask permission for. Our setup screen says this plainly: in the default mode, "no cookies or persistent identifiers are stored, so no consent banner is needed. Returning visitors can't be recognized across visits."
The honest tradeoff is right there in that last sentence. Cookieless means we cannot tell a returning visitor from a new one across separate visits. If you need cross-visit identity, you turn on consent mode, and only then do we store an analytics identifier, and only after the visitor opts in. You choose the tradeoff. It is not chosen for you.
The IP address is used, then thrown away
To tell you which countries your traffic comes from, we need the visitor's IP address for a moment. We use it, and then we discard it. It is never written to the database.
The flow, on every tracked event, is:
1. Read the IP from the connection.
2. Turn it into a keyed hash (HMAC-SHA256).
3. Use the raw IP once to look up an approximate location.
4. Store only the hash and the location. The raw IP is dropped.
There is no column in our schema for a raw IP address anywhere. The only thing we keep is `ip_hash`, and it is a keyed hash rather than a plain one, so it cannot be reversed by guessing addresses against a rainbow table. The location lookup itself goes to a provider on EU infrastructure that does not retain the IP beyond the call, and private or loopback addresses skip the lookup entirely.
Being specific about what the hash is for: it is how we estimate unique visitors without a cookie. We count distinct hashed IPs over a time range. It is a pragmatic proxy, not a perfect one. Two people behind the same office network can share an address, and a keyed hash that does not rotate will map the same IP to the same value for the life of the deployment. We think that is the right balance for a metric that is meant to be directional, but it is a balance, and you should know which side of it we chose.
What we collect, and what we deliberately do not
The rule we hold to is that measurement should never require reading the content of what a person types or who they are.
Forms are the clearest example. Clerion can tell you that a form was interacted with and which fields were touched. It records the field's name and type. It never reads the value. The code that watches forms simply does not look at what was entered. So "email address" as a field can show up in your funnel; the email itself never leaves the page.
We also do not fingerprint devices. There is no canvas fingerprinting, no font enumeration, none of the silent techniques that rebuild an identity when cookies are gone. Session identity is a random token that lives in the tab and disappears when the tab closes.
For full honesty, here is what we do collect and store as part of an event: the page path, referrer, UTM parameters, and some environment details from the browser such as user agent, language, and timezone. For click tracking, we store the visible text of the clicked element (capped at 100 characters) and its coordinates. These are useful, and in combination they are more identifying than the word "anonymous" would suggest. That is why our documentation tells site owners not to put personal data into button or link labels, since the visible text is captured. We would rather tell you exactly where the edges are than round them off.
We delete data your plan no longer needs
Privacy is not only about what you collect. It is also about how long you hold it. Clerion runs a purge job every day that deletes events older than your plan's retention window. Shorter plans keep 30 days; longer plans keep about 13 months. Nothing sits around forever waiting to become a liability.
Inside the product this shows up as a small, deliberate piece of honesty. On the activity view there is a horizon line marking the days that have been purged, with a note that reads "This day has been let go." It is the same principle as never needing a cookie banner: hold only what you need, for only as long as you need it.
We respect the browser's own privacy signals
If a visitor's browser announces that they do not want to be tracked, we listen before anything else runs. Clerion checks for Global Privacy Control and Do Not Track, and when either is set, tracking is suppressed. Global Privacy Control in particular carries legal weight under laws like the CCPA and the Colorado Privacy Act, so this is not a courtesy, it is a requirement we build in by default. A site owner can override it, but they have to do so on purpose.
Unguessable identifiers
One recent change is worth calling out because it is quiet but it matters. The public identifiers Clerion hands out, like a site's tracking key, are now high-entropy random values (160 bits for a tracking key). They encode nothing about you or your account, and they are validated against a strict character set before they are ever used in a query, which closes the door on one class of cross-tenant attack. Regenerating a key is real revocation: the old value stops working. Identifiers should be unguessable and should mean nothing, and now they are and they do.
The shape of it
Put together, the design is simple to describe. Collect what measurement needs and nothing that identifies a person by default. Use the IP for a location lookup and then discard it. Never read form values. Do not fingerprint. Delete on a schedule. Honor the browser's privacy signals. Make identifiers unguessable and meaningless.
None of this makes the analytics worse. You still see your traffic, your sources, your popular pages, and where people drop off. What you do not get is a pile of personal data you never wanted to be responsible for, and what your visitors do not get is a banner asking them to consent to something that, with Clerion, is not happening in the first place.
That is what privacy first means here. Not a badge on the marketing page. A set of decisions in the code, with the tradeoffs left visible.