Web analytics and privacy

To install the tracker and use its API, see Web analytics.

How visitors are counted

For every event, the Logdash server computes the visitor ID as a SHA-256 hash in hex:

• The weekly salt is 32 random bytes, created for each week starting on Monday at 00:00 UTC. It is held only in Redis and expires 30 minutes after that week ends.
• Once the salt is gone, nobody can recompute that week's visitor IDs, Logdash included. The same visitor gets a new ID every week.
• The IP address is used only to compute the hash and is never stored.
• The User-Agent goes into the hash and is reduced to device type, browser and operating system. The full string is not stored.
• Behind a first-party proxy, the proxy passes the visitor's IP address in the x-logdash-client-ip header, so the hash uses the visitor's address rather than your server's. The proxy forwards Origin, User-Agent and x-logdash-client-ip, never cookies, authorization headers or ingest keys.

Sessions live on the server too. A session ends after 30 minutes without events or after 24 hours, and the next event starts a new one. During the first 30 minutes of a week, a visitor whose session started the week before continues that session and keeps the previous week's visitor ID.

Within a week, an anonymous visitor who comes back counts once. In the next week they get a new ID and count again, and so does a visitor whose IP address or browser changes. Retention, stickiness and comebacks are measured for identified users only.

Events your apps send to /events are counted the same way, with the app's name added to the hash, so an anonymous visitor of one app is never linked to the website or another app:

Signed-in users

When your app passes the signed-in user's ID to identify, the tracker hashes it in the browser before anything is sent: sha256(siteId + ':' + id), in lowercase hex. The raw ID never leaves the browser. Because the site ID is part of the hash, the same user ID gives a different hash on every site.

• A value that contains @ or is longer than 256 characters is ignored, so an email address is never sent by mistake.
• The identity lives in memory only, and identify(null) clears it when the user signs out.
• The server never copies a user ID onto an event sent without one, so events after sign-out are not attributed to the previous user.
• Your apps send the user ID with each event over HTTPS. The server computes the same sha256(siteId + ':' + id) on arrival and stores only the hash, never the ID, so one user is one person across the website and apps.

Pass a stable internal ID, never an email address or a name. The hash is pseudonymous, not anonymous: your site ID is public in the script tag, so anyone can hash guessable IDs, such as small sequential numbers, and compare.

Custom event properties

A custom event can carry up to 10 properties, such as a quality, a theme or a variant. A value that contains @ or a control character is dropped, so an email address is never stored by mistake.

Never put emails, names, user IDs, purchase details or other personal data in event names or properties. Properties describe what happened, never who did it.

Opt-out and browser storage

The tracker does not start in automated browsers that set navigator.webdriver. It counts browsers that send Do Not Track or Global Privacy Control like any other, unless the script tag has data-respect-dnt. Your site can let visitors opt out with optOut, both described in Web analytics.

The tracker sets no cookies and writes nothing to localStorage or sessionStorage, except localStorage['logdash:opt-out'] = '1' when a visitor opts out, so the choice survives reloads. On load it deletes the ldv_ and lds_ cookies that earlier versions of the tracker set.

What Logdash stores

Each event is stored with:

• the event name: pageview, pageleave, browser_error or one of your custom events. browser_error carries no error message or stack trace.
• for custom events, the properties you pass to track, after the checks described above.
• the host name and path of the page, without query string or fragment. Path segments that contain @ become :redacted, and segments that look like database IDs, UUIDs or numbers of four or more digits become :id.
• the host name of the referring site, UTM source, medium, campaign and term, and the name of an ad click ID parameter such as gclid, never its value. They come from the first event of the session.
• device type, browser and operating system, derived from the User-Agent.
• a country, derived from the browser's time zone rather than the IP address.
• the time of the event.
• the visitor ID, a random session ID and, for identified users, the user hash.
• for events from your apps, the app name instead of the page, referrer, campaign and browser details.

While a session is live, its ID, start time and attribution are held in Redis. They expire 30 minutes after the session's last event.

How long data is kept

Events are deleted automatically when the retention period of your plan has passed, counted from the time of each event. The retention that applies is the one of the plan you had when the event arrived.

Deleting a domain in Logdash deletes all of its web analytics events. Copies in encrypted backups are deleted when the backups expire, 14 days after they were made.

Consent

Whether your site needs consent for analytics depends on the law that applies to you and your visitors, and on how you use the data. You decide that, not Logdash. This page and the data processing agreement describe the processing precisely, so you can make that decision and explain it to your visitors. If you decide you need consent, load the script only after the visitor agrees.

Text for your privacy policy

Adapt this text to your site: fill in the parts in square brackets, remove the bracketed sentences that do not apply, and change the legal basis if you rely on consent.

Data processing agreement

When you use Logdash for web analytics or logs, Logdash processes personal data on your behalf as a processor. The data processing agreement covers the subject and duration of the processing, the categories of data, the security measures, the sub-processors, breach notification and deletion.