Clickport
Start free trial

Privacy Overview

Clickport is designed so that privacy is built into the architecture, not bolted on as a configuration option. This page explains exactly how Clickport handles visitor data, what is collected, what is not, and how the system works without cookies or personal identifiers.

Cookie-free tracking

Clickport never sets cookies. Not "optional" cookies. Not "strictly necessary" cookies. Zero cookies, period. The tracker also never writes to localStorage for tracking purposes.

Sessions use sessionStorage to store only the session ID for the current browser tab. This value is automatically cleared when the tab closes. Under the ePrivacy Directive, storage that is strictly necessary for the service the user requested is explicitly exempt from consent requirements.

The practical result: no consent banner needed. No cookie management platform. No conversion loss from visitors declining consent or closing popups. Your visitors see your content immediately.

Technical detail: The tracker stores a single numeric session ID in sessionStorage under the key cp_sid. This ID is generated server-side on the first pageview and links subsequent events to the same session within the same tab. It cannot be used to track visitors across tabs, across sites, or across sessions.

How visitor identification works

Clickport identifies visitors without cookies, fingerprinting, or any persistent identifier. Instead, it generates a user_id using a one-way hash of four inputs combined into a single string:

  1. IP address (used only for this hash, then discarded)
  2. User-Agent string (standard browser header)
  3. Today's date (in the visitor's timezone)
  4. A server-side salt (environment variable, never sent to the browser)

These four values are concatenated and hashed into a numeric ID. The daily date component means this hash produces a completely different ID for the same visitor every day. There is no way to link Monday's visitor to Tuesday's visitor, even with full access to the database.

How visitor identification works
Daily rotating hash, no persistent identifiers
1
Request arrives with IP + User-Agent
Standard HTTP headers. No cookies, no custom identifiers.
2
Server builds hash input string
ip | user-agent | 2026-02-12 | server_salt
3
One-way hash produces numeric user_id
The hash is irreversible. You cannot extract IP or User-Agent from the result.
4
Date rotates daily (per visitor timezone)
Tomorrow the same visitor gets a completely different user_id. No cross-day tracking is possible.
5
IP address is discarded
After geo lookup and hash generation, the raw IP is gone. It is never stored in the database.

Session lifetime

A session starts when a visitor opens a page and ends when they close the tab. There is no 30-minute inactivity timeout like Google Analytics. The session ID is stored in sessionStorage, which is scoped to a single browser tab and cleared on close. Each new tab starts a new session.

IP address handling

The visitor's IP address is used for exactly two purposes, then immediately discarded:

  1. Geographic lookup: A local database (DB-IP) on the server maps the IP to a country, region, and city. No external API call is made. The lookup happens entirely in memory on the same server that received the request.
  2. Hash generation: The IP is combined with the User-Agent, today's date, and a server-side salt to produce the daily rotating user_id described above.

After these two operations, the IP is gone. There is no ip_address column in the ClickHouse database schema. The stored user_id is a numeric hash that cannot be reversed to recover the original IP.

IP address lifecycle
IP arrives with HTTP request
Geo lookup via local DB-IP database
In-memory, no external API call
Stored: country_code = DE   city_name = Berlin
Hashed with daily rotating salt
New hash output every calendar day
Stored: user_id = 847291 (numeric, irreversible)
IP address discarded from memory
-- ClickHouse sessions table schema
session_id UInt64
user_id UInt64 -- hashed, rotates daily
country_code LowCardinality(String)
city_name LowCardinality(String)
ip_address -- this column does not exist

What Clickport collects

Clickport collects the data you need for meaningful analytics without ever touching personal information. Here is the full list of what is and is not stored.

Data collection overview

Collected

Page URLs and pathnames
Referrer source (domain only, query params stripped)
UTM campaign parameters
Country, region, city (from IP, then discarded)
Device type, browser, OS (from User-Agent)
Screen width category
Scroll depth and time on page
Outbound link clicks (URL and text)
Form submissions (form ID/name only)
Custom events you explicitly send

Never collected

IP addresses
Names or email addresses
Phone numbers
Form field contents
Browser fingerprints
Cookies or localStorage identifiers
Cross-site tracking identifiers
Advertising IDs (GCLID, FBCLID, etc.)
Device fingerprints (canvas, WebGL, fonts)
Precise location (GPS, WiFi)

Referrer privacy

Referrer URLs are stripped of all query parameters before storage. If a visitor arrives from https://google.com/search?q=my+health+condition, only https://google.com/search is stored. The search query is never recorded.

Tracking parameter stripping

Clickport automatically strips tracking parameters from page URLs before storing them. This includes UTM parameters (extracted separately for campaign attribution), Facebook Click IDs (fbclid), Google Click IDs (gclid), Microsoft Click IDs (msclkid), and other ad-tracking identifiers. The campaign data is preserved in dedicated UTM fields, but the raw click IDs that could be used for cross-site tracking are discarded.

No fingerprinting

Clickport never uses browser fingerprinting techniques. Device type, browser name, and operating system are determined solely from the standard User-Agent header that every browser sends with every request. There is no canvas rendering, WebGL probing, font enumeration, plugin detection, AudioContext analysis, or any other fingerprinting technique.

No personal data in the database

The ClickHouse database stores only aggregate-friendly data points. Here is what a session record looks like:

No field in the database can identify a specific person. You could publish the entire dataset and no visitor's identity would be compromised.

Privacy controls in the dashboard

Beyond the architectural privacy guarantees, Clickport provides several controls for site owners who want additional protection.

Privacy settings
Site Settings
Control how your site handles visitor data
Excluded IP Addresses
Exclude your own visits from analytics data
203.0.113.42 ×
198.51.100.7 ×
+ Exclude my current IP

Session Management
View, flag, or delete individual sessions from the Sessions panel
Self-exclusion
Set localStorage.setItem('clickport_ignore', 'true') in your browser console to exclude yourself

IP exclusion

You can exclude specific IP addresses from tracking in your site settings. This is typically used to filter out your own visits or your team's traffic. The excluded IP check happens at ingestion time, before any data is written to the database.

Self-exclusion via localStorage

The tracker checks for a clickport_ignore key in localStorage. If it is set to 'true', the tracker exits immediately without sending any data. This is useful for developers and site owners who want to exclude themselves without adding their IP.

Session deletion

Individual sessions can be viewed, flagged as bots, or deleted entirely from the Sessions panel in the dashboard. Deleting a session removes all associated events from the ClickHouse database.

Data storage and hosting

All visitor analytics data is stored on a Hetzner server in Germany. It never leaves the European Union. The database engine is ClickHouse, running on the same server as the API.

No US data transfers: Because all visitor data stays on EU infrastructure with zero third-party sub-processors touching it, there are no Schrems II concerns and no Standard Contractual Clauses needed for visitor data.

How Clickport compares

Traditional analytics tools were built in an era before privacy regulations. Their architecture assumes cookies, persistent identifiers, and cross-site tracking. Retrofitting privacy onto these systems requires configuration, consent management, and legal documentation.

Clickport takes the opposite approach. Privacy constraints are baked into the data model itself. There is no configuration that could make Clickport collect personal data, because the system has no mechanism to do so.

ClickportGoogle AnalyticsMatomo Cloud
Cookie-free by default
No consent banner neededOptional
IP addresses never storedOptional
No browser fingerprinting
No cross-site tracking
EU-hosted dataEU option
No data shared with third parties
GDPR-compliant without configurationRequires setup
Visitor data sub-processors05+Varies

Bot detection and privacy

Clickport uses multi-layered bot detection to prevent automated traffic from polluting your analytics. All detection methods are privacy-preserving:

Blocked bot events are counted in aggregate statistics (the Bot Management panel) but no personal data about the blocked request is retained.

The tracker script

The Clickport tracker is approximately 2 KB in size (gzipped). It is open and readable. Here is what it does and does not do:

Transparency: The tracker's full source code is loaded as a single JavaScript file. You can read it at https://clickport.io/tracker.js at any time. There are no external dependencies, no bundled third-party scripts, and no obfuscation.

Legal documentation

Clickport provides complete legal documentation for your compliance needs:

For a detailed technical analysis of GDPR compliance, including the legal basis for processing, data subject rights, and the specific GDPR articles that apply, see the GDPR Compliance documentation page.