This page describes what Clientlog does with data. It is written for someone deciding whether to install it, and for the person who will be asked to justify that decision.

The short version

Clientlog sets no cookies, uses no fingerprinting, and creates no identifier that works across sites or across visits. IP addresses are used to derive a coarse location and are not stored on the event. Data reaches an advertising platform only if you configure a relay and nominate the destination.

In most default installations, no personal data is processed at all.

What is collected

Each event records:

  • Action name. A string you define, such as page_view.pricing or user.signup.success.
  • Payload. A JSON object you control, capped at 512 characters.
  • Session identifier. Generated in the browser. See below.
  • Origin and project. Which site and which namespace.
  • Timestamp. Assigned on receipt.

Enrichment adds:

  • Browser and device. Browser family and version, operating system, device type, and whether the user agent is a known bot. Derived from the User-Agent header.
  • Coarse location. Country, region, city, timezone and network operator. Derived from the IP address.
  • Query parameters. The request query string, parsed into fields.

The session identifier

The default identifier looks like 1782693098872-7xzwuxbzd: a timestamp and a random suffix, generated in the browser and held in sessionStorage.

Its properties matter more than its shape:

  • It is not a cookie. It is never transmitted in a request header, and it is not available to any other site.
  • It is per-tab and per-visit. Closing the tab ends it. A return visit produces a new one, with no link to the previous.
  • It correlates with nothing. It is not derived from the IP address, the user agent, or any browser characteristic. Two sessions from the same person are indistinguishable from two sessions from different people.
  • It is not shared. Each site’s sessions are namespaced to its own origin and project.

This is why a default Clientlog installation does not require a cookie banner, and why it produces no data that identifies a person.

If you change it

The client accepts a sessionIdFn option that replaces the generator. Using it to supply an authenticated user identifier, or any value derived from device characteristics, creates identity linkage.

That is a supported configuration and there are good reasons to want it. It also changes the legal position: you become the controller of personal data, and the lawful basis, the consent mechanism, the privacy notice your users read, and the response to access and erasure requests are all yours to provide. Clientlog provides the mechanism and no part of the obligation.

The same applies to putting personal data in event payloads. The documentation recommends against it, the field is not designed for it, and doing so is a decision with consequences you own.

IP addresses

The IP address of an incoming event is used to look up an approximate location: country, region, city, timezone and network operator.

The address is not written to the event record and is not retained as part of your data. Lookups are cached for operational efficiency; that cache is not part of your project’s data and is not queryable through the API, the CLI or any export.

The derived location is retained on the enriched event. City-level accuracy from an IP address is approximate at best and is frequently wrong by a considerable distance; treat country and network operator as the reliable fields.

What is never collected

  • Cookies of any kind.
  • Browser fingerprints: no canvas, font, audio or hardware probing.
  • Cross-site identifiers, and no participation in any identity graph.
  • Form field contents. The client records that a click occurred and the visible text of the element clicked; it does not read input values.
  • Keystrokes, mouse paths, screen recordings, or DOM snapshots. Clientlog does no session replay.
  • Data from any site other than the one where the client is installed.

Advertising platforms

Clientlog does not send data to Google, Meta, or any advertising network as part of its normal operation. Measurement is independent of those platforms by design, and independence is the reason the product exists.

A conversion relay is available as an opt-in feature per project. When you configure one, sessions matching a rule you write cause a conversion event to be sent to the destination you nominate, using an identifier such as fbclid or gclid that the advertising platform itself placed in your URL.

This is off unless you turn it on, it applies only to the rule you attach it to, and you choose the destination. When it is on, you are sending your own conversion data to a platform of your choosing, and that platform’s handling of it is governed by your relationship with them.

We state this plainly because a privacy claim that quietly omits an available feature is not a privacy claim.

Retention

Data Retention
Raw events 30 days
Enriched events 13 months
Session summaries 13 months
Tags 13 months
Aggregates and digests Retained for the life of the account
Account and project records Retained for the life of the account

Aggregates hold counts and distributions, not individual sessions.

On account closure, all project data is deleted within 30 days. Export everything first, through the API or the CLI, in JSON or CSV.

Controller and processor

Under UK GDPR, where personal data is processed:

  • You are the controller. You decide what to measure, what your event payloads contain, and whether to introduce identity linkage.
  • Bay Information Systems is the processor. We process on your instruction, which is expressed through your project configuration and your rules.

Where your configuration processes personal data, a data processing agreement is available on request. Most default installations do not require one, since no personal data is processed.

Where a default installation is used without modification, our position is that no personal data is processed, and the controller and processor framing does not engage. That position depends on your configuration, so it is one to confirm against your own circumstances rather than assume.

Location and subprocessors

Data is stored and processed in Amazon Web Services, London region (eu-west-2), within the United Kingdom.

Subprocessors:

Subprocessor Purpose Location
Amazon Web Services Compute, storage, email delivery United Kingdom (eu-west-2)

Any addition to this list will be notified to account holders before it takes effect.

Your users’ rights

Where a default installation is in use, there is no personal data to which access, rectification or erasure rights attach, because no data can be connected to an identifiable person.

If you have introduced identity linkage, you can locate and delete the relevant sessions through the API. You are the controller and the request comes to you; we will support you in fulfilling it.

Clientlog is not blocked by common tracker-blocking lists, because it is not a tracker: it makes no third-party request, sets no cookie, and builds no profile.

That is a description of what it does, not an attempt to evade a user’s stated preference. The client supports a respectDoNotTrack option which disables all logging when the browser sends the header. If your privacy notice commits to honouring it, enable it.

Security

  • All traffic is over TLS.
  • Authenticated endpoints require a token scoped to your account. A token grants access to your projects and no others.
  • API keys can be issued, scoped and revoked separately.
  • Access to production infrastructure requires multi-factor authentication.

Changes

Material changes to this page are notified to account holders before they take effect. The page carries no version history yet; it will once there is something to record.

Contact

ed@bayis.co.uk for anything on this page, including a copy of the data processing agreement.