Skip to main content

What We Track vs What We Don’t

Sealmetrics records a small set of non-identifying variables per page view ("hit") — timestamp, user agent (for device classification), current URL, referral URL, browser timezone (for the country), and a session identifier that is re-keyed every day — and never sets cookies. No IP address, user ID, name or email is stored, and nothing stored can link the same device across days. During the day the session identifier is pseudonymised data, processed under legitimate interest (GDPR Art. 6(1)(f)); once the daily salt rotates, not even Sealmetrics can reconstruct it, and reports are always aggregated. Nothing is stored on the visitor's device. This page is the authority on what is collected and for how long; for the concept and the legal reasoning, see What is Consentless Analytics?.

What We DO Track​

What each hit carries​

Each page view ("hit") carries the following data points. The tracker sends the URL, the referrer, the timestamp, the timezone and an ephemeral session identifier (computed in the browser from device properties it reads); the user agent arrives with the request itself, and is used in flight only. The server also sees the IP: it is checked in flight against a public list of automated-traffic IPs to filter bots, and is not stored. The timezone and the session identifier are what let Sealmetrics assign a country and tell a new entrance from a second pageview:

1. Timestamp​

  • Purpose: time-based analysis and trend insights
  • Privacy: cannot identify an individual

2. User Agent​

  • Purpose: device classification (browser family, OS family, mobile/desktop/tablet)
  • What we keep: only the derived categories (browser family, OS family, device type). The raw UA string is used in flight to derive them and to classify automated traffic, and is never written to analytics storage; the derived categories persist in aggregated reports for 24 months.
  • What we never do: the UA is never linked to an individual, never joined with any personal identifier (we don't have one), and never used to reconstruct a user's history across sessions. It's a category signal, not an identifier.

3. Current URL​

  • Page path
  • Page popularity
  • Aggregated content performance

4. Referral URL​

  • Aggregated attribution
  • Campaign performance
  • Traffic source identification

5. Browser timezone​

  • The IANA timezone reported by the browser (for example Europe/Madrid), used to assign the visit's country. See Geographic Data below.

6. Session identifier​

  • How it is computed: the tracker computes, in the browser, a hash of standard device characteristics — user agent, timezone, languages, screen resolution, colour depth, dark-mode and reduced-motion preferences, CPU core count and device memory — combined with your site's account ID. That hash is a device fingerprint: stable for the same browser, and never written to the visitor's device (no cookie, no localStorage, no sessionStorage).
  • What happens on the server: before anything is stored, the pixel service replaces it with HMAC-SHA256(server key, hash + salt of the day). The salt rotates every day at 04:00 in your site's timezone and the previous salt is destroyed on rotation, so the stored identifier changes every day and two days of the same device cannot be re-linked — not even by Sealmetrics. The raw hash is never stored.
  • How long it lives: the live session in the pixel service's memory expires after 2 hours of inactivity (GA4-style); that window is what tells a second pageview from a new entrance, which bounce rate and engagement need. The daily pseudonym is also written to the per-hit log, which is purged after 1 day. It cannot be used to recognise a returning visitor on another day.
  • Site-isolated by design: the account ID is part of the hash, so the same browser yields different identifiers on different publishers' sites — no cross-site correlation is possible at the identifier level.
  • Why it needs no consent (our self-assessment): the stored identifier changes every day and cannot be linked across days, so it does not enable tracking an individual over time, which is why analytics of this kind can operate without consent under the CNIL's audience-measurement criteria. Under the GDPR, the daily pseudonym is personal data while it can still be re-keyed (Recital 26); Sealmetrics processes it under legitimate interest (Art. 6(1)(f)) and it becomes unrecoverable when the salt rotates. Reports are aggregated.

How long is each field kept?​

Retention is fixed and identical for every plan, enforced by database TTLs. Nothing here is configurable per customer.

WhatRetentionNotes
Per-hit log1 dayOne row per hit, then purged. Holds the daily session pseudonym, URL, referrer, timezone and UTMs. It contains neither the raw user agent string nor device categories
Live session (in memory)2 hours of inactivityUsed only to tell a second pageview from a new entrance
Hourly aggregates90 daysHour-by-hour reporting
Daily aggregates, conversions and microconversions24 monthsInclude the derived device categories — browser family, OS family, device type — but no session identifier

The distinction that matters for the user agent: the raw UA string is never stored. It is read while the hit is processed and discarded; what survives, for up to 24 months, is only the derived category (for example "Chrome / Windows / desktop") inside aggregate counts — never attached to anything that identifies a person.

Full operational retention (logs, backups, account closure) is documented in Data Location & Retention.

What This Allows Us to Measure​

1. Page Analytics​

  • Pageviews (aggregated)
  • Top pages
  • Aggregated navigation patterns

2. Traffic Analytics​

  • Entrances (aggregated)
  • Traffic volume trends
  • Marketing channel performance
  • Within-session engagement — bounce rate, engaged entrances, engagement rate, pages per session. These are computed inside a single session from the session identifier; they never require recognising a returning visitor. Session duration and unique visitors are not measured. See the Metrics Reference.

3. Engagement Behavior (Custom Events)​

  • Click events
  • Scroll depth
  • Form interactions
  • Video plays
  • Downloads

ALL aggregated — no user-level behavior.

4. Entry Points​

  • Entry pages (landing pages)
  • Internal search (aggregated; via events)

Exit pages and individual navigation paths are not tracked — reconstructing either requires sequencing one visitor's pageviews, which needs a persistent identifier.

5. Campaign & Marketing Analytics​

  • UTM campaign tracking
  • Referrer attribution
  • Search traffic
  • Social media traffic
  • Revenue attribution (aggregated)

6. Conversion Tracking​

  • Goal completions
  • E-commerce events
  • Lead generation
  • Micro-conversions
  • Channel-level revenue attribution

7. Device Categories​

  • Browser category
  • OS category
  • Desktop / mobile / tablet

With the standard tracker, screen resolution and browser languages are read only as inputs to the session-identifier hash above; they are not stored and not reported. The one exception is the separate tracker used by Agent Analytics, which would also send screen and window size, pixel ratio and the number of browser languages as bot-detection signals — that feature is not live and cannot be enabled on any account.

8. Geographic Data​

  • Country — primary source: browser timezone. Every visit's country comes from Intl.DateTimeFormat().resolvedOptions().timeZone, mapped to the country most represented by that IANA zone. No IP lookup involved.
  • ❌ GeoIP country — not collected. A stateless GeoLite2 lookup was designed for the Agent Analytics bot detector, but that feature is not live and cannot be enabled, so no IP-based country lookup runs on any account.
  • ❌ Region / City — not collected.

9. Automated-traffic detection signals — not collected​

Not live

Agent Analytics, an automated-traffic detector that would classify traffic as human vs. automated, is designed but not live, and cannot be enabled on any account. No account collects any of the signals below today. They are listed so this page stays a complete statement of what could ever be collected.

If it ships, it would store aggregate, per-hit environmental and behavioral signals about the browser and the interaction pattern — not about the person. Examples: WebDriver flag, whether the WebGL renderer is SwiftShader, screen size buckets, aggregate mouse-movement linearity, click-timing variance. They would never be associated with an identifier, and the purpose would be filtering bot traffic out of reports. See Bot Detection for what actually runs today.

10. Business Intelligence Metrics​

  • Conversion rate
  • Average order value
  • ROAS
  • Funnel performance

What We DO NOT Track​

No Identifying Data Stored​

❌ IP addresses (checked in flight against a public list of automated-traffic IPs to filter bots, never stored) ❌ User IDs ❌ Emails ❌ Phone numbers ❌ Names ❌ Persistent identifiers (the session identifier is re-keyed daily; no cross-day or cross-device linking)

No Individual-Level Tracking​

❌ User journeys across sessions ❌ Returning-visitor recognition ❌ Individual preferences ❌ Personal browsing behavior ❌ Any join between a hit and a person's identity

No Cross-Site Tracking​

❌ Third-party cookies
❌ Advertising identifiers
❌ Cross-domain identification
❌ Social media identifiers

No Sensitive Personal Data​

❌ Health
❌ Financial
❌ Political
❌ Religious
❌ Demographic profiling

No Persistent Device Identifiers​

❌ Persistent device IDs
❌ MAC addresses
❌ Stored device fingerprints (the in-browser hash is re-keyed daily on the server — see Session identifier)
❌ Advertising IDs

Nothing stored on the device​

❌ Cookies
❌ LocalStorage
❌ SessionStorage

The tracker does compute a device-characteristics hash in the browser (see Session identifier); it is sent with each hit, re-keyed daily on the server and never stored as sent. Hits are sent with navigator.sendBeacon (with a fetch fallback).

No Private Communications or Content​

❌ Email contents
❌ Chat messages
❌ Form personal data (only event counts)
❌ Uploaded files
❌ Social media posts
❌ Documents

  • GDPR — European company, customer analytics data stored only in Dublin, Ireland. No data that identifies anyone is stored: the session identifier is pseudonymised data during the day, processed under legitimate interest (Art. 6(1)(f)), with the per-hit log purged after one day; it becomes unrecoverable when the daily salt rotates. No identifier is carried across days or sessions, and reports are aggregated.
  • ePrivacy Directive — nothing is stored on the visitor's device (no cookies, no localStorage, no sessionStorage). The tracker does read standard browser properties to compute the session identifier described above; see Analytics Cookies: Consent Exemption Requirements for how the exemption criteria apply.
  • CCPA / PECR — nothing that identifies anyone is stored, and no user-level data is sold or shared.

Sealmetrics holds no third-party security certification (no ISO 27001, no SOC 2), and no supervisory authority certifies analytics tools. The pages under compliance are our own self-assessments against published criteria. A signed DPA is available at sealmetrics.com/dpa.

How We Decide What to Track​

Before tracking any metric, we evaluate:

  • Privacy Risk: Could this identify someone?
  • Business Need: Is this essential?
  • Legal Compliance: GDPR, ePrivacy, CCPA, PECR
  • Future Proofing: Will it remain compliant?
  • User Expectation: Would users expect this?

Sealmetrics always chooses the more restrictive option.

Summary​

Web analytics that answers business questions does not require identifying anyone. From the fields above, Sealmetrics reports:

  • every hit, with no loss from consent rejection
  • channel and campaign attribution
  • conversions, revenue and ROAS
  • aggregate engagement and funnel performance

What it does not report is anything tied to an individual — that is the deliberate trade-off that removes the consent requirement.

Written and maintained by the Sealmetrics Team