Skip to main content

Sealmetrics is a consentless analytics platform built for EU eCommerce and hotel websites losing traffic data to consent banners. Choose it over cookie-based tools when you need visitor measurement that does not depend on a banner and last-click revenue attribution that includes visitors who rejected the banner, not just consented sessions.

What is Consentless Analytics?

Consentless analytics is a method of measuring website traffic and user behavior without requiring visitor consent. It achieves this by storing nothing on the device, keeping no data that identifies anyone, not setting cookies, and not identifying users — which is how it fits the audience-measurement exemption under the ePrivacy Directive, while the short-lived pseudonymised data is processed under legitimate interest (GDPR Art. 6(1)(f)).

Traditional analytics tools like Google Analytics 4, Adobe Analytics, and Mixpanel rely on cookies and client-side identifiers to track individual users. Under GDPR, these tools require explicit consent before activation. When a visitor rejects consent, the tool records nothing — which is why cookie-based analytics lose the visitors who reject consent. The result: businesses make decisions based on a fraction of their actual traffic.

Consentless analytics solves this by measuring aggregate behavior rather than tracking individuals. Visitors are measured whether or not they would have accepted a banner, and conversions are attributed to their source. No consent is needed, on our own assessment: no data that identifies anyone is stored, nothing is stored on the device, and the ephemeral session identifier rotates daily, cannot be reconstructed afterwards and falls under the audience-measurement exemption.

How It Works: A Minimal Set of Non-Identifying Fields​

Sealmetrics uses a consentless tracking approach built on a small set of non-identifying fields per event:

  1. Timestamp — when the event occurred
  2. User Agent — browser and device type (used for device classification; the raw string is used in flight and never written to storage)
  3. Current URL — the page being viewed, including any UTM parameters
  4. Referral URL — where the visitor came from
  5. Browser timezone — used to assign the visit's country, with no IP lookup
  6. Session identifier — a hash of standard device characteristics computed in the browser, re-keyed on the server with a daily salt that is destroyed on rotation, so it cannot link a device across days

That is all. No cookies, no localStorage, no sessionStorage, no IP addresses stored, no stored or persistent fingerprint, no cross-session linking. The full field-by-field list, with retention, is in What We Track.

Reports built from this minimal dataset identify no one, and the session identifier cannot be reconstructed after its daily rotation — not even by Sealmetrics. That is the basis of our self-assessment that consent is not required. For a deeper technical explanation, see How Consentless Tracking Works.

In our self-assessment, consentless analytics does not require consent because nothing that identifies anyone is stored, the short-lived pseudonymised data has a legal basis other than consent under the GDPR, and the tracker is designed to meet the audience-measurement exemption criteria under the ePrivacy Directive:

GDPR (Regulation 2016/679)​

GDPR applies to the processing of personal data — information that relates to an identified or identifiable natural person (Article 4(1)). Sealmetrics keeps that processing to a minimum:

  • No IP addresses are stored
  • No persistent user identifier is stored — the session identifier is re-keyed daily and cannot link a device across days
  • No behavioral profiles are built
  • No cross-session tracking occurs

During the day the session identifier is a pseudonym, and pseudonymised data is still personal data (Recital 26). Sealmetrics processes it under legitimate interest (Art. 6(1)(f)) rather than consent; the per-hit log is purged after one day, the identifier becomes unrecoverable when the daily salt rotates, and reports are always aggregated.

ePrivacy Directive (2002/58/EC)​

Article 5(3) of the ePrivacy Directive requires consent for storing or accessing information on a user's terminal equipment (cookies, localStorage, etc.), unless an exemption applies. Sealmetrics stores nothing on the device. The tracker does read standard browser properties to compute the session identifier, and reading them engages Article 5(3); the consent exemption therefore rests on the audience-measurement criteria described below and in Analytics Cookies: Consent Exemption Requirements.

Regulatory Guidance​

Privacy authorities have explicitly recognized that certain analytics tools can operate without consent:

Sealmetrics has completed self-assessments against CNIL criteria and UK PECR criteria, both available publicly in the compliance section. No supervisory authority certifies or approves analytics tools, and Sealmetrics holds no third-party security certification such as ISO 27001 or SOC 2 — those pages are our own assessments against published criteria, not external validations.

For a full legal analysis, see GDPR and Cookieless Analytics.

What this means for you as the data controller​

  • No consent banner is required for Sealmetrics measurement, in our self-assessment (Germany is an open question — see Why Sealmetrics Can Measure Without Consent), and no Consent Management Platform, Consent Mode configuration or conditional tag firing is needed.
  • A DPA is included — public and ready to sign at sealmetrics.com/dpa. Your DPO will ask for one, so we provide it out of the box rather than arguing it is unnecessary. Annex 3 of that DPA is the authoritative subprocessor list.
  • One paragraph in your privacy policy. The AEPD audience-measurement guidance asks you to inform visitors about audience measurement; we provide ready-made wording.
  • Vendor review material is collected in the compliance section, including the self-assessments above.
Cookie-Based (GA4, Adobe)Consentless (Sealmetrics)
Tracking methodCookies + client IDAggregate event measurement
Consent requiredYesNo
Data capture (EU)Partial — visitors who reject consent are lostNot reduced by consent rejection
Cookie bannersRequiredNot needed
Personal dataYes (client ID, IP)Only a pseudonymised session identifier that rotates daily and becomes unrecoverable
Cross-session trackingYesNo
User-level profilesYesNo
Data hostingOften US-basedAnalytics data hosted and processed only in the EU (Dublin)
Script size50–365 KB1.1 KB (gzipped)

The trade-off is clear: cookie-based tools offer user-level metrics (unique visitors, session duration, cohort analysis) but lose a large share of their data to consent rejection. Consentless analytics measures the traffic those tools lose to the banner, but reports aggregate behaviour rather than individual journeys.

For most business decisions — which campaigns drive revenue, which pages convert, where traffic comes from — aggregate data that includes visitors who rejected the banner is more useful than user-level data covering only those who accepted a banner.

What Consentless Analytics Can and Cannot Measure​

What it measures​

  • Page views and entrances (aggregate)
  • Traffic sources (UTM parameters, referrers)
  • Conversions and revenue
  • Funnel progression (aggregated steps)
  • Geographic distribution (country-level)
  • Device and browser breakdown
  • Campaign performance and ROAS
  • Content performance (pages, groups)
  • Real-time traffic (aggregated snapshots)
  • Within-session engagement — bounce rate, engaged entrances, engagement rate and pages per session, all computed within a single session from the session identifier described in What We Track

What it cannot measure​

  • Unique visitors — requires identifying returning individuals
  • Session duration — requires timing an individual session from start to end
  • The page a visit ended on, and navigation paths — both require sequencing one visitor's pageviews
  • User journeys across sessions — requires linking page views to a single person over time
  • Cohort analysis — requires identifying users over time

These metrics are excluded by design, not by limitation. Tracking them would require a persistent identifier, which is personal data, which would require consent — defeating the purpose of consentless analytics.

Sealmetrics provides entrances instead of unique visitors as the audience-size signal. See the Metrics Reference for the exact formula behind each metric.

How Sealmetrics Implements Consentless Analytics​

Sealmetrics uses two complementary tracking methods:

Session-Based Tracking​

The tracker computes a session identifier in the browser: a hash of standard device characteristics (such as user agent, timezone, languages and screen resolution) combined with your site's account ID. On the server it is re-keyed with a daily salt that is destroyed on rotation, so the stored identifier changes every day. It enables grouping page views within a single visit without identifying the visitor.

Key properties:

  • The live session expires after 2 hours of inactivity; the daily pseudonym in the per-hit log is purged after 1 day
  • Cannot be linked to a person
  • Cannot be used across days or to recognise a returning visitor — not even by Sealmetrics
  • Never written to the device (no cookies, no localStorage, no sessionStorage), and the raw hash is never stored

Isolated Hit Tracking​

Each page view is recorded as an independent event with no identifier. No attempt is made to link hits to a user or to other hits. This provides the most privacy-preserving form of measurement: pure aggregate counting.

Both methods can run simultaneously or independently, depending on the account configuration. See tracker documentation for technical details.

How data flows​

  1. Event detection — the JavaScript tracker detects a page view or event. Nothing is written to the device: no cookies, no localStorage, no sessionStorage. The tracker reads standard browser properties to compute the session identifier, which is re-keyed daily on the server and never stored as sent.
  2. Transmission — the hit is sent as a lightweight beacon request to Sealmetrics' EU infrastructure. IP addresses appear at the network layer as they do for any HTTP request, but are never persisted in the analytics database; they are used in memory only for anti-abuse checks and site-configured exclusions.
  3. Processing — each hit is processed on its own. Hits are not joined to a person, and are not linked across sessions.
  4. Aggregation and reporting — dashboards report statistical patterns. Event-level detail is short-lived: it is purged after 1 day, hourly aggregates are kept 90 days, and daily aggregates and conversions 24 months. Retention is fixed for every plan and enforced by database TTLs — see Data Location & Retention.

All processing and storage of customer analytics data happens in Dublin, Ireland.

Practical effects of having no persistent identifiers​

  • Nothing for privacy tooling to strip. Ad blockers and browser tracking protections such as ITP target identifiers and known tracking domains; Sealmetrics stores nothing on the device and uses its own domain, so measurement stays consistent across Safari, Firefox and private browsing modes.
  • No CMP dependency. No cookie categorisation, no Consent Mode v2, no region-conditional GTM triggers, and no re-testing the analytics setup every time a banner changes.
  • No consent-driven attribution gaps. UTM values are read on arrival rather than after a banner interaction, so traffic is not misfiled as Direct when a visitor accepts cookies mid-journey.
  • Light footprint. The tracker is 1.1 KB gzipped, loads asynchronously and does not block rendering.

Implementation​

Adding consentless analytics to any website requires one line of code:

<script src="https://t.sealmetrics.com/t.js?id=YOUR_ACCOUNT_ID" defer></script>

No consent management platform, cookie banner configuration or Consent Mode setup for Sealmetrics itself (our self-assessment; Germany: open question). The tracker loads asynchronously (1.1 KB gzipped), detects SPA navigation automatically, and begins capturing data immediately.

For platform-specific installation, see guides for WordPress, WooCommerce, Shopify, Next.js, and more integrations.

Who Uses Consentless Analytics​

Consentless analytics is particularly valuable for:

  • E-commerce businesses that need accurate conversion and revenue data for budget allocation
  • Marketing teams that need reliable campaign attribution across all EU markets
  • Companies in regulated industries (finance, healthcare, government) where minimizing data collection reduces compliance risk
  • Multi-market businesses operating across EU countries with different consent rejection rates
  • Performance-focused teams that want a lightweight tracker without page speed impact

Frequently Asked Questions​

For aggregate metrics (total traffic, conversions, source attribution), consentless analytics is more accurate because consent rejection does not remove visits from the data. Cookie-based tools only measure the subset of visitors who accept consent, which creates a biased sample.

Can consentless analytics track returning visitors?​

No. Identifying returning visitors requires storing a persistent identifier, which constitutes personal data. Consentless analytics treats every session as independent. If you need returning visitor analysis, you would need a consent-based tool for that specific metric.

Does consentless analytics work with Google Ads?​

Yes. Sealmetrics reads UTM parameters from Google Ads URLs and attributes conversions and revenue to campaigns. It provides ROAS reporting at the campaign, source, and medium level. However, it does not sync audience data back to Google Ads for automated bidding.

Is this the same as server-side analytics?​

No. Server-side analytics (like log analysis) processes server access logs. Consentless analytics uses a client-side JavaScript tracker that fires on page load and user events. The key difference is that consentless analytics captures JavaScript-dependent events (SPA navigation, conversions, form submissions) that server logs cannot see.

How is this different from Plausible or Fathom?​

Plausible and Fathom are privacy-focused analytics tools, but they use hashed IP addresses for visitor identification. Some legal experts argue that hashed IPs still constitute personal data under GDPR. Sealmetrics does not store IPs or use them for analytics or geolocation — visitor country is derived from the browser timezone (Intl.DateTimeFormat().resolvedOptions().timeZone), not from IP. To filter bots we check the IP in flight against a public list of automated-traffic IPs, and don't keep it; site-configured exclusions are checked the same way, in memory. See the country detection page and the Sealmetrics vs Plausible comparison for details.

Learn More​

Ready to see your real traffic numbers? Open your free account — your first 1M events are free, setup takes about 4 minutes, and on our self-assessment no cookie banner is required for its own analytics.

Written and maintained by the Sealmetrics Team