Order #{order.id}
" \
-d "code_verifier=" \
-d "redirect_uri=https://acme.example/oauth/callback" \
-d "client_id="
```
```json
{
"access_token": "…",
"refresh_token": "…",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "analytics:read offline_access"
}
```
Token responses are sent with `Cache-Control: no-store`.
**Lifetimes:** authorization codes are valid for 5 minutes, access tokens for 1 hour, refresh tokens for 30 days.
### Refreshing
```bash
curl -X POST https://my.sealmetrics.com/api/v1/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=refresh_token" \
-d "refresh_token=" \
-d "client_id="
```
`grant_type` values other than `authorization_code` and `refresh_token` return `unsupported_grant_type`.
## Step 4 — Call the API
Use the access token as a bearer token against any read endpoint:
```bash
curl "https://my.sealmetrics.com/api/v1/stats/overview?account_id=ACCOUNT&period=30d" \
-H "Authorization: Bearer "
```
## Revoking
[RFC 7009](https://datatracker.ietf.org/doc/html/rfc7009). Revoking a refresh token tears down the whole grant.
```bash
curl -X POST https://my.sealmetrics.com/api/v1/oauth/revoke \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "token=" \
-d "token_type_hint=refresh_token"
```
Always returns `200`, whether or not the token existed — per the RFC, so the endpoint cannot be used to probe token validity.
Users can also revoke from the dashboard at any time: **My Account → Connected Apps**. See [Connected Apps](/platform/settings/account/connected-apps).
## Managing connections from the dashboard
These endpoints back the Connected Apps screen and authenticate with the dashboard session, not with an OAuth token:
| Endpoint | Method | Description |
|---|---|---|
| `/oauth/connections` | GET | List the user's active grants |
| `/oauth/connections/{grant_id}` | DELETE | Revoke one grant |
| `/oauth/consent/{request_id}` | GET | Details of a pending authorization request |
| `/oauth/consent/{request_id}/decision` | POST | Approve or deny, and choose the site |
| `/oauth/onboarding` | POST | Complete signup inside the consent flow |
## Error format
OAuth endpoints use the **RFC 6749 error shape**, not the standard Sealmetrics [error envelope](/api/errors):
```json
{
"error": "invalid_grant",
"error_description": "Authorization code is expired or already used"
}
```
| `error` | Meaning |
|---|---|
| `invalid_request` | A required parameter is missing or malformed |
| `invalid_client` | Unknown `client_id` |
| `invalid_redirect_uri` | The `redirect_uri` does not match a registered URI |
| `invalid_grant` | Code or refresh token is invalid, expired, already used, or the PKCE verifier does not match |
| `invalid_scope` | A requested scope is not in `scopes_supported` |
| `unsupported_response_type` | `response_type` is not `code` |
| `unsupported_grant_type` | `grant_type` is not `authorization_code` or `refresh_token` |
| `access_denied` | The user declined on the consent screen |
## Rate limiting
`/oauth/register`, `/oauth/authorize`, `/oauth/token` and `/oauth/revoke` are rate-limited per IP address, independently of the plan-tier limits described in [Rate Limits](/api/rate-limits). Back off on `429` and honour `Retry-After`.
## Related
- [For AI Agents](/api/for-agents) — which auth method to pick, and the rest of the agent surface
- [MCP Server](/integrations/mcp-server) — the hosted server that uses this flow
- [Connected Apps](/platform/settings/account/connected-apps) — the user-facing revocation screen
- [API Tokens](/api/api-tokens) — the simpler option for single-account access
## Provisioning (headless signup)
URL: https://docs.sealmetrics.com/api/provision
# Provisioning (headless signup)
`POST /provision` creates a **free-tier Sealmetrics account without a browser** — no card, no dashboard login, no OAuth round trip. It exists so an AI agent or an installer can go from "this site has no analytics" to "the tracker is live" inside a single conversation.
This is the endpoint behind the [`sealmetrics` CLI](https://www.npmjs.com/package/sealmetrics) and the `provision_site` tool in the [AI Agentic Package](/integrations/agentic-package).
**Info:**
If you just want an agent to set up analytics for you, install the [Agentic Package](/integrations/agentic-package) or run the CLI — both wrap this endpoint and handle the provision key for you. Call the endpoint yourself only if you are building your own installer or integration.
## Endpoint
Public and unauthenticated in the usual sense — there is no API key or session — but **gated by a publishable provision key** sent in the `X-Provision-Key` header. The key identifies the distribution channel (npm CLI, desktop extension, a partner integration) for attribution and rate limiting. It is publishable, not secret: it grants nothing except the ability to create free-tier accounts, under a rate limit.
The official CLI and MCP packages ship with a key embedded. If you are building your own integration and need your own key, email [support@sealmetrics.com](mailto:support@sealmetrics.com).
## Request
```bash
curl -X POST https://my.sealmetrics.com/api/v1/provision \
-H "Content-Type: application/json" \
-H "X-Provision-Key: " \
-d '{
"site_name": "My Shop",
"domain": "myshop.com",
"email": "me@example.com",
"name": "Rafa",
"accept_terms": true,
"install_source": "my-installer",
"timezone": "Europe/Madrid"
}'
```
| Field | Type | Required | Notes |
|---|---|---|---|
| `site_name` | string | Yes | 1–255 characters. |
| `email` | string | Yes | Valid email. Receives the claim link and the API key. |
| `accept_terms` | boolean | Yes | Must be `true`. The agent passes this on the human's behalf, so make sure the human has actually seen the [terms](https://sealmetrics.com/terms). |
| `domain` | string | No | Up to 255 characters. |
| `name` | string | No | The person's name, up to 255 characters. |
| `install_source` | string | No | Up to 64 characters. Free-form attribution label for your integration. |
| `timezone` | string | No | IANA timezone, up to 64 characters. Determines how `today`, `30d` and friends resolve for this site. |
## Response
```json
{
"success": true,
"data": {
"success": true,
"account_id": "…",
"snippet": "",
"api_key": "sm_…",
"dashboard_url": "https://my.sealmetrics.com/…",
"claim_url": "https://my.sealmetrics.com/…",
"free_quota": { "events_total": 1000000 },
"next_steps": [
"Paste the snippet just before the closing tag on every page.",
"Deploy your site so the tracker can start capturing pageviews.",
"Check your email to set a password and open your dashboard.",
"Read your analytics with the api_key via the Sealmetrics MCP server."
]
}
}
```
| Field | Description |
|---|---|
| `account_id` | Pass this as `account_id` to every [stats endpoint](/api/stats). |
| `snippet` | The tracking script, ready to paste before ``. |
| `api_key` | Read-only API key for this account. Also emailed to the user. |
| `claim_url` | Magic link for the human to set a password and take ownership. |
| `free_quota.events_total` | Free-tier event allowance — a **lifetime cumulative** cap, not a monthly one. |
**Caution:**
Both grant access to the new account. Never echo them into a chat transcript, a log, or a shared terminal — the official tools deliberately send them by email instead of printing them. If you build your own integration, do the same.
## Free tier
A provisioned account starts on the free tier with **1,000,000 events total** — cumulative over the life of the organization, not reset monthly. Rate limits follow the free-tier row in [Rate Limits](/api/rate-limits).
## Errors
| Status | `error.code` | `error.message` / meaning |
|---|---|---|
| `400` | `bad_request` | `accept_terms` was not `true`. |
| `400` | `invalid_input` | A field failed validation — see `error.message`. |
| `401` | `unauthorized` | Message is `provision_key_required` (header missing) or `invalid_provision_key` (unknown or deactivated key). |
| `409` | `provision_unavailable` | The account could not be created with those details. **Deliberately ambiguous**: it does not confirm whether the email is already registered. If a matching account exists, its owner is notified by email. Tell the user to log in and add a site from the dashboard. |
| `429` | `rate_limit_exceeded` | Rate-limited per IP *and* per provision key. Honour `Retry-After`. |
| `503` | `service_unavailable` | Message is `provisioning_disabled` — headless provisioning is switched off globally. Not retryable on a short timescale. |
Do not treat `409 provision_unavailable` as "email taken" in your UI copy. The API will not tell you that, on purpose.
## After provisioning
1. Place the `snippet` before `` and deploy.
2. Confirm the pixel is live — via `GET /sites/{id}/pixel/status` ([Sites](/api/sites)), or the `verify_setup` MCP tool.
3. Start reading data with the `api_key`: `GET /stats/overview?account_id=&period=7d`.
4. Point the user at `claim_url` so they can set a password.
## Related
- [For AI Agents](/api/for-agents) — the rest of the agent surface
- [AI Agentic Package](/integrations/agentic-package) — the packaged version of this flow
- [MCP Server](/integrations/mcp-server)
- [Quick Start](/api/quick-start)
- [Rate Limits](/api/rate-limits)
---
# Security & Privacy
## Privacy & Consentless Analytics
URL: https://docs.sealmetrics.com/security-privacy
# Privacy & Consentless Analytics
Explore how **Sealmetrics** redefines web analytics with complete privacy, consentless data capture, and GDPR-compliant measurement.
## Two-Factor Authentication
URL: https://docs.sealmetrics.com/security-privacy/account-security/two-factor-auth
# Two-Factor Authentication (2FA)
Two-factor authentication adds a second layer of security beyond your password, significantly reducing the risk of unauthorized access.
## Why Enable 2FA?
Even with a strong password, your account can be compromised through:
- Password reuse from other breached sites
- Phishing attacks
- Keyloggers or malware
- Shoulder surfing
With 2FA enabled, attackers need both your password AND physical access to your authenticator device.
## Supported Methods
### TOTP (Time-based One-Time Password)
Sealmetrics uses TOTP, the industry standard for 2FA:
- 6-digit codes that change every 30 seconds
- Works offline (no SMS needed)
- Compatible with all major authenticator apps
### Compatible Apps
| App | Platform | Notes |
|-----|----------|-------|
| Google Authenticator | iOS, Android | Simple, widely used |
| Authy | iOS, Android, Desktop | Cloud backup, multi-device |
| 1Password | All platforms | Integrated with password manager |
| Microsoft Authenticator | iOS, Android | Good for Microsoft ecosystems |
| Bitwarden | All platforms | Open source |
## Enabling 2FA
### Step 1: Access Security Settings
1. In the sidebar, go to **My Account → Security**
2. Find the **Two-Factor Authentication** section
### Step 2: Start Setup
Click **Enable 2FA**. You'll be asked to enter your current password to begin setup.
```
Two-Factor Authentication
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Status: Not enabled
Two-factor authentication adds an extra layer
of security by requiring a code from your
phone in addition to your password.
[Enable 2FA]
```
### Step 3: Scan QR Code and Save Backup Codes
```
Set Up Two-Factor Authentication
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 1: Scan this QR code with your authenticator app
┌─────────────────────┐
│ ▄▄▄▄▄ ▄▄▄ ▄▄▄▄▄ │
│ █ █ ▀▀▀ █ █ │
│ █▄▄▄█ ▄▄▄ █▄▄▄█ │
│ ▄▄▄▄▄ █▀█ ▄▄▄▄▄ │
│ █ █ ▀▀▀ █ █ │
│ █▄▄▄█ █▄▄▄█ │
└─────────────────────┘
Can't scan? Enter this code manually:
XXXX-XXXX-XXXX-XXXX (your unique secret)
```
On the same screen, Sealmetrics shows your **10 backup codes**. Save them somewhere safe before continuing — you'll use them to sign in if you lose your authenticator device. Each code can be used once.
```
Backup Codes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ Save these codes somewhere safe!
┌─────────────────────────────────────────┐
│ abc12-def34 ghi56-jkl78 │
│ mno90-pqr12 stu34-vwx56 │
│ yza78-bcd90 efg12-hij34 │
│ klm56-nop78 qrs90-tuv12 │
│ wxy34-zab56 cde78-fgh90 │
└─────────────────────────────────────────┘
[Copy All Codes]
[I've saved my backup codes]
```
### Step 4: Verify the Code
Enter the 6-digit code from your authenticator app to confirm setup.
```
Verify Setup
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Enter the 6-digit code from your authenticator app
[______]
[Verify & Enable]
```
### Step 5: Confirm Enabled
```
Two-Factor Authentication
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Status: ✅ Enabled
Enabled on: January 15, 2024
Backup codes remaining: 10 of 10
[Regenerate Codes] [Disable 2FA]
```
## Signing In with 2FA
After entering your email and password:
```
Two-Factor Authentication
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Enter the 6-digit code from your authenticator app
[______]
[Verify]
Having trouble?
→ Use a backup code instead
```
## Using Backup Codes
If you can't access your authenticator:
1. Click **Use a backup code instead**
2. Enter one of your saved backup codes
3. Sign in successfully
4. Code is marked as used
```
Use Backup Code
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Enter one of your backup codes:
[____________]
[Verify]
Note: Each backup code can only be used once.
After signing in, generate new codes if running low.
```
## Managing 2FA
The **Two-Factor Authentication** section in **My Account → Security** shows your status, the number of backup codes remaining (e.g. "8 of 10 codes remaining"), and buttons to **Regenerate Codes** and **Disable 2FA**.
**Note:**
### Regenerate Codes
When running low on backup codes:
1. Go to **My Account → Security**
2. In **Two-Factor Authentication**, click **Regenerate Codes**
3. Enter your current 6-digit 2FA code to confirm
4. Save the new codes securely — the old codes stop working immediately
### Change Authenticator App
To switch to a different authenticator:
1. Disable 2FA (requires current code)
2. Re-enable with new app
3. Scan new QR code
4. Save new backup codes
### Disable 2FA
Disabling 2FA requires **both** your password and a current verification code (a 6-digit code from your authenticator app, or a backup code).
```
Disable Two-Factor Authentication
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ This will make your account less secure.
Password: [________________]
Verification code: [______]
(6-digit code or a backup code)
[Disable 2FA]
```
## Lost Access to Authenticator
### If You Have Backup Codes
1. Sign in with backup code
2. Go to **My Account → Security**
3. Disable 2FA (requires your password and a backup code)
4. Re-enable with new device
### If You Don't Have Backup Codes
Contact support for account recovery:
1. Email security@sealmetrics.com
2. Provide:
- Account email
- Proof of identity (ID document)
- Recent activity details you remember
3. Support will verify and assist
**Warning:**
## Security Best Practices
### Do
- ✅ Use a reputable authenticator app
- ✅ Save backup codes in a secure location (password manager, safe)
- ✅ Keep backup codes separate from your password
- ✅ Regenerate codes after using some
### Don't
- ❌ Store backup codes in plaintext on your computer
- ❌ Share your authenticator with others
- ❌ Screenshot your QR code
- ❌ Disable 2FA without good reason
## Troubleshooting
### "Invalid Code" Error
1. Check your device time is accurate (TOTP is time-based)
2. Ensure you're entering code for Sealmetrics (not another service)
3. Wait for new code (codes change every 30 seconds)
4. Try using a backup code
### Authenticator Shows Wrong Time
TOTP requires accurate time:
**iPhone:** Settings → General → Date & Time → Set Automatically
**Android:** Settings → Date & Time → Automatic date & time
### Syncing Issues with Authy
1. Open Authy settings
2. Tap "Sync" to refresh
3. Try code again
## Related
- [Backup Codes](./backup-codes) - Managing your recovery codes
- [Session Management](./session-management) - View and manage active sessions
- [IP Allowlist](./ip-allowlist) - Restrict access by IP address
## What is Consentless Analytics?
URL: https://docs.sealmetrics.com/security-privacy/consentless-analytics
# What is Consentless Analytics?
**Consentless analytics** is a method of measuring website traffic and user behavior without requiring visitor consent. It achieves this by not collecting personal data, not setting cookies, and not using any form of user identification — making consent legally unnecessary under GDPR, ePrivacy Directive, and other privacy regulations.
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 typically lose **15–60% of visitor data in EU markets** — how much depends on sector, brand strength and traffic mix. 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. Every visitor is measured. Every page view is counted. Every conversion is attributed to its source. No consent is needed because no personal data is involved.
---
## How It Works: The Four-Variable System
Sealmetrics uses a consentless tracking approach built on four non-identifying variables per event:
1. **Timestamp** — when the event occurred
2. **User Agent** — browser and device type (used for anonymous device classification; the event-level raw string is purged after 1 day)
3. **Current URL** — the page being viewed
4. **Referral URL** — where the visitor came from
That is all. No cookies, no IP addresses stored, no fingerprinting, no localStorage, no sessionStorage, no cross-session linking.
This minimal dataset makes it technically impossible to identify any individual visitor, which is why consent is not required. For a deeper technical explanation, see [How Consentless Tracking Works](/security-privacy/how-consentless-works).
---
## Legal Basis: Why Consent Is Not Required
Consentless analytics does not require consent because it falls outside the scope of both GDPR and 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)). Consentless analytics does not process personal data:
- No IP addresses are stored
- No user identifiers are generated
- No behavioral profiles are built
- No cross-session tracking occurs
When no personal data is processed, GDPR consent requirements (Article 6) do not apply. Additionally, Recital 26 states that anonymized data falls outside the regulation's scope.
### 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.). Consentless analytics does not store or access any information on user devices, so Article 5(3) does not apply.
### Regulatory Guidance
Privacy authorities have explicitly recognized that certain analytics tools can operate without consent:
- **CNIL (France)** — Published criteria for analytics tools exempt from consent. Tools that do not track individuals, do not enable cross-site tracking, and aggregate data can operate without consent banners.
- **AEPD (Spain)** — Allows audience measurement without consent when data is aggregated daily and no personal identification is possible.
- **ICO (United Kingdom)** — Under the DUAA 2025 update to PECR, strictly necessary analytics cookies are exempt from consent.
Sealmetrics has completed self-assessments against [CNIL criteria](/compliance/cnil-self-assessment) and [UK PECR criteria](/compliance/uk-pecr-self-assessment), 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](/compliance/gdpr-cookieless-analytics).
### What this means for you as the data controller
- **No consent banner is required** for Sealmetrics measurement, 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](https://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](/compliance), including the self-assessments above.
---
## Consentless vs Cookie-Based Analytics
| | Cookie-Based (GA4, Adobe) | Consentless (Sealmetrics) |
|--|---------------------------|---------------------------|
| **Tracking method** | Cookies + client ID | Aggregate event measurement |
| **Consent required** | Yes | No |
| **Data capture (EU)** | Partial — 15–60% of visitor data lost to consent rejection | Every hit measured |
| **Cookie banners** | Required | Not needed |
| **Personal data** | Yes (client ID, IP) | No |
| **Cross-session tracking** | Yes | No |
| **User-level profiles** | Yes | No |
| **Data hosting** | Often US-based | EU-only (Dublin, Ireland) |
| **Script size** | 50–365 KB | 1.3 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 every visit 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 covering all visitors 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 (anonymous 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 from the short-lived session marker described in [What We Track](/security-privacy/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](/reports/definitions) for the exact formula behind each metric.
---
## How Sealmetrics Implements Consentless Analytics
Sealmetrics uses two complementary tracking methods:
### Session-Based Tracking
A temporary session identifier is generated when a visitor arrives. This ID exists only for the duration of the browser session and is never persisted. It enables grouping page views within a single visit without identifying the visitor.
Key properties:
- Expires when the browser tab/window closes
- Cannot be linked to a person
- Cannot be used across sessions
- Not stored on disk (no cookies, no localStorage)
### Isolated Hit Tracking
Each page view is recorded as an independent, anonymous event. 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](/implementation/tracker) for technical details.
### How data flows
1. **Event detection** — the JavaScript tracker detects a page view or event. Nothing is written to or read from the device: no cookies, no localStorage, no sessionStorage, no fingerprinting.
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](/security-privacy/data-location).
All processing and storage of customer analytics data happens in **Dublin, Ireland**.
### Practical effects of having no identifiers
- **Nothing for privacy tooling to strip.** Ad blockers and browser tracking protections such as ITP target identifiers and known tracking domains; Sealmetrics sets none 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.3 KB gzipped, loads asynchronously and does not block rendering.
---
## Implementation
Adding consentless analytics to any website requires one line of code:
```html
```
No consent management platform needed. No cookie banner configuration. No Consent Mode setup. The tracker loads asynchronously (1.3 KB gzipped), detects SPA navigation automatically, and begins capturing data immediately.
For platform-specific installation, see guides for [WordPress](/integrations/cms/wordpress), [WooCommerce](/integrations/ecommerce/woocommerce), [Shopify](/integrations/ecommerce/bigcommerce), [Next.js](/integrations/frameworks/nextjs), and [more integrations](/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
### Is consentless analytics less accurate than cookie-based analytics?
For aggregate metrics (total traffic, conversions, source attribution), consentless analytics is *more* accurate because it captures 100% of traffic. 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 never processes visitor IP addresses for analytics **or geolocation** — visitor country is derived from the browser timezone (`Intl.DateTimeFormat().resolvedOptions().timeZone`), not from IP. IPs are only handled in-memory at the edge for anti-bot checks and site-configured exclusions, and are never persisted. See the [country detection page](/security-privacy/country-detection) and the [Sealmetrics vs Plausible comparison](/blog/sealmetrics-vs-plausible) for details.
---
## Learn More
- [How Consentless Tracking Works](/security-privacy/how-consentless-works) — Technical deep dive into the Four-Variable System
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) — Full legal analysis with GDPR article references
- [CNIL Self-Assessment](/compliance/cnil-self-assessment) — Compliance against CNIL's 14 criteria
- [GA4 vs Sealmetrics](/faq/ga4-vs-sealmetrics) — Feature-by-feature comparison
- [Getting Started](/getting-started/quick-start) — Set up consentless analytics in under 5 minutes
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) — The consent-free legal basis in plain language
- [Benefits of Consentless Tracking](/security-privacy/consentless-benefits) — Why the consentless model outperforms cookie-based tools
- [Frequently Asked Questions](/faq/privacy-security) — Common privacy and security questions
---
*Ready to see your real traffic numbers? [Start a free trial](https://my.sealmetrics.com/register) — setup takes under 5 minutes, no cookie banner required.*
## Backup Codes
URL: https://docs.sealmetrics.com/security-privacy/account-security/backup-codes
# Backup Codes
Backup codes are one-time use codes that let you access your account when you can't use your authenticator app.
## What Are Backup Codes?
Backup codes are:
- 10 unique codes generated when you enable 2FA
- Each code can only be used once
- Your safety net when your phone is lost, broken, or unavailable
- Independent of your authenticator app
## When to Use Backup Codes
Use a backup code when:
- Your phone is lost or stolen
- Your phone is dead and you can't charge it
- You're traveling without your usual device
- Your authenticator app was deleted
- You got a new phone and forgot to transfer 2FA
## Viewing Your Backup Codes
Backup codes are shown **only once** — when you first enable 2FA, and again each time you regenerate them. For security, Sealmetrics does not let you re-view an existing set later.
In **My Account → Security**, the **Two-Factor Authentication** section shows how many codes you have left (for example, "8 of 10 codes remaining"), but it does not list the codes themselves or which specific codes were used.
```
Two-Factor Authentication
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Backup Codes
8 of 10 codes remaining
[Regenerate Codes]
```
If you can't find the codes you saved, generate a new set with **Regenerate Codes** (see below).
## Using a Backup Code
### At Login
1. Enter your email and password
2. On the 2FA screen, click **Use a backup code instead**
3. Enter one of your backup codes
4. Click **Verify**
```
Use Backup Code
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Can't access your authenticator?
Use one of your backup codes to sign in.
Enter backup code:
[mno90-pqr12 ]
[Verify]
← Back to authenticator code
```
### After Using a Code
Once a backup code is used, it can't be used again. The remaining-codes count in **My Account → Security** decreases accordingly. When you're running low, regenerate a fresh set so you always have codes available.
## Regenerating Codes
Generate new codes when:
- You've used several codes
- You think codes may be compromised
- You want fresh codes for peace of mind
### How to Regenerate
1. Go to **My Account → Security**
2. In **Two-Factor Authentication**, click **Regenerate Codes**
3. Enter your current 6-digit 2FA code
4. Save the new codes
```
Regenerate Backup Codes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ This will invalidate ALL existing codes,
including unused ones.
Current unused codes: 7
These will stop working.
Enter your 2FA code to confirm:
[______]
[Cancel] [Regenerate]
```
### After Regenerating
```
New Backup Codes Generated
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Your previous codes have been invalidated.
Save these new codes securely.
┌─────────────────────────────────────────┐
│ new11-code22 │
│ abc33-def44 │
│ ghi55-jkl66 │
│ mno77-pqr88 │
│ stu99-vwx00 │
│ yza11-bcd22 │
│ efg33-hij44 │
│ klm55-nop66 │
│ qrs77-tuv88 │
│ wxy99-zab00 │
└─────────────────────────────────────────┘
[Download] [Copy] [I've Saved Them]
```
## Storing Backup Codes Safely
### Good Storage Options
| Method | Pros | Cons |
|--------|------|------|
| Password manager | Encrypted, accessible | Single point of failure |
| Physical printout in safe | Offline, secure | Can be lost/destroyed |
| Encrypted USB drive | Portable, secure | Can be lost |
| Bank safe deposit box | Very secure | Inconvenient access |
### Storage Best Practices
1. **Never store in plaintext** on your computer
2. **Keep separate** from your password
3. **Store in multiple locations** (e.g., password manager + printed backup)
4. **Don't take photos** on your phone (could sync to cloud)
5. **Label clearly** so you know what they're for
### What NOT to Do
- ❌ Email codes to yourself
- ❌ Store in notes app without encryption
- ❌ Keep only one copy
- ❌ Store in same place as password
- ❌ Share with others
## Running Low on Codes
There's no automatic alert when you're down to your last few codes. Check the remaining count in **My Account → Security** periodically, and regenerate a new set before you run out so you always have a way back into your account.
## Troubleshooting
### "Invalid Backup Code" Error
1. Check for typos (especially 0 vs O, 1 vs l)
2. Ensure you haven't already used this code
3. Verify codes haven't been regenerated since you saved them
4. Try a different code
### All Codes Used
If you've used all 10 codes:
- You must have access to your authenticator to generate new codes
- If you can't access your authenticator, contact support
### Lost All Codes and Authenticator
Contact support for account recovery:
1. Email security@sealmetrics.com
2. Subject: "2FA Account Recovery"
3. Include:
- Your account email
- Proof of identity
- Recent account activity you remember
4. Recovery takes 2-5 business days
## Related
- [Two-Factor Authentication](./two-factor-auth) - Setting up and using 2FA
- [Session Management](./session-management) - Manage your active sessions
## How Sealmetrics determines the country without using IP addresses
URL: https://docs.sealmetrics.com/security-privacy/country-detection
# Country Determination Without Using IP Addresses
## Timezone-Based Geo Estimation
Sealmetrics determines the country of origin for each event ("hit") using the **timezone configured in the user's browser**. This method provides an approximate geographic estimation without processing IP addresses or collecting personal identifiers.
### 1. Retrieving the Timezone
The browser exposes the timezone value through standard APIs such as:
``` js
Intl.DateTimeFormat().resolvedOptions().timeZone
```
Examples of possible values include:\
- `Europe/Madrid`\
- `America/Santiago`\
- `Asia/Tokyo`
This information is provided directly by the user's device and **does not contain identifiable data**, nor does it allow individual tracking.
### 2. Mapping Timezone to Country
Each timezone is matched against an internal table connecting **IANA
timezones** to the countries that use them.
- For unique timezones (e.g., `Asia/Tokyo`), the country is determined
with high confidence.\
- For shared timezones (e.g., `Europe/Paris`), the system selects the
most likely country based on majority usage or internal statistical
criteria.
The resulting estimation is accurate enough for aggregated analytics and
attribution metrics, although it cannot guarantee absolute precision in
every case.
### 3. Privacy & Compliance
This approach fully adheres to privacy and data-minimization principles:
- No IP lookup is involved in country determination — not for
analytics reports, and not for anything else. (A country-by-IP
signal was designed for the Agent Analytics bot detector, but that
feature is not live and cannot be enabled, so no such lookup runs
on any account. See
[What We Track](/security-privacy/what-we-track).)\
- No unique device identifiers are stored.\
- Timezone information does not identify the user.\
- Country calculation relies solely on non-personal technical data
provided by the browser.
Thanks to this method, Sealmetrics can offer meaningful geographic
insights while preserving user privacy and operating without requiring
consent for tracking.
## Related documentation
- [What We Track vs What We Don't](/security-privacy/what-we-track) — where timezone-based country fits in the data model
- [How Sealmetrics Protects User Privacy](/security-privacy/how-we-protect-privacy) — the data-minimization approach behind this method
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) — why non-IP geo needs no consent
- [Geography Report](/reports/geography) — see the country-level insights this produces
- [Frequently Asked Questions](/faq/privacy-security) — common privacy questions
## IP Allowlist
URL: https://docs.sealmetrics.com/security-privacy/account-security/ip-allowlist
# IP Allowlist
IP allowlisting restricts access to a Sealmetrics **site (account)** to a defined set of IP patterns, adding a network-level control on top of passwords and 2FA.
The allowlist is configured **per site** in the dashboard under **Site Config → Settings → IP Allowlist**, and is also available through the [IP Allowlist API](/api/ip-allowlist) for automation.
**Info:**
## What Is IP Allowlisting?
When an account's allowlist is enabled, requests from an IP that doesn't match any active pattern are rejected — even with valid credentials. When the allowlist is disabled, the account is reachable from any IP.
```
Request to an account
↓
Allowlist enabled? ──No──► Allow
│ Yes
IP matches an active pattern? ──No──► Block
│ Yes
Allow
```
If a user belongs to several accounts, login filters the accounts they can reach from their current IP: accounts whose allowlist blocks the IP are dropped, while accounts without an active allowlist remain available.
## Settings
Each site's allowlist has these settings:
| Setting | Default | Description |
|---------|---------|-------------|
| `is_enabled` | `false` | Whether the allowlist is enforced for the site |
| `enforce_for_dashboard` | `true` | Apply the IP check to dashboard / JWT authentication |
| `enforce_for_api_tokens` | `true` | Apply the IP check to API token authentication |
In the dashboard, the IP Allowlist tab exposes the **Enable IP Allowlist** toggle (`is_enabled`) and the list of patterns. The `enforce_for_dashboard` and `enforce_for_api_tokens` flags default to enabled and can be adjusted through the [API](/api/ip-allowlist) — for example, to enforce the allowlist for dashboard logins while leaving API token access unrestricted, or vice versa.
## Pattern Types
Each entry in the allowlist is a **pattern** with one of three types:
| Type | Example | Matches |
|------|---------|---------|
| `ip` | `192.168.1.100`, `2001:db8::1` | One exact IPv4 or IPv6 address |
| `cidr` | `192.168.1.0/24`, `10.0.0.0/8` | All addresses in a CIDR range |
| `regex` | `^192\.168\..*` | Any address matching the regular expression |
Each pattern can also carry an optional **label** (e.g. "Office Network") and **description**, and can be toggled active or inactive.
## Typical Setup
1. Go to **Site Config → Settings → IP Allowlist**.
2. **Add your patterns first** with **Add IP Pattern** — every IP, CIDR range, or regex you need, including your current IP and any VPN exit IPs. Each pattern can have a label.
3. **Enable the allowlist** with the **Enable IP Allowlist** toggle.
**Warning:**
## Examples
### Office network and a static home IP
```
Office network (CIDR): 192.168.1.0/24 label: "Office"
VPN range (CIDR): 203.0.113.0/28 label: "VPN"
CEO home (IP): 83.45.123.78 label: "CEO Home"
```
### Dynamic IPs
If your ISP assigns dynamic addresses, prefer a **CIDR range** that covers the pool, or route through a VPN with a static exit IP and allowlist that. A broad `regex` pattern is also possible but harder to reason about — use it sparingly.
## When Access Is Blocked
A blocked login is rejected with an "IP not allowed" error. Access attempts (granted and denied) are recorded with the IP address, authentication type (dashboard or API token), and which pattern matched, so you can review them via the API.
There is no in-product "request access" workflow or self-serve admin bypass. If you lock yourself out, connect from an already-allowed network (office or VPN), have a teammate with access add your IP, or contact support to disable enforcement.
## Best Practices
- ✅ Add and verify your current IP before enabling enforcement
- ✅ Include VPN exit IPs (the public exit IP, not the internal VPN address)
- ✅ Use CIDR ranges for office networks instead of listing each address
- ✅ Label each pattern so its purpose is clear
- ✅ Review the allowlist periodically and remove patterns you no longer need
- ❌ Don't enable enforcement with no matching pattern for your own connection
- ❌ Don't use overly broad ranges that defeat the purpose
## Troubleshooting
### Locked out
1. Connect from an already-allowed location (office, VPN)
2. Ask a teammate with access to add your IP
3. Contact support to disable enforcement, then re-add your IP
### Can't access from VPN
1. Confirm you're allowlisting the VPN **exit** IP, not the internal VPN address
2. Find the exit IP with `curl ifconfig.me`
3. Add that IP (or its CIDR range) to the allowlist
## How Sealmetrics Protects User Privacy
URL: https://docs.sealmetrics.com/security-privacy/how-we-protect-privacy
# How Sealmetrics Protects User Privacy
Sealmetrics protects visitors by **not collecting the data that would put them at risk in the first place**. The protection is architectural rather than procedural: there is no personal data to secure, disclose, leak or hand over, because none is collected.
In practice that means four things:
- **Nothing is written to the visitor's device.** No cookies, no localStorage, no sessionStorage, no fingerprinting. The session marker used to group hits within one visit is held in memory, expires with the visit, and cannot recognise a returning visitor.
- **No identifier is stored.** No IP addresses in the analytics database (they are used in memory only for anti-abuse checks and site-configured exclusions), no user IDs, no device IDs, no cross-session or cross-device linking. The user agent is kept for anonymous device classification only — the raw string for 1 day, then only the derived browser/OS/device categories inside aggregates.
- **Data is minimised, then aged out.** Event-level rows are purged after 1 day, hourly aggregates after 90 days, daily aggregates and conversions after 24 months. Retention is fixed for every plan and enforced by database TTLs.
- **Storage stays in the EU.** All customer analytics data is stored and processed in Dublin, Ireland, encrypted in transit and at rest, under role-based access control.
Because visitor analytics data carries no identifier, a visitor access or deletion request cannot be matched to any record — there is nothing tied to an individual to produce or erase. Account data (your dashboard users: name, email, billing) is a different category and data subject rights apply to it in full; see [Data Subject Rights (DSAR)](/compliance/data-subject-rights). A Data Processing Agreement is included and ready to sign at [sealmetrics.com/dpa](https://sealmetrics.com/dpa/).
Sealmetrics holds no third-party security certification such as ISO 27001 or SOC 2, and no supervisory authority certifies analytics tools. What exists is our own [compliance self-assessments](/compliance) against published criteria.
## Related documentation
- [What We Track vs What We Don't](/security-privacy/what-we-track) — the field-by-field detail, with retention
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — the model and its legal basis
- [Data Location & Retention](/security-privacy/data-location) — EU hosting, encryption, retention schedule, account closure
- [Privacy by Design Principles](/security-privacy/privacy-by-design) — how these choices map to the privacy-by-design framework
- [Account Security](/security-privacy/account-security/two-factor-auth) — protecting the dashboard account itself
## Session Management
URL: https://docs.sealmetrics.com/security-privacy/account-security/session-management
# Session Management
Session management lets you see the devices where **your own account** is currently signed in, and sign out of sessions you don't recognize.
## Viewing Active Sessions
1. In the sidebar, go to **My Account → Security**
2. Find the **Active Sessions** section
Your current session is highlighted, and any other sessions are listed below it.
```
Active Sessions
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Current Session:
┌─────────────────────────────────────────┐
│ 🟢 macOS — Chrome │
│ IP: 192.168.1.50 │
│ Active now [Current] │
└─────────────────────────────────────────┘
Other Sessions:
┌─────────────────────────────────────────┐
│ 🟢 iOS — Safari │
│ IP: 83.45.123.78 │
│ Last active: 2 hours ago [🗑] │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ ⚪ Windows — Chrome │
│ IP: 203.0.113.45 │
│ Last active: 3 days ago [🗑] │
└─────────────────────────────────────────┘
[Logout All Other Sessions]
```
## Session Information
Each session shows:
| Field | Description |
|-------|-------------|
| Device | Operating system inferred from the browser (macOS, Windows, iOS, Android, Linux) |
| Browser | Chrome, Firefox, Safari, Edge, etc. (inferred from the user agent) |
| IP Address | The IP address recorded for the session |
| Last Active | When the session was last used |
**Note:**
## Signing Out Sessions
### Single Session
Click the trash icon next to any other session to terminate it. That device's token is invalidated immediately and the session is removed from the list.
### All Other Sessions
Click **Logout All Other Sessions** to sign out everywhere except your current device.
```
Logout All Other Sessions?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
This will:
• Log out your other sessions
• Invalidate all existing tokens on those devices
• Require re-authentication on those devices
Your current session stays active.
[Cancel] [Logout All Sessions]
```
## When to Review Sessions
Review your sessions when:
- 🔴 **Immediately:** You notice suspicious activity
- 🔴 **After:** Your password was compromised
- 🟡 **Regularly:** Monthly security check
- 🟡 **After:** Using a shared or public computer
- 🟢 **Optionally:** After traveling
## Suspicious Sessions
### Warning Signs
Watch for sessions from:
| Sign | Concern Level | Action |
|------|---------------|--------|
| Unknown device or browser | 🔴 High | Sign out, change password |
| IP address you don't recognize | 🔴 High | Sign out immediately |
| Very old sessions | 🟡 Medium | Sign out for hygiene |
### If You See Suspicious Activity
1. **Sign out** the suspicious session immediately
2. **Change your password** right away
3. **Enable 2FA** if not already enabled
4. **Review** recent account activity
5. **Check** for any changes made to your account
```
⚠️ Suspicious Session Detected?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
If you don't recognize this session:
1. Terminate that session (trash icon)
2. Use **Logout All Other Sessions** to clear every other device
3. Change your password
4. Review the [Audit Logs](/platform/settings/advanced/audit-log) for unexpected activity
```
**Note:**
## Session Security Best Practices
- ✅ Sign out from shared computers
- ✅ Review your sessions periodically
- ✅ Enable 2FA on your account
- ✅ Use **Logout All Other Sessions** if you suspect your account was accessed
- ❌ Don't stay signed in on public computers
- ❌ Don't ignore sessions you don't recognize
## Troubleshooting
### "Session expired unexpectedly"
- Verify you didn't sign out from another device or use **Logout All Other Sessions**
- Note that changing your password signs out all sessions
- Clear browser cookies and sign in again
### "Can't see my sessions"
- Make sure you're signed in
- Try refreshing the page
### "Old sessions still showing"
- "Last active" shows the last recorded activity for that session
- Terminate a session to remove it from the list immediately
## Why Sealmetrics Is Not Blocked by AdBlockers
URL: https://docs.sealmetrics.com/security-privacy/adblocker-bypass
# Why Sealmetrics Is Not Blocked by AdBlockers
## How Sealmetrics Bypasses AdBlockers
Most analytics platforms rely on **third-party tracking domains**, which are automatically flagged and blocked by AdBlockers. Sealmetrics avoids this completely by using a **1st-party tracking architecture** that is treated as part of your own website.
---
## How AdBlockers Work
AdBlockers typically block requests to well-known tracking domains such as:
- `google-analytics.com`
- `facebook.net`
- `doubleclick.net`
When a pixel or script loads from a recognized third-party tracker, the AdBlocker intercepts and blocks it automatically.
This is one of the reasons traditional analytics lose data — alongside consent rejection, which costs them 15–60% depending on sector, brand strength and traffic mix.
---
## Why Sealmetrics Is Not Blocked
### Sealmetrics Uses 1st-Party Tracking
Instead of loading the pixel from a third-party domain, Sealmetrics works through **your own domain**, for example:
```
https://analytics.yourdomain.com/t.js
```
Because the request is served from a subdomain of your own site, AdBlockers treat it as a first-party asset and do **not** block it. No uBlock, AdBlock Plus, Brave Shields, or Safari ITP heuristic flags this traffic as third-party tracking.
---
## Why This Matters
- **No data loss** from ad-blocking users (typically 25–40% of tech-literate audiences).
- **Accurate attribution** — cookieless, server-side attribution works without cookies or third-party domains.
- **GDPR-safe** — first-party collection of non-personal data requires no consent banner.
- **Resilient** — Safari ITP, Firefox ETP and Chrome's Privacy Sandbox target cross-site tracking, not first-party requests, so first-party delivery is not what those mechanisms are built to block.
---
## How to Configure 1st-Party Tracking
See the [Tracker Installation guide](/implementation/tracker/installation) and the [CNAME setup](/implementation/tracking-methods) to point a subdomain of your own site at the Sealmetrics pixel.
Once configured, Sealmetrics captures 100% of your traffic — including users behind AdBlockers, VPNs, and aggressive privacy extensions.
## Related documentation
- [1st Party Tracker](/implementation/tracker/first-party) — the first-party architecture that avoids ad-blocker filters
- [First Party Tracker](/implementation/tracker/first-party) — configure the first-party subdomain
- [Installation](/implementation/tracker/installation) — install and point a subdomain at the pixel
- [Bot Detection & Traffic Quality](/security-privacy/bot-detection) — how captured traffic is kept clean of bots
- [Frequently Asked Questions](/faq/privacy-security) — common privacy and tracking questions
## How Attribution Works Without a User-ID
URL: https://docs.sealmetrics.com/security-privacy/attribution-without-userid
# How Attribution Works Without a User-ID
Sealmetrics delivers accurate campaign and conversion attribution without using User-IDs, cookies, fingerprinting, or session reconstruction. This article explains the mechanism behind our privacy-preserving attribution system.
---
## Why Traditional Analytics Require User-IDs
Conventional analytics platforms depend on identifiers to track user journeys:
- Cookie IDs
- Device IDs
- Fingerprints
- Cross-session identifiers
These technologies **link visits, clicks, and conversions to individuals**, which legally requires consent under GDPR and ePrivacy.
Sealmetrics does **not** use any of these identifiers.
---
## Sealmetrics' Privacy-First Approach
Sealmetrics does **not**:
❌ Track individual users across sessions
❌ Link a hit to a person (there is no personal identifier to link with)
❌ Store IP addresses
❌ Use cookies or persistent identifiers
The user agent is used for anonymous device classification (browser/OS category): the raw string is purged with the event row after 1 day, and only the derived categories persist in the 24-month aggregates. Neither can be joined with anything that identifies the person — because no such identifier exists. Short-lived session context exists inside a single browsing session (~2-hour inactivity), never across sessions or devices.
---
## The Key Innovation — The Source-ID
Instead of identifying users, Sealmetrics groups traffic and conversions using a **Source-ID**, derived exclusively from **traffic source characteristics**, not from user behavior.
### A Source-ID is generated from:
- `utm_source`
- `utm_medium`
- `utm_campaign`
- `utm_term`
- OR the referring domain
No personal data. No unique identifiers.
### How It Works
1. A visitor lands on the site from a marketing source
2. Sealmetrics reads the traffic parameters
3. A **Source-ID** is generated from those parameters
4. All hits with the same campaign parameters share the same Source-ID
5. Conversions inherit the same Source-ID
This groups interactions by **campaign**, not by user.
---
## Example — Attribution in Action
### 🔵 Step 1: User clicks a Google Ads campaign
UTM parameters detected → Source-ID created.
### 🟣 Step 2: They browse the site
Hits remain isolated but carry the same Source-ID.
### 🟢 Step 3: They convert
The conversion is assigned to the same Source-ID.
### Result
**Conversion is attributed to Google Ads → Campaign XYZ → Keyword ABC.**
No user identification required.
---
## Why This Needs No Consent
Because no identifier is created and nothing is stored on the device, the obligations these frameworks attach to personal data and to terminal storage are not triggered:
- ✔ No personal data
- ✔ No user identification
- ✔ No behavioral profiling
- ✔ No cross-session linkage
- ✔ No consent required
Privacy protection is embedded by design.
---
## What You Can Measure With Source-ID
Even without User-IDs, Sealmetrics provides full marketing intelligence:
### Campaign Analytics
- Traffic by campaign
- Source/medium performance
- UTM analytics
- Cost attribution
- ROAS
### Conversion Analytics
- Conversions per channel
- Revenue attribution
- Aggregated funnel insights
- Lead and e-commerce conversions
### Accuracy Benefits
- No consent loss
- No cookie rejection
- 100% traffic + 100% conversions measured
---
## Summary
Sealmetrics proves that accurate attribution **does not** require user tracking.
We achieve attribution by grouping hits by **campaign characteristics**, not by individuals.
- 🟢 No personal data processed
- 🟢 Every hit measured — no loss from consent rejection
- 🟢 No User-IDs, no cookies, no consent banner
Because no personal data is involved, no consent is required — see [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent). Sealmetrics holds no third-party security certification, and the [compliance pages](/compliance) are self-assessments.
## Related documentation
- [How Attribution Accuracy Works](/reports/insights/attribution-accuracy) — how last-click, source-based attribution performs
- [What We Track vs What We Don't](/security-privacy/what-we-track) — the non-identifying signals that feed the Source-ID
- [How Consentless Tracking Works](/security-privacy/how-consentless-works) — the isolated-hit model behind this approach
- [Sources Report](/reports/sources) — see traffic and conversions grouped by source and campaign
- [Attribution Model](/faq/attribution) — how Sealmetrics assigns conversions to channels
## Security & Privacy
URL: https://docs.sealmetrics.com/security-privacy/overview
# Security & Privacy
Sealmetrics measures websites **without collecting personal data**: four non-identifying variables per hit, nothing written to the visitor's device, no identifier carried across sessions, and all customer analytics data stored in Dublin, Ireland. Because there is no personal data, the consent requirements of GDPR and the ePrivacy Directive are not triggered — the reasoning is set out in full in [What is Consentless Analytics?](/security-privacy/consentless-analytics).
Sealmetrics holds no third-party security certification (no ISO 27001, no SOC 2), and no supervisory authority certifies analytics tools. The pages under [compliance](/compliance) are our own self-assessments against published criteria. A Data Processing Agreement is included and ready to sign at [sealmetrics.com/dpa](https://sealmetrics.com/dpa/); Annex 3 of that DPA is the authoritative subprocessor list.
## Start here
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — the concept, the legal basis under GDPR and ePrivacy, and what the model can and cannot measure
- [What We Track vs What We Don't](/security-privacy/what-we-track) — the field-by-field list, with retention for each field
## The consentless model
- [How Consentless Tracking Works](/security-privacy/how-consentless-works) — the technical mechanics, step by step
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) — the short answer on consent
- [Benefits of Consentless Tracking](/security-privacy/consentless-benefits) — what complete data changes in practice
- [How Attribution Works Without a User-ID](/security-privacy/attribution-without-userid) — last-click attribution without identifiers
## Privacy practice
- [How Sealmetrics Protects User Privacy](/security-privacy/how-we-protect-privacy) — the concrete protections
- [Privacy by Design Principles](/security-privacy/privacy-by-design) — the seven principles mapped to architecture
- [How Sealmetrics determines the country without using IP addresses](/security-privacy/country-detection) — timezone-based geolocation
## Data, hosting and quality
- [Data Location & Retention](/security-privacy/data-location) — EU hosting, retention schedule, encryption, deletion and export
- [Bot Detection & Traffic Quality](/security-privacy/bot-detection) — how automated traffic is filtered out of reports
- [Why Sealmetrics Is Not Blocked by AdBlockers](/security-privacy/adblocker-bypass) — first-party delivery and why filter lists do not match
## Account security
- [Two-Factor Authentication](/security-privacy/account-security/two-factor-auth)
- [Backup Codes](/security-privacy/account-security/backup-codes)
- [Session Management](/security-privacy/account-security/session-management)
- [IP Allowlist](/security-privacy/account-security/ip-allowlist)
## Auditing someone else's tags
- [What Is This Domain in My Cookie Audit?](/security-privacy/third-party-analytics-domains) — lookup table of external analytics domains
- [What Is demdex.net?](/security-privacy/demdex-net-cookies) — Adobe's Experience Cloud ID cookies
- [What Is omtrdc.net?](/security-privacy/omtrdc-net-requests) — Adobe Analytics' collection domain
## Related documentation
- [Compliance self-assessments](/compliance) — GDPR, ePrivacy, CNIL, AEPD, PECR analysed one by one
- [Data Subject Rights (DSAR)](/compliance/data-subject-rights) — how access and erasure requests work
- [Privacy and security FAQ](/faq/privacy-security) — common questions in Q&A form
## Why Sealmetrics Can Measure Without Consent
URL: https://docs.sealmetrics.com/security-privacy/why-no-consent
# Why Sealmetrics Can Measure Without Consent
Sealmetrics needs no consent banner because it collects **no personal data** and stores **nothing on the visitor's device**. Two separate rules are in play, and neither one attaches:
- **GDPR** governs the processing of personal data. Sealmetrics stores no IP address, no user ID, no persistent identifier and no profile, so the obligations that apply to personal data — including the consent question — are not triggered.
- **The ePrivacy Directive** (Article 5(3)) requires consent to store or read information on a user's terminal equipment. Sealmetrics sets no cookies and uses no localStorage or sessionStorage, so there is nothing on the device to ask about.
What Sealmetrics records instead is four non-identifying variables per hit: **timestamp**, **user agent** (used for anonymous device classification — the raw string is purged after 1 day, and only the derived browser/OS/device categories persist in aggregates for 24 months), **current URL** and **referral URL**. Hits are measured on their own; they are never joined to a person or linked across sessions.
This distinction matters more than it looks. Under ePrivacy, tracking individuals requires consent *even when the tracking is anonymous* — which is why moving tags server-side does not remove the consent requirement. Sealmetrics does not track individuals at all, which is a different thing from tracking them anonymously.
Both the CNIL (France) and the AEPD (Spain) have published criteria under which audience measurement can operate without consent, and Sealmetrics has self-assessed against them. To be clear about what that is and is not: no supervisory authority certifies or approves analytics tools, so the [compliance pages](/compliance) are our own assessments against published criteria, not third-party validations. Sealmetrics also holds no ISO 27001 or SOC 2 certification. A Data Processing Agreement is included and ready to sign at [sealmetrics.com/dpa](https://sealmetrics.com/dpa/).
## Related documentation
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — the full legal basis, with the GDPR and ePrivacy articles and the regulatory guidance
- [What We Track vs What We Don't](/security-privacy/what-we-track) — every variable recorded, with its retention
- [How Consentless Tracking Works](/security-privacy/how-consentless-works) — the technical mechanism
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) — the detailed regulatory analysis
- [Consentless Analytics FAQ](/faq/consentless-analytics) — the same question in Q&A form
## Bot Detection & Traffic Quality
URL: https://docs.sealmetrics.com/security-privacy/bot-detection
# Bot Detection & Traffic Quality
SealMetrics employs multiple layers of protection to ensure your analytics data reflects real human visitors, not bots or spam traffic.
---
## Multi-Layer Detection System
### Layer 1: IP Blocklist
Known malicious IPs are blocked at the edge:
- **Global blocklist** — Common bot IPs, data centers, VPN exit nodes
- **Per-account blocklist** — Custom IPs you want to exclude
- **Real-time updates** — Blocklist refreshed automatically
### Layer 2: User-Agent Filtering
Bot signatures in the User-Agent string are detected:
- Known bot identifiers (Googlebot, Bingbot, etc.)
- Automated tool signatures (curl, wget, python-requests)
- Headless browser patterns (HeadlessChrome, PhantomJS)
### Layer 3: Geographic Validation
Traffic from unknown or suspicious locations:
- Missing geo data indicates potential bots
- Data center IP ranges flagged
- Unusual geographic patterns monitored
### Layer 4: Behavioral Analysis
Click patterns and timing analysis:
- Inhuman click speeds detected
- Rapid repeated actions blocked
- Session behavior scoring
### Layer 5: HMAC Token Validation
Each request includes a cryptographic token:
- Prevents replay attacks
- Validates request authenticity
- Time-bound token expiration
### Layer 6: Domain Authorization
Only authorized domains can send data:
- Configure allowed domains in Settings
- Prevents data injection from unauthorized sources
- Subdomain wildcard support
---
## How Bot Traffic is Handled
When bot traffic is detected:
1. **Blocked immediately** — No data stored
2. **Logged for analysis** — Helps improve detection
3. **Not counted** — Never appears in reports
---
## What Gets Filtered
| Traffic Type | Filtered | Notes |
|--------------|----------|-------|
| Search engine crawlers | Yes | Googlebot, Bingbot, etc. |
| SEO tools | Yes | Ahrefs, Semrush, Moz |
| Uptime monitors | Yes | Pingdom, UptimeRobot |
| Security scanners | Yes | Vulnerability scanners |
| Automated testing | Yes | Selenium, Puppeteer |
| Data center traffic | Yes | AWS, GCP, Azure IPs |
| Known bot networks | Yes | Spam networks |
| Your own test traffic | Configurable | Optional filtering |
---
## What Passes Through
| Traffic Type | Tracked | Notes |
|--------------|---------|-------|
| Real browsers | Yes | Chrome, Firefox, Safari, etc. |
| Mobile apps | Yes | In-app browsers |
| VPN users | Yes | Legitimate users with VPNs |
| Tor exit nodes | Configurable | Can be filtered if needed |
---
## Agent Detection (not available)
**Caution:**
Advanced agent detection — also referred to as Agent Analytics — is **designed but not live, and cannot be enabled on any account**, including on request. Nothing described in this section runs today, and no account collects behavioral signals. The layers above are the whole of what filters bot traffic.
If it ships, it would work like this:
1. **Initial classification** — first hit analyzed
2. **Behavioral signals** — mouse movements, scroll patterns, timing
3. **Final classification** — human vs. suspected agent
Planned classification results:
| Classification | Meaning |
|----------------|---------|
| `human` | Confirmed human behavior |
| `agent_suspected` | Automated behavior detected |
Classification would happen at session level: the entrance is classified and its pageviews inherit the result.
---
## Custom Blocklists
### Adding IPs to Blocklist
You can exclude specific IPs via the dashboard:
1. Go to **Settings → Security**
2. Select **IP Blocklist**
3. Add IPs or CIDR ranges
```
192.168.1.100 # Single IP
10.0.0.0/8 # CIDR range
```
### Common Use Cases
- Exclude your office IP
- Block competitor scrapers
- Filter internal testing traffic
---
## User-Agent Blocklist
Block traffic by User-Agent patterns:
1. Go to **Settings → Security**
2. Select **UA Blocklist**
3. Add patterns (supports regex)
```
curl/* # Block curl requests
python-requests/* # Block Python scripts
custom-bot/* # Block specific bot
```
---
## Data Quality Indicators
In your reports, look for:
- **Bounce rate** — Extremely high rates may indicate bot traffic
- **Session duration** — 0-second sessions could be bots
- **Geographic distribution** — Unusual concentrations warrant investigation
---
## Best Practices
1. **Review traffic periodically** — Check for anomalies
2. **Use content grouping** — Helps identify targeted bot traffic
3. **Monitor conversion rates** — Bots don't convert
4. **Check referrer sources** — Unknown referrers may be spam
---
## Comparison with Other Tools
| Feature | SealMetrics | Google Analytics |
|---------|-------------|------------------|
| Bot filtering | Multi-layer | Single checkbox |
| Custom blocklists | Yes | Limited |
| Real-time blocking | Yes | Delayed |
| Behavioral analysis | Yes | Limited |
| Transparent filtering | Yes | Black box |
---
## Related Documentation
- [Domain Authorization](/platform/account-setup/how-to-add-domains)
- [First-Party Tracking](/implementation/tracker/first-party)
- [Privacy Overview](/security-privacy/overview)
- [Bot Stats](/api/bot-stats) — query filtered bot traffic through the API
- [Frequently Asked Questions](/faq/privacy-security) — common privacy and traffic-quality questions
## Data Location & Retention
URL: https://docs.sealmetrics.com/security-privacy/data-location
# Data Location & Retention
Sealmetrics is committed to data sovereignty and transparent retention policies.
---
## Data Location
### Customer Analytics Data: Dublin, Ireland
All customer analytics data — every hit, report, and backup — is stored and processed in **Dublin, Ireland (EU)**:
| Component | Location | Provider |
|-----------|----------|----------|
| Application servers | Dublin, Ireland | EU data center |
| Analytics database | Dublin, Ireland | EU data center |
| Backups | Dublin, Ireland | EU data center |
### Why EU?
- **GDPR compliance** — Data stays within EU jurisdiction
- **Data sovereignty** — No US CLOUD Act concerns for stored data
- **Low latency** — Fast response times for European users
- **Legal clarity** — Single regulatory framework
### No Data Transfer Outside EU
Your analytics data:
- Never leaves EU borders
- Is stored and processed exclusively on EU infrastructure
- Is not transferred to any third country
- Remains under EU data protection law
---
## Data Retention Periods
### Analytics Data
Retention is **fixed and identical for every plan**, enforced by database TTLs:
| Data Type | Retention | Notes |
|-----------|-----------|-------|
| Event-level detail | 1 day | Individual hit data, then purged |
| Hourly aggregates | 90 days | Hour-by-hour reports |
| Daily aggregates | 24 months | Daily/monthly reports |
| Conversion data | 24 months | Including properties |
### Operational Data
| Data Type | Retention | Notes |
|-----------|-----------|-------|
| Raw logs | 1 day | For debugging only |
| Error logs | 30 days | System diagnostics |
| API access logs | 90 days | Security audit trail |
### Real-time / Session Data
| Data Type | Retention | Notes |
|-----------|-----------|-------|
| Session state (Redis) | 2 hours | Ephemeral, in-memory session grouping |
---
## Why 24 Months?
The 24-month retention for aggregated reports and conversions allows:
1. **Year-over-year comparison** — Compare current month to same month last year
2. **Seasonal analysis** — Full 2-year cycle for seasonal businesses
3. **Trend identification** — Long-term patterns become visible
4. **Regulatory compliance** — Meets typical audit requirements
---
## Data Deletion
### Automatic Deletion
Data older than retention period is automatically purged:
- Runs daily during low-traffic hours
- Irreversible deletion
- No recovery possible
### Manual Deletion
You can request early deletion:
1. **Single account** — Contact support
2. **Specific date range** — Provide details
3. **Full account deletion** — Account closure
### Account Closure
When you close your account:
- All data deleted within 30 days
- Backups purged within 90 days
- No data retained after that
---
## What We Store
### Collected Data Points
| Data | Stored | Purpose |
|------|--------|---------|
| Page URL | Yes | Page analytics |
| Referrer | Yes | Traffic sources |
| UTM parameters | Yes | Campaign tracking |
| Device info | Yes | Device reports |
| Browser | Yes | Browser analytics |
| Country | Yes | Geographic reports |
| Timestamp | Yes | Timing analysis |
| Session ID | Yes (hashed) | Session grouping |
### Not Stored
| Data | Stored | Why |
|------|--------|-----|
| IP address | No | Privacy |
| Cookies | No | Consentless |
| Email | No | Not collected |
| Name | No | Not collected |
| User ID | No | Privacy |
---
## Data Security
### Encryption
| State | Encryption |
|-------|------------|
| In transit | TLS 1.3 |
| At rest | AES-256 |
| Backups | AES-256 |
### Access Control
- Role-based access
- Audit logging
- Two-factor authentication available
- IP allowlist option
---
## Regulatory Compliance
| Framework | Status |
|-----------|--------|
| GDPR | Compliant |
| ePrivacy | Compliant |
Sealmetrics does not hold third-party security certifications (such as SOC 2 or ISO 27001). Compliance with GDPR and ePrivacy is based on the architecture described above — no personal data collected, EU-only processing — and is documented in the [compliance self-assessments](/compliance).
---
## Subprocessors
Sealmetrics keeps its subprocessor list deliberately short. The authoritative, always-current list is **Annex 3 of the [Data Processing Agreement](https://sealmetrics.com/dpa)**.
All subprocessors sign data processing agreements and are GDPR compliant. **Visitor analytics data is processed and stored exclusively in the EU.**
Full details: [Subprocessors](/compliance/subprocessors)
---
## Data Portability
Export your data anytime:
1. **Dashboard exports** — CSV downloads
2. **API access** — Full programmatic access
3. **Bulk export** — Contact support for large exports
---
## Questions?
- **DPO contact** — privacy@sealmetrics.com
- **Data requests** — support@sealmetrics.com
- **Legal inquiries** — legal@sealmetrics.com
---
## Related Documentation
- [Privacy Overview](/security-privacy/overview)
- [What We Track](/security-privacy/what-we-track)
- [Subprocessors](/compliance/subprocessors)
- [Data Subject Rights (DSAR)](/compliance/data-subject-rights)
- [GDPR Compliance](/compliance/compliance-overview/legal-faq)
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent)
- [Frequently Asked Questions](/faq/privacy-security)
## Benefits of Consentless Tracking
URL: https://docs.sealmetrics.com/security-privacy/consentless-benefits
# Benefits of Consentless Tracking
The practical case for consentless tracking is that **the data arrives complete and stays complete**. Cookie-based analytics typically lose 15–60% of visitor data in EU markets — the range depends on sector, brand strength and traffic mix — because a tool that only fires after consent records nothing from visitors who decline. Sealmetrics fires on every visit, so there is no consent-shaped hole in the numbers.
Four benefits follow from having no cookies and no identifiers.
**Complete data.** Every hit is measured regardless of whether a banner was accepted, what the browser's privacy settings are, or whether the visitor is in a private window. That removes the two most common distortions in EU reporting: missing traffic and the "dark traffic" that gets filed as Direct.
**Nothing for privacy tooling to block.** Ad blockers and browser protections such as Safari's ITP target identifiers, third-party cookies and known tracking domains. Sealmetrics sets no identifiers, stores nothing on the device and serves from its own domain, so measurement stays consistent across browsers and browser versions.
**Cleaner attribution.** UTM values are read when the visitor arrives, not after they interact with a banner, so a mid-journey consent acceptance cannot overwrite the original source. Attribution is last-click at channel level — the model that works without linking touchpoints to a person. Multi-touch attribution is not available for exactly that reason.
**No consent machinery to run.** No CMP, no Consent Mode v2 configuration, no cookie categorisation, no region-conditional GTM triggers, and no re-testing analytics every time the banner changes. The tracker is 1.3 KB gzipped, loads asynchronously and does not block rendering.
The trade-off is real and worth stating plainly: consentless measurement gives up user-level metrics. There are no unique visitors, no session duration, no cross-session journeys and no cohorts, because each of those requires a persistent identifier. See [what the model can and cannot measure](/security-privacy/consentless-analytics#what-consentless-analytics-can-and-cannot-measure).
## Related documentation
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — the concept, legal basis and full comparison with cookie-based tools
- [What We Track vs What We Don't](/security-privacy/what-we-track) — every field recorded, with retention
- [GA4 vs Sealmetrics](/faq/ga4-vs-sealmetrics) — feature-by-feature comparison
- [Cookie Banner Ghosting: Why Data Disappears](/blog/cookie-banner-ghosting-data-loss) — the consent problem behind the data loss
- [Cookieless vs Cookie-Based Analytics](/blog/cookieless-analytics-vs-cookie-based) — technical comparison of both approaches
## How Consentless Tracking Works
URL: https://docs.sealmetrics.com/security-privacy/how-consentless-works
# How Consentless Tracking Works
Consentless tracking measures **events in aggregate instead of following people**. The tracker records four non-identifying variables per hit — timestamp, user agent, current URL and referral URL — sends them to EU infrastructure, and never writes anything to the visitor's device. Because there is no identifier and nothing stored on the device, there is nothing to ask consent for.
## The mechanics, in four steps
1. **Event detection.** A JavaScript tracker (1.3 KB gzipped) fires on page load and on events you instrument. It sets no cookies and uses no localStorage, sessionStorage or fingerprinting.
2. **Transmission.** The hit is sent as a lightweight beacon request. The visitor's IP appears at the network layer, as it does for any HTTP request, but is never persisted in the analytics database — it is used in memory only for anti-abuse checks and site-configured exclusions.
3. **Isolated processing.** Each hit is processed on its own. Hits from the same person are never joined across sessions, so no journey or profile can be reconstructed.
4. **Aggregation.** Reports are built from aggregate counts. Event-level rows — including the raw user agent string — are purged after 1 day; hourly aggregates are kept 90 days; daily aggregates and conversions 24 months. Retention is fixed for every plan and enforced by database TTLs.
All customer analytics data is stored and processed in **Dublin, Ireland (EU)**.
## Two measurement modes
**Isolated hits** — every page view is an independent, anonymous event with no link to any other event. This is the most privacy-preserving mode: pure aggregate counting.
**Session-marked hits** — a short-lived, context-derived marker groups the hits of one visit (roughly a two-hour inactivity window). It is held in memory, never written to the device, and cannot recognise a returning visitor. Markers incorporate the publisher account, so the same browser produces different markers on different sites and no cross-site correlation is possible. This is what makes within-session metrics such as bounce rate and pages per session possible without an identifier.
## Why this needs no consent
No personal data is collected, so the GDPR obligations that attach to personal data are not triggered; and nothing is stored on or read from the visitor's terminal equipment, so the ePrivacy Directive's Article 5(3) consent requirement does not attach either. Cookie-based tools face the opposite situation, which is why they typically lose **15–60% of visitor data** in EU markets when visitors decline, depending on sector, brand strength and traffic mix.
Sealmetrics holds no third-party security certification, and no supervisory authority certifies analytics tools — the [compliance pages](/compliance) are self-assessments against published criteria.
## Where to read the detail
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — the full concept, the legal basis, the comparison with cookie-based tools, and what the model can and cannot measure
- [What We Track vs What We Don't](/security-privacy/what-we-track) — every field recorded, with its retention
- [Data Location & Retention](/security-privacy/data-location) — EU hosting, complete retention schedule, encryption
- [How Attribution Works Without a User-ID](/security-privacy/attribution-without-userid) — last-click attribution mechanics
- [Installation](/implementation/tracker/installation) — adding the script tag and instrumenting conversions
- [Cookieless Tracking: Technical Deep Dive](/blog/cookieless-tracking-technical-deep-dive) — extended analysis of the architecture
## Privacy by Design Principles
URL: https://docs.sealmetrics.com/security-privacy/privacy-by-design
# Privacy by Design Principles
Privacy by Design is the framework GDPR Article 25 refers to as *data protection by design and by default*. Sealmetrics satisfies it the blunt way: by not collecting personal data, so there is no personal data to protect, disclose or lose. The seven principles below map to specific architectural choices rather than to policies.
| Principle | How it shows up in Sealmetrics |
|-----------|-------------------------------|
| **1. Proactive, not reactive** | Privacy constraints are structural. The system cannot start identifying visitors later without a redesign, because there is no identifier to switch on. |
| **2. Privacy as the default** | Anonymous measurement from the first page load. Visitors do not opt in to anything, and there is no less-private mode to fall back to. |
| **3. Full functionality** | Traffic, attribution, conversions, revenue and aggregate engagement are all reported without personal data. What is genuinely lost — unique visitors, session duration, cross-session journeys — is [documented rather than worked around](/security-privacy/consentless-analytics#what-consentless-analytics-can-and-cannot-measure). |
| **4. End-to-end security** | EU-only storage in Dublin, Ireland; encryption in transit and at rest; role-based access control; short retention enforced by database TTLs. See [Data Location & Retention](/security-privacy/data-location). |
| **5. Visibility and transparency** | The complete field list and its retention is published in [What We Track](/security-privacy/what-we-track). The tracker is client-side and inspectable. |
| **6. Respect for user privacy** | No cookies, no device storage, no fingerprinting, no cross-session or cross-site linking. Session markers incorporate the publisher account, so the same browser yields different markers on different sites. |
| **7. Accommodate all legitimate interests** | Site owners get the measurement they need for business decisions; visitors are not identified to provide it. |
Two claims worth keeping straight, because vendor reviews turn on them: privacy by design is an architectural property, **not a certification**. Sealmetrics holds no ISO 27001 or SOC 2 certification, and no supervisory authority certifies analytics tools. The pages under [compliance](/compliance) are our own self-assessments against published criteria, and a Data Processing Agreement is included at [sealmetrics.com/dpa](https://sealmetrics.com/dpa/).
## Related documentation
- [What We Track vs What We Don't](/security-privacy/what-we-track) — the field-by-field disclosure behind principle 5
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — the model and its legal basis
- [How Sealmetrics Protects User Privacy](/security-privacy/how-we-protect-privacy) — the same protections in plain language
- [Data Location & Retention](/security-privacy/data-location) — the security and retention detail behind principle 4
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) — the regulatory analysis
## What We Track vs What We Don’t
URL: https://docs.sealmetrics.com/security-privacy/what-we-track
# 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 anonymous device classification), current URL, referral URL, and a short-lived contextual session marker — and never collects personal data or sets cookies. **No IP address, user ID, cross-session identifier, name, email or persistent device fingerprint is stored.** Because this minimal, aggregation-only dataset contains no personal data, the GDPR obligations that attach to personal data are not triggered, and there is nothing stored on the visitor's device for the ePrivacy Directive to require consent for. 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?](/security-privacy/consentless-analytics).
---
## What We DO Track
### The Four-Variable System (Isolated Hits)
Sealmetrics processes each page view (“hit”) independently using **only four non-identifying data points**:
#### 1. Timestamp
- **Purpose:** time-based analysis and trend insights
- **Privacy:** cannot identify an individual
#### 2. User Agent
- **Purpose:** anonymous device classification (browser family, OS family, mobile/desktop/tablet)
- **What we keep:** the raw UA string is stored in the event row alongside the derived category buckets. Event-level rows are purged after 1 day; the derived category dimensions (browser family, OS family, device type) 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
- Anonymous content performance
#### 4. Referral URL
- Anonymous attribution
- Campaign performance
- Traffic source identification
#### 5. Session context marker
- **What it is:** an in-memory, short-lived identifier scoped to a single browsing session (~2-hour inactivity timeout, GA4-style), derived from the visitor's browser context. It exists so that within one session we can distinguish "second pageview" from "new entrance".
- **What it isn't:** a cross-session identifier. It is not a cookie, it is not stored in the browser (localStorage, sessionStorage, or otherwise), and it does not persist beyond the session. It cannot be used to recognize a returning visitor.
- **Site-isolated by design:** session identifiers incorporate the publisher account into their derivation, so the same browser yields different identifiers on different publishers' sites — no cross-site correlation is possible at the identifier level.
- **Why it's compliant:** the identifier is context-derived and short-lived — it does not enable individual tracking under GDPR Article 4(1), which is why analytics without user identifiers can operate without consent under the CNIL's audience-measurement criteria. Note that no Article 6 legal basis is needed for the stored dataset: with no personal data in it, the GDPR does not apply to it (Recital 26).
---
## How Long Each Field Is Kept
Retention is **fixed and identical for every plan**, enforced by database TTLs. Nothing here is configurable per customer.
| What | Retention | Notes |
|------|-----------|-------|
| Event-level rows (including the raw user agent string) | **1 day** | The row that holds the individual hit, then purged |
| Session context marker | ~2 hours | In-memory only (Redis), expires with the inactivity window |
| Hourly aggregates | 90 days | Hour-by-hour reporting |
| Daily aggregates and conversions | 24 months | Includes the *derived* device categories — browser family, OS family, device type |
The distinction that matters for the user agent: **the raw UA string lives for 1 day** in the event row. What survives for 24 months is only the derived category (for example "Chrome / Windows / desktop") inside aggregate counts — never the original string, and never attached to anything that identifies a person.
Full operational retention (logs, backups, account closure) is documented in [Data Location & Retention](/security-privacy/data-location).
---
## What This Allows Us to Measure
### 1. Page Analytics
- Pageviews (aggregated)
- Top pages
- Anonymous navigation patterns
### 2. Traffic Analytics
- Entrances (anonymous hits)
- 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 context marker; they never require recognising a returning visitor. Session *duration* and unique visitors are not measured. See the [Metrics Reference](/reports/definitions).
### 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 (anonymous; 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. Anonymous Device Data
- Browser category
- OS category
- Desktop / mobile / tablet
- Screen-size buckets
- Language
### 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
**Caution:**
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](/security-privacy/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 Personal Data Stored
❌ IP addresses (used in memory only, never persisted)
❌ User IDs
❌ Emails
❌ Phone numbers
❌ Names
❌ Persistent identifiers (no cross-session 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 Device-Level Identifiers
❌ Device IDs
❌ MAC addresses
❌ Hardware fingerprints
❌ Advertising IDs
### No Tracking Technologies
❌ Cookies
❌ LocalStorage
❌ SessionStorage
❌ Fingerprinting
❌ Terminal code
❌ Web beacons
### No Private Communications or Content
❌ Email contents
❌ Chat messages
❌ Form personal data (only event counts)
❌ Uploaded files
❌ Social media posts
❌ Documents
---
## Why This Dataset Needs No Consent
- **GDPR** — European company, customer analytics data stored only in Dublin, Ireland. No personal data is collected, so the obligations that attach to personal data are not triggered. Hits are processed in isolation and no identifier is carried across sessions.
- **ePrivacy Directive** — nothing is stored on or read from the visitor's device (no cookies, no localStorage, no sessionStorage), so the Article 5(3) consent requirement does not attach.
- **CCPA / PECR** — no personal information is collected 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](/compliance) are our own self-assessments against published criteria. A signed DPA is available at [sealmetrics.com/dpa](https://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 personal data. 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.
## Related documentation
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — the concept and the legal basis in full
- [Data Location & Retention](/security-privacy/data-location) — where the data lives and the complete retention schedule
- [How Attribution Works Without a User-ID](/security-privacy/attribution-without-userid) — how the four variables still produce attribution
- [How Sealmetrics determines the country without using IP addresses](/security-privacy/country-detection) — timezone-based geo without personal data
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) — why this minimal dataset needs no consent
- [Frequently Asked Questions](/faq/privacy-security) — common questions about what is and isn't collected
- [Analytics Cookies: Consent Exemption Requirements](/compliance/analytics-cookies-exemption) — the criteria that make consent-free analytics lawful
## What Is This Domain in My Cookie Audit?
URL: https://docs.sealmetrics.com/security-privacy/third-party-analytics-domains
# What Is This Domain in My Cookie Audit?
You ran a cookie scan, a CMP audit or a privacy report, and it returned a list of domains
your site contacts. Some are obvious. Others — `omtrdc.net`, `demdex.net`, `mxpnl.com` — give
no clue who owns them or what they do.
This page maps them. Every entry comes from our own measurement: we installed each tool on
the same page and recorded which external hosts it actually contacted, rather than trusting
vendor documentation.
---
## 1. The lookup table
Sorted alphabetically by domain, which is how you will be reading it.
| Domain | Tool | What it does | Party | Resolves |
|---|---|---|---|---|
| `api-js.mixpanel.com` | Mixpanel | Event ingestion | Third | US |
| `assets.adobedtm.com` | Adobe Launch | Tag manager delivery | Third | Akamai CDN |
| `cdn.mxpnl.com` | Mixpanel | Library delivery | Third | US |
| `cdn.usefathom.com` | Fathom Analytics | Script and collection | Third | — |
| `collect.yourdomain.com` | SealMetrics | Collection, on your own subdomain | **First** | Your DNS |
| `d1.sc.omtrdc.net` | Adobe Analytics | Collection | Third | — |
| `.demdex.net` | Adobe Experience Cloud ID | Identity and ID sync | Third | AWS Dublin |
| `dpm.demdex.net` | Adobe Experience Cloud ID | ID sync endpoint | Third | AWS Dublin |
| `google-analytics.com` | GA4 | Collection | Third | EU CDN |
| `googletagmanager.com` | Google Tag Manager | Script delivery | Third | US |
| `gtm-msr.appspot.com` | Google Tag Manager | Preview and debug sandbox | Third | — |
| `plausible.io` | Plausible | Script and collection | Third | — |
| `queue.simpleanalyticscdn.com` | Simple Analytics | Collection queue | Third | — |
| `region1.google-analytics.com` | GA4 | Regional collection | Third | US |
| `sc.omtrdc.net` | Adobe Analytics | Collection | Third | — |
| `us-assets.i.posthog.com` | PostHog | Asset delivery | Third | US |
| `us.posthog.com` | PostHog | Collection | Third | US |
| `yourname.containers.piwik.pro` | Piwik PRO | Tag manager | Third | EU/US |
| `yourname.piwik.pro` | Piwik PRO | Collection | Third | EU/US |
The `yourname.` and `yourdomain.com` portions vary per account — the rest of the hostname is
the identifying part.
---
## 2. How to read the "Party" column
**Third-party** means the domain is not yours. The browser treats cookies set there as
third-party cookies, which Safari and Firefox block by default and Chrome restricts. It also
means a DNS lookup and a connection to infrastructure you do not control, on every page load.
**First-party** means the request goes to a subdomain of your own site. Cookies set there
survive browser restrictions, and there is no cross-origin request to justify in an
assessment.
Two things this column does not tell you:
- **First-party does not mean "no consent needed."** ePrivacy Article 5(3) governs *storage
on the device*, not who owns the domain. A first-party cookie still requires consent. What
removes the requirement is storing nothing at all.
- **Some tools can be configured either way.** Adobe supports a CNAME implementation that
moves the visitor ID to your own domain. Check your own setup rather than assuming the
default.
---
## 3. What "Resolves" tells you, and what it does not
Where a hostname resolves is a useful fact and a weak argument.
It is useful because a domain resolving to US infrastructure means a cross-border transfer to
document. It is weak because the reverse does not hold: `dpm.demdex.net` resolves to AWS
Dublin, inside the EU, and that does **not** make the transfer question go away. Schrems II
turns on legal access regimes — who can compel disclosure — rather than on where the packet
lands.
So treat an EU result as one input to the assessment, not as the conclusion. And do not repeat
the inverse shortcut that "a US company means the data leaves the EU"; on this evidence it is
simply not true.
---
## 4. Checking your own site
The table tells you what a domain is. Only your own site tells you what it is doing.
1. Open your site in a private window, DevTools on the **Network** tab.
2. Reload and sort by domain. Compare what appears against the table above.
3. Note the **timestamp** of each collection request. That is when measurement starts;
anything before it is unmeasured.
4. Reload with an **ad blocker** enabled. Anything that disappears is a domain your reports
silently lose.
5. Reload with the consent banner **rejected**. Anything that still fires is a compliance
finding rather than a data one.
Steps 4 and 5 are the ones worth recording. The first three describe your setup; the last two
tell you whether it behaves the way you think it does.
---
## 5. Detail pages
Domains with enough going on to need their own page:
- [demdex.net cookies](/security-privacy/demdex-net-cookies) — the Adobe identity layer: `demdex`, `dextp`, `dst`, and the first-party `AMCV_*` set
- [omtrdc.net requests](/security-privacy/omtrdc-net-requests) — the Adobe collection endpoint: what the request is, when it fires, and why an image GET loses visits
- [gtm-msr.appspot.com and tag blocking](/reports/insights/gtm-msr-appspot-and-tag-blocking) — Google Tag Manager's preview sandbox, and how to stop it firing your tags
---
## 6. Related documentation
- [Consentless Analytics](/security-privacy/consentless-analytics) — measuring without storing anything on the device, so Article 5(3) is never engaged
- [What We Track](/security-privacy/what-we-track) — the full list of what SealMetrics collects
- [Adblocker Bypass](/security-privacy/adblocker-bypass) — why filter lists block collection endpoints
- [Data Location](/security-privacy/data-location) — where SealMetrics processes and stores data
## What Is demdex.net? The Adobe Cookies in Your Audit
URL: https://docs.sealmetrics.com/security-privacy/demdex-net-cookies
# What Is demdex.net? The Adobe Cookies in Your Audit
If you have run a cookie audit, a CMP scan or a privacy report on your own site, `demdex.net`
is one of the domains that turns up without an obvious owner. It is **Adobe**.
Specifically, it belongs to the **Adobe Experience Cloud ID Service (ECID)** — the component
that assigns and syncs a visitor identifier across Adobe products. It appears whenever Adobe
Analytics is installed, **even if you do not use Adobe Audience Manager**.
---
## 1. The cookies you will see
| Cookie | Domain | Type | What it does |
|---|---|---|---|
| `demdex` | `.demdex.net` | Third-party | Core ECID visitor identifier |
| `dextp` | `.demdex.net` | Third-party | Records the last time an ID sync ran with a given partner |
| `dst` | `.demdex.net` | Third-party | Signals an error state in the ID sync process |
| `AMCV_*` | Your domain | First-party | The Experience Cloud ID as stored on your own site |
| `AMCVS_*` | Your domain | First-party | Session flag for the ECID service |
| `s_vi` | Your domain | First-party | Adobe Analytics visitor ID |
| `s_fid` | Your domain | First-party | Fallback visitor ID, used when `s_vi` cannot be set |
| `s_cc` | Your domain | First-party | Checks whether cookies are enabled |
`dextp` and `dst` only appear once Audience Manager is in play. The `demdex` cookie itself is
part of the base ECID infrastructure and shows up regardless.
---
## 2. Where the requests actually go
Adobe Analytics contacts **four** external domains on a standard install:
| Domain | Role |
|---|---|
| `assets.adobedtm.com` | Adobe tag manager (Akamai CDN) |
| `dpm.demdex.net` | ECID sync endpoint |
| `sc.omtrdc.net` | Analytics collection |
| `d1.sc.omtrdc.net` | Analytics collection |
One detail worth knowing before it appears in a vendor assessment: when we measured these
endpoints, **`dpm.demdex.net` resolved to AWS Dublin** — inside the EU. The common shorthand
that "Adobe is a US company, therefore the data leaves the EU" does not survive a DNS lookup.
That does not settle the transfer question. Schrems II turns on legal access regimes rather
than server geography, so the assessment depends on Adobe's corporate structure and the
safeguards in your contract, not on where the packet lands. It is a question for your counsel
— but the geography argument is not the one to build it on.
---
## 3. What this means for consent
Under the ePrivacy Directive, Article 5(3), consent is required before **storing or accessing**
information on a visitor's device. The rule applies to the act of storage, regardless of
whether the stored value is personal data.
Every cookie in the table above is storage on the device. That means:
- They must fire **after** an affirmative consent signal, not before.
- Legitimate interest is not available here. ePrivacy does not offer the route GDPR does for
some processing.
- Third-party cookies on `.demdex.net` will usually need their own entry in your CMP, since
they are set on a domain you do not control.
A frequent audit finding is that the ECID call fires on page load while the CMP is still
initialising. The result is a cookie set before consent — which is a finding, not a
configuration preference.
---
## 4. Your numbers are probably already affected
Independent of consent, **Safari and Firefox block third-party cookies by default**. The
`.demdex.net` cookies are third-party by definition, so ID syncing silently degrades for a
large share of visitors before your banner is involved at all.
The visible symptom is usually attribution: returning visitors counted as new, and channel
credit drifting toward direct. If your Adobe reports have stopped reconciling with revenue,
this is one of the places to look.
---
## 5. How to check your own site
1. Open your site in a private window with DevTools on the **Network** tab.
2. Filter for `demdex`.
3. Reload, and watch **when** the call to `dpm.demdex.net` fires — specifically whether it
happens before you interact with the consent banner.
4. Switch to **Application → Cookies** and check both your own domain and `.demdex.net`
against the table in section 1.
5. Repeat with the banner **rejected**. Any cookie still present at that point is the finding
worth writing down.
Step 5 is the one that matters. Steps 1 to 4 tell you what is installed; step 5 tells you
whether your consent gate actually works.
---
## 6. Related documentation
- [Third-party domain lookup](/security-privacy/third-party-analytics-domains) — the full table of external domains analytics tools contact, and which tool owns each
- [omtrdc.net requests](/security-privacy/omtrdc-net-requests) — the Adobe collection endpoint, and why an image GET loses visits
- [Consentless Analytics](/security-privacy/consentless-analytics) — measuring without setting anything on the device, so Article 5(3) is never engaged
- [Why No Consent Is Needed](/security-privacy/why-no-consent) — the legal basis in full
- [What We Track](/security-privacy/what-we-track) — the complete list of what SealMetrics collects, for comparison
- [Adblocker Bypass](/security-privacy/adblocker-bypass) — why filter lists block collection endpoints, and what that costs
- [Bot Detection](/security-privacy/bot-detection) — separating real visitors from automated traffic
## What Is omtrdc.net? Adobe's Collection Domain, Explained
URL: https://docs.sealmetrics.com/security-privacy/omtrdc-net-requests
# What Is omtrdc.net? Adobe's Collection Domain, Explained
`omtrdc.net` turns up in network logs, cookie audits and CSP reports on any site running
Adobe Analytics. It is **Adobe** — the name is a contraction of *Omniture Track Domain*,
from the company Adobe acquired in 2009.
Unlike [`demdex.net`](/security-privacy/demdex-net-cookies), which handles identity,
`omtrdc.net` is the **collection endpoint**. Every pageview, event and conversion Adobe
records leaves the browser as a request to this domain. If a request to `omtrdc.net` does not
happen, that visit does not exist in Adobe Analytics.
That makes it the most useful domain on the list to understand, because it is where data is
won or lost.
---
## 1. The hostnames you will see
| Hostname | Role |
|---|---|
| `sc.omtrdc.net` | Primary collection endpoint |
| `d1.sc.omtrdc.net` | Regional collection endpoint |
| `.sc.omtrdc.net` | Tenant-specific collection host |
The `` portion is your Adobe report suite's tracking namespace, so the exact
hostname differs per account. All of them serve the same function.
For context, a standard Adobe Analytics install contacts **four** external domains:
| Domain | Role |
|---|---|
| `assets.adobedtm.com` | Adobe Launch tag manager (Akamai CDN) |
| `dpm.demdex.net` | Experience Cloud ID sync |
| `sc.omtrdc.net` | Analytics collection |
| `d1.sc.omtrdc.net` | Analytics collection |
---
## 2. What the request actually is
The hit to `omtrdc.net` is an **image GET** — historically a 1×1 pixel request with the
measurement payload encoded in the URL.
This matters more than it sounds. An image GET is a normal browser resource request, which
means it is **cancelled if the visitor leaves the page before it completes**. A visit that
bounces, or a user who taps back quickly, can produce no hit at all.
The modern alternative is `navigator.sendBeacon()`, which hands the payload to the browser
and survives page unload by design. SealMetrics uses `sendBeacon`; Adobe's AppMeasurement
uses the image GET.
---
## 3. When the hit fires
We measured this on a real European media site running both vendors side by side:
| Time | Event |
|---|---|
| ~1.5–1.6 s | SealMetrics `t.js` loads (late — through the site's own tag chain) |
| **~1.8 s** | SealMetrics pageview dispatched via `sendBeacon` — secured |
| **~3.0 s** | Adobe Analytics pageview fires — image GET to the collection domain |
Installed directly in the `` rather than through a tag chain, the SealMetrics hit is
secured at ~0.1–0.3 s.
**In fairness to Adobe:** part of that 3.0 seconds is this specific site's rule sequencing —
identity and personalization calls are ordered before the analytics hit. That ordering is
common, because ECID and Target are designed to run early, but a leaner Adobe install will
fire sooner. The structural floor is what remains: roughly 730 KB of JavaScript to parse and
a multi-stage chain to walk before any hit can leave the device.
Over a 30-day dual-tag run on that reference site, the gap came to **+25% pageviews** measured
by SealMetrics over Adobe — with Adobe firing without a consent gate at all.
Full methodology: [Adobe Analytics tracker performance](/guides/tracker-performance-adobe-analytics).
---
## 4. The cookie question
The visitor identifier associated with collection is `s_vi`, with `s_fid` as the fallback when
`s_vi` cannot be set.
Whether these appear as first-party or third-party cookies depends on your implementation:
- **Default setup** — the collection server sets the identifier on the Adobe domain, making
it a third-party cookie, which Safari and Firefox block by default.
- **CNAME / first-party implementation** — collection is routed through a subdomain of your
own site, so the cookie is first-party and survives browser restrictions.
If you are filling in a cookie register, this is the distinction to check before you classify
the entry, because both configurations are common and the audit answer differs.
The identity cookies on `.demdex.net` are covered separately in
[demdex.net cookies](/security-privacy/demdex-net-cookies).
---
## 5. Why requests to omtrdc.net go missing
Three independent causes, all of which reduce what Adobe records:
1. **Privacy filter lists.** `omtrdc.net` appears on the common blocklists used by uBlock
Origin, Brave and Firefox Enhanced Tracking Protection. The request never leaves.
2. **The transport.** An image GET cancelled on unload, as described in section 2.
3. **Consent.** Where the hit is gated behind a banner, rejection means no request at all.
In European eCommerce, banner rejection runs 40–60%.
These compound. A visitor can be lost to any one of them, and the three populations do not
overlap neatly.
---
## 6. How to check your own site
1. Open your site in a private window with DevTools on the **Network** tab.
2. Filter for `omtrdc`.
3. Reload and note the **timestamp** of the first request — that is when your measurement
actually starts. Everything before it is unmeasured.
4. Check the request **type**. If it is `img`, unload cancellation applies to you.
5. Now enable an ad blocker and reload. If the request disappears entirely, every visitor
using that blocker is invisible in Adobe.
6. Finally, reload with the consent banner **rejected**. If a request still fires, that is a
compliance finding rather than a data one.
Steps 3 and 5 are the ones worth writing down. Step 3 tells you how much of the visit you
never see; step 5 tells you how many visitors you never see at all.
---
## 7. Related documentation
- [Third-party domain lookup](/security-privacy/third-party-analytics-domains) — the full table of external domains analytics tools contact, and which tool owns each
- [demdex.net cookies](/security-privacy/demdex-net-cookies) — the identity side of the same stack
- [Adobe Analytics tracker performance](/guides/tracker-performance-adobe-analytics) — full methodology behind the timings above
- [Adblocker Bypass](/security-privacy/adblocker-bypass) — why filter lists block collection endpoints and what it costs
- [Consentless Analytics](/security-privacy/consentless-analytics) — collecting without a banner, so rejection is not a data-loss path
- [Bot Detection](/security-privacy/bot-detection) — separating real visitors from automated traffic
---
# Compliance
## GDPR and ePrivacy
URL: https://docs.sealmetrics.com/legal/gdpr-and-eprivacy
# GDPR and ePrivacy
Learn about GDPR and ePrivacy compliance with Sealmetrics. This section addresses the legal framework that enables consentless analytics in the European Union.
Two separate rules decide whether analytics needs consent: the ePrivacy Directive governs what you store on or read from the device, and the GDPR governs the processing of personal data. Sealmetrics triggers neither — nothing is written to the device, and the stored dataset holds no personal data. These pages explain how session markers fit into that framework and when a session identifier does require consent.
## Available Documentation
- [Do Session IDs Require Consent](/legal/gdpr-and-eprivacy/do-session-ids-require-consent) - Legal analysis of session-based tracking under GDPR and ePrivacy
## Compliance Overview
URL: https://docs.sealmetrics.com/compliance/compliance-overview
# Compliance Overview
Understanding Sealmetrics' legal compliance framework. This section provides detailed information about how Sealmetrics meets GDPR, ePrivacy, and CNIL requirements while enabling consentless analytics.
Our privacy-first approach is built on legal foundations, not technical workarounds. Learn how we ensure data accuracy through bot filtering, why our tracking method is legally compliant across EU jurisdictions, and get answers to common legal questions about implementing analytics without consent banners.
## Available Documentation
- [How Sealmetrics Blocks Bot Traffic](/compliance/compliance-overview/how-sealmetrics-blocks-bot-traffic) - Technical measures ensuring data accuracy and compliance
- [Is Sealmetrics Privacy Compliant](/compliance/compliance-overview/is-sealmetrics-privacy-compliant) - Legal analysis of our compliance with EU privacy regulations
- [Legal FAQ](/compliance/compliance-overview/legal-faq) - Common questions about implementing consentless analytics legally
## Legal & Compliance
URL: https://docs.sealmetrics.com/compliance
# Legal & Compliance
Learn how Sealmetrics ensures GDPR, CNIL, UK PECR, and ePrivacy compliance while enabling consentless analytics. This section provides comprehensive legal documentation for implementing privacy-first web analytics in the European Union, United Kingdom, and beyond.
Understanding the legal framework behind consentless analytics is essential for making informed decisions about your analytics stack. We explain the regulatory foundations, why a dataset holding no personal data falls outside the GDPR's material scope (Recital 26), and how the architecture maps onto the audience-measurement criteria published by authorities such as the CNIL — so you can measure without cookie banners or a consent management platform.
## Available Documentation
### Core Compliance Guides
- [Compliance Overview](/compliance/compliance-overview) - How Sealmetrics meets privacy regulations and ensures legal compliance
- [**CNIL Self-Assessment**](/compliance/cnil-self-assessment) - Official auto-evaluation against CNIL's 14 criteria for consent exemption
- [**UK PECR Self-Assessment**](/compliance/uk-pecr-self-assessment) - Official auto-evaluation against UK PECR analytics exemption under DUAA 2025
- [**Germany TDDDG Self-Assessment**](/compliance/germany-ttdsg-self-assessment) - Auto-evaluation against §25 TDDDG (formerly TTDSG): no cookies, no terminal storage access
- [**Italy Garante Self-Assessment**](/compliance/italy-garante-self-assessment) - Auto-evaluation against the Garante's cookie guidelines and analytics decisions
- [**Switzerland FADP Self-Assessment**](/compliance/switzerland-fadp-self-assessment) - Auto-evaluation against the revised Swiss FADP (nFADP): no personal data, no non-adequate transfers
- [GDPR and ePrivacy](/legal/gdpr-and-eprivacy) - Detailed analysis of EU privacy laws and session-based tracking requirements
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) - The regulatory analysis behind cookieless measurement, and the legal-basis options open to site owners
- [Analytics Cookies: Consent Exemption](/compliance/analytics-cookies-exemption) - AEPD and EU DPA requirements for analytics without consent
### Data Processing Transparency
- [Subprocessors](/compliance/subprocessors) - Who touches what data, where — and why customer analytics data never leaves the EU
- [Data Subject Rights (DSAR)](/compliance/data-subject-rights) - How visitor and account-holder rights requests work with identifier-free analytics
### EU Digital Omnibus Regulation
- [EU Digital Omnibus Overview](/compliance/omnibus) - Complete guide to the Digital Omnibus (COM(2025) 837)
- [Cookie Consent Reform](/compliance/omnibus/cookies-eprivacy) - Articles 88a/88b and the end of cookie banner fatigue
- [Impact on Web Analytics](/compliance/omnibus/impact-analytics) - How the Omnibus affects analytics providers and tracking
- [GDPR Amendments](/compliance/omnibus/gdpr-changes) - Personal data definition, AI processing, breach notifications
- [View All Omnibus Documentation →](/compliance/omnibus)
## Do Temporary Session Identifiers (Session IDs) Require Consent Under GDPR?
URL: https://docs.sealmetrics.com/legal/gdpr-and-eprivacy/do-session-ids-require-consent
# Do Temporary Session Identifiers (Session IDs) Require Consent Under GDPR?
A common question around privacy-compliant analytics is whether **temporary Session IDs** fall under “tracking technologies” that require user consent.
The short answer: **it depends on how the Session ID is implemented**.
## When Session IDs *Do* Require Consent
A temporary Session ID **requires consent** if:
- It is **stored in a cookie** or similar persistent storage
- It can be used to **recognize a user over time**
- It can be combined with other identifiers to **reconstruct a profile**
- It is used for **tracking across multiple domains**
In these cases, the Session ID becomes a **personal identifier**, making consent mandatory under:
- **GDPR**
- **ePrivacy Directive**
- Local guidelines (CNIL, AEPD, ICO…)
## When Session IDs *Do Not* Require Consent
Regulators such as **CNIL (France)** and **AEPD (Spain)** explicitly allow “cookie-less session identifiers” for **audience measurement**, *as long as* they meet **strict conditions**:
### Conditions for Consent-Free Session IDs
- **Used exclusively for audience measurement** (no marketing / profiling)
- **No cross-site tracking**
- **Not persistent** → disappears after the browser session ends
- **Not stored in cookies or localStorage**
- **Cannot be combined with other identifiers** to re-identify the user
- **No fingerprinting techniques**
If all these requirements are met, the Session ID is considered **non-identifying**, and consent is not required.
## How Sealmetrics Ensures Compliance
Sealmetrics uses a temporary, context-derived session marker that meets the CNIL and AEPD audience-measurement criteria for operating without consent:
✔ Temporary Session IDs
✔ Meets the CNIL and AEPD audience-measurement criteria (self-assessed)
✔ No persistence
✔ No personal identification
Session IDs are used only within the active session to group hits — never to track or identify users.
## Summary
| Scenario | Requires Consent? | Why |
|---------|-------------------|------|
| Session ID stored in a cookie | **Yes** | Persistence = identification |
| Temporary ID without cookies | **No** | Cannot identify the user |
| Cross-site session tracking | **Yes** | Considered profiling |
| Sealmetrics session tracking | **No** | Temporary, non-identifying |
---
**The marker is never stored on the device and never joins hits across sessions, which is what keeps measurement outside the ePrivacy consent requirement — without compromising your analytics.**
## Related documentation
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) — the wider GDPR case for cookieless, non-identifying measurement.
- [Does SealMetrics comply with CNIL guidelines?](/compliance/cnil-self-assessment) — the CNIL first-party session-ID exemption in detail.
- [CNIL Self-Assessment: Sealmetrics Compliance](/compliance/cnil-self-assessment) — the session-ID condition assessed criterion by criterion.
- [Legal FAQ — Sealmetrics Compliance Questions](/compliance/compliance-overview/legal-faq) — how the Session ID and Source ID are computed and used.
- [How Attribution Works Without a User-ID](/security-privacy/attribution-without-userid) — attribution without persistent user identifiers.
## Analytics Cookies: Consent Exemption Requirements
URL: https://docs.sealmetrics.com/compliance/analytics-cookies-exemption
# Analytics Cookies: Consent Exemption Requirements
**Info:**
Any statement here about how Sealmetrics meets a criterion is a **self-assessment**, not a certification. No supervisory authority certifies or validates analytics tools, and Sealmetrics holds no third-party security certification (no ISO 27001, no SOC 2). This page is general regulatory analysis, not legal advice.
Analytics cookies can be exempt from consent requirements under specific conditions defined by EU data protection authorities, including Spain's AEPD (Agencia Española de Protección de Datos). This guide explains when analytics tools can operate without cookie banners and what requirements must be met.
## Legal Framework
### ePrivacy Directive Article 5(3)
**Current rule** (until EU Digital Omnibus takes effect):
Storage of information or accessing information stored in terminal equipment requires **consent**, except when:
> "The sole purpose is to carry out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service."
**Key question**: Do analytics cookies qualify as "strictly necessary" for the service explicitly requested?
### Evolving Interpretation
Data protection authorities across the EU have developed guidance on when analytics qualifies for exemption. The most detailed frameworks come from:
- **CNIL** (France) - First to publish analytics exemption criteria (2020, updated 2024)
- **AEPD** (Spain) - Adopted similar framework (2024)
- **ICO** (UK) - Post-Brexit guidance on analytics cookies
- **EDPB** - European-level guidance on cookies and similar technologies
## AEPD Requirements (Spain)
### Compliance Deadline
**January 11, 2024**: Organizations using analytics cookies must comply with AEPD requirements or obtain consent.
### Three Core Requirements for Exemption
To qualify for consent exemption, **all three** conditions must be met:
#### 1. User Notification
**Requirement**: Inform users of analytics cookie use through privacy policy
**Implementation**:
- Clear statement in privacy policy
- Description of analytics purposes
- What data is collected
- Retention periods
- Rights of data subjects
**Not required**:
- Cookie banner for exempt analytics
- Active user consent
- Granular cookie preferences (for exempt cookies only)
#### 2. Cookie Lifespan Limitation
**Requirement**: Limit cookies' lifespan to **13 months** maximum
**Key details**:
- No automatic renewal on new visits
- Cookie expires after 13 months from placement
- If user returns after expiration, new consent would be required (if cookie were subject to consent)
- For exempt analytics, new cookie can be placed after expiration
**Technical implementation**:
```javascript
// Example: Setting 13-month expiry
const expires = new Date();
expires.setMonth(expires.getMonth() + 13);
document.cookie = `analytics_id=value; expires=${expires.toUTCString()}; path=/`;
```
#### 3. Data Retention Cap
**Requirement**: Ensure data retention does not exceed **24 months**
**What this means**:
- Raw analytics data must be deleted or anonymized after 24 months
- Aggregated reports can be retained indefinitely (no personal data)
- Applies to data collected via cookies, not just cookies themselves
**Example timeline**:
- Month 0: Cookie placed
- Month 13: Cookie expires (can be renewed on next visit)
- Month 25: All raw data from original cookie must be deleted
### Permitted Analytics Activities
The AEPD identifies specific measurements that may qualify for exemption:
#### Traffic and Performance Statistics
**Permitted**:
- Total page views
- Unique visitors (counted, not tracked cross-session)
- Pages visited
- Referrer information (where visitor came from)
- Entry and exit pages
- Bounce rate (aggregated)
- Time on page (aggregated)
- Device type, browser, screen size
- Geographic location (country/region level)
- Page load time statistics
- Scroll depth (aggregated)
- User actions: clicks, selections (aggregated)
**Key principle**: Statistics for **publisher's own use** to understand and improve their website.
### Prohibited Uses (Require Consent)
**Not exempt**:
- Cross-site tracking
- User profiling for advertising
- Sharing analytics data with third parties for their purposes
- Retargeting or remarketing
- Behavioral advertising
- Matching analytics data with other datasets for non-analytics purposes
- Tracking users across multiple websites or apps
- Building individual user profiles over time
### Third-Party Analytics Service Requirements
When using external analytics providers (e.g., Google Analytics, Matomo hosted service), additional guarantees required:
#### 1. Documented Tool Configuration Evaluation
**Requirement**: Written assessment demonstrating analytics tool is configured for exemption compliance
**Must document**:
- Which features are enabled/disabled
- Data sharing settings
- IP anonymization implementation
- Cross-site tracking disabled
- Advertising features disabled
- Data retention settings
#### 2. Contractual Commitment Not to Reuse Data
**Requirement**: Contract with analytics provider must prohibit using data for provider's own purposes
**Data Processing Agreement must include**:
- Provider acts as processor only (GDPR Article 28)
- Data used solely for providing analytics service to controller
- No independent use of data by provider
- No sharing with other clients or third parties
- No use for improving provider's own products
#### 3. GDPR Compliance for Data Transfers
**Requirement**: If data transferred outside EU, must comply with GDPR Chapter V
**Mechanisms**:
- Standard Contractual Clauses (SCCs)
- Adequacy decision (if available)
- Additional safeguards per Schrems II
**Practical impact**: Google Analytics transfers to US have been problematic; providers keeping data in EU are safer.
## Comparison with CNIL (France)
### CNIL Exemption Criteria
The French DPA (CNIL) developed similar framework:
**CNIL-recognized compliant tools**:
- AT Internet
- Matomo (self-hosted in exempt mode)
- Piano Analytics
- Others meeting criteria
**Key difference from AEPD**: CNIL publishes list of approved tools; AEPD does not (organizations must self-assess).
### CNIL vs. AEPD Requirements
| Aspect | CNIL | AEPD |
|--------|------|------|
| **Cookie lifespan** | 13 months | 13 months |
| **Data retention** | 24 months | 24 months |
| **IP anonymization** | Required (at collection) | Implied by data minimization |
| **Cross-site tracking** | Prohibited | Prohibited |
| **Own purposes only** | Required | Required |
| **Third-party guarantees** | Required | Required |
| **Approved vendor list** | Yes (published) | No |
**Convergence**: Both authorities follow similar principles; organizations compliant with CNIL likely compliant with AEPD.
## Google Analytics Compliance
### Google Analytics 4 (GA4)
**Can GA4 be exempt from consent?**
**Likely NO** under AEPD/CNIL frameworks without significant configuration changes:
**Problems with default GA4**:
1. **Data sharing with Google**: Data used by Google for its own purposes (improving products, advertising)
2. **Cross-property tracking**: Tracks users across sites using same GA4 property
3. **Google Signals**: Links analytics to Google account data (advertising integration)
4. **US data transfers**: Data transferred to US (Schrems II concerns)
5. **No full IP anonymization at collection**: IP addresses processed before anonymization
**Could GA4 ever be exempt?**
**Theoretically yes, if**:
- Disable all data sharing with Google
- Disable Google Signals
- Disable all advertising features
- Implement strict IP anonymization
- Ensure data stays in EU
- Obtain contractual commitment from Google not to reuse data
**Practically**: Very difficult; Google's business model conflicts with exemption requirements.
**AEPD position**: No explicit statement, but exemption requirements effectively exclude default GA4.
### Universal Analytics (Deprecated)
**Status**: Sunset July 1, 2023
**Historical note**: Even with IP anonymization, Universal Analytics faced similar challenges for consent exemption.
## Compliant Analytics Solutions
### Characteristics of Exempt Analytics
**Requirements for consent exemption**:
✅ **First-party only**: Data collected directly by website owner
✅ **No cross-site tracking**: Data not matched across domains
✅ **No user profiling**: No individual behavioral analysis over time
✅ **No data sharing**: Data not shared with third parties for their purposes
✅ **Aggregated measurement**: Statistics, not individual tracking
✅ **Own purposes**: Used solely by website owner to understand their site
✅ **13-month cookies**: Cookie lifespan limited
✅ **24-month retention**: Raw data deleted after 24 months
✅ **IP anonymization**: IP addresses not stored or processed beyond necessary
### Examples of Compliant Approaches
#### Self-Hosted Matomo (Exempt Configuration)
**Why compliant**:
- Self-hosted (full data control)
- IP anonymization at collection
- No cross-site tracking
- No data sharing
- First-party cookies only
**Required configuration**:
- Enable IP anonymization (at least last 2 octets)
- Disable user tracking across sites
- Set cookie lifetime to 13 months
- Set data retention to 24 months
- No third-party integrations
#### Sealmetrics
**Why compliant**:
- Cookieless by design (no cookie lifespan issue)
- First-party data only
- No cross-site tracking
- No individual user profiling
- Aggregated measurement
- Data not shared with third parties
- Used solely for client's own analytics
**Alignment with AEPD**:
- Meets the AEPD exemption criteria on our own assessment
- No cookie banner required
- Expected to fall within Digital Omnibus Article 88a(3)(c) once it takes effect (the text is not yet in force)
#### Server-Side Analytics
**Why compliant** (if properly configured):
- No client-side cookies needed
- Full control over data processing
- IP anonymization at collection
- No third-party dependencies
**Requirements**:
- Implement IP anonymization in server logs
- Do not track individuals over time
- Aggregate data for statistical purposes only
- 24-month data retention limit
## Practical Implementation Guide
### Step 1: Assess Current Analytics
**Questions to ask**:
1. **What analytics tools are we using?**
- Google Analytics? Matomo? Custom solution? Sealmetrics?
2. **How is data being used?**
- Only for our own traffic insights?
- Shared with advertising platforms?
- Used for user profiling?
3. **Where is data stored?**
- EU? US? Elsewhere?
- Do we control the infrastructure?
4. **What cookies are set?**
- Lifespan? Purpose? First-party or third-party?
5. **Is data shared with third parties?**
- Analytics provider's use of data?
- Integration with ad networks?
### Step 2: Determine Exemption Eligibility
**Checklist for exemption**:
- [ ] Analytics used only for own purposes (understanding our website)
- [ ] No cross-site tracking
- [ ] No individual user profiling for advertising
- [ ] First-party cookies only (if cookies used)
- [ ] Cookie lifespan ≤ 13 months
- [ ] Data retention ≤ 24 months
- [ ] IP addresses anonymized
- [ ] No data sharing with third parties for their purposes
- [ ] If using third-party service: DPA prohibiting data reuse
- [ ] Users informed via privacy policy
**If all checked**: Exemption likely applies (no consent banner needed)
**If any unchecked**: Consent required
### Step 3: Configure Analytics for Compliance
**If using Google Analytics**:
- Consider switching to exempt-eligible alternative
- If keeping GA4: Expect to need consent banner
**If using Matomo**:
- Self-host if possible
- Enable IP anonymization (2 bytes minimum)
- Disable user ID tracking across visits
- Set 13-month cookie, 24-month retention
- Document configuration
**If using Sealmetrics**:
- The default configuration already meets these criteria
- Update privacy policy to mention analytics
- No further configuration needed on your side
### Step 4: Update Privacy Policy
**Required disclosures**:
```markdown
## Analytics
We use [analytics tool name] to understand how visitors use our website. This helps us improve content and user experience.
**Data collected**:
- Pages visited
- Referrer information
- Device type and browser
- Geographic location (country/region)
- Time spent on pages
- [other specific metrics]
**Purpose**: Website performance analysis and improvement
**Legal basis**: Legitimate interest (GDPR Article 6(1)(f)) — *note: if your analytics tool stores no personal data, as Sealmetrics does not, you have no Article 6 processing to declare for it; this line is for tools that do*
**Data retention**: 24 months maximum
**Your rights**: You can object to analytics processing. Contact [email] to exercise your rights.
**Analytics provider**: [If third-party] [Provider name] acts as our data processor and does not use data for their own purposes.
```
### Step 5: Document Compliance
**Maintain records**:
- Configuration settings of analytics tools
- Data Processing Agreement with provider (if applicable)
- Assessment of exemption criteria
- Privacy policy version showing analytics disclosure
- Data retention and deletion procedures
**For audits/complaints**: Be ready to demonstrate:
- Analytics is for own purposes only
- No data sharing beyond necessary processing
- Technical measures (IP anonymization, retention limits)
- User information provided
## Enforcement and Risks
### AEPD Enforcement
**Compliance checks**:
- AEPD can audit analytics implementations
- Requests for configuration documentation
- Assessment of cookie practices
**Penalties for non-compliance**:
- GDPR fines (up to €20M or 4% global revenue)
- Requirement to implement cookie consent banner
- Data deletion orders
**Risk areas**:
- Google Analytics without consent
- Exceeding 24-month retention
- Cross-site tracking without consent
- False claims of exemption
### User Complaints
**Users can file complaints** with AEPD if:
- Analytics cookies placed without consent when required
- Privacy policy inadequate
- Data retention excessive
- Rights not respected
**Best practice**: Be conservative in exemption assessment; when in doubt, obtain consent.
## Timeline: Current Rules vs. Digital Omnibus
### Current (2024)
**Legal basis**: ePrivacy Directive Article 5(3) + AEPD interpretation
**Exemption criteria**: Narrowly interpreted ("strictly necessary" + AEPD requirements)
**Compliance**: Many analytics implementations require consent
### Future (2027-2028, estimated)
**Legal basis**: GDPR Article 88a(3)(c) (Digital Omnibus)
**Exemption criteria**: Explicitly recognized for "aggregated audience measurement for own use"
**Impact**: Broader exemption, clearer legal certainty, more analytics implementations without consent
**Learn more**: [EU Digital Omnibus - Cookie Consent Reform](./omnibus/cookies-eprivacy.md)
### Continuity
Organizations complying with AEPD requirements today will be well-positioned for Digital Omnibus:
**AEPD requirements** (2024):
- Own purposes only ✅
- No cross-site tracking ✅
- No data sharing ✅
- IP anonymization ✅
- Retention limits ✅
**Article 88a(3)(c)** (future):
- Own use only ✅
- Aggregated measurement ✅
- By controller ✅
**Alignment**: AEPD-compliant analytics likely exempt under Digital Omnibus too.
## Related Resources
- [EU Digital Omnibus - Cookie Consent Reform](./omnibus/cookies-eprivacy.md) - Future framework for analytics exemption
- [EU Digital Omnibus - Impact on Analytics](./omnibus/impact-analytics.md) - How Omnibus affects analytics industry
- [GDPR and Cookieless Analytics](./gdpr-cookieless-analytics.md) - GDPR compliance without cookies
- [Does SealMetrics comply with CNIL guidelines?](/compliance/cnil-self-assessment) - CNIL consent-exemption criteria in practice
- [CNIL Self-Assessment: Sealmetrics Compliance](/compliance/cnil-self-assessment) - Point-by-point evaluation against the exemption criteria
- [UK PECR Self-Assessment: Sealmetrics Compliance](/compliance/uk-pecr-self-assessment) - The equivalent UK analytics exemption under DUAA 2025
## Sources and Further Reading
**AEPD (Spain)**:
- [AEPD Cookie Guidelines](https://www.aepd.es) (Spanish)
- [AEPD Public Administration Web Analytics Guide](https://www.aepd.es/guides/guidelines-cookies-web-analytics-public-administration-websites.pdf)
**CNIL (France)**:
- [CNIL Analytics Exemption Criteria](https://www.cnil.fr/en/cookies-and-other-trackers/rules/cookies/how-comply-cookies-and-trackers)
- [CNIL List of Compliant Tools](https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications)
**EDPB**:
- [EDPB Guidelines 05/2020 on Consent](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en)
**Industry Analysis**:
- [Didomi: Analytics Cookies in Spain](https://www.didomi.io/blog/analytics-cookies-consent-spain-update-aepd)
- [Data Guidance: AEPD Cookie Guide](https://www.dataguidance.com/news/spain-aepd-releases-updated-cookie-guide-line-edpbs-0)
## Key Takeaways
1. **Analytics CAN be exempt from consent** under specific AEPD criteria
2. **Three requirements**: User notification, 13-month cookies, 24-month retention
3. **Own purposes only**: No data sharing, cross-site tracking, or advertising use
4. **Third-party analytics**: Require contractual guarantees against data reuse
5. **Google Analytics**: Difficult to qualify for exemption in default configuration
6. **Compliant alternatives**: Self-hosted Matomo, Sealmetrics, server-side analytics
7. **Privacy policy disclosure**: Required even for exempt analytics
8. **Digital Omnibus alignment**: AEPD-compliant analytics likely exempt under future EU framework
9. **Conservative approach recommended**: When uncertain, obtain consent
10. **Document compliance**: Maintain records of configuration and assessment
Analytics without consent is legally possible—but only when genuinely used for website improvement, not tracking, profiling, or monetization. The AEPD framework provides a clear path for privacy-respecting measurement that aligns with the upcoming Digital Omnibus regulation.
## Legal FAQ — Sealmetrics Compliance Questions
URL: https://docs.sealmetrics.com/compliance/compliance-overview/legal-faq
# Legal FAQ
This page answers the most common legal and compliance questions related to Sealmetrics, privacy regulations, audits, and data protection.
---
## **Compliance Validation**
### **How can I validate Sealmetrics' compliance claims?**
Sealmetrics publishes detailed, criterion-by-criterion **self-assessments** against the published frameworks of European regulators, so your DPO can verify every claim directly:
👉 [CNIL (France)](/compliance/cnil-self-assessment) · [ICO PECR (UK)](/compliance/uk-pecr-self-assessment) · [TDDDG (Germany)](/compliance/germany-ttdsg-self-assessment) · [Garante (Italy)](/compliance/italy-garante-self-assessment) · [FADP (Switzerland)](/compliance/switzerland-fadp-self-assessment)
Technical claims (what is collected, what is never stored) are documented in [What We Track](/security-privacy/what-we-track) and can be verified from the browser: every request the tracker sends is visible in your own DevTools.
---
## **Data Processing & Legal Documentation**
### **How does Sealmetrics process customer data?**
You can review our full **Privacy Notice** for our role as a B2B Data Controller here:
👉 [Sealmetrics Privacy Notice](https://sealmetrics.com/privacy)
For our role as Data Processor:
👉 [Data Processing Agreement (DPA)](https://sealmetrics.com/dpa) · [Subprocessors](/compliance/subprocessors)
---
### **Where can I access Sealmetrics' DPIA?**
We provide a completed **DPIA** (Data Protection Impact Assessment) for all customers.
You can request access directly from our team.
---
### **Legal Documentation**
All legal documentation is available in the footer of our website, including:
- Privacy Notice
- Data Processing Agreement (DPA)
- Terms of Service
- Customer DPIA availability
---
## **Privacy by Design & Company Structure**
### **Why is Sealmetrics a true privacy-by-design solution?**
Because **every metric that appears in the Sealmetrics platform must be validated and approved by our Legal Department** before being allowed into the product.
No exceptions.
---
### **What kind of company is Sealmetrics?**
Sealmetrics is a **bootstrapped European company** with no external investors on the board.
---
## **Data Collection & Calculation**
### **What data does Sealmetrics collect?**
We only collect four essential, non-personal variables per hit:
- Current URL (including UTM parameters)
- Referral URL
- Timestamp
- User Agent (used for anonymous device classification; event detail purged after 1 day, aggregated categories kept 24 months; never linked to a person)
Plus a short-lived **session context marker** used to tell a second pageview apart from a new entrance. See [What We Track vs What We Don't](/security-privacy/what-we-track) for the full breakdown.
All data is anonymous and isolated.
---
### **What data does Sealmetrics calculate?**
We compute:
- **Source ID** (`_adin`): Used for attribution
- **Session context marker**: a short-lived identifier scoped to a single browsing session (~2-hour inactivity window). It is not stored in the browser, does not persist across sessions, and cannot recognize a returning visitor.
---
### **Does Sealmetrics use IP addresses for calculation?**
**Never for analytics, and never stored in the analytics database.**
- No metric in Sealmetrics is calculated from IP addresses. Visitor country comes from the [browser timezone](/security-privacy/country-detection), not from the IP.
- The visitor's IP is used **transiently on the server** for security and anti-bot protection (checking the request against curated bot/datacenter blocklists before it is accepted). As with any web service, IPs may also appear transiently in operational logs with limited retention; those logs are separate from analytics data and are never available to clients.
- The IP is **never written to the analytics database** — there is no IP column in our event storage — and it is never linked to any hit, session, or metric.
- No GeoIP lookup is performed on the IP. One was designed for the optional **Agent Analytics** bot detector, but that feature is **not live and cannot be enabled on any account**, so it runs nowhere today.
This transient security use is processed under legitimate interest (GDPR Art. 6(1)(f), Recital 49 — network and information security). What keeps Sealmetrics consentless is that the IP is never stored with analytics data, never used for identification or tracking, and never used to compute analytics.
---
## **Bot Filtering**
### **How does Sealmetrics block bots?**
We use several layers, none of which stores personal data:
- **Bot user-agent signature lists** (known crawlers, headless browsers, automation tools)
- **Curated IP/CIDR blocklists** of known bots and datacenters, checked in memory at request time — the IP is used only for this transient check and never stored with analytics data
- **Request-header consistency checks**
(A fourth layer — **Agent Analytics**, using environmental and behavioral signals to classify traffic as human vs. automated — is designed but **not live**, and collects nothing on any account today.)
See [How Sealmetrics Blocks Bot Traffic](/compliance/compliance-overview/how-sealmetrics-blocks-bot-traffic) for the full picture.
---
## **Cookies & Storage**
### **Does Sealmetrics use cookies?**
No.
Sealmetrics does **not** use:
- cookies
- session storage
- local storage
- fingerprinting
- cross-site IDs
---
## **Data Retention**
### **How many months does Sealmetrics store my data?**
We store data for a **maximum of 24 months**.
This stays inside the 25-month ceiling that CNIL guidance sets for consent-exempt analytics — Sealmetrics deliberately applies the stricter 24-month limit.
## Related documentation
- [Is Sealmetrics GDPR, ePrivacy, CCPA, and PECR Compliant?](/compliance/compliance-overview/is-sealmetrics-privacy-compliant) — the architecture behind these answers.
- [How Sealmetrics Blocks Bot Traffic](/compliance/compliance-overview/how-sealmetrics-blocks-bot-traffic) — the full anti-bot pipeline and why it stays consentless.
- [Do Temporary Session Identifiers (Session IDs) Require Consent Under GDPR?](/legal/gdpr-and-eprivacy/do-session-ids-require-consent) — why the Session ID and Source ID stay consent-exempt.
- [CNIL Self-Assessment: Sealmetrics Compliance](/compliance/cnil-self-assessment) — the retention and cookie-lifetime criteria referenced above.
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) — the consentless measurement model explained.
## EU Digital Omnibus Regulation
URL: https://docs.sealmetrics.com/compliance/omnibus
# EU Digital Omnibus Regulation
The **EU Digital Omnibus Regulation** (COM(2025) 837) represents the most significant simplification of European data law since the GDPR came into force in 2018. Published on November 19, 2025, this comprehensive reform consolidates five separate data regulations into two, eliminates cookie banners for 60% of websites, and promises to save businesses €1 billion annually.
## What is the Digital Omnibus?
The Digital Omnibus is part of the European Commission's broader simplification agenda to reduce regulatory complexity while maintaining strong protections for citizens and businesses.
**Official designation**: COM(2025) 837 final
**Published**: November 19, 2025
**Current status**: Under review by European Parliament and Council
**Goal**: Simplify the EU data regulatory framework by:
- Reducing the number of overlapping regulations
- Eliminating contradictions and ambiguities
- Lowering compliance costs
- Maintaining high standards for data protection and privacy
---
## Current Legislative Status
**Info:**
This section reflects the current state of the legislative process. Check official EU sources for the latest developments.
**Tip:**
On February 10, 2026, the European Data Protection Board and European Data Protection Supervisor published their [Joint Opinion 2/2026](./edpb-edps-opinion.md) on the Digital Omnibus. They support simplification goals but raise concerns about personal data definition changes and request stronger AI safeguards. This consultative document may influence the final text during Parliament/Council negotiations.
### Committee Assignments
The Digital Omnibus proposal (procedure 2025/0360(COD)) has been assigned to **joint committee responsibility**:
| Committee | Role |
|-----------|------|
| **ITRE** (Industry, Research and Energy) | Joint lead committee |
| **LIBE** (Civil Liberties, Justice and Home Affairs) | Joint lead committee |
**Rapporteurs**: Not yet appointed (as of January 2026)
### Open Feedback Periods
The Commission has opened post-adoption feedback opportunities:
| Consultation | Deadline |
|--------------|----------|
| Digital Omnibus feedback | **9 March 2026** |
| Digital Fitness Check | **11 March 2026** |
Organizations can submit feedback through the [Have Your Say portal](https://ec.europa.eu/info/law/better-regulation/have-your-say_en).
### Expected Timeline
| Milestone | Expected Date |
|-----------|---------------|
| Committee rapporteur appointments | Q1 2026 |
| Parliament/Council positions | Q2 2026 |
| Trilogue negotiations | Summer 2026 |
| Final adoption | Mid-to-late 2026 |
| Entry into force | ~Q3 2027 |
**Note**: Timeline may shift based on negotiation complexity and political priorities.
---
## The Great Consolidation: 5 Laws → 2 Laws
### Laws Being Amended (Not Repealed)
#### General Data Protection Regulation (GDPR)
**Status**: Amended with targeted improvements
The GDPR remains the cornerstone of EU data protection but receives important updates:
- Personal data definition clarified
- Cookie consent rules integrated (new Articles 88a, 88b)
- AI processing provisions (new Article 88c)
- Breach notification threshold raised
- Research exemptions expanded
- Information requirements simplified
See: [GDPR Amendments in Detail](./gdpr-changes.md)
#### Data Act
**Status**: Becomes consolidated framework for data sharing and access
The Data Act absorbs provisions from:
- Data Governance Act
- Open Data Directive
- Free Flow of Data Regulation (partially)
**Result**: Single comprehensive regulation for data access, sharing, and portability across sectors.
### Laws Being Repealed or Merged
#### 1. Platform-to-Business Regulation (EU 2019/1150)
**Status**: Fully repealed
**Reason**: Superseded by the Digital Services Act (DSA) and Digital Markets Act (DMA), which provide more comprehensive and effective rules for platform governance.
**What this means**: No separate P2B compliance regime; platform obligations now governed by DSA/DMA.
#### 2. Free Flow of Data Regulation (EU 2018/1807)
**Status**: Mostly repealed; core provisions merged into Data Act
**Provisions retained:**
- Freedom of data flows within the EU
- Restrictions on data localization requirements
- Portability of non-personal data
**Why consolidate**: Avoids fragmentation between personal data (GDPR) and non-personal data (Free Flow) rules.
#### 3. Data Governance Act (EU 2022/868)
**Status**: Merged into Data Act
**Key provisions integrated:**
- Data intermediation services
- Data altruism organizations
- Public sector data re-use
- Governance structures for data sharing
**Benefit**: Single coherent framework for data governance instead of overlapping regulations.
#### 4. Open Data Directive (EU 2019/1024)
**Status**: Merged into Data Act
**What's integrated:**
- Public sector information re-use
- High-value datasets
- Transparency requirements
- Charging principles
**Result**: Public and private data sharing governed by unified rules.
### The Final Landscape
**Before Omnibus (2024):**
- GDPR
- Data Act
- Data Governance Act
- Open Data Directive
- Free Flow of Data Regulation
- P2B Regulation
**Total**: 6 major data regulations
**After Omnibus (2026+):**
- GDPR (amended)
- Data Act (consolidated)
**Total**: 2 major data regulations
**Plus**: DSA and DMA continue to govern digital platforms
## Key Changes Overview
### 1. Cookie Consent Reform
**The biggest change**: Article 5(3) ePrivacy Directive repealed for personal data; cookies brought under GDPR framework.
**New regime (Articles 88a, 88b GDPR):**
- Audience measurement for own use: **NO CONSENT NEEDED**
- Third-party tracking: **CONSENT REQUIRED**
- Single-click refuse button mandatory
- No re-asking for 6 months after refusal
- Browser signals for machine-readable consent (24-48 month timeline)
**Impact:**
- First-party analytics for own use: **NO CONSENT NEEDED**
- Third-party tracking: **CONSENT STILL REQUIRED**
- €820M/year projected business savings
- €500M/year projected user productivity gains
**Note:**
While the Commission projects significant banner reduction, legal analysts note that information obligations and third-party tools will maintain some form of notification for many websites. Full banner elimination applies mainly to sites using **only** first-party, aggregated analytics.
**Learn more**: [Cookie Consent Reform](./cookies-eprivacy.md)
### 2. GDPR Clarifications
**Personal data definition:**
- "Reasonably likely to be used" standard codified
- Entity-specific determination
- Pseudonymization clarity
**AI processing:**
- New Article 88c: Legitimate interest for AI development
- Safeguards for special category data
- Unconditional right to object
**Breach notifications:**
- Threshold raised from "risk" to "high risk"
- Single entry point via ENISA
- EDPB to create common template
**Research exemptions:**
- Expanded definition (includes tech development)
- Further processing compatibility
- Legitimate interest basis
**Learn more**: [GDPR Amendments](./gdpr-changes.md)
### 3. Single Incident Reporting Point
**Current problem**: Businesses must report security incidents to multiple authorities under different regulations.
**Omnibus solution**: ENISA (European Union Agency for Cybersecurity) operates a **single entry point** for incident reporting.
**Benefits:**
- One report satisfies multiple obligations
- Consistent format and process
- Better coordination across authorities
- Reduced administrative burden
### 4. SME/SMC Extended Exemptions
**SMEs (Small and Medium Enterprises)** and **SMCs (Small and Medium-Sized Companies)** receive:
- Extended exemptions from certain Data Act obligations
- Reduced fees for certifications
- Simplified compliance pathways
- Proportionate requirements based on size
**Estimated savings**: €5-19M annually across the SME sector.
## Economic Impact
### Cost Savings for Businesses
| Category | Annual Savings |
|----------|---------------|
| Cookie banner elimination | €820 million |
| Data intermediation simplification | €6 million |
| SMC fee exemptions | €5-19 million |
| Custom cloud contracts (one-off) | €1.015 billion |
| B2G scope narrowing | €19.7 million/year |
| **Total business savings by 2029** | **≥€5 billion** |
### Cost Savings for Public Sector
| Category | Annual Savings |
|----------|---------------|
| Cookie banner elimination | €320 million |
| Data governance consolidation | Significant (TBD) |
| Simplified compliance | Significant (TBD) |
| **Total public authority savings by 2029** | **€1 billion** |
### User Benefits
**Time savings**: 334 million hours/year currently wasted on cookie banners will be reclaimed.
**Productivity value**: €500 million/year in user time savings (200 million users × reduced banner interactions).
**Better experience**: Fewer interruptions, clearer choices, more respectful web browsing.
## Timeline
### Legislative Process
**November 19, 2025**: Commission proposal published (COM(2025) 837)
**2026**: European Parliament and Council negotiation (ordinary legislative procedure)
**Expected adoption**: Late 2026 or early 2027
**Entry into force**: 20 days after publication in Official Journal
### Implementation Deadlines
**Article 88a (cookies)**: 6 months after entry into force
**Article 88b (browser signals):**
- Websites: 24 months after entry into force
- Browser vendors: 48 months after entry into force
**Estimated operational dates:**
- Cookie exemptions: Mid-2027
- Website browser signal support: 2028-2029
- Full browser controls: 2029-2030
## Who is Affected?
### Website Operators
**All EU websites:**
- New cookie consent rules apply
- Opportunity to eliminate banners for audience measurement
- Browser signal support required (24 months)
**Action required:**
- Audit analytics and tracking tools
- Identify exempt vs. consent-required processing
- Update privacy policies
- Prepare for browser signals
### Analytics and Ad Tech Providers
**First-party analytics:**
- Clear legal basis without consent
- Competitive advantage
**Third-party tracking:**
- Consent still required
- Browser signals will impact consent rates
- Need to adapt business models
**Learn more**: [Impact on Web Analytics](./impact-analytics.md)
### AI Developers
**New legal basis:**
- Article 88c provides legitimate interest for AI development
- Must implement safeguards
- Respect right to object
- Avoid special category data
### Data Controllers and Processors (General)
**Simplified framework:**
- Fewer regulations to navigate
- Clearer rules
- Reduced overlaps
**New obligations:**
- Browser signal support
- Updated GDPR compliance
- Adapted data governance practices
## Documentation in This Section
### Core Documents
- **[Cookie Consent Reform](./cookies-eprivacy.md)** - Detailed analysis of Articles 88a and 88b, cookie banner elimination, and browser signals
- **[GDPR Amendments](./gdpr-changes.md)** - Personal data definition, AI processing, breach notifications, research exemptions
- **[Data Law Consolidation](./data-consolidation.md)** - How 5 separate data laws are merged into 2
- **[Data Intermediation Services](./data-intermediation.md)** - Voluntary regime for trusted data sharing platforms
### Implementation & Compliance
- **[Timeline and Implementation](./timeline-implementation.md)** - Key dates, deadlines, and preparation phases
- **[SME and Small Mid-Cap Exemptions](./smes-small-midcaps.md)** - Extended protections for companies with up to 749 employees
- **[Single Entry Point for Incident Reporting](./incident-reporting.md)** - Unified cybersecurity and data breach reporting via ENISA
### Industry Impact
- **[Impact on Web Analytics](./impact-analytics.md)** - How the Omnibus affects analytics providers and website tracking
- **[AI Act Amendments](./ai-act-amendments.md)** - GDPR-AI intersection and Article 88c legitimate interest
### Regulatory Positions
- **[EDPB-EDPS Joint Opinion](./edpb-edps-opinion.md)** - Official position of European data protection authorities on the Digital Omnibus proposal
## Key Differences from Current Law
| Aspect | Current Law | Digital Omnibus |
|--------|-------------|-----------------|
| **Number of data regulations** | 5-6 separate laws | 2 consolidated laws |
| **Cookie consent** | Article 5(3) ePrivacy (separate from GDPR) | Article 88a GDPR (unified) |
| **Audience measurement** | Consent required (limited exemptions) | No consent if aggregated, own use |
| **Browser signals** | Not addressed | Must be supported (Art 88b) |
| **Breach notification** | "Risk" threshold | "High risk" threshold |
| **Personal data definition** | CJEU case law | Codified "reasonably likely" standard |
| **AI processing** | Unclear legal basis | Article 88c legitimate interest |
| **Incident reporting** | Multiple entry points | Single ENISA entry point |
| **Research exemptions** | Limited definition | Expanded (tech development) |
## Frequently Asked Questions
### Does the Omnibus repeal the GDPR?
**No.** The GDPR is **amended**, not repealed. It remains the foundational data protection regulation but receives targeted improvements.
### When will cookie banners disappear?
**Partial reduction starting mid-2027** (6 months after entry into force, estimated).
**First-party analytics** for aggregated, own use will no longer need consent.
**Third-party tracking** (advertising, cross-site) will still require consent.
**Reality check**: Cookie banners will reduce but not fully disappear for most websites. Information obligations and third-party tools will maintain some form of notification. Sites using **only** first-party analytics (like Sealmetrics) have the clearest path to banner-free operation.
### What happens to the ePrivacy Directive?
**Article 5(3) is repealed** for personal data processing. Cookie consent moves to GDPR (Articles 88a, 88b).
**Rest of ePrivacy Directive** remains in force for:
- Non-personal data cookies
- Electronic communications confidentiality
- Marketing communications rules
**Long-term**: ePrivacy Regulation (currently stalled) may eventually replace the entire ePrivacy Directive.
### Do I still need a cookie banner?
**It depends on what you're doing:**
**No banner needed if:**
- ✅ First-party analytics only
- ✅ Aggregated measurement
- ✅ For your own use only
- ✅ Functional cookies for requested services
**Banner still needed if:**
- ❌ Third-party tracking
- ❌ Advertising pixels
- ❌ Cross-site profiling
- ❌ Selling or sharing data
**See**: [Cookie Consent Reform](./cookies-eprivacy.md) for detailed guidance.
### How does this affect my GDPR compliance?
**Mostly simplifies:**
- Personal data definition clearer
- Breach notification threshold higher (fewer reports needed)
- Information requirements more flexible (Article 13 exemption)
- Research exemptions broader
**New requirements:**
- Cookie consent under GDPR framework (Articles 88a, 88b)
- Browser signal support (24 months)
- AI processing safeguards (Article 88c)
**Overall**: Compliance becomes clearer and less burdensome for most organizations.
### What should I do to prepare?
**Immediate steps:**
1. **Audit analytics and tracking**
- What tools do you use?
- Which need consent vs. are exempt?
2. **Review data processing inventory**
- Update for Article 88a framework
- Identify browser signal impact
3. **Update privacy policies**
- Reference new legal bases
- Explain exempt processing
4. **Plan infrastructure changes**
- Browser signal support
- Consent management updates
5. **Consider switching to consentless analytics**
- Sealmetrics, Plausible, Fathom, etc.
- Eliminate banner costs
- Gain complete data
**Timeline**: Finalize plans by late 2026, implement by mid-2027.
## Additional Resources
### Official EU Documents
- [COM(2025) 837 final - Proposal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2025:837:FIN) (when published)
- Staff Working Document (Impact Assessment)
- European Data Protection Board guidelines (forthcoming)
### Related Regulations
- **GDPR** (EU 2016/679) - Data protection foundation
- **Data Act** (EU 2023/2854) - Data sharing and access
- **Digital Services Act** (EU 2022/2065) - Platform governance
- **Digital Markets Act** (EU 2022/1925) - Gatekeeper regulation
- **ePrivacy Directive** (2002/58/EC, as amended) - Electronic communications privacy
### Regulatory Opinions
- [EDPB-EDPS Joint Opinion 2/2026](https://www.edpb.europa.eu/our-work-tools/our-documents/edpbedps-joint-opinion/edpb-edps-joint-opinion-22026-proposal_en) - Official position on the Digital Omnibus
- EDPB guidelines on Articles 88a and 88b (expected after adoption)
- National DPA guidance on cookie exemptions (expected after adoption)
- European standardisation bodies: Browser signal standards
## Conclusion
The EU Digital Omnibus represents a pragmatic evolution of European data law. By consolidating five regulations into two, eliminating cookie banners for benign processing, and clarifying ambiguities in the GDPR, the Omnibus promises to reduce compliance costs by €1 billion annually while maintaining the EU's world-leading privacy standards.
For website operators, the message is clear: privacy-respecting, first-party analytics will become the norm, while invasive tracking faces increasing barriers. Organizations that embrace consentless analytics and first-party data strategies will gain competitive advantages in compliance simplicity, data quality, and user experience.
The transition period (2026-2030) provides ample time to adapt. Those who prepare early will reap the greatest benefits.
---
**Stay Updated**: This documentation will be updated as the Omnibus proceeds through the legislative process and implementing acts are adopted.
**Questions?** Explore the detailed analyses linked above or consult with privacy counsel on your specific situation.
## Related documentation
- [Cookie Consent Reform: The End of Banner Fatigue](/compliance/omnibus/cookies-eprivacy) — how Article 88a moves cookie consent under the GDPR.
- [Impact on Web Analytics and Tracking](/compliance/omnibus/impact-analytics) — what the Omnibus means for consentless measurement.
- [EDPB-EDPS Joint Opinion on the Digital Omnibus](/compliance/omnibus/edpb-edps-opinion) — the regulators' position on the proposal.
- [Compliance Overview](/compliance/compliance-overview) — how Sealmetrics maps to GDPR, ePrivacy, CCPA, and PECR today.
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) — the technical basis for consentless analytics.
## CNIL Self-Assessment: Sealmetrics Compliance
URL: https://docs.sealmetrics.com/compliance/cnil-self-assessment
# CNIL Self-Assessment: Sealmetrics
This document provides the official self-assessment of Sealmetrics against CNIL's criteria for consent-exempt audience measurement tools, as defined in the [CNIL's auto-evaluation framework](https://www.cnil.fr/sites/default/files/2025-07/outil_d_auto-evaluation_mesure_d_audience.pdf) (July 2025).
**Info:**
This self-assessment follows CNIL guidelines but **does not constitute CNIL certification**. Per CNIL guidance, providers cannot claim to be "certified" or "validated" by CNIL. This document demonstrates how Sealmetrics meets the published exemption criteria when properly configured.
---
## Executive Summary
| Category | Status |
|----------|--------|
| **5 Permitted Objectives** | ✅ All compliant |
| **14 Technical Criteria** | ✅ All compliant |
| **Consent Exemption Eligible** | ✅ Yes |
| **Last Assessment Date** | February 2026 |
---
## Part 1: Permitted Objectives
CNIL allows consent exemption **only** when analytics are used for these 5 specific purposes:
### Objective 1: Performance Measurement
**Requirement:** Measure website/application performance metrics.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| Measures page load times | ✅ Yes |
| Tracks error rates | ✅ Yes |
| Limited to performance data | ✅ Yes - no behavioral profiling |
**Evidence:** Sealmetrics tracks pageviews, load events, and technical errors exclusively for performance analysis.
---
### Objective 2: Navigation Problem Detection
**Requirement:** Identify navigation issues affecting user experience.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| Detects 404 errors | ✅ Yes — error pages appear in the Pages report when they load the pixel |
| Identifies drop-off between funnel steps | ✅ Yes — aggregate, via the Funnel report |
| Tracks individual user flows or exit pages | ❌ No — would require per-visitor page sequencing |
**Evidence:** The Funnel report shows aggregate drop-off between defined steps, and the Pages report surfaces underperforming or erroring URLs. Sealmetrics does **not** reconstruct individual navigation paths or exit pages, because both require following one visitor across page loads — precisely the processing this exemption depends on avoiding.
---
### Objective 3: Technical & Ergonomic Optimization
**Requirement:** Optimize technical performance and user experience.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| Device/browser analysis | ✅ Yes |
| Screen resolution data | ✅ Yes |
| Used only for optimization | ✅ Yes - not for targeting |
**Evidence:** Device reports provide aggregated, anonymized data for UX optimization only.
---
### Objective 4: Server Capacity Estimation
**Requirement:** Estimate necessary server infrastructure.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| Traffic volume metrics | ✅ Yes |
| Peak usage identification | ✅ Yes |
| Real-time visitor counts | ✅ Yes |
**Evidence:** Real-time dashboard and traffic reports enable infrastructure planning.
---
### Objective 5: Content Analysis
**Requirement:** Analyze which content is consulted by visitors.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| Page view tracking | ✅ Yes |
| Content grouping | ✅ Yes |
| Aggregated statistics only | ✅ Yes |
**Evidence:** Pages report shows aggregated content performance without individual user tracking.
---
## Part 2: Technical Criteria (14 Points)
### Criterion 1: Purpose Limitation
**Requirement:** Tool must be used exclusively for audience measurement for the publisher's own account.
| Aspect | Compliance |
|--------|------------|
| Single-purpose tool | ✅ Sealmetrics is exclusively for analytics |
| Publisher's own account | ✅ Each client has isolated account |
| No secondary uses | ✅ No advertising, profiling, or resale |
**Configuration:** Default configuration. No additional setup required.
---
### Criterion 2: Anonymous Statistical Output
**Requirement:** Must produce only anonymous statistical data.
| Aspect | Compliance |
|--------|------------|
| Aggregated reports | ✅ All reports show aggregated data |
| No individual user data export | ✅ Cannot export individual sessions |
| Statistical anonymization | ✅ Data aggregated before display |
**Configuration:** Built into platform architecture. Cannot be disabled.
---
### Criterion 3: No Cross-Site Tracking
**Requirement:** Cannot track users across different websites or applications.
| Aspect | Compliance |
|--------|------------|
| First-party only | ✅ No third-party cookies (no cookies at all) |
| Site-isolated identifiers | ✅ Session identifiers incorporate the publisher account into their derivation, so the same browser yields different identifiers on different publishers' sites |
| No cross-domain identification | ✅ Hits are stored per account and never joined across sites |
| No unified IDs | ✅ No cross-site user graph, no shared advertising ID |
**Technical Implementation:**
```
Session marker: ephemeral (~2h), computed in the browser, never stored on the device
Session marker scope: per publisher account — the account is an input to the identifier's derivation, so identifiers cannot match across different publishers' sites
Cookies: none (neither first- nor third-party)
Cross-domain tracking: not performed — data is collected, stored, and reported per account
```
---
### Criterion 4: No Data Cross-Referencing
**Requirement:** Cannot cross-reference analytics data with other processing activities.
| Aspect | Compliance |
|--------|------------|
| Isolated data processing | ✅ Analytics data stays in Sealmetrics |
| No CRM integration for profiling | ✅ No user-level data merge |
| No external enrichment | ✅ No third-party data added |
**Configuration:** Platform architecture prevents data cross-referencing. API exports only aggregated statistics.
---
### Criterion 5: No Third-Party Data Transmission
**Requirement:** Cannot transmit non-anonymized data to third parties.
| Aspect | Compliance |
|--------|------------|
| No data sales | ✅ Sealmetrics never sells data |
| No third-party sharing | ✅ No data shared with external parties |
| Client owns their data | ✅ Data belongs exclusively to client |
**Legal Basis:** [Sealmetrics Privacy Policy](https://sealmetrics.com/privacy) and [DPA](https://sealmetrics.com/dpa) guarantee no third-party data sharing.
---
### Criterion 6: Cookie Lifetime ≤ 13 Months
**Requirement:** Cookie validity must not exceed 13 months, without automatic renewal.
| Aspect | Compliance |
|--------|------------|
| Cookie duration | ✅ **No persistent cookies used** |
| Session-based identification | ✅ Session IDs expire with browser session |
| No automatic renewal | ✅ N/A - no persistent storage |
**Technical Implementation:**
```
Storage method: Session-based (no cookies in default mode)
Maximum theoretical lifetime: Browser session only
```
**Note:** Sealmetrics exceeds this requirement by not using persistent cookies at all in standard configuration.
---
### Criterion 7: Data Retention ≤ 25 Months
**Requirement:** Collected data must not be retained beyond 25 months. Sealmetrics deliberately applies a stricter 24-month limit.
| Aspect | Compliance |
|--------|------------|
| Analytics data retention | ✅ 24 months maximum |
| Automatic deletion | ✅ Data purged after retention period |
| Raw logs retention | ✅ 1 day only |
**Data Retention Schedule:**
| Data Type | Retention Period |
|-----------|-----------------|
| Raw request logs | 1 day |
| Aggregated analytics | 24 months |
| Account configuration | Until account deletion |
---
### Criterion 8: IP Address Anonymization
**Requirement:** IP addresses must be anonymized (last octet removed minimum).
| Aspect | Compliance |
|--------|------------|
| IP storage | ✅ **IP is never persisted in the analytics database** (operational request logs are retained a maximum of 1 day) |
| Geolocation (default) | ✅ Country derived from browser timezone, not IP |
| In-memory use | ✅ IP is used in-memory only for rate limiting and blocklist matching, then discarded. It is never associated with a hit that reaches ClickHouse. (A GeoIP lookup was designed for the Agent Analytics bot detector, but that feature is **not live and cannot be enabled**, so no such lookup runs today.) |
**Technical Implementation:**
```javascript
// Country detection (default): browser timezone API
Intl.DateTimeFormat().resolvedOptions().timeZone
// No GeoIP lookup runs today: the Agent Analytics bot detector
// that would use one is not live and cannot be enabled.
```
**Note:** Sealmetrics goes beyond this requirement — no IP anonymization is needed because the IP is never persisted with analytics data in the first place.
---
### Criterion 9: Geolocation Precision Limit
**Requirement:** Geolocation must not be more precise than postal code level.
| Aspect | Compliance |
|--------|------------|
| Location precision | ✅ Country level only |
| No precise geolocation | ✅ No city/region/postal code |
| Privacy-preserving method | ✅ Timezone-based detection |
**Geolocation Data Collected:**
- Country (derived from timezone)
- No region, city, or postal code
- No GPS or IP-based location
---
### Criterion 10: Independent Data Collection Per Publisher
**Requirement:** For services serving multiple publishers, data collection must be independent for each.
| Aspect | Compliance |
|--------|------------|
| Client data isolation | ✅ Complete separation of datasets |
| Per-account tracking IDs | ✅ Each account has a unique tracking ID |
| Independent databases | ✅ Logical separation per account |
**Architecture:**
```
Account A ──► Isolated dataset A ──► Reports A only
Account B ──► Isolated dataset B ──► Reports B only
↓
No cross-account access possible
```
---
### Criterion 11: Totally Independent Trackers
**Requirement:** Trackers must be completely independent with no interdependencies.
| Aspect | Compliance |
|--------|------------|
| Unique tracking IDs | ✅ Each account has unique ID |
| No shared infrastructure impact | ✅ Client A cannot affect Client B |
| Independent configuration | ✅ Each account configured separately |
**Implementation:**
```html
```
---
### Criterion 12: User Information Requirement
**Requirement:** Users must be informed about analytics via privacy policy.
| Aspect | Compliance |
|--------|------------|
| Documentation provided | ✅ Privacy policy template available |
| Clear information | ✅ Plain language explanation |
| Purpose explanation | ✅ Audience measurement stated |
**Recommended Privacy Policy Text:**
```
This website uses Sealmetrics for audience measurement. This tool
is configured to comply with CNIL guidelines for consent exemption.
It collects anonymous statistical data only, does not use cookies,
and does not track you across websites. You can block analytics
using your browser's privacy settings or an ad blocker.
```
---
### Criterion 13: Opt-Out Mechanism
**Requirement:** Users must have ability to refuse audience measurement.
| Aspect | Compliance |
|--------|------------|
| Opt-out available | ✅ Yes - via browser settings or site implementation |
| Easy to access | ✅ Standard browser controls |
| No individual tracking | ✅ Nothing personal to opt out of |
**Important Context:**
Sealmetrics does **not use localStorage, cookies, or any persistent storage** by default. This means:
- There is no individual user tracking to opt out of
- Data is collected as aggregate statistics only
- Each pageview is independent with no user identification
**Opt-Out Methods:**
1. **Browser-level blocking** - Users can block the tracking script using browser privacy settings or ad blockers
2. **Publisher-implemented opt-out** - Site owners can implement conditional script loading based on user preference
```html
```
**Note:** Since Sealmetrics collects only aggregate statistics without individual identification, the opt-out requirement is satisfied by standard browser controls.
---
### Criterion 14: No Reuse by Provider
**Requirement:** Analytics provider cannot reuse data for their own commercial purposes.
| Aspect | Compliance |
|--------|------------|
| No data monetization | ✅ Sealmetrics never sells data |
| No model training | ✅ Client data not used for AI/ML |
| No benchmarking without consent | ✅ No cross-client analysis |
**Legal Guarantee:** Our [Terms of Service](https://sealmetrics.com/terms) and [DPA](https://sealmetrics.com/dpa) legally prohibit any reuse of client data.
---
## Part 3: Data Processing Details
### Data Collected
| Data Point | Collected | Purpose | Anonymization |
|------------|-----------|---------|---------------|
| Page URL | ✅ | Content analysis | Aggregated |
| Referrer | ✅ | Traffic source | Aggregated |
| User agent | ✅ | Device analysis | Aggregated |
| Screen size | ✅ | UX optimization | Aggregated |
| Timezone | ✅ | Country detection | Country only |
| Session ID | ✅ | Visit counting | Temporary, hashed |
| IP address | ❌ | Not collected | N/A |
| Email/name | ❌ | Not collected | N/A |
| Precise location | ❌ | Not collected | N/A |
### Data NOT Collected
Sealmetrics explicitly does **not** collect:
- IP addresses
- Email addresses or personal identifiers
- Precise geolocation (GPS, city, postal code)
- Device fingerprints
- Cross-site identifiers
- Advertising IDs
- Social media profiles
---
## Part 4: Infrastructure & Security
### Data Location
| Aspect | Detail |
|--------|--------|
| **Processing location** | Dublin, Ireland (EU) |
| **Data storage** | EU only |
| **Subprocessors** | Visitor analytics data processed only in the EU (full list: Annex 3 of the [DPA](https://sealmetrics.com/dpa/)) |
| **International transfers** | None required |
### Security Measures
- TLS 1.3 encryption in transit
- AES-256 encryption at rest
- Regular security audits
- GDPR Article 32 technical measures
---
## Part 5: Configuration Checklist
To ensure CNIL compliance, verify your Sealmetrics configuration:
### Required Settings ✅
- [ ] Standard tracking mode enabled (not debug mode)
- [ ] No custom user ID implementation
- [ ] No PII in custom properties
- [ ] Privacy policy updated with Sealmetrics mention
- [ ] Opt-out mechanism available to users
### Recommended Settings
- [ ] Content grouping for aggregated analysis
- [ ] Conversion tracking without PII
### Prohibited Configurations ❌
- [ ] Do NOT pass email addresses as properties
- [ ] Do NOT use custom user IDs for cross-session tracking
- [ ] Do NOT combine with advertising/remarketing tools
- [ ] Do NOT export individual-level data for profiling
---
## Part 6: Compliance Statement
### Official Declaration
Sealmetrics declares that:
1. Our solution **meets the CNIL criteria** for consent-exempt audience measurement
2. When properly configured, Sealmetrics **can be implemented without requiring user consent** under Article 82 of French Data Protection Law
3. We provide **documentation and configuration guidance** to ensure compliant implementation
4. We **do not reuse client data** for any commercial purpose
### What This Means
Publishers using Sealmetrics in France can:
- ✅ Measure website traffic without consent banners
- ✅ Track conversions for their own business analysis
- ✅ Analyze content performance
- ✅ Monitor technical performance
Publishers **cannot**:
- ❌ Claim Sealmetrics is "CNIL certified" or "CNIL validated"
- ❌ Use Sealmetrics data for advertising purposes
- ❌ Combine Sealmetrics with profiling tools and claim exemption
---
## Part 7: Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.0 | February 2026 | Initial self-assessment based on CNIL July 2025 framework |
---
## References
- [CNIL - Cookies: solutions pour les outils de mesure d'audience](https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies-solutions-pour-les-outils-de-mesure-daudience)
- [CNIL - Self-Assessment Tool (PDF)](https://www.cnil.fr/sites/default/files/2025-07/outil_d_auto-evaluation_mesure_d_audience.pdf)
- [CNIL - Sheet n°16: Use analytics on your websites](https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications)
- [Sealmetrics Privacy Policy](https://sealmetrics.com/privacy)
- [Sealmetrics DPA](https://sealmetrics.com/dpa)
---
## Contact
For compliance questions or DPO inquiries:
- **Email:** privacy@sealmetrics.com
- **DPO Contact:** dpo@sealmetrics.com
## Related documentation
- [Does Sealmetrics comply with CNIL guidelines?](/compliance/cnil-self-assessment) — the plain-language overview of CNIL consent exemption.
- [Analytics Cookies: Consent Exemption Requirements](/compliance/analytics-cookies-exemption) — how CNIL and AEPD exemption criteria compare.
- [UK PECR Self-Assessment: Sealmetrics Compliance](/compliance/uk-pecr-self-assessment) — the equivalent self-assessment for the UK.
- [Do Temporary Session Identifiers (Session IDs) Require Consent Under GDPR?](/legal/gdpr-and-eprivacy/do-session-ids-require-consent) — the session-ID condition assessed above.
- [Cookie Consent Reform: The End of Banner Fatigue](/compliance/omnibus/cookies-eprivacy) — how the Digital Omnibus reinforces this exemption.
## How Sealmetrics Blocks Bot Traffic (And Stays Consentless)
URL: https://docs.sealmetrics.com/compliance/compliance-overview/how-sealmetrics-blocks-bot-traffic
# How Sealmetrics Blocks Bot Traffic (And Stays Consentless)
Bot and automated traffic can distort every metric you rely on. Sealmetrics filters it out with a layered, privacy-safe system — and this page explains exactly how each layer works and why the approach remains fully consentless.
---
## Our IP position, stated plainly
Let's address the most common question first: **does bot filtering involve IP addresses?**
Yes — transiently, and never stored in the analytics database. Here is the complete picture:
- **No analytics metric is ever calculated from an IP.** Visitor country comes from the [browser timezone](/security-privacy/country-detection), not from IP lookup.
- **The visitor's IP is never written to the analytics database.** Our event storage has no IP column at all — storing one is architecturally impossible, not just policy.
- During request handling, the IP is used **transiently on the server** for security purposes: checking the request against curated blocklists of known bots and datacenters. If it matches, the request is dropped. Either way, the IP is not carried forward into analytics processing. (As with any web service, IPs may appear transiently in operational logs with limited retention, separate from analytics data.)
- **The IP is never linked to any hit, session, or metric**, and never used to identify, profile, or track anyone.
Transient use of an IP is still "processing" under GDPR — we don't pretend otherwise. It is processed under **legitimate interest (Art. 6(1)(f))**, which Recital 49 explicitly recognizes for network and information security purposes, including "preventing unauthorised access... and stopping denial-of-service attacks". Transient, security-focused IP handling with nothing persisted in the analytics database is the textbook case.
What makes Sealmetrics consentless is not a claim that IPs never exist in our infrastructure — it's that they are **never stored with analytics data, never used for tracking, and never used for analytics**.
---
## Layer 1 — Bot user-agent signatures
Every browser and bot sends a *user agent* string describing the client software. Most legitimate bots identify themselves clearly.
Sealmetrics maintains an updated signature list of known bot user agents — search engine crawlers, uptime monitors, headless browsers, automation tools — with exact, prefix, substring, and pattern matching. A hit matching a bot signature is discarded immediately and never enters your reports.
---
## Layer 2 — Curated IP and datacenter blocklists
Sealmetrics maintains curated blocklists of IPs and network ranges (CIDRs) belonging to known bots, scrapers, and datacenters, plus any per-site block rules you configure yourself.
When a hit arrives:
1. The request's IP is checked **in memory** against these lists.
2. If it matches, the request is dropped.
3. The IP is discarded — it is never persisted, in either case.
These lists are curated block rules (like a firewall's), not records of your visitors.
---
## Layer 3 — Request-header consistency checks
Automated clients frequently send request headers that are inconsistent with the browser they claim to be. Sealmetrics scores header consistency on each request as an additional bot signal — no personal data involved.
---
## Layer 4 — Agent Analytics (not available)
**Caution:**
Agent Analytics is **not live and cannot be enabled on any account**. No site performs the processing described below. It is documented here only so that this page stays a complete description of the detection design; treat it as roadmap, not as current behaviour.
If it ships, sites that explicitly enable it would get deeper detection of AI agents and automated browsers on entrance hits:
- A **stateless GeoLite2 lookup** deriving datacenter/ISP signals from the IP (is this a datacenter? does the network belong to a known AI provider?) and a country label used to detect geo/timezone mismatches, with only the derived signals kept and the IP discarded.
- **Environmental signals** about the browser (e.g. WebDriver flag, rendering characteristics) and **behavioral signals** about the interaction pattern (e.g. mouse-movement linearity, click-timing variance) feeding a score that classifies each session as human or automated.
Those signals would describe the *software environment*, not the person, and would never be associated with an identifier. **Today, no account collects any of it** — Layers 1 to 3 above are the whole of what runs.
---
## Why this approach is privacy-compliant
- **User agents** are used as anonymous device-category signals, stored with the hit for the standard 24-month retention window, never linked to any personal identifier (we don't have one), and never used to reconstruct anyone's history.
- **IPs** are processed transiently on the server for security only, under legitimate interest (Recital 49), and never stored with analytics data.
- **No tracking identifiers** are created or used at any layer.
- **No profiling of individuals** — classification targets bot vs. human traffic, at session level, based on software signals.
This is why bot filtering requires **no consent banner** and creates **no personal-data exposure**.
---
## Summary
| Layer | Signal | IP stored? | Personal data stored? |
|---|---|---|---|
| Bot UA signatures | User-agent string | No | No |
| IP/datacenter blocklists | IP, in memory only | No | No |
| Header consistency | Request headers | No | No |
| Agent Analytics *(not available)* | Derived geo/ISP + environment + behavior | No | No |
The result: clean analytics, honest architecture, and zero consent requirements.
## Related documentation
- [Is Sealmetrics GDPR, ePrivacy, CCPA, and PECR Compliant?](/compliance/compliance-overview/is-sealmetrics-privacy-compliant) — the full compliance picture.
- [Legal FAQ — Sealmetrics Compliance Questions](/compliance/compliance-overview/legal-faq) — how IPs are (and aren't) used, in FAQ form.
- [What We Track vs What We Don't](/security-privacy/what-we-track) — the exact data Sealmetrics does and does not collect.
- [How Sealmetrics determines the country without using IP addresses](/security-privacy/country-detection) — timezone-based geolocation for analytics.
- [Bot Detection & Traffic Quality](/security-privacy/bot-detection) — how filtered bot traffic keeps reports clean.
## GDPR Amendments in the Digital Omnibus
URL: https://docs.sealmetrics.com/compliance/omnibus/gdpr-changes
# GDPR Amendments in the Digital Omnibus
The EU Digital Omnibus introduces targeted amendments to the General Data Protection Regulation (GDPR) that clarify ambiguities, reduce compliance burdens, and adapt the framework to new technological realities like artificial intelligence.
Unlike the wholesale repeal of other regulations, the GDPR is **amended, not replaced**—recognizing its fundamental soundness while addressing practical pain points identified since 2018.
## Personal Data Definition Clarified
**Warning:**
The European data protection authorities have expressed **strong opposition** to these changes in their [Joint Opinion 2/2026](./edpb-edps-opinion.md), recommending their complete removal from the proposal. They argue the current definition works well and changes risk reducing protection levels. The final text may differ from the Commission proposal.
### The "Reasonably Likely" Standard
The Omnibus amends **Article 4** to codify the Court of Justice of the European Union (CJEU) interpretation of "personal data":
**New standard**: Data is personal when it is **"reasonably likely to be used"** by the holder to identify an individual.
**What this changes:**
**Before**: Uncertainty about whether data is "personal" if identification is theoretically possible but highly impractical.
**After**: Clear standard based on reasonable likelihood, considering:
- Available technical means
- Cost of identification
- Time required
- Practical feasibility
### Entity-Specific Personal Data
**Key principle**: Data that is personal for one entity may NOT be personal for another.
**Example scenario:**
A hospital shares pseudonymized medical records with a research institution:
- **For the hospital**: Personal data (they have the key to re-identify)
- **For the researcher**: NOT personal data (they cannot re-identify)
**Legal consequence**: The researcher is NOT bound by GDPR requirements applicable to personal data processing, as long as they lack the means to re-identify individuals.
### Pseudonymization Clarity
**Article 4 amendments** clarify that pseudonymized data is NOT personal data for a recipient who:
1. Receives the data in pseudonymized form, AND
2. Does not have the means to re-identify the data subject
**Practical impact:**
- Facilitates legitimate data sharing for research
- Reduces compliance burden on recipients of pseudonymized data
- Encourages privacy-enhancing technologies
- Creates legal certainty for data intermediaries
### Commission Implementing Acts on Pseudonymization
**New provision**: The Commission can adopt **implementing acts** specifying:
- Criteria for effective pseudonymization
- Technical techniques and standards
- When pseudonymization provides sufficient protection
**Note:**
The [Joint Opinion 2/2026](./edpb-edps-opinion.md) opposes giving the Commission this power, arguing that whether data is "personal" is a fundamental rights question, not a technical specification. They recommend the EDPB retain authority over pseudonymization guidance.
**Benefits (per Commission):**
- Harmonized standards across EU
- Technical guidance for implementation
- Legal certainty for processors
- Promotes interoperability
## Scientific Research Expanded
### New Definition in Article 4
**Scientific research** now explicitly includes:
- Fundamental research
- Applied research
- **Technological development**
- **Demonstration activities**
**Impact**: Broader scope for research exemptions and flexibilities.
### Further Processing Compatibility
**Article 5(1)(b)** clarification: Further processing for scientific research is **compatible with the initial purpose** of data collection.
**What this means:**
- Data collected for one purpose can be used for research
- No need for fresh legal basis
- Simplifies longitudinal studies
- Encourages data reuse for public benefit
### Legitimate Interest for Research
**Article 6(1)(f)** amendment: Processing for scientific research explicitly recognized as a **legitimate interest**.
**Requirements:**
- Balance test still applies
- Data subject rights remain
- Appropriate safeguards required
**Benefit**: Clarifies legal basis for research activities without need for consent in many cases.
### Information Obligation Exemption
When providing information to data subjects would require **disproportionate effort** in a research context, the obligation can be waived.
**Conditions:**
- Legitimate research purpose
- Appropriate safeguards in place
- Public interest considerations
**Example**: Retrospective medical research on decades of patient records where contacting all individuals is impractical.
## AI Training and Development
**Note:**
The [Joint Opinion 2/2026](./edpb-edps-opinion.md) accepts the legitimate interest basis for AI but requests stronger safeguards, particularly for web scraping scenarios and meaningful right to object implementation.
### New Article 88c: AI Legitimate Interest
The Omnibus introduces **Article 88c**, a dedicated provision for AI system development:
**Core principle**: Processing personal data for AI development and operation is a **legitimate interest** under Article 6(1)(f).
**Full text:**
> "Where the processing of personal data is necessary for the interests of the controller in the context of the development and operation of an AI system as defined in Article 3, point (1), of Regulation (EU) 2024/1689 or an AI model, such processing may be pursued for legitimate interests within the meaning of Article 6(1)(f)..."
### Scope and Limitations
**What Article 88c covers:**
- Training AI models on personal data
- Testing and validating AI systems
- Operating AI systems that process personal data
- Fine-tuning and improving models
**What Article 88c does NOT override:**
- Laws explicitly requiring consent (e.g., DMA requirements for gatekeepers)
- Fundamental rights that override legitimate interests
- Special protections for children
- Article 9 special category data (see below)
**Balance test still required**: The legitimate interest must not be overridden by data subject rights and freedoms.
### Special Categories of Data (Article 9)
**Article 88c addresses special category data** (race, health, religion, etc.):
**Goal**: Avoid processing special categories through technical measures.
**Requirements for AI developers:**
1. **Implement technical measures** during data source selection to avoid collecting special category data
2. **Data minimization** during training and testing
3. **Remove or protect** special category data if identified despite safeguards
4. **Exception**: Special category data processed residually despite safeguards does NOT violate Article 9
**Practical meaning:**
- AI developers must try to filter out sensitive data
- If some sensitive data remains despite best efforts, processing may continue
- Must demonstrate good-faith technical safeguards
- Cannot intentionally target special category data
### Required Safeguards
**Article 88c mandates** "appropriate organisational, technical measures and safeguards":
**Technical measures:**
- Data minimization during source selection
- Filtering and sanitization
- Protection against disclosure of residual data
- Non-disclosure safeguards in model outputs
**Organizational measures:**
- Enhanced transparency to data subjects
- Clear documentation of safeguards
- Regular review and updates
**Unconditional right to object**: Data subjects must have the right to object to processing of their data for AI purposes.
### Impact on AI Industry
**Positive:**
- Legal certainty for AI training
- Legitimate interest basis clearly established
- Harmonized EU-wide approach
**Obligations:**
- Cannot ignore data subject rights
- Must implement technical safeguards
- Must respect objections
- Transparency requirements
**Not a free pass:**
- Balance test applies
- High-risk processing still restricted
- Children's data has additional protection
- DMA gatekeepers still need consent
## Data Breach Notification Threshold
### Raising the Bar to "High Risk"
**Article 33 amendment**: Data breach notification to supervisory authorities now required only for **HIGH RISK** breaches (previously "risk").
**Before**:
- Notify supervisory authority within 72 hours if breach poses "risk" to rights and freedoms
- Resulted in over-notification of minor incidents
- Burdened supervisory authorities with trivial reports
**After**:
- Notify only if "high risk" to rights and freedoms
- Aligns with Article 34 (direct communication to data subjects, which always required "high risk")
- Reduces administrative burden
### What Constitutes "High Risk"?
The **European Data Protection Board (EDPB)** will create:
- Common template for notifications
- List of breach types constituting "high risk"
- Guidance on assessment criteria
**Expected "high risk" scenarios:**
- Large-scale breaches affecting thousands
- Sensitive data (health, financial, credentials)
- Breaches enabling identity theft or fraud
- Data of vulnerable populations (children)
- Breaches with severe consequences
**Not "high risk" (examples):**
- Accidental disclosure of limited non-sensitive data
- Breaches with effective mitigating measures already in place
- Technical incidents with no real-world impact
- Isolated incidents affecting single individuals with minimal data
### Single Entry Point via ENISA
**New centralized reporting**: Breaches can be reported through a **single entry point** managed by ENISA (European Union Agency for Cybersecurity).
**Benefits:**
- Simplified reporting for multi-national controllers
- Consistent format and handling
- Reduced administrative complexity
- Better data for EU-wide security analysis
### Practical Impact
**For controllers:**
- Fewer required notifications
- Focus on genuinely serious incidents
- Reduced compliance costs
- Still must document ALL breaches internally
**For supervisory authorities:**
- Fewer trivial notifications
- Can focus on serious incidents
- Better resource allocation
- Improved oversight quality
## Information Requirements Simplified
### Article 13 Exemption for Low-Risk Processing
**New Article 13 provision**: Controllers need NOT provide information to data subjects when **BOTH** conditions are met:
**Condition (a)**: Data subject likely already has the information
**Condition (b)**: Processing is NOT high-risk
**Who benefits:**
- Small business operators (craftspeople, hairdressers)
- Local service providers (sports clubs, community organizations)
- SMEs with straightforward processing
- Public authorities for routine operations
**Example scenarios:**
✅ **Hairdresser appointment book**: Customer knows their name and phone number are recorded for appointments. Low risk. No privacy notice needed.
✅ **Local sports club membership**: Members obviously know the club has their contact info. Low risk. Simplified or no notice acceptable.
❌ **Online health monitoring service**: High-risk processing. Full Article 13 notice required.
❌ **Customer profiling for marketing**: Data subject may not know extent of processing. Full notice required.
### What This Changes
**Before**: Every processing activity, no matter how trivial, required detailed Article 13 information.
**After**: Proportionate approach recognizing low-risk, obvious processing.
**Safeguards:**
- Only for genuinely low-risk processing
- Data subject must reasonably expect the processing
- All other GDPR requirements still apply
- Data subject rights remain fully enforceable
## Right of Access: Abusive Requests
### Article 12 Amendment
**New provision**: Controllers can **refuse abusive access requests** where the request is made for purposes other than data protection.
**What constitutes "abusive":**
- Litigation harassment
- Commercial intelligence gathering
- Competitor research disguised as access requests
- Repeated requests with no legitimate data protection purpose
- Requests clearly aimed at disrupting business operations
### Lower Burden of Proof
**Key change**: **Lower burden of proof** for controllers to demonstrate that a request is abusive.
**Before**: Controllers had to clearly prove abuse, often difficult in practice.
**After**: Reasonable indications of abuse are sufficient to justify refusal.
**Safeguards:**
- Must still be genuine abuse (not simply inconvenient)
- Data subjects can challenge refusal
- Supervisory authorities can review
- Cannot be used to deny legitimate requests
### Impact
**For controllers:**
- Protection against weaponized access requests
- Reduced costs from abusive requesters
- Can focus resources on legitimate requests
**For data subjects:**
- Legitimate requests still fully protected
- No impact on genuine exercise of rights
- Challenge mechanism if unfairly refused
## Automated Decision-Making
### Article 22 Clarification
**Article 22** has been clarified regarding the "necessary for contract" exception:
**Old ambiguity**: Could automated decisions be "necessary for contract" only if human decision-making was impossible?
**New clarity**: The fact that a **human could make the decision does NOT prevent** automated processing from being "necessary for the contract."
**What this means:**
✅ **Credit decisions**: Automated credit scoring can be "necessary for contract" even though humans could theoretically assess creditworthiness.
✅ **Fraud prevention**: Automated fraud checks are permissible even if manual review is possible.
✅ **Pricing algorithms**: Dynamic pricing based on automated analysis can be necessary for the service model.
**Limits:**
- Must still be genuinely necessary for the specific contract
- Cannot be arbitrary
- Data subject rights (explanation, human review) remain
- Transparency requirements apply
**Not a blanket authorization**: Controllers must still demonstrate the automated decision-making is necessary for the specific contractual relationship, not just convenient.
## Summary of GDPR Amendments
| Amendment | Article | Impact |
|-----------|---------|--------|
| **Personal data definition** | Article 4 | "Reasonably likely" standard; entity-specific determination |
| **Pseudonymization** | Article 4 | Clarity on when pseudonymized data is not personal; Commission implementing acts |
| **Scientific research definition** | Article 4 | Includes tech development and demonstration |
| **Research compatibility** | Article 5(1)(b) | Further processing for research is compatible |
| **Research legitimate interest** | Article 6(1)(f) | Research explicitly recognized as legitimate interest |
| **Information exemption** | Article 13 | No notice needed if data subject has info AND low-risk |
| **Abusive access requests** | Article 12 | Lower burden to refuse abusive requests |
| **Automated decisions** | Article 22 | "Necessary for contract" doesn't require automation to be only option |
| **Breach notification** | Article 33 | Threshold raised to "high risk" only |
| **AI processing** | Article 88c (new) | Legitimate interest for AI development; safeguards required |
| **Cookie consent** | Article 88a (new) | Unified GDPR framework for terminal storage |
| **Browser signals** | Article 88b (new) | Machine-readable consent preferences |
## Related Resources
- [Cookie Consent Reform](./cookies-eprivacy.md) - Details on Articles 88a and 88b
- [Impact on Web Analytics](./impact-analytics.md) - How amendments affect analytics
- [EDPB-EDPS Joint Opinion](./edpb-edps-opinion.md) - Regulatory position on these amendments
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) - How cookieless measurement satisfies GDPR principles
- [Analytics Cookies: Consent Exemption Requirements](/compliance/analytics-cookies-exemption) - Consent-exemption rules that apply today
## Key Takeaways
1. **Personal data definition clarified** with "reasonably likely" standard from CJEU case law
2. **Pseudonymization promoted** with clarity on when data is no longer personal
3. **Scientific research expanded** in definition and flexibilities
4. **AI training has legal basis** via Article 88c legitimate interest
5. **Breach notifications reduced** to high-risk incidents only
6. **Information requirements simplified** for low-risk, obvious processing
7. **Abusive access requests** can be refused with lower burden of proof
8. **Automated decision-making** clarified for contractual necessity
These amendments preserve the GDPR's core privacy protections while addressing practical implementation challenges identified over six years of application. The result is a more workable framework that reduces unnecessary compliance burdens without compromising data subject rights.
## Is Sealmetrics GDPR, ePrivacy, CCPA, and PECR Compliant?
URL: https://docs.sealmetrics.com/compliance/compliance-overview/is-sealmetrics-privacy-compliant
# Is Sealmetrics GDPR, ePrivacy, CCPA, and PECR Compliant?
**Info:**
This is a **self-assessment**, not a certification. No supervisory authority certifies or validates analytics tools, and Sealmetrics holds no third-party security certification (no ISO 27001, no SOC 2). This page documents how the architecture meets the published criteria of each framework.
Sealmetrics is built so that the questions these frameworks ask about personal data do not arise: no personal data is collected, so there is nothing to consent to and no personal-data obligations are triggered. This is our own assessment against:
- **GDPR** (European Union)
- **ePrivacy Directive** (EU)
- **CCPA** (California Consumer Privacy Act)
- **PECR** (UK Privacy and Electronic Communications Regulations)
Sealmetrics achieves this by operating on a **privacy-first, cookieless, consentless measurement model** based entirely on **isolated hits**.
---
## 1. European Infrastructure & Legal Alignment
Sealmetrics is a **European company**, and:
- All servers are located in **Dublin, Ireland**
- All data is processed within the **EU**
- No personal data is transferred outside the EU
- Operations comply with GDPR’s strict data handling requirements
All customer analytics data therefore stays within the EU.
---
## 2. Compliant by Design: No Personal Data, No Tracking
Sealmetrics does **not**:
- Track individual users
- Correlate hits across time
- Build user profiles
- Use cookies, localStorage, fingerprinting, or identifiers
- Insert any tracking code in the user’s terminal beyond the measurement script
This architectural model ensures there is **no processing of personal data**, eliminating the need for cookie banners or consent.
---
## 3. Based on “Isolated Hits” — No User Tracking
Sealmetrics does not track sessions or users.
Instead, it measures **isolated page views (hits)** that are *never linked together*.
### For each hit, Sealmetrics collects only four variables:
1. **Timestamp**
2. **User Agent** *(used for anonymous device classification; the raw string is purged after 1 day and only the derived browser/OS/device categories persist in aggregates — never linked to a person)*
3. **Current URL**
4. **Referral URL**
These four elements allow meaningful analytics, but **do not enable any type of identification or re-identification**, keeping the stored dataset anonymous, which is what places it outside the GDPR's material scope (Recital 26).
---
## 4. ePrivacy Directive Interpretation
Sealmetrics follows a strict privacy interpretation:
> **Tracking individual users without consent is not permissible — even anonymously — under the ePrivacy Directive.**
Because Sealmetrics never tracks individuals and never correlates hits, measurement can operate without consent.
This makes Sealmetrics one of the only analytics platforms capable of providing **cookieless and consentless analytics** that still offer valuable insights.
---
## 5. Compliance With Global Privacy Regulations
### GDPR
✔ No personal data collected
✔ No identifiers
✔ No consent required
✔ EU-based processing
### ePrivacy Directive
✔ No individual user tracking
✔ No session reconstruction
✔ No device-level identifiers
### CCPA
✔ No personal information collected
✔ No user profiling
✔ No cross-site tracking
### PECR
✔ No cookies or terminal identifiers
✔ No persistent technology used
---
## Conclusion
Sealmetrics is **GDPR, ePrivacy, CCPA, and PECR compliant by design**, thanks to its strict privacy-first architecture:
- 0 personal data
- 0 cookies
- 0 user identifiers
- Isolated hits that are never joined to a person or to each other
This enables marketers and analysts to access reliable, actionable analytics **without compromising user privacy or requiring consent banners**.
## Related documentation
- [Does SealMetrics comply with CNIL guidelines?](/compliance/cnil-self-assessment) — the French consent-exemption criteria in detail.
- [Legal FAQ — Sealmetrics Compliance Questions](/compliance/compliance-overview/legal-faq) — audits, DPIA, data processing, and retention questions.
- [UK PECR Self-Assessment: Sealmetrics Compliance](/compliance/uk-pecr-self-assessment) — the UK analytics exemption under DUAA 2025.
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) — the GDPR reasoning behind the isolated-hit model.
- [What We Track vs What We Don’t](/security-privacy/what-we-track) — the four variables Sealmetrics records and nothing more.
## GDPR and Cookieless Analytics
URL: https://docs.sealmetrics.com/compliance/gdpr-cookieless-analytics
# GDPR and Cookieless Analytics
**Info:**
Any statement here about how Sealmetrics meets a criterion is a **self-assessment**, not a certification. No supervisory authority certifies or validates analytics tools, and Sealmetrics holds no third-party security certification (no ISO 27001, no SOC 2). This page is general regulatory analysis, not legal advice.
Cookieless analytics represent a fundamental shift in how websites measure traffic while complying with GDPR. By eliminating persistent user identifiers, cookieless solutions can provide comprehensive analytics without consent banners, data loss, or privacy violations.
## The GDPR Challenge for Traditional Analytics
### Why Cookies Trigger GDPR
**Cookies = Personal Data** (in most cases):
When a cookie contains a unique identifier that can be linked to an individual—even indirectly—it constitutes **personal data** under GDPR Article 4(1):
> "Personal data means any information relating to an identified or identifiable natural person"
**Traditional analytics cookies**:
- Unique visitor IDs
- Session identifiers
- Tracking across visits
- Building behavioral profiles over time
**Result**: Processing personal data requires lawful basis under **GDPR Article 6**.
### Common (Problematic) Approaches
#### Approach 1: Consent (Article 6(1)(a))
**Implementation**: Cookie banner requesting consent for analytics
**Problems**:
- 20-30% of users reject cookies
- Data loss from non-consenting users
- Skewed analytics (privacy-conscious users underrepresented)
- Consent fatigue
- Complex consent management
- Cost of consent management platforms
**Compliance challenge**: Consent must be "freely given, specific, informed, and unambiguous" (GDPR Article 4(11))—difficult with cookie walls or dark patterns.
#### Approach 2: Legitimate Interest (Article 6(1)(f))
**Claim**: Analytics is a legitimate interest
**Problems**:
- Must pass three-part test:
1. Legitimate interest exists ✅ (understanding website performance)
2. Processing is necessary ❓ (are cookies necessary for analytics?)
3. Balancing test ❓ (interests vs. rights)
- Data protection authorities skeptical of legitimate interest for tracking cookies
- Right to object must be provided
- EDPB guidance suggests consent is safer route for most cookies
**Risk**: Supervisory authority or court may reject legitimate interest claim for tracking cookies.
#### Approach 3: Ignore GDPR (Non-Compliance)
**Implementation**: Place analytics cookies without legal basis
**Consequences**:
- GDPR violations
- Fines up to €20M or 4% global revenue
- Enforcement actions
- Reputational damage
- User complaints
**Not recommended**: High-profile Google Analytics enforcement (Austria, France, Italy) demonstrates authorities are serious.
## The Cookieless Solution
### What is Cookieless Analytics?
**Definition**: Web analytics that do not use cookies or similar persistent identifiers to track users across sessions.
**Technical approaches**:
1. **Session-based measurement**: Track page views within session, without cross-session linking
2. **Server-side logging**: Analyze server logs without client-side identifiers
3. **Cookieless session identification**: Without personal data or persistent identifiers
4. **Aggregated metrics only**: Count events without identifying individuals
**Key principle**: Measure the **audience** (how many, from where, what they do) without **tracking individuals** (who specifically, what they do over time).
### Why Cookieless Complies with GDPR
#### 1. No Personal Data Processing (Ideal Case)
**If truly anonymous**:
- No unique identifiers
- No linking across sessions
- No individual tracking
- GDPR does not apply (Recital 26: anonymous information not covered)
**Example**: Server logs counting page views per hour, by country, without any visitor identification.
**Advantage**: No legal basis required; GDPR inapplicable to anonymous data.
#### 2. Minimal Personal Data (Practical Case)
**Even if some personal data processed** (e.g., IP addresses):
**Legitimate interest (Article 6(1)(f)) is stronger** for cookieless analytics:
**Necessity test**:
- Cookieless measurement is **genuinely necessary** (no less intrusive alternative exists for basic traffic measurement)
- Purpose is limited and clear
**Balancing test**:
- Low privacy impact (no profiling, no cross-site tracking, no long-term identifiers)
- User expectations: Reasonable to expect website measures traffic
- Transparency: Easy to explain and understand
- No high risk to data subjects
**Outcome**: Legitimate interest likely valid for cookieless analytics where it may not be for cookie-based tracking.
### GDPR Article 6 Bases for Cookieless Analytics
| Legal Basis | Applicability | Requirements |
|-------------|---------------|--------------|
| **Consent (6(1)(a))** | Not needed for cookieless | N/A - no tracking to consent to |
| **Contract (6(1)(b))** | Rarely applicable | Analytics not necessary for service delivery |
| **Legal obligation (6(1)(c))** | Not applicable | No law requires website analytics |
| **Vital interests (6(1)(d))** | Not applicable | Analytics don't protect life |
| **Public task (6(1)(e))** | Public sector only | Government websites measuring performance |
| **Legitimate interest (6(1)(f))** | **Primary basis** | Website operator's interest in understanding traffic |
**Most common**: **Legitimate interest (Article 6(1)(f))**
## Legitimate Interest Assessment for Cookieless Analytics
### Three-Part Test
#### Part 1: Legitimate Interest
**Question**: Does the controller have a legitimate interest?
**For cookieless analytics**:
- ✅ Understanding website performance
- ✅ Improving user experience
- ✅ Optimizing content
- ✅ Technical operations and security
- ✅ Business planning and development
**GDPR Recital 47**: "The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest."
**By analogy**: If direct marketing is legitimate interest, certainly understanding website usage is too.
**Conclusion**: Legitimate interest clearly exists.
#### Part 2: Necessity
**Question**: Is processing necessary for that interest?
**For cookieless analytics**:
- ✅ Cannot understand traffic without measurement
- ✅ Cookieless approach is **least intrusive** method
- ✅ No alternative that is less invasive (unless you don't measure at all)
**Article 5(1)(c)**: Data minimization—collect only what is necessary
**Cookieless analytics demonstrates data minimization**:
- No persistent identifiers
- No cross-session tracking
- Aggregated measurement
- Short data retention
**Conclusion**: Processing is necessary, and minimized to what's required.
#### Part 3: Balancing Test
**Question**: Do data subject interests, rights, and freedoms override the legitimate interest?
**Factors to consider**:
**Nature of data**:
- Basic traffic metrics (not sensitive)
- No special categories (Article 9)
- Minimal personal data (if any)
**Reasonable expectations**:
- Users expect websites measure traffic
- Cookieless is less invasive than expected (no tracking)
- Transparent and understandable
**Impact on data subjects**:
- **Low risk**: No profiling, no behavioral advertising, no selling data
- **No discrimination**: Analytics not used for automated decisions affecting individuals
- **No vulnerability**: Not targeting children or vulnerable populations
**Safeguards**:
- Privacy policy disclosure
- Right to object provided
- Data security measures
- Limited retention periods
**Conclusion**: Interests do NOT override; legitimate interest is valid.
### Legitimate Interest Assessment: Cookieless vs. Cookie-Based
| Factor | Cookieless Analytics | Cookie-Based Tracking |
|--------|----------------------|----------------------|
| **Legitimate interest** | Understanding traffic ✅ | Understanding + profiling ❓ |
| **Necessity** | Minimized approach ✅ | Could use cookieless ❌ |
| **Privacy impact** | Low (no tracking) ✅ | High (persistent tracking) ❌ |
| **User expectations** | Reasonable ✅ | Negative (tracking) ❌ |
| **Safeguards** | Built-in (no IDs) ✅ | Requires controls ⚠️ |
| **Balancing outcome** | Legitimate interest valid ✅ | Questionable, consent safer ❌ |
**Result**: Legitimate interest is appropriate for cookieless; questionable for cookie-based tracking.
## GDPR Principles and Cookieless Analytics
### Principle 1: Lawfulness, Fairness, Transparency (Article 5(1)(a))
**Lawfulness**: Legitimate interest provides legal basis ✅
**Fairness**:
- Users not deceived
- No hidden tracking
- Processing aligns with reasonable expectations ✅
**Transparency**:
- Privacy policy discloses analytics
- Clear explanation of what's measured
- How to exercise rights ✅
**Cookieless advantage**: Easier to explain ("we count visitors, we don't track you") vs. complex cookie ecosystems.
### Principle 2: Purpose Limitation (Article 5(1)(b))
**Requirement**: Data collected for specified, explicit, legitimate purposes; not further processed incompatibly
**Cookieless analytics**:
- ✅ Clear purpose: Website performance measurement
- ✅ Limited scope: Traffic statistics for website operator's use
- ✅ No secondary uses: Not sold, not used for advertising, not shared
**Compliance**: Purpose limitation naturally satisfied by design.
### Principle 3: Data Minimization (Article 5(1)(c))
**Requirement**: Adequate, relevant, and limited to what is necessary
**Cookieless analytics**:
- ✅ No persistent user IDs (eliminates unnecessary tracking)
- ✅ Aggregated metrics (only what's needed for statistics)
- ✅ No individual profiles (unnecessary for traffic measurement)
- ✅ Minimal personal data (IP anonymization, no cross-session linking)
**Gold standard**: Cookieless is **data minimization by design**.
### Principle 4: Accuracy (Article 5(1)(d))
**Requirement**: Personal data must be accurate and kept up to date
**Cookieless analytics**:
- ✅ Aggregate statistics (accuracy inherent in counting)
- ✅ No individual data to be inaccurate
- ✅ Session-based measurement (no stale profiles)
**Benefit**: Less risk of inaccuracy when not maintaining user profiles.
### Principle 5: Storage Limitation (Article 5(1)(e))
**Requirement**: Kept in identifiable form no longer than necessary
**Cookieless analytics**:
- ✅ Session-only tracking (no long-term storage of identifiers)
- ✅ Aggregated data quickly (raw logs not retained long)
- ✅ Typical retention: 24 months maximum (align with AEPD requirements)
- ✅ Aggregated reports can be kept indefinitely (no personal data)
**Best practice**: Delete raw server logs after aggregation; retain only statistics.
### Principle 6: Integrity and Confidentiality (Article 5(1)(f))
**Requirement**: Appropriate security measures
**Cookieless analytics**:
- ✅ Less data to secure (no long-term user profiles)
- ✅ Encryption in transit (HTTPS)
- ✅ Access controls
- ✅ Secure infrastructure
**Reduced risk**: Less valuable to attackers (no persistent user data to breach).
### Principle 7: Accountability (Article 5(2))
**Requirement**: Controller must demonstrate compliance
**Cookieless analytics**:
- ✅ Document legitimate interest assessment
- ✅ Maintain records of processing activities (Article 30)
- ✅ Privacy policy reflects cookieless approach
- ✅ Data protection by design (Article 25)
**Demonstration**: Easier to show compliance when processing is minimal.
## Data Subject Rights and Cookieless Analytics
### Right of Access (Article 15)
**User request**: "What personal data do you have about me?"
**Cookieless analytics response**:
- **If truly anonymous**: "Our analytics do not process your personal data; we cannot identify you in our statistics."
- **If minimal data (IP in logs)**: "We have server logs with your IP address from [date/time], used for traffic measurement. This data will be deleted after [retention period]."
**Advantage**: Simple response; no extensive user profiles to provide.
### Right to Rectification (Article 16)
**User request**: "Correct inaccurate data about me"
**Cookieless analytics**:
- Not applicable (no individual user profiles to be inaccurate)
- Aggregate statistics are accurate by design
### Right to Erasure (Article 17)
**User request**: "Delete my data"
**Cookieless analytics**:
- **If anonymous**: Not possible (cannot identify user in aggregate data)
- **If IP in logs**: Can delete specific IP entries, or explain scheduled deletion period
**Practical**: Much easier than cookie-based systems tracking users across months/years.
### Right to Restriction (Article 18)
**User request**: "Stop processing my data while we resolve a dispute"
**Cookieless analytics**:
- Rarely applicable (no ongoing individual processing to restrict)
- Can flag IP for non-processing if requested
### Right to Data Portability (Article 20)
**User request**: "Give me my data in portable format"
**Cookieless analytics**:
- Not applicable (Article 20 requires processing based on consent or contract; analytics typically legitimate interest)
- Even if applied: No meaningful individual data to port (aggregate statistics not "personal data")
### Right to Object (Article 21)
**User request**: "Stop processing my data for analytics"
**Cookieless analytics must provide**:
- ✅ Mechanism to object (e.g., email address in privacy policy)
- ✅ Honor objections (stop including user in analytics)
**Implementation options**:
1. **IP exclusion**: Add user's IP to exclusion list (imperfect, dynamic IPs)
2. **Browser signal**: Respect Do Not Track or Global Privacy Control
3. **Opt-out cookie**: Paradoxically, set cookie to exclude from cookieless analytics
4. **Manual request**: User contacts, we exclude their IP or sessions
**Best practice**: Make objection easy and effective.
## Cookieless Analytics and ePrivacy
### ePrivacy Directive Article 5(3)
**Separate from GDPR**: Regulates terminal equipment access (cookies, device fingerprinting)
**Requirement**: Consent for storing/accessing information in terminal equipment
**Exception**: Strictly necessary for service delivery
### Cookieless and ePrivacy Compliance
**Key question**: Do cookieless analytics access/store information in terminal equipment?
**If NO cookies or client-side storage**:
- ✅ ePrivacy Directive does not apply
- ✅ No consent required under ePrivacy
- ✅ Only GDPR applies (covered by legitimate interest)
**If minimal cookies (e.g., session cookie)**:
- "Strictly necessary" exception may apply (if truly needed for service)
- Or analytics exemption under AEPD framework (see [Analytics Cookies Exemption](./analytics-cookies-exemption.md))
**Cookieless advantage**: Bypasses ePrivacy consent requirement entirely.
### Digital Omnibus Future Framework
**Article 88a(3)(c)** (when in force):
> "Creating aggregated information about the usage of an online service to measure the audience of such a service, where it is carried out by the controller of that online service solely for its own use"
**Explicit consent exemption** for:
- Aggregated measurement
- By controller
- For own use
**Cookieless analytics alignment**: Perfectly aligned with Article 88a(3)(c)
**Learn more**: [EU Digital Omnibus - Cookie Consent Reform](./omnibus/cookies-eprivacy.md)
## Practical Implementation: GDPR-Compliant Cookieless Analytics
### Step 1: Choose Cookieless Solution
**Options**:
**Sealmetrics**:
- Cookieless by design
- Aggregated measurement
- First-party data only
- Meets these criteria out of the box, with no configuration needed
**Server-side analytics**:
- Parse server logs
- Anonymize IPs
- Aggregate metrics
- No client-side tracking
**Privacy-focused platforms**:
- Plausible (cookieless mode)
- Fathom Analytics
- Simple Analytics
- Matomo (cookieless configuration)
### Step 2: Configure for Privacy
**If using Sealmetrics**: the default configuration already meets the criteria above
**If using other tools**:
- ✅ Disable cookies
- ✅ Disable user ID tracking
- ✅ Disable cross-site tracking
- ✅ Enable IP anonymization
- ✅ Limit data retention (24 months max recommended)
- ✅ Disable any advertising features
- ✅ Ensure first-party data only
### Step 3: Conduct Legitimate Interest Assessment
**Document**:
1. **Legitimate Interest**:
- What: Understanding website performance to improve user experience
- Why: Necessary for operating and improving our online service
- Benefit: Better content, faster site, improved UX
2. **Necessity**:
- Processing limited to traffic statistics
- Cookieless approach = minimum data
- No less intrusive alternative exists
3. **Balancing Test**:
- Low privacy impact (no tracking, no profiling)
- Reasonable user expectations
- Transparency in privacy policy
- Right to object provided
- **Conclusion**: Legitimate interest valid
**Retain this assessment**: For accountability (Article 5(2))
### Step 4: Update Privacy Policy
**Required disclosures**:
```markdown
## Website Analytics
We use cookieless analytics to understand how visitors use our website. This helps us improve content and user experience.
### What We Measure
- Pages visited
- Referrer (where you came from)
- Device type and browser
- Geographic location (country/region)
- Time spent on pages
### What We Don't Do
- We do not use cookies to track you
- We do not track you across websites
- We do not build individual user profiles
- We do not sell or share your data
- We do not use your data for advertising
### Legal Basis
Legitimate interest (GDPR Article 6(1)(f)): We have a legitimate interest in understanding how our website is used to improve it. Our processing is limited, transparent, and does not override your privacy rights.
### Your Rights
You have the right to:
- Object to analytics processing
- Access any personal data we hold
- Request deletion of your data
To exercise these rights, contact: [privacy@example.com]
### Data Retention
// ... see full example at https://docs.sealmetrics.com/compliance/gdpr-cookieless-analytics
```
### Step 5: Provide Opt-Out Mechanism
**Options**:
**Simple email**:
> "If you wish to opt out of our analytics, contact privacy@example.com with your IP address or approximate time of visit."
**Technical opt-out**:
- Respect Do Not Track header
- Respect Global Privacy Control
- Provide dedicated opt-out page
**Best practice**: Make it easy; few users will actually opt out of non-invasive cookieless analytics.
### Step 6: Maintain Records
**Article 30 GDPR**: Record of processing activities
**Required information**:
- Name and contact details of controller
- Purposes of processing (website analytics)
- Categories of data subjects (website visitors)
- Categories of personal data (IP address [if processed], referrer, user agent)
- Categories of recipients (analytics provider, if any)
- Retention periods (24 months)
- Security measures
**Maintain this record**: Available for supervisory authority if requested.
## Common Questions
### Do I need a cookie banner for cookieless analytics?
**No.** If analytics are truly cookieless (no cookies, no persistent identifiers), ePrivacy consent requirement does not apply.
**GDPR still applies**: But legitimate interest is sufficient; consent not required.
### Can I use cookieless Google Analytics?
**Google Analytics 4** has a "cookieless mode" but:
- Data still transferred to Google
- Google may use data for its purposes
- May not qualify for GDPR legitimate interest
- May still require consent
**Recommendation**: Use purpose-built cookieless analytics (Sealmetrics, Plausible, Fathom) for genuine compliance.
### Is IP address personal data?
**Yes**, under GDPR (confirmed by CJEU in Breyer case).
**But**: Can be processed under legitimate interest if:
- Purpose is limited (traffic measurement)
- Retention is limited (deleted after aggregation)
- Anonymized or pseudonymized where possible
**Cookieless analytics**: Often anonymize IPs at collection or immediately after processing.
### What about device fingerprinting?
**Device fingerprinting** = Combining browser/device characteristics to create a persistent unique identifier for tracking users across sessions.
**GDPR status**: Persistent device fingerprinting creates personal data and requires legal basis (typically consent).
**ePrivacy status**: Accessing device information to build persistent identifiers may require consent under Article 5(3).
**Sealmetrics**: Does not use device fingerprinting. Sessions are identified using cookieless, privacy-preserving technology that does not create persistent identifiers and cannot track users across sessions.
### How long can I retain cookieless analytics data?
**GDPR Storage Limitation** (Article 5(1)(e)): No longer than necessary
**Best practice**:
- **Raw data (IP addresses, logs)**: 24 months maximum (aligns with AEPD)
- **Aggregated statistics**: Indefinitely (no personal data)
**Recommended approach**:
1. Collect raw data
2. Aggregate into statistics daily/weekly/monthly
3. Delete raw data after aggregation (or after 24 months max)
4. Retain aggregated reports indefinitely
### Can I share cookieless analytics data?
**With data processor** (Article 28): Yes, if:
- Data Processing Agreement in place
- Processor only acts on your instructions
- Processor does not use data for own purposes
**With third parties for their purposes**: No, unless:
- Data is truly anonymous (aggregated to point of non-identification)
- OR you obtain consent
- OR another Article 6 basis applies
**Best practice**: Keep analytics data in-house; only share truly anonymous statistics.
## Cookieless Analytics and Data Transfers
### GDPR Chapter V: International Transfers
**If analytics data transferred outside EU/EEA**:
**GDPR requirements**:
- Adequacy decision, OR
- Appropriate safeguards (Standard Contractual Clauses, Binding Corporate Rules), OR
- Derogations (consent, contract, etc.)
**Cookieless advantage**:
- Less data to transfer (no user profiles)
- Can keep data in EU more easily (self-hosted or EU providers)
**Sealmetrics**: customer analytics data stays in the EU (Dublin), so Chapter V transfer rules are not engaged for it.
**US-based analytics**: Proceed with caution post-Schrems II; ensure SCCs and supplementary measures.
## Comparison: Cookie-Based vs. Cookieless
| Aspect | Cookie-Based Analytics | Cookieless Analytics |
|--------|------------------------|----------------------|
| **GDPR legal basis** | Consent (usually) or contested legitimate interest | Legitimate interest (strong case) |
| **ePrivacy requirement** | Consent required | Not applicable (no cookies) |
| **Cookie banner** | Required | Not required |
| **Data subject rights** | Complex (years of profiles) | Simple (minimal data) |
| **Consent rate** | 50-80% (data loss) | N/A (100% data) |
| **Privacy impact** | High (tracking over time) | Low (session-only) |
| **User experience** | Interrupted (banner) | Seamless (no banner) |
| **Compliance complexity** | High | Low |
| **Cost** | High (CMP, legal review) | Low (no CMP needed) |
| **Data quality** | Skewed (consent bias) | Complete (all visitors) |
**Clear winner**: Cookieless analytics for privacy, compliance, UX, and data quality.
## Related Resources
- [Analytics Cookies Exemption Requirements](./analytics-cookies-exemption.md) - AEPD and EU DPA guidance on analytics without consent
- [EU Digital Omnibus - Cookie Consent Reform](./omnibus/cookies-eprivacy.md) - Future framework for analytics under Article 88a
- [EU Digital Omnibus - Impact on Analytics](./omnibus/impact-analytics.md) - How regulations affect analytics industry
- [Is Sealmetrics GDPR, ePrivacy, CCPA, and PECR Compliant?](/compliance/compliance-overview/is-sealmetrics-privacy-compliant) - How the isolated-hit model applies these principles
- [Do Temporary Session Identifiers (Session IDs) Require Consent Under GDPR?](/legal/gdpr-and-eprivacy/do-session-ids-require-consent) - When session identifiers stay consent-exempt
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) - The technical basis for consentless measurement
## Key Takeaways
1. **Cookieless analytics can comply with GDPR** without consent banners
2. **Legitimate interest (Article 6(1)(f))** is appropriate legal basis for cookieless analytics
3. **ePrivacy consent not required** when no cookies or terminal storage used
4. **Data minimization by design**: Cookieless naturally satisfies GDPR principles
5. **Simpler data subject rights**: Minimal data = minimal rights management
6. **No cookie banner needed**: Better UX, complete data, lower costs
7. **Future-proof**: Aligns with Digital Omnibus Article 88a(3)(c)
8. **Document legitimate interest**: Conduct and retain assessment for accountability
9. **Privacy policy disclosure**: Required even for cookieless analytics
10. **Right to object**: Must be provided and honored
Cookieless analytics represent the evolution of privacy-respecting measurement. By eliminating persistent tracking while maintaining statistical accuracy, they satisfy both GDPR requirements and user expectations for privacy. As the Digital Omnibus makes clear, aggregated audience measurement for own use is not invasive surveillance—it's legitimate business intelligence. Cookieless analytics embody this principle in practice.
## Cookie Consent Reform: The End of Banner Fatigue
URL: https://docs.sealmetrics.com/compliance/omnibus/cookies-eprivacy
# Cookie Consent Reform: The End of Banner Fatigue
**Info:**
The EU Digital Omnibus is a **legislative proposal still under negotiation**; article numbers and text may change before it is in force. Any statement about how Sealmetrics would fall under it is our own reading and a **self-assessment**, not a certification — no supervisory authority certifies analytics tools.
The EU Digital Omnibus proposes the most significant reform to cookie consent rules since the ePrivacy Directive of 2009. By moving cookie consent under the GDPR framework, the regulation promises to eliminate cookie banners for an estimated 60% of websites while maintaining strong privacy protections.
## The Current Problem
### A Broken System
The current Article 5(3) of the ePrivacy Directive, dating from 2009, has created a system that frustrates users and burdens businesses without delivering meaningful privacy protection:
**Economic costs:**
- **€1.64 billion annually** spent on cookie banners by businesses
- 10 million websites × 41% with banners × €400/year average cost
- **€820 million/year** in business compliance costs
- **€320 million/year** in public sector costs
**User burden:**
- **334 million hours per year** spent by EU users clicking through cookie banners
- Average user encounters multiple banners daily
- **€500 million/year** in lost productivity
**Undermined protection:**
- **54% of users randomly accept** cookie banners without reading
- **26% randomly reject** without understanding implications
- "Consent fatigue" means users make uninformed decisions
- The very goal of informed consent is defeated
### Why the Current System Fails
The 2009 ePrivacy Directive predates modern web analytics, programmatic advertising, and today's data ecosystem. Its blanket consent requirement for any terminal storage has created:
1. **Banner overload**: Nearly half of all websites show cookie banners
2. **Dark patterns**: Pressure to accept through design manipulation
3. **Compliance complexity**: Different rules from GDPR create confusion
4. **Poor user experience**: Constant interruptions with no real choice
## The Solution: GDPR Integration
**Tip:**
The European data protection authorities **strongly support** addressing cookie banner fatigue in their [Joint Opinion 2/2026](./edpb-edps-opinion.md). They endorse the Article 88a(3)(c) exemption for audience measurement and additionally recommend creating an explicit exemption for **contextual advertising** (ads based on page content, not user tracking).
### Article 5(3) ePrivacy Repealed
The Digital Omnibus **repeals Article 5(3) of the ePrivacy Directive** for processing of personal data. This eliminates the separate cookie consent regime that has run parallel to GDPR since 2018.
### New Article 88a GDPR: Unified Rules
Cookie and terminal storage processing is brought under GDPR's comprehensive framework through new **Article 88a**:
**Default rule (Article 88a(1)):**
> "Storing of personal data, or gaining of access to personal data already stored, in the terminal equipment of a natural person is only allowed when that person has given his or her consent, in accordance with this Regulation."
Consent must meet GDPR standards: freely given, specific, informed, and unambiguous.
### Lawful Processing WITHOUT Consent
The breakthrough comes in **Article 88a(3)**, which identifies processing activities that do NOT require consent:
#### 1. Carrying Out Transmission (Article 88a(3)(a))
Necessary for transmitting electronic communication over a network. This covers:
- Session cookies
- Load balancing
- Network routing data
- Communication delivery mechanisms
#### 2. Service Explicitly Requested (Article 88a(3)(b))
Providing a service the user specifically asked for, such as:
- Shopping cart functionality
- User authentication and login
- Payment processing
- Form completion and preferences
- Language selection
#### 3. Aggregated Audience Measurement (Article 88a(3)(c))
**This is the game-changer for web analytics:**
> "Creating aggregated information about the usage of an online service to measure the audience of such a service, where it is carried out by the controller of that online service solely for its own use"
**Requirements:**
- Must be **aggregated** (not individual tracking)
- By the **controller** (website owner)
- For the controller's **own use only** (cannot be shared or sold)
**What this means:**
- First-party analytics: **NO CONSENT NEEDED**
- Basic traffic measurement: **NO CONSENT NEEDED**
- Understanding your own audience: **NO CONSENT NEEDED**
**What still needs consent:**
- Third-party tracking networks
- Cross-site user profiling
- Selling analytics data to advertisers
- Individual user tracking beyond aggregation
#### 4. Security Maintenance (Article 88a(3)(d))
Maintaining or restoring security of services and terminal equipment:
- Fraud prevention
- DDoS protection
- Security logging
- Malware detection
### Improved Consent Requirements
When consent IS required, **Article 88a(4)** strengthens user rights:
#### Single-Click Refusal (Article 88a(4)(a))
> "The data subject shall be able to refuse requests for consent in an easy and intelligible manner with a single-click button or equivalent means"
- No more buried "reject all" options
- Equal prominence to "accept"
- Cannot be harder to refuse than accept
#### No Re-Asking During Valid Consent (Article 88a(4)(b))
If a user gives consent, controllers cannot ask again for the same purpose during the consent validity period. This prevents:
- Repeated consent requests
- Consent fatigue from same-site re-prompting
- Dark patterns that wear users down
#### 6-Month Cooldown After Refusal (Article 88a(4)(c))
If a user declines consent, the controller **cannot ask again for at least 6 months** for the same purpose.
**Impact:**
- Stops repeated harassment
- Makes "no" mean "no"
- Reduces consent fatigue
- Protects user autonomy
## Browser Signals: The Future of Consent
### Article 88b: Machine-Readable Preferences
**Article 88b(1)-(2)** requires controllers to:
- Accept automated, machine-readable consent signals
- Accept automated consent refusal and objections (Article 21(2))
- Respect user choices communicated through browsers
### Media Service Provider Exemption
**Article 88b(3)**: Media service providers (news sites, publishers) are **EXEMPT** from accepting browser signals. They can still show consent dialogs.
**Rationale:**
- Publishers rely on advertising revenue
- Need flexibility for funding models
- Allows industry-specific solutions
### Standards Development
**Article 88b(4)**: The European Commission will request European standardisation bodies to develop standards for:
- Format of machine-readable signals
- Interpretation protocols
- Interoperability requirements
Think of this as a European alternative/complement to initiatives like Global Privacy Control (GPC).
### Implementation Timeline
**For websites (Article 88b(5)):**
- Must support browser signals: **24 months after entry into force**
- Gives businesses 2 years to update systems
**For browsers (Article 88b(7)):**
- Non-SME browser providers must offer consent controls: **48 months after entry into force**
- Gives browser vendors 4 years to implement
**What this means:**
- Phase 1 (2027-2028): Websites prepare infrastructure
- Phase 2 (2029-2030): Browsers deploy user controls
- Users will eventually set privacy preferences once in their browser
- Those preferences will be automatically respected across websites
## Cost Savings and Benefits
### Business Savings
**€820 million annually** from cookie banner elimination:
- No banner implementation costs
- No consent management platform (CMP) fees
- No legal review of cookie policies
- No A/B testing of consent designs
- No engineering time maintaining banner code
**60% of cookies no longer need consent**, meaning:
- 50% of private websites won't need banners
- 80% of public sector websites won't need banners
### User Benefits
**€500 million annually** in productivity gains:
- 200 million users × fewer hours on banners
- Faster website loading
- Reduced interruptions
- Better user experience
**334 million hours/year** currently wasted on cookie banners will be reclaimed.
### Public Sector Savings
**€320 million annually**:
- Government websites can drop most banners
- Universities and research institutions benefit
- Public services become more accessible
- Compliance burden reduced
## Practical Implications
**Warning:**
While the Digital Omnibus promises significant relief, legal analysts note that cookie banners will likely persist in many scenarios. The exemptions are narrower than headlines suggest, and information obligations still require some form of user notification.
### Why Cookie Banners May Persist
Despite the reforms, several factors will keep cookie banners alive for many websites:
**1. Narrow Exemptions**
The Article 88a(3)(c) exemption applies only to:
- Aggregated data (not individual tracking)
- Controller's own use (not shared with third parties)
- The specific service being measured
Most third-party analytics tools, advertising pixels, and cross-site tracking fall **outside** these exemptions.
**2. Information Obligations Remain**
Even when consent isn't required, GDPR's transparency requirements (Articles 13-14) still mandate informing users about data processing. This may require:
- Privacy policy updates (minimum)
- Some form of notification interface (likely)
**3. Hybrid Solutions Expected**
Legal experts predict many websites will adopt "hybrid" approaches:
- **Notification-only banners** for exempt processing (no consent button)
- **Consent banners** for third-party tracking (accept/reject)
- **Combined banners** explaining both
**4. Browser Signal Delays**
Full browser-based consent management requires:
- European standards development (ongoing)
- Website implementation (24 months after entry into force)
- Browser vendor implementation (48 months after entry into force)
Until browsers widely support automated signals (~2029-2031), manual consent mechanisms will remain necessary for consent-required processing.
### What Changes for Website Operators
**If you only do first-party analytics for your own use:**
- ✅ No consent required
- ✅ Direct cost savings
- ⚠️ Must be aggregated data
- ⚠️ Only for your own use (no data sharing)
- ⚠️ May still need information notice (not consent banner)
**If you use third-party tracking or advertising:**
- ⚠️ Still need consent
- ✅ Better consent UX requirements
- ✅ 6-month refusal protection
- 📅 Prepare for browser signals (24 months)
**If you're a media service provider:**
- ℹ️ Exempt from browser signal requirement
- ⚠️ Can still ask for consent directly
- ✅ Flexibility for publishing business models
### What Changes for Users
**Fewer cookie banners:**
- Many sites won't need them anymore
- Simpler web browsing experience
- Less interruption
**Better consent when required:**
- Equal "reject all" buttons
- No re-asking after refusal
- Clearer choices
**Future browser controls (2029+):**
- Set preferences once in browser
- Automatic application across sites
- Granular control if desired
## Timeline
**Entry into force**: Expected 2026-2027 (after legislative process)
**Article 88a applies**: 6 months after entry into force
**Article 88b (browser signals):**
- Websites: 24 months after entry into force
- Browsers: 48 months after entry into force
## Comparison with Current Rules
| Aspect | Current (ePrivacy 2009) | New (Article 88a) |
|--------|------------------------|-------------------|
| **Legal basis** | Article 5(3) ePrivacy Directive | Article 88a GDPR |
| **First-party analytics** | Consent required (with exemptions) | No consent if aggregated, own use |
| **Third-party tracking** | Consent required | Consent required |
| **Consent refusal** | No specific UX requirements | Single-click button required |
| **Re-asking after refusal** | Allowed | Blocked for 6 months |
| **Browser signals** | Not addressed | Must be supported (24 months) |
| **Functional cookies** | Exemption exists but unclear | Clear exemption (88a(3)(b)) |
| **Framework** | Separate from GDPR | Unified with GDPR |
## Related Resources
- [GDPR Amendments in the Digital Omnibus](./gdpr-changes.md) - Other changes to the GDPR
- [Impact on Web Analytics](./impact-analytics.md) - What this means for analytics providers
- [EDPB-EDPS Joint Opinion](./edpb-edps-opinion.md) - Regulatory support for cookie consent reform
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [Analytics Cookies: Consent Exemption Requirements](/compliance/analytics-cookies-exemption) - How analytics already qualifies for exemption today
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) - The technical basis for banner-free analytics
## Key Takeaways
1. **First-party analytics for own use = no consent needed** (clear win)
2. **Third-party tracking still requires consent** (no change)
3. **Cookie banners will reduce but not disappear entirely** — information obligations and third-party tools maintain some form of notification
4. **Better consent UX** when consent is required (single-click refuse, 6-month cooldown)
5. **Browser signals coming** in 24-48 months (but full adoption will take longer)
6. **Hybrid banner solutions** likely for sites mixing first-party and third-party tools
7. **Unified GDPR framework** replaces fragmented ePrivacy/GDPR cookie rules
The cookie consent reform represents a pragmatic evolution: preserving privacy protections while reducing consent fatigue. For websites using **only first-party, aggregated analytics** (like Sealmetrics), the path to banner-free operation is clear. For websites mixing multiple tracking tools, the picture is more nuanced — expect simplified banners rather than no banners.
## Data Law Consolidation: From 5 Acts to 2
URL: https://docs.sealmetrics.com/compliance/omnibus/data-consolidation
# Data Law Consolidation: From 5 Acts to 2
The EU Digital Omnibus achieves one of the most significant simplifications in European regulatory history: consolidating five separate data laws into two. This consolidation eliminates overlaps, reduces compliance complexity, and creates a coherent framework for Europe's data economy.
## The Current Fragmentation
### Five Separate Data Laws
Before the Omnibus, organizations navigating EU data regulation must comply with five distinct legal instruments:
#### 1. General Data Protection Regulation (GDPR)
**Regulation (EU) 2016/679**
**Scope**: Processing of personal data
**Focus**:
- Individual rights (access, erasure, portability)
- Lawful processing bases
- Controller and processor obligations
- Supervisory authority enforcement
**Status**: Foundational regulation, not repealed
#### 2. Free Flow of Data Regulation (FFDR)
**Regulation (EU) 2018/1807**
**Scope**: Free movement of non-personal data
**Focus**:
- Prohibition of data localization requirements
- Professional user data portability
- Self-regulatory codes of conduct
- Regulatory barriers monitoring
**Current problem**: Creates artificial distinction between personal/non-personal data that is difficult to apply in practice
#### 3. Data Governance Act (DGA)
**Regulation (EU) 2022/868**
**Scope**: Framework for trusted data sharing
**Focus**:
- Re-use of protected public sector data
- Data intermediation services (registration regime)
- Data altruism organizations
- European data innovation board
**Current problem**: Only 27 registered data intermediaries despite expectations of 100-150; heavy compliance burden
#### 4. Open Data Directive (ODD)
**Directive (EU) 2019/1024**
**Scope**: Public sector information re-use
**Focus**:
- Open data by default
- High-value datasets publication
- Charging principles
- Exclusive arrangements prohibition
**Current problem**: Overlaps with DGA on public sector data; creates confusion on which regime applies
#### 5. Data Act
**Regulation (EU) 2023/2854**
**Scope**: Data access and sharing rights
**Focus**:
- User access to IoT device data
- Data holder obligations to share with users
- Business-to-business data sharing
- Switching between data processing services
- Public sector access in emergencies
**Current problem**: Newest regulation, but already needs integration with older frameworks
### The Complexity Problem
**For businesses:**
- Must navigate five separate legal texts
- Overlapping definitions create uncertainty
- Different compliance procedures
- Multiple reporting obligations
- High legal advisory costs
**For regulators:**
- Fragmented enforcement
- Inconsistent interpretation
- Coordination challenges
- Resource inefficiency
**For innovation:**
- Legal uncertainty deters investment
- Compliance complexity favors large players
- Difficult to build pan-European data services
- Regulatory burden slows deployment
## The Consolidation Solution
### Result: 2 Laws
**After the Digital Omnibus:**
1. **GDPR (amended)**: Governs all personal data processing
2. **Data Act (consolidated)**: Governs all other data economy rules
### Why GDPR Remains Separate
The GDPR is **amended but not merged** because:
**Distinct purpose**: Fundamental rights protection vs. economic framework
**Different legal basis**: Article 16 TFEU (data protection) vs. Article 114 TFEU (internal market)
**Special enforcement**: Data protection authorities with independence guarantees
**International standard**: GDPR is globally recognized; maintaining as standalone regulation preserves its status
**Proportionality**: Personal data rules deserve distinct treatment given fundamental rights implications
## What Moves Into the Data Act
### From FFDR: Data Localization Ban
**FFDR Article 4** prohibition on data localization requirements becomes **Data Act Article 32h**.
**Content**:
> Member States shall not impose data localisation requirements that restrict the storage or processing of data in a specific geographical location within the Union.
**Exceptions maintained**:
- National security justified restrictions
- Public interest requirements (proportionate and necessary)
**Rationale for consolidation**: Data localization affects all data (personal and non-personal), so better integrated into comprehensive Data Act rather than separate regulation.
**What happens to rest of FFDR**: Mostly repealed; portability provisions absorbed into Data Act Chapter V (switching).
### From DGA: Data Intermediation Services
**DGA Chapter III** (Articles 9-15) moves to **Data Act Chapter VIIa**.
**What's included**:
- Data intermediation service provider definition
- Notification and registration (now voluntary—see below)
- Neutrality and transparency requirements
- Code of conduct framework
- Competent authority designation
**Key changes in consolidation**:
- **Notification becomes voluntary** (trust label system instead)
- **Separate legal entity requirement removed** (functional separation sufficient)
- Streamlined registration process
- Lighter monitoring obligations
**Services covered**:
- Data sharing platforms
- Data marketplaces
- Data cooperatives
- Personal data intermediaries
### From DGA: Data Altruism Organizations
**DGA Chapter IV** (Articles 16-28) moves to **Data Act Chapter VIIa**.
**What's included**:
- Data altruism definition (voluntary sharing for general interest)
- Registration of recognized data altruism organizations
- Transparency requirements
- European data altruism consent form
- Oversight mechanisms
**Key changes in consolidation**:
- **Rulebook requirement deleted** (too burdensome for voluntary activity)
- **National policy reporting deleted**
- Simplified compliance
- Easier registration
**Purpose**: Enable citizens and companies to donate data for research, statistics, and public interest purposes.
### From DGA: Protected Public Sector Data
**DGA Chapter II** (Articles 3-8) moves to **Data Act Chapter VIIa**.
**What's included**:
- Re-use of protected data held by public sector bodies
- Single information points
- Competent bodies for re-use requests
- Conditions and fees
- Non-discrimination requirements
**Integration rationale**: Fits naturally with Data Act's public sector data access provisions (emergency access, high-value datasets).
### From Open Data Directive: Public Sector Information
**Entire ODD framework** moves to **Data Act Chapter VIIc**.
**What's included**:
- Open data by default principle
- High-value datasets identification and publication
- Real-time data access
- Charging principles (marginal cost)
- Prohibition of exclusive arrangements
- Research data access
**Benefits of consolidation**:
- Single regime for all public sector data
- No more confusion between DGA and ODD
- Harmonized charging rules
- One-stop shop for public data access
**Member States**: Must transpose ODD provisions into national law (Directive obligations); now superseded by directly applicable Data Act provisions (Regulation).
## What Gets Fully Repealed
### Platform-to-Business Regulation (P2B)
**Regulation (EU) 2019/1150** is **fully repealed**.
**Why**: Completely superseded by Digital Services Act (DSA) and Digital Markets Act (DMA).
**DSA coverage**:
- Platform transparency obligations
- Terms and conditions requirements
- Algorithmic transparency
- Complaint handling mechanisms
**DMA coverage**:
- Gatekeeper obligations
- Fair treatment requirements
- Data access for business users
- Interoperability mandates
**Result**: P2B obligations now covered (and exceeded) by DSA/DMA; no need for separate regime.
**Transition**: Existing P2B compliance efforts seamlessly transfer to DSA/DMA compliance.
### Most of Free Flow of Data Regulation
**FFDR mostly repealed** except:
- Article 4 (data localization ban) → moves to Data Act
- Core free movement principle preserved in recitals
**What's deleted**:
- Separate monitoring framework (€846,612/year savings for public authorities)
- Standalone portability provisions (covered by Data Act switching rules)
- Code of conduct facilitation (redundant with Data Act mechanisms)
## Correlation Tables: Article-by-Article Mapping
The Digital Omnibus includes detailed **Annexes** with correlation tables showing exactly where each article of the repealed regulations moves in the consolidated framework.
### Example: DGA to Data Act Mapping
| DGA Article | Topic | New Location |
|-------------|-------|--------------|
| Articles 3-8 | Protected public sector data | Data Act Chapter VIIa, Section 1 |
| Articles 9-15 | Data intermediation services | Data Act Chapter VIIa, Section 2 |
| Articles 16-28 | Data altruism | Data Act Chapter VIIa, Section 3 |
| Articles 29-32 | Competent authorities | Data Act Chapter VIIa, Section 4 |
| Article 33 | European Data Innovation Board | Data Act Chapter VIIa, Section 5 |
### Example: ODD to Data Act Mapping
| ODD Chapter | Topic | New Location |
|-------------|-------|--------------|
| Chapter I | General provisions | Data Act Chapter VIIc, Section 1 |
| Chapter II | Re-use requests | Data Act Chapter VIIc, Section 2 |
| Chapter III | High-value datasets | Data Act Chapter VIIc, Section 3 |
| Chapter IV | Research data | Data Act Chapter VIIc, Section 4 |
**Practical value**: Legal counsel and compliance teams can trace every obligation from old law to new location.
## Benefits of Consolidation
### 1. Single Legal Framework for Data Economy
**Before**: Navigate GDPR + FFDR + DGA + ODD + Data Act
**After**: Navigate GDPR (personal) + Data Act (everything else)
**Impact**:
- Simpler compliance mapping
- Reduced legal advisory costs
- Easier training for compliance teams
- Better accessibility for SMEs
### 2. Harmonized Definitions
**Current problem**: Same concepts defined differently across laws.
**Examples**:
- "Data holder" in Data Act vs. "data controller" in GDPR
- "Data intermediary" in DGA vs. "data processing service" in Data Act
- "Public sector body" in ODD vs. DGA
**Consolidation solution**: Single set of definitions in Data Act applicable to all non-personal data provisions.
**Result**: Legal certainty, consistent interpretation, predictable enforcement.
### 3. Reduced Compliance Complexity
**Fewer registers to check**:
- Before: National DGA registers + Data Act registers + ODD high-value datasets
- After: Unified Data Act registers
**Fewer notifications**:
- Before: Separate DGA intermediation notification + Data Act switching notification
- After: Integrated notification process (and voluntary for intermediation)
**Fewer competent authorities**:
- Before: DGA authority + ODD authority + Data Act authority
- After: Single Data Act competent authority per Member State
### 4. Easier Compliance Navigation
**Single regulatory text**: Instead of cross-referencing five laws, consult two.
**Integrated obligations**: Related requirements in same chapters instead of scattered across regulations.
**Unified enforcement**: One competent authority for data economy (excluding personal data).
**Better guidance**: Regulators can issue comprehensive guidance on Data Act instead of fragmented guidance across multiple laws.
### 5. Supports Innovation
**Legal certainty**: Clear rules encourage investment in data-driven services.
**Lower barriers to entry**: Simplified compliance helps startups and SMEs compete.
**Pan-European services**: Easier to build services across all Member States with unified framework.
**Faster deployment**: Less time spent on legal analysis, more on product development.
## Cost Savings from Consolidation
### Direct Regulatory Savings
**FFDR monitoring relief**: €846,612/year for public authorities
- No separate monitoring framework
- Resources redirected to Data Act implementation
**DGA separate entity removal**: €318,750 one-off savings
- Data intermediaries no longer need separate legal entities
- Functional separation sufficient
**DGA monitoring simplification**: €6M/year
- Lighter oversight regime
- Risk-based supervision instead of continuous monitoring
### Indirect Business Savings
**Reduced legal advisory**: Fewer laws to analyze and cross-reference
**Simpler compliance procedures**: Unified processes instead of parallel tracks
**Lower training costs**: Staff learn one framework instead of five
**Faster market entry**: Less time from idea to launch for data services
### Public Sector Efficiency
**One competent authority per Member State** instead of multiple:
- Shared expertise
- Consistent interpretation
- Better resource allocation
- Coordinated enforcement
## Implementation Considerations
### Transitional Provisions
**Existing DGA registrations**: Automatically transfer to Data Act regime
- No need to re-register
- Existing rights and obligations continue
- Can opt in to new voluntary regime benefits
**ODD transposition**: Member States that transposed ODD Directive can repeal national laws once Data Act provisions apply
- Directly applicable regulation supersedes national transposition
- Simplifies national legal landscape
**FFDR compliance**: Organizations already complying with FFDR data localization ban continue under Data Act Article 32h
- No substantive change to obligations
- Same exemptions apply
### For Organizations
**Compliance mapping**:
1. Identify which regulations currently apply to your activities
2. Use correlation tables to find new Data Act provisions
3. Update internal policies and procedures
4. Train compliance teams on consolidated framework
**Documentation updates**:
- Privacy policies and transparency documents
- Data processing agreements
- Compliance manuals
- Training materials
**Legal basis review**:
- Ensure legal bases remain valid under consolidated framework
- Update references from repealed regulations to Data Act
- Consider new opportunities from simplified regime
## Visual Summary: Before and After
### Before Omnibus (2024)
```
Personal Data:
└─ GDPR
Non-Personal Data:
├─ Free Flow of Data Regulation (FFDR)
├─ Data Governance Act (DGA)
├─ Open Data Directive (ODD)
└─ Data Act
Mixed/Unclear:
└─ Platform-to-Business Regulation (P2B)
```
**Result**: Fragmented, overlapping, complex
### After Omnibus (2027)
```
Personal Data:
└─ GDPR (amended)
All Other Data:
└─ Data Act (consolidated)
├─ Data access and sharing (original Data Act)
├─ Data localization ban (from FFDR)
├─ Data intermediation (from DGA)
├─ Data altruism (from DGA)
├─ Protected public data (from DGA)
└─ Open data (from ODD)
Platform Regulation:
├─ Digital Services Act (DSA)
└─ Digital Markets Act (DMA)
```
**Result**: Coherent, integrated, simplified
## Comparison Table
| Aspect | Before (5 Laws) | After (2 Laws) |
|--------|----------------|----------------|
| **Legal texts to consult** | GDPR + FFDR + DGA + ODD + Data Act | GDPR + Data Act |
| **Personal data** | GDPR only | GDPR only (unchanged) |
| **Non-personal data localization** | FFDR Article 4 | Data Act Article 32h |
| **Data intermediation** | DGA Chapter III (mandatory) | Data Act Ch VIIa (voluntary) |
| **Data altruism** | DGA Chapter IV (with rulebook) | Data Act Ch VIIa (no rulebook) |
| **Public sector data** | ODD + DGA overlap | Data Act Ch VIIc (unified) |
| **Platform obligations** | P2B Regulation | DSA + DMA |
| **Competent authorities** | Multiple per MS | One per MS (plus DPAs) |
| **Definitions** | Inconsistent across laws | Harmonized in Data Act |
| **Compliance complexity** | High (fragmentation) | Reduced (consolidation) |
## Related Resources
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [GDPR Amendments](./gdpr-changes.md) - What changes in the GDPR
- [Data Intermediation Services](./data-intermediation.md) - Details on voluntary regime
- [Timeline and Implementation](./timeline-implementation.md) - Key dates for consolidation
- [EDPB-EDPS Joint Opinion on the Digital Omnibus](./edpb-edps-opinion.md) - Regulators' view on data acquis consolidation
## Key Takeaways
1. **Five data laws consolidated into two**: GDPR (personal) + Data Act (everything else)
2. **GDPR remains separate** with amendments; Data Act absorbs DGA, ODD, and FFDR core provisions
3. **P2B Regulation fully repealed** (superseded by DSA/DMA)
4. **Correlation tables provided** for article-by-article mapping
5. **Major cost savings**: €6M+/year from monitoring reduction alone
6. **Simplified compliance**: One framework instead of fragmented rules
7. **Better for innovation**: Legal certainty and lower barriers to entry
8. **Practical implementation**: Existing registrations and compliance transfer automatically
The consolidation is not just bureaucratic housekeeping—it's a fundamental restructuring of Europe's data economy framework. By eliminating overlaps, harmonizing definitions, and creating a single coherent legal regime (alongside GDPR), the Digital Omnibus makes EU data law navigable for businesses of all sizes while maintaining strong protections and enabling innovation.
## UK PECR Self-Assessment: Sealmetrics Compliance
URL: https://docs.sealmetrics.com/compliance/uk-pecr-self-assessment
# UK PECR Self-Assessment: Sealmetrics
This document provides the official self-assessment of Sealmetrics against the UK's criteria for consent-exempt analytics under the **Privacy and Electronic Communications Regulations (PECR)** as amended by the **Data Use and Access Act 2025**, effective **February 5, 2026**.
**Info:**
This self-assessment follows ICO guidelines but **does not constitute ICO certification**. This document demonstrates how Sealmetrics meets the published exemption criteria when properly configured for UK users.
---
## Executive Summary
| Category | Status |
|----------|--------|
| **Analytics Exemption Conditions** | ✅ All compliant |
| **Aggregate Statistics Purpose** | ✅ Compliant |
| **User Information Requirement** | ✅ Compliant |
| **Opt-Out Mechanism** | ✅ Compliant |
| **No Advertising Use** | ✅ Compliant |
| **Consent Exemption Eligible** | ✅ Yes |
| **Last Assessment Date** | February 2026 |
---
## Background: UK PECR Changes 2026
### Data Use and Access Act 2025
The **Data Use and Access Act 2025** (DUAA) received Royal Assent on **November 7, 2025** and takes effect on **February 5, 2026**. It introduces significant changes to UK PECR, including a new exemption for analytics cookies and similar technologies.
### Key Changes for Analytics
Prior to DUAA 2025, UK PECR required consent for **all** cookies except those "strictly necessary" for service delivery. The new legislation introduces an **analytics exemption** similar to existing frameworks in France (CNIL) and other EU member states.
### Legal Reference
> **Section 99 of DUAA 2025** amends PECR Regulation 6 to allow storing or accessing information on a user's terminal equipment without consent when the **sole purpose** is to obtain or compile statistical information about the use of an information society service, subject to specific conditions.
---
## Part 1: Analytics Exemption Conditions
The UK analytics exemption requires **all four conditions** to be met:
### Condition 1: Sole Purpose - Aggregate Statistics
**Requirement:** The sole purpose must be to obtain or compile statistical information about the use of an information society service.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| Purpose limited to statistics | ✅ Yes - only audience measurement |
| No secondary purposes | ✅ No advertising, profiling, or resale |
| Aggregate data only | ✅ All reports show aggregated statistics |
**Evidence:** Sealmetrics is a purpose-built analytics tool that produces only aggregate statistical reports. Individual user tracking, profiling, and advertising are architecturally impossible.
---
### Condition 2: Clear User Information
**Requirement:** The subscriber or user must have been provided with clear and comprehensive information about the purposes of storing or accessing the information.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| Information provided | ✅ Privacy policy templates available |
| Clear language | ✅ Plain English explanations |
| Comprehensive coverage | ✅ All data collection explained |
**Recommended Privacy Policy Text:**
```
This website uses Sealmetrics for audience measurement. This is a privacy-first
analytics tool that collects aggregate statistics only. It does not use cookies,
does not track you across websites, and does not collect personal information.
You can block analytics using your browser's privacy settings or an ad blocker.
```
---
### Condition 3: Simple Opt-Out Mechanism
**Requirement:** The subscriber or user must have been given a simple means, free of charge, of refusing storage or access to that information.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| Opt-out available | ✅ Yes - via browser settings or site implementation |
| Simple to use | ✅ Standard browser controls |
| Free of charge | ✅ No cost to user |
| Easily accessible | ✅ Built into all modern browsers |
**Important Context:**
Sealmetrics does **not use localStorage, cookies, or any persistent storage** by default. This means:
- There is no individual user tracking to opt out of
- Data is collected as aggregate statistics only
- Each pageview is independent with no user identification
**Opt-Out Methods:**
1. **Browser-level blocking** - Users can block the tracking script using:
- Browser privacy settings
- Ad blockers (uBlock Origin, etc.)
- Privacy extensions
2. **Publisher-implemented opt-out** - Site owners can implement their own opt-out:
```html
```
**Note:** Since Sealmetrics collects only aggregate statistics without individual identification, the opt-out requirement is satisfied by standard browser controls that allow users to block any script.
---
### Condition 4: No Advertising Use
**Requirement:** The information cannot be used for purposes relating to advertising.
| Criterion | Sealmetrics Compliance |
|-----------|----------------------|
| No advertising features | ✅ Not available in Sealmetrics |
| No ad targeting | ✅ Architecturally impossible |
| No retargeting data | ✅ No data shared for ads |
| No ad networks | ✅ No third-party integrations |
**Evidence:** Sealmetrics has no advertising features, no integration with ad platforms, and no capability to share data with advertising networks. The platform is designed exclusively for audience measurement.
---
## Part 2: Permitted Activities Under UK Exemption
The ICO guidance clarifies what activities are permitted under the analytics exemption:
### Permitted Analytics Activities
| Activity | Sealmetrics Support | Compliance |
|----------|---------------------|------------|
| Aggregate visitor counts | ✅ Yes | ✅ Compliant |
| Page interaction metrics | ✅ Yes | ✅ Compliant |
| Session duration | ❌ Not measured — it would require following a visitor across page loads | ✅ Compliant |
| Device and browser info | ✅ Yes (aggregated) | ✅ Compliant |
| Referrer source analysis | ✅ Yes | ✅ Compliant |
| A/B testing | ✅ Via events | ✅ Compliant |
| Coarse geolocation | ✅ Country only | ✅ Compliant |
| Page load performance | ✅ Yes | ✅ Compliant |
| Error monitoring | ✅ Yes | ✅ Compliant |
---
### Prohibited Activities (Not Available in Sealmetrics)
| Activity | Sealmetrics | Status |
|----------|-------------|--------|
| Individual user tracking | ❌ Not possible | ✅ Compliant |
| User profiling | ❌ Not possible | ✅ Compliant |
| Cross-device tracking | ❌ Not possible | ✅ Compliant |
| Advertising purposes | ❌ Not available | ✅ Compliant |
| Device fingerprinting | ❌ Not used | ✅ Compliant |
| Cross-site tracking | ❌ Not possible | ✅ Compliant |
---
## Part 3: Technical Compliance Details
### Data Collection Practices
| Data Point | Collected | Purpose | UK Exemption Status |
|------------|-----------|---------|---------------------|
| Page URL | ✅ | Content analysis | ✅ Permitted |
| Referrer | ✅ | Traffic source | ✅ Permitted |
| User agent | ✅ | Device analysis | ✅ Permitted |
| Screen size | ✅ | UX optimization | ✅ Permitted |
| Timezone | ✅ | Country detection | ✅ Permitted |
| Session ID | ✅ | Visit counting | ✅ Permitted (temporary) |
| IP address | ❌ | Not collected | ✅ N/A |
| Email/name | ❌ | Not collected | ✅ N/A |
| Precise location | ❌ | Not collected | ✅ N/A |
### Storage Methods
| Method | Sealmetrics Use | UK Exemption Compliance |
|--------|-----------------|-------------------------|
| First-party cookies | ❌ Not used by default | ✅ N/A |
| Third-party cookies | ❌ Never used | ✅ Compliant |
| localStorage | ❌ Not used | ✅ Compliant |
| Device fingerprinting | ❌ Never used | ✅ Compliant |
---
## Part 4: Comparison with Previous UK Requirements
### Before February 5, 2026
| Requirement | Status |
|-------------|--------|
| Consent required for all analytics | ✅ Required |
| Exception for "strictly necessary" only | Limited |
| Analytics = consent required | Yes |
### After February 5, 2026
| Requirement | Status |
|-------------|--------|
| Analytics exemption available | ✅ Yes |
| Conditions must be met | 4 conditions |
| Advertising use prohibited | ✅ Required |
| Opt-out must be provided | ✅ Required |
---
## Part 5: ICO Enforcement Considerations
### Increased Penalties Under DUAA 2025
The Data Use and Access Act 2025 increases maximum penalties for PECR violations:
| Penalty Type | Maximum |
|--------------|---------|
| **Standard maximum** | £17.5 million |
| **Turnover-based** | 4% of worldwide annual turnover |
| **Applicable** | Whichever is higher |
### ICO Enforcement Priorities
The ICO has indicated focus on:
- **Advertising-related cookies** without consent
- **Third-party tracking** without valid legal basis
- **Inadequate user information** about data collection
- **Missing or difficult opt-out mechanisms**
**Sealmetrics Advantage:** By design, Sealmetrics cannot be used for advertising or cross-site tracking, eliminating the highest-risk compliance concerns.
---
## Part 6: Configuration Checklist for UK Compliance
### Required Settings ✅
- [ ] Standard tracking mode enabled
- [ ] No custom user ID implementation that enables individual tracking
- [ ] No PII in custom event properties
- [ ] Privacy policy updated with analytics information
- [ ] Opt-out mechanism available and easily accessible
- [ ] No integration with advertising platforms
### Recommended Settings
- [ ] Content grouping for aggregate analysis
- [ ] Conversion tracking without PII
- [ ] Clear opt-out link in website footer
### Prohibited Configurations ❌
- [ ] Do NOT pass email addresses as properties
- [ ] Do NOT use custom user IDs for cross-session tracking
- [ ] Do NOT combine with advertising or remarketing tools
- [ ] Do NOT share data with third parties for advertising
- [ ] Do NOT use data for user profiling
---
## Part 7: Compliance Statement
### Official Declaration
Sealmetrics declares that:
1. Our solution **meets the UK PECR analytics exemption criteria** as amended by DUAA 2025
2. When properly configured, Sealmetrics **can be implemented without requiring user consent** under Regulation 6 of PECR
3. We provide **documentation and configuration guidance** to ensure compliant implementation
4. We **do not use client data** for advertising or any prohibited purpose
### What This Means for UK Publishers
Publishers using Sealmetrics in the UK can:
- ✅ Measure website traffic without consent banners (for analytics)
- ✅ Track conversions for their own business analysis
- ✅ Analyze content performance
- ✅ Monitor technical performance
Publishers **must**:
- ✅ Provide clear information about analytics in their privacy policy
- ✅ Offer a simple, free opt-out mechanism
- ✅ Use analytics data only for aggregate statistics
Publishers **cannot**:
- ❌ Use analytics data for advertising purposes
- ❌ Share data with advertising networks
- ❌ Enable individual user tracking or profiling
---
## Part 8: Data Protection & Security
### Data Location
| Aspect | Detail |
|--------|--------|
| **Processing location** | Dublin, Ireland (EU) |
| **Data storage** | EU only |
| **UK adequacy** | ✅ EU has UK adequacy decision |
| **International transfers** | Protected by adequacy |
### UK GDPR Alignment
Sealmetrics also complies with UK GDPR requirements:
| Requirement | Compliance |
|-------------|------------|
| Data minimisation | ✅ Only essential data collected |
| Purpose limitation | ✅ Analytics only |
| Storage limitation | ✅ 24 months maximum |
| Security measures | ✅ TLS 1.3, AES-256 encryption |
---
## Part 9: Transition Timeline
### Key Dates
| Date | Event |
|------|-------|
| **November 7, 2025** | DUAA 2025 receives Royal Assent |
| **February 5, 2026** | PECR amendments take effect |
| **Ongoing** | ICO guidance updates expected |
### Recommended Actions for Publishers
1. **Before February 5, 2026**: Review current analytics setup
2. **February 5, 2026**: Analytics exemption becomes available
3. **Ongoing**: Monitor ICO guidance for clarifications
---
## Part 10: Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.0 | February 2026 | Initial self-assessment based on DUAA 2025 |
---
## References
- [Data Use and Access Act 2025](https://www.legislation.gov.uk/ukpga/2025/25/contents/enacted)
- [ICO - Cookies and similar technologies](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/cookies-and-similar-technologies/)
- [Privacy and Electronic Communications Regulations 2003](https://www.legislation.gov.uk/uksi/2003/2426/contents)
- [Sealmetrics Privacy Policy](https://sealmetrics.com/privacy)
- [Sealmetrics DPA](https://sealmetrics.com/dpa)
---
## Contact
For compliance questions or DPO inquiries:
- **Email:** privacy@sealmetrics.com
- **DPO Contact:** dpo@sealmetrics.com
## Related documentation
- [Is Sealmetrics GDPR, ePrivacy, CCPA, and PECR Compliant?](/compliance/compliance-overview/is-sealmetrics-privacy-compliant) — the overall multi-regulation compliance summary.
- [CNIL Self-Assessment: Sealmetrics Compliance](/compliance/cnil-self-assessment) — the equivalent self-assessment for France.
- [Analytics Cookies: Consent Exemption Requirements](/compliance/analytics-cookies-exemption) — the analytics exemption conditions across EU DPAs.
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) — the cookieless basis that satisfies UK GDPR too.
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) — the model behind the PECR exemption.
## Germany TTDSG/TDDDG Self-Assessment: Sealmetrics Compliance
URL: https://docs.sealmetrics.com/compliance/germany-ttdsg-self-assessment
# Germany TTDSG/TDDDG Self-Assessment: Sealmetrics
This document provides the self-assessment of Sealmetrics against the German **Telecommunications Digital Services Data Protection Act** — the **TDDDG** (*Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz*), known until May 2024 as the **TTDSG**. The central provision for analytics is **§25 TDDDG**, Germany's transposition of Article 5(3) of the ePrivacy Directive.
**Info:**
This self-assessment follows the published legal framework and the guidance of the German Data Protection Conference (DSK), but **does not constitute certification** by the DSK, any German supervisory authority (Landesdatenschutzbehörde), or the BfDI. No such certification scheme for analytics tools currently exists in Germany. This document demonstrates how Sealmetrics meets the applicable requirements when properly configured.
---
## Executive Summary
| Category | Status |
|----------|--------|
| **§25(1) TDDDG — storage of information on terminal equipment** | ✅ Not triggered — nothing is stored |
| **§25(1) TDDDG — access to information stored on terminal equipment** | ✅ Not triggered — no stored information is read |
| **GDPR layer (visitor data)** | ✅ No personal data stored; no identifiers |
| **DSK Orientierungshilfe alignment** | ✅ Consistent |
| **Consent banner required** | ✅ No |
| **Last Assessment Date** | February 2026 |
---
## Background: Why Germany Is the Hard Case
Germany is widely regarded as the strictest large EU market for analytics:
1. **§25 TDDDG has no analytics exemption.** Unlike France (CNIL's audience-measurement exemption) or the UK (the DUAA 2025 analytics exemption), German law exempts only what is **strictly necessary** to provide the service the user requested (§25(2) Nr. 2). The DSK has consistently stated that audience measurement is *not* strictly necessary.
2. **Cookie rejection rates in Germany are among the highest in Europe** (estimated 70–87%).
3. **German supervisory authorities actively enforce** against cookie banners and tracking implementations.
This means a tool can only operate consent-free in Germany by **not triggering §25(1) at all** — not by claiming an exemption. That is exactly Sealmetrics' approach.
---
## Part 1: §25(1) TDDDG — The Two Prohibited Acts
§25(1) TDDDG requires consent for two acts:
> "The storage of information in the terminal equipment of the end user, or the access to information already stored in the terminal equipment, is only permitted if the end user has consented on the basis of clear and comprehensive information."
The provision is technology-neutral: it covers cookies, localStorage, sessionStorage, IndexedDB, cache-based identifiers, and fingerprinting techniques that read stored device information. Note that §25 applies **regardless of whether personal data is involved** — it protects the integrity of the terminal equipment itself.
### Criterion 1: Storage of information in the terminal equipment
**Requirement:** No information may be stored on the user's device without consent (unless strictly necessary).
| Aspect | Sealmetrics Compliance |
|--------|----------------------|
| Cookies (first- or third-party) | ✅ None set |
| localStorage / sessionStorage | ✅ Not used by the tracker |
| IndexedDB, cache identifiers, ETags | ✅ Not used |
| Any other write to the terminal | ✅ None |
**Evidence:** The Sealmetrics tracker (~1 KB) writes nothing to the browser. Session continuity (~2-hour window) is handled **server-side**, not by placing any marker on the device. You can verify this yourself: load a page with Sealmetrics installed and inspect DevTools → Application → Cookies/Storage. Nothing appears.
**Assessment:** ✅ The first prohibited act of §25(1) does not occur.
---
### Criterion 2: Access to information already stored in the terminal equipment
**Requirement:** No reading of information stored on the user's device without consent.
| Aspect | Sealmetrics Compliance |
|--------|----------------------|
| Reading cookies or storage APIs | ✅ Never — nothing was stored, nothing is read |
| Fingerprinting via stored device data | ✅ Not performed |
| Reading files, contacts, or device identifiers | ✅ Not performed |
**The nuance, stated honestly:** the tracker does evaluate a small number of runtime browser parameters via standard JavaScript APIs — the browser timezone (`Intl.DateTimeFormat().resolvedOptions().timeZone`, used for country detection) and screen size buckets. Whether reading such runtime environment parameters constitutes "access to information stored in the terminal equipment" under §25(1) is a debated question in German commentary.
The DSK's *Orientierungshilfe für Anbieter von Telemedien* takes the position that information the browser transmits anyway as part of the communication (e.g., the User-Agent header in every HTTP request) is not "access" within the meaning of the provision, whereas *active* retrieval of stored information is. Sealmetrics' position, criterion by criterion:
| Parameter | How obtained | §25 analysis |
|-----------|--------------|--------------|
| User agent | Transmitted by the browser in every HTTP request | Not "access" — part of the communication itself |
| Referrer, URL | Transmitted by the browser / part of the page context | Not "access" |
| Timezone | Standard JS runtime API; a configuration value, not stored user information | Reasonably outside §25; even under the strictest reading, it is a single non-identifying value used only for coarse (country-level) statistics, and no identifier is created or persisted |
| Screen size (bucketed) | Standard JS runtime API | Same analysis as timezone |
Crucially, even under the most restrictive interpretation, **the decisive risk factor that §25 targets — building or reading an identifier on the device — is absent**. No combination of these values is used to fingerprint, recognize, or re-identify a device or user, and nothing is ever written back to the terminal.
**Assessment:** ✅ No access to stored terminal information in the sense targeted by §25(1); residual interpretive nuance is disclosed above and does not involve any identifier.
---
### Criterion 3: §25(2) exemptions — not needed, but noted
**Requirement:** If §25(1) were triggered, consent-free operation would require the "strictly necessary" exemption (§25(2) Nr. 2), which the DSK does not extend to analytics.
| Aspect | Sealmetrics Position |
|--------|---------------------|
| Does Sealmetrics rely on §25(2)? | ✅ No — §25(1) is not triggered in the first place |
| Would analytics qualify as "strictly necessary"? | Per DSK guidance, generally no — which is why cookie-based analytics tools need banners in Germany and Sealmetrics does not |
This is the structural difference from consent-managed tools: Sealmetrics does not need an exemption because it performs neither of the acts §25(1) regulates.
---
## Part 2: The GDPR Layer (Visitor Data)
§25 TDDDG governs the terminal equipment; the GDPR governs any subsequent processing of personal data. The DSK's two-step model requires both to be assessed.
### Criterion 4: No personal data stored about visitors
| Aspect | Compliance |
|--------|------------|
| IP addresses | ✅ Never stored — used ephemerally in memory for anti-bot protection only |
| User IDs / cross-session identifiers | ✅ None exist |
| Device fingerprints | ✅ Not created |
| Country detection | ✅ Derived from browser timezone, not IP geolocation |
| Session handling | ✅ Server-side, short-lived (~2h), incapable of recognizing a returning visitor |
| Retention | ✅ 24 months for aggregated analytics data, then automatic deletion |
**Assessment:** ✅ Stored analytics records contain no data relating to an identified or identifiable natural person. Rights requests from visitors cannot be linked to any record — see [Data Subject Rights](/compliance/data-subject-rights).
### Criterion 5: Transient processing of the IP address
During request handling, the visitor's IP address is technically received (as with any web server) and used **in memory only** for rate limiting and abuse prevention, then discarded. To the extent this transient handling constitutes processing of personal data, it is supported by **Article 6(1)(f) GDPR** (legitimate interest in network and service security), satisfies data minimization (Article 5(1)(c)), and results in no stored personal data.
No other use of the IP occurs. A GeoLite2 lookup was designed for the **Agent Analytics** bot detector, but that feature is **not live and cannot be enabled on any account**, so it runs on no site today. See [What We Track](/security-privacy/what-we-track).
**Assessment:** ✅ Compliant — minimal, transient, security-purposed, never persisted.
### Criterion 6: Data location and transfers
| Aspect | Detail |
|--------|--------|
| Processing location | ✅ Dublin, Ireland (EU) |
| Transfers of analytics data outside the EU | ✅ None |
| US cloud storage of analytics data | ✅ None |
| Subprocessors | ✅ Visitor analytics data processed exclusively in the EU — see [Subprocessors](/compliance/subprocessors) |
German authorities have scrutinized US-linked analytics transfers intensively since *Schrems II*. Sealmetrics avoids the issue entirely: visitor analytics data is never transferred outside the EU.
---
## Part 3: DSK Orientierungshilfe Checklist
The DSK's guidance for telemedia providers frames the questions a German controller should ask. Summary against Sealmetrics:
| DSK question | Sealmetrics answer |
|--------------|-------------------|
| Is information stored on the terminal? | No |
| Is stored information accessed? | No (see nuance in Criterion 2) |
| Is consent under §25(1) required? | No — neither act occurs |
| Is personal data processed afterwards? | Only transiently (IP in memory); nothing personal is stored |
| Legal basis for that processing? | Art. 6(1)(f) GDPR (security); stored analytics are anonymous aggregates |
| Are users informed? | Yes — via the publisher's privacy policy (template below) |
| Joint controllership / third-party sharing? | No third-party data sharing; processor relationship under the [DPA](https://sealmetrics.com/dpa) |
---
## Part 4: Configuration Checklist for German Publishers
### Required ✅
- [ ] Standard tracking mode (default configuration)
- [ ] No custom user IDs enabling cross-session tracking
- [ ] No PII in custom event properties
- [ ] Privacy policy (Datenschutzerklärung) updated to mention Sealmetrics
**Recommended Privacy Policy Text (German):**
```
Diese Website verwendet Sealmetrics zur Reichweitenmessung. Sealmetrics
setzt keine Cookies, speichert keine Informationen auf Ihrem Endgerät
und greift nicht auf dort gespeicherte Informationen zu (§25 TDDDG wird
nicht berührt). Es werden keine personenbezogenen Daten gespeichert;
IP-Adressen werden nicht gespeichert. Die Daten werden ausschließlich
in der EU (Dublin, Irland) verarbeitet.
```
### Prohibited ❌
- [ ] Do NOT pass email addresses or other PII as properties
- [ ] Do NOT combine Sealmetrics data with advertising or profiling tools
- [ ] Do NOT implement custom device-storage workarounds around the tracker
---
## Part 5: Compliance Statement
Sealmetrics declares that:
1. Its standard configuration **stores no information on, and reads no stored information from, the end user's terminal equipment**, so the consent requirement of **§25(1) TDDDG is not triggered**
2. Stored visitor analytics data **contains no personal data and no identifiers**
3. All customer analytics data is processed **exclusively in the EU (Dublin, Ireland)** with no third-country transfers
4. Publishers using Sealmetrics in Germany can measure their audience **without a consent banner** for the analytics function, when configured per this document
Publishers **cannot** claim Sealmetrics is "certified" or "approved" by the DSK, the BfDI, or any Landesdatenschutzbehörde — no such certification exists.
---
## Part 6: Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.0 | February 2026 | Initial self-assessment against §25 TDDDG and DSK guidance |
---
## References
- [TDDDG (formerly TTDSG) — full text (gesetze-im-internet.de)](https://www.gesetze-im-internet.de/ttdsg/)
- [DSK — Orientierungshilfe für Anbieter von Telemedien](https://www.datenschutzkonferenz-online.de/orientierungshilfen.html)
- [Sealmetrics Privacy Policy](https://sealmetrics.com/privacy)
- [Sealmetrics DPA](https://sealmetrics.com/dpa)
## Contact
- **Email:** privacy@sealmetrics.com
- **DPO Contact:** dpo@sealmetrics.com
## Related documentation
- [CNIL Self-Assessment](/compliance/cnil-self-assessment) — the equivalent self-assessment for France
- [UK PECR Self-Assessment](/compliance/uk-pecr-self-assessment) — the equivalent self-assessment for the UK
- [Italy Garante Self-Assessment](/compliance/italy-garante-self-assessment) — the equivalent self-assessment for Italy
- [Switzerland FADP Self-Assessment](/compliance/switzerland-fadp-self-assessment) — the equivalent self-assessment for Switzerland
- [What We Track vs What We Don't](/security-privacy/what-we-track) — the full data inventory behind this assessment
## Data Intermediation Services: From Mandatory to Voluntary
URL: https://docs.sealmetrics.com/compliance/omnibus/data-intermediation
# Data Intermediation Services: From Mandatory to Voluntary
The EU Data Governance Act (DGA) created a framework for trusted data intermediation—platforms that facilitate data sharing between individuals, businesses, and researchers. But the mandatory registration regime proved too burdensome, with only 27 providers registering instead of the expected 100-150.
The Digital Omnibus transforms data intermediation from a mandatory compliance burden into a **voluntary trust label system**, removing barriers while maintaining quality standards. This change, combined with abolishing the separate legal entity requirement, could save €318,750 one-off and €6 million annually while encouraging market growth.
## What Are Data Intermediation Services?
### Definition
**Data intermediation service providers** act as neutral intermediaries facilitating data sharing between:
**Data holders** → **Data intermediary** → **Data users**
**Key characteristic**: Neutrality—the intermediary does not use the data for its own purposes.
### Types of Data Intermediation Services
#### 1. Data Marketplaces
**Function**: Platforms connecting data sellers and buyers
**Examples**:
- B2B data exchanges (industrial sensor data, logistics data)
- Personal data marketplaces (individuals sell their shopping/browsing data)
- Public sector data platforms
**Value**: Discovery, valuation, contracting, secure transfer
#### 2. Data Sharing Platforms
**Function**: Infrastructure enabling data sharing for specific purposes
**Examples**:
- Research data sharing (health research consortia)
- Supply chain data sharing (collaborative logistics)
- Smart city data platforms (municipal data for urban planning)
**Value**: Technical interoperability, governance, access control
#### 3. Data Cooperatives
**Function**: Member-owned organizations pooling and sharing data on behalf of members
**Examples**:
- Agricultural cooperatives (farmers share equipment/weather data)
- Consumer data cooperatives (pooled shopping data for collective benefit)
- Professional data cooperatives (freelancers share skills/availability data)
**Value**: Collective bargaining power, shared benefits, democratic governance
#### 4. Personal Data Intermediaries
**Function**: Services helping individuals exercise data portability rights
**Examples**:
- Personal data stores (individuals aggregate data from multiple sources)
- Data portability platforms (move data between services)
- Consent management platforms (centralized consent control)
**Value**: User control, simplified data management, privacy enhancement
## The Current DGA Framework (Pre-Omnibus)
### Mandatory Notification/Registration
**DGA Chapter III (Articles 9-15)** establishes:
**Notification requirement**:
- Data intermediation providers must notify competent authority
- Notification before commencing services
- Detailed information about activities, safeguards, governance
**Registration**:
- Competent authority registers compliant providers
- National registers published
- Union-level register maintained by Commission
**Compliance obligations**:
- Neutrality (cannot use data for own purposes)
- Separate legal entity requirement
- Transparency reports
- Monitoring and auditing
- Compliance with cybersecurity standards
### Why It Hasn't Worked
#### Only 27 Registered Providers
**Expected**: 100-150 providers by 2024
**Actual**: 27 providers as of late 2025
**Gap**: 73-123 fewer providers than projected
**Why the shortfall?**
#### 1. Separate Legal Entity Requirement
**DGA Article 12(1)**: Data intermediaries must be established as separate legal entities "for the sole purpose of providing data intermediation services."
**Cost**: Estimated **€318,750 one-off** to establish separate entity
- Legal incorporation
- Corporate structure
- Governance setup
- Accounting systems
- Tax registration
- Offices and personnel
**Problem**: Prohibitive for startups and existing businesses wanting to add data intermediation to service portfolio
**Example**: A cloud provider wanting to offer data marketplace functionality must create entirely separate company, cannot integrate with existing business
#### 2. Continuous Monitoring Obligations
**DGA Article 12(m)**: Implement procedures for monitoring compliance
**Cost**: Estimated **€6 million annually** across the sector
- Internal compliance officers
- External audits
- Documentation and reporting
- Technical monitoring systems
- Regular reviews and updates
**Problem**: Heavy ongoing burden relative to business size; discourages market entry
#### 3. Mandatory Notification Creates Barrier
**Psychological barrier**: Notification feels like asking permission (even though it's not authorization)
**Administrative burden**: Preparing notification, collecting required documentation, responding to competent authority queries
**Uncertainty**: Unclear whether specific business model qualifies; risk of notification rejection
**Delay**: Time from notification to registration delays market entry
#### 4. Rulebook Requirement for Data Altruism
**DGA Article 21**: Recognized data altruism organizations must have publicly available rulebook
**Content**: Purpose, data use, safeguards, governance
**Problem**: For voluntary, public-interest activity, requiring formal rulebook is disproportionate
**Impact**: Deters organizations from offering data altruism frameworks
## Changes in the Digital Omnibus
### 1. Notification Becomes Voluntary
**Key change**: Notification shifts from **mandatory** to **voluntary**
**How it works**:
**Mandatory regime (current DGA)**:
- Must notify to operate
- Cannot offer services without registration
- Enforcement for non-compliance
**Voluntary regime (Digital Omnibus)**:
- Can operate without notification
- Notification earns "trusted intermediary" label
- Market choice whether to certify
**Trust label system**:
- Providers meeting DGA standards can notify
- Receive official recognition
- Use "EU Trusted Data Intermediary" designation (or similar)
- Listed in public registers
- Marketing advantage from trust label
**Benefits**:
**For startups and small providers**:
- Can test business models without notification
- Enter market faster
- Scale up, then notify if desired
- No upfront compliance costs for experimentation
**For established providers**:
- Choice to differentiate via trust label
- Can operate without label if preferred (lower costs)
- Market decides value of certification
**For data users/holders**:
- Can choose certified intermediaries for higher trust
- Or use uncertified for lower cost/more flexibility
- Market competition on trust vs. price
### 2. Separate Legal Entity Requirement Removed
**DGA Article 12(1)** removed; replaced with **functional separation** requirement
**Functional separation means**:
- Data intermediation services must be operationally separate within organization
- Cannot use data accessed via intermediation for other business purposes
- Technical and organizational safeguards for separation
- Audit trails and access controls
- But NOT a separate legal entity
**Savings**: **€318,750 one-off** per provider avoiding separate entity setup
**Impact**:
**Cloud providers** can offer data marketplace functionality:
- Functional separation: Intermediation data isolated
- Technical measures: Access controls, encryption, logging
- Governance: Internal walls between teams
- But: Single legal entity, integrated billing, shared infrastructure
**Existing platforms** can add data sharing features:
- E-commerce platform adds supplier data sharing
- IoT platform adds sensor data marketplace
- SaaS provider adds customer data portability tools
- Without spinning off separate company
**Example**:
**Before (separate entity required)**:
- Company X operates cloud storage
- Wants to offer B2B data marketplace
- Must create Company Y (separate entity)
- Company Y operates marketplace
- Company X and Y have formal separation
- Result: €318,750 setup cost, duplicate infrastructure
**After (functional separation sufficient)**:
- Company X operates cloud storage
- Adds data marketplace service (same entity)
- Implements functional separation (access controls, governance)
- Result: No separate entity cost, integrated services, still compliant
### 3. Simplified Monitoring
**Continuous monitoring obligation reduced**
**Lighter regime**:
- Risk-based supervision instead of continuous monitoring
- Self-assessment with spot checks
- Periodic reviews instead of constant auditing
- Proportionate documentation
**Savings**: **€6 million annually** across sector
**Impact**: Lower ongoing compliance costs make market entry viable for more providers
### 4. Union-Level Registers Only
**National registers**: Eliminated (multiple Member State registers created confusion)
**Union register**: Single EU-wide register maintained by Commission
**Benefits**:
- One place to find all EU trusted intermediaries
- No need to check 27 national registers
- Clearer for cross-border services
- Less administrative burden
### 5. Data Altruism Simplifications
**Rulebook requirement**: **Deleted**
**National policy reporting**: **Deleted**
**Simplified registration**:
- Lighter application process
- Fewer ongoing obligations
- Focus on genuine public interest purposes
**Impact**: Encourages voluntary data sharing for research, statistics, public good
## Expected Impact
### Market Growth
**Projected**: Up to **36 new providers** entering market post-Omnibus
**Reasoning**:
- Voluntary regime removes entry barrier
- Functional separation cuts €318,750 cost
- Lighter monitoring reduces ongoing burden
- Trust label provides marketing benefit without mandatory compliance
**From 27 providers → 60-65+ providers**: More competitive, innovative data sharing ecosystem
### New Business Models
**Enabled by functional separation**:
**Integrated data platforms**:
- Cloud + data marketplace
- IoT + sensor data sharing
- SaaS + customer data portability
- Single integrated offering
**Freemium models**:
- Basic intermediation without certification (free)
- Premium certified service with trust label (paid)
- Market segmentation by trust needs
**Niche intermediaries**:
- Sector-specific (health data, agricultural data, mobility data)
- Geography-specific (local/regional data cooperatives)
- Purpose-specific (research data sharing only)
**Innovation**:
- Experimental models can launch without notification
- Successful models can upgrade to trusted status
- Failure fast without heavy compliance sunk costs
### More Data Sharing
**For research**:
- More data altruism organizations
- Easier access to shared datasets
- Better support for data-driven research
- Public interest benefits
**For SMEs**:
- Access to data marketplaces for insights
- Share data with partners via trusted platforms
- Participate in data cooperatives
- Compete with data-rich incumbents
**For individuals**:
- More personal data intermediaries
- Better control over data
- Monetization opportunities (if desired)
- Exercise portability rights more easily
## Comparison: Before and After
| Aspect | Current DGA | Digital Omnibus |
|--------|-------------|-----------------|
| **Notification** | Mandatory | Voluntary (trust label) |
| **Separate entity** | Required | Not required (functional separation) |
| **Setup cost** | €318,750 | Reduced or eliminated |
| **Monitoring** | Continuous (€6M/year) | Risk-based (lower cost) |
| **Registers** | National + Union | Union only |
| **Data altruism rulebook** | Required | Not required |
| **Market entry** | High barrier | Low barrier |
| **Number of providers** | 27 (underwhelming) | 60-65+ (projected) |
| **Market model** | Mandatory compliance | Voluntary certification |
## Who Benefits?
### Startups and Innovators
**Before**: Cannot afford €318,750 + €6M/year ongoing costs
**After**: Launch with functional separation, notify later if desired
**Result**: More innovation, experimentation, competition
### Established Businesses
**Before**: Must create separate entity to add data intermediation to service portfolio
**After**: Integrate within existing business with functional separation
**Result**: More comprehensive service offerings, better customer value
### SMEs as Data Intermediary Users
**Before**: Limited choice (27 providers), high costs passed to users
**After**: More providers (60+), competitive pricing, diverse options
**Result**: Better access to data sharing infrastructure
**Extended benefits**: SMCs also get simplified compliance (see [SME and Small Mid-Cap Exemptions](./smes-small-midcaps.md))
### Data Holders and Users
**Before**: Limited trusted intermediaries, mandatory regime creates supply constraint
**After**: More options, trust label differentiates quality, competitive market
**Result**: Better services, lower costs, more trust options
### Society and Public Interest
**Data altruism growth**:
- More organizations offering voluntary data sharing
- Better research data availability
- Public interest projects (health research, climate science, urban planning)
**Data cooperatives**:
- Empower individuals and small businesses
- Collective bargaining for data
- Democratic data governance
## Practical Guidance
### For Aspiring Data Intermediaries
**Step 1: Determine if you qualify**
You're a data intermediary if you:
- Facilitate data sharing between data holders and users
- Act neutrally (don't use data for your own purposes)
- Provide technical, legal, or commercial intermediation
You're NOT a data intermediary if you:
- Process data as a controller (use for your own purposes)
- Simply provide infrastructure (cloud storage without intermediation)
- Operate outside the EU
**Step 2: Choose your path**
**Option A: Operate without notification**
- Pros: No compliance costs, faster launch, test business model
- Cons: No trust label, cannot market as "EU trusted intermediary"
- Best for: Startups, experimental models, low-trust-requirement markets
**Option B: Notify and get trust label**
- Pros: Marketing advantage, listed in EU register, customer trust
- Cons: Compliance obligations, monitoring, transparency reporting
- Best for: Established providers, high-trust markets (health, financial data)
**Step 3: Implement functional separation**
Even without notification, best practice:
- Separate intermediation data from other business data
- Access controls and encryption
- Internal policies prohibiting data use for own purposes
- Audit logging
- Staff training
**Step 4: Consider notification later**
Start without notification → Grow → Notify when business case justifies:
- Customer demand for trust label
- Competitive differentiation
- Regulatory comfort
- Market maturity
### For Organizations Using Data Intermediaries
**Evaluate trust needs**:
**High-trust scenarios** (health data, financial data, sensitive research):
- Prioritize EU trusted intermediaries (notified, in register)
- Verify compliance with DGA standards
- Check transparency reports and audits
**Lower-trust scenarios** (non-sensitive B2B data, public data):
- Consider uncertified intermediaries (lower cost)
- Assess functional separation measures
- Contractual safeguards
**Due diligence**:
- Does intermediary have conflicts of interest?
- What are their data use policies?
- What technical safeguards are in place?
- What's their incident response capability?
- Check EU register if trust label claimed
### For Data Altruism Organizations
**Simplified requirements**:
- No rulebook needed (though transparency about purposes still valuable)
- Lighter registration process
- Focus on genuine public interest
**Steps**:
1. Define public interest purpose (research, statistics, public good)
2. Establish transparent data use policies
3. Implement safeguards for donated data
4. Register with competent authority (simplified process)
5. Use European data altruism consent form
6. Report on use of data (lighter requirements)
**Examples**:
- Health data altruism for medical research
- Mobility data for traffic planning
- Energy data for sustainability research
- Educational data for pedagogy improvement
## Transition Provisions
### Existing DGA Registrations
**Automatically transferred** to Digital Omnibus regime:
- No need to re-register
- Existing registrations remain valid
- Can continue operating under same terms
**Can opt into new regime**:
- Remove separate legal entity (restructure into parent company with functional separation)
- Benefit from simplified monitoring
- Lighter ongoing obligations
### Grace Period Expected
**Likely**: 6-12 month transition after Data Act consolidation takes effect
**During transition**:
- Existing providers adapt to new requirements
- New providers can enter under new regime
- Competent authorities update processes
## Risks and Safeguards
### Risk: Loss of Trust Without Mandatory Regime
**Concern**: Voluntary notification means uncertified intermediaries operate
**Mitigation**:
- Trust label creates two-tier market (certified vs. uncertified)
- High-value/sensitive data sharing gravitates to certified intermediaries
- Market disciplines uncertified providers (reputational risk)
- Functional separation still required (baseline safeguard)
### Risk: Race to the Bottom
**Concern**: Providers avoid notification to cut costs; market fails
**Mitigation**:
- Data holders and users demand trust label for valuable data
- Regulatory enforcement on functional separation (even for uncertified)
- GDPR, NIS2, and other regulations provide baseline safeguards
- Market will support both certified and uncertified segments
### Safeguards Maintained
Even under voluntary regime:
**Neutrality requirement**: Cannot use intermediated data for own purposes (enforced via functional separation)
**Transparency**: Certified intermediaries must publish transparency reports
**Security**: Cybersecurity standards apply (NIS2, GDPR security)
**Data subject rights**: GDPR rights enforceable regardless of certification
**Competent authority oversight**: Supervision of certified intermediaries continues
## Related Resources
- [Data Law Consolidation](./data-consolidation.md) - How DGA merges into Data Act
- [SME and Small Mid-Cap Exemptions](./smes-small-midcaps.md) - Additional relief for SMC intermediaries
- [Timeline and Implementation](./timeline-implementation.md) - When changes take effect
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [EDPB-EDPS Joint Opinion on the Digital Omnibus](./edpb-edps-opinion.md) - Regulators' position on intermediation oversight
## Key Takeaways
1. **Notification shifts from mandatory to voluntary** (trust label system)
2. **Separate legal entity requirement removed** (functional separation sufficient)
3. **€318,750 one-off savings** per provider from entity requirement removal
4. **€6 million annual savings** across sector from lighter monitoring
5. **Expected 36+ new providers** entering market post-Omnibus
6. **From 27 to 60-65+ providers** creates competitive market
7. **Trust label differentiates** certified intermediaries from uncertified
8. **Data altruism simplified** (no rulebook, lighter registration)
9. **Union-level register only** (national registers eliminated)
10. **Startups can test models** without notification, certify later if desired
The transformation of data intermediation from mandatory compliance to voluntary certification represents a sophisticated regulatory evolution. Instead of forcing all providers through the same heavy regime (which failed—only 27 registered), the Omnibus creates a light baseline (functional separation) with optional certification for those seeking trust differentiation. This approach should unlock the data sharing market's potential while maintaining safeguards for high-trust scenarios. The result: more providers, more innovation, more data sharing, and more economic value—exactly what the Data Governance Act aimed for, but this time with a framework that actually works.
## Italy Garante Self-Assessment: Sealmetrics Compliance
URL: https://docs.sealmetrics.com/compliance/italy-garante-self-assessment
# Italy Garante Self-Assessment: Sealmetrics
This document provides the self-assessment of Sealmetrics against the requirements of the Italian data protection authority (**Garante per la protezione dei dati personali**) for consent-free audience measurement, based on the Garante's **"Linee guida sui cookie e altri strumenti di tracciamento"** (Guidelines on cookies and other tracking tools, adopted 10 June 2021) and **Article 122 of the Italian Privacy Code** (d.lgs. 196/2003, as amended), Italy's transposition of Article 5(3) of the ePrivacy Directive.
**Info:**
This self-assessment follows the Garante's published guidelines but **does not constitute certification or approval by the Garante**. No such certification scheme for analytics tools exists in Italy. This document demonstrates how Sealmetrics meets the published requirements when properly configured.
---
## Executive Summary
| Category | Status |
|----------|--------|
| **Art. 122 Privacy Code — storage/access on terminal equipment** | ✅ Not triggered — no cookies, no terminal storage |
| **Garante 2021 guidelines — analytics conditions** | ✅ Met (and exceeded — no cookie is used at all) |
| **No US transfers (post-GA decisions of 2022)** | ✅ EU-only processing (Dublin, Ireland) |
| **Consent banner required for analytics** | ✅ No |
| **Last Assessment Date** | February 2026 |
---
## Background: The Italian Framework
The Italian regime for analytics rests on three pillars:
1. **Article 122 of the Privacy Code** requires consent for storing information on, or accessing information already stored in, a user's terminal equipment, unless strictly necessary for the requested service (the Italian equivalent of §25 TDDDG in Germany or PECR Regulation 6 in the UK).
2. **The Garante's June 2021 cookie guidelines** distinguish technical cookies (no consent), profiling cookies (consent required), and **analytics cookies, which may be assimilated to technical cookies** — i.e., used without consent — only under specific minimization conditions.
3. **The Garante's 2022 Google Analytics decisions** (starting with the ruling against Caffeina Media of 9 June 2022) found that using Google Analytics involved unlawful transfers of personal data to the United States, effectively putting US-hosted analytics implementations out of compliance in Italy.
Sealmetrics addresses all three pillars structurally: it uses no cookies or terminal storage at all, produces only aggregate statistics without identifiers, and processes all data exclusively in the EU.
---
## Part 1: Article 122 — Terminal Equipment
### Criterion 1: No storage of information on the terminal
| Aspect | Sealmetrics Compliance |
|--------|----------------------|
| Cookies (technical, analytics, or profiling) | ✅ None set |
| localStorage / sessionStorage | ✅ Not used |
| Other terminal storage (IndexedDB, cache tricks) | ✅ Not used |
**Evidence:** The tracker writes nothing to the browser. Session continuity (~2-hour window) is handled server-side. Verifiable in browser DevTools on any page running Sealmetrics.
### Criterion 2: No access to stored information / no fingerprinting
The 2021 guidelines explicitly extend to "other tracking tools", including **fingerprinting** as a cookie substitute — so-called "passive identifiers".
| Aspect | Sealmetrics Compliance |
|--------|----------------------|
| Reading stored terminal information | ✅ Not performed |
| Device fingerprinting | ✅ Not performed — no combination of parameters is used to identify or re-identify a device |
| Cross-session recognition of any kind | ✅ Impossible by design — no persistent identifier exists |
**Assessment:** ✅ Article 122 consent obligations are not triggered: neither prohibited act occurs, and no fingerprinting substitute is used.
---
## Part 2: The Garante's Analytics Conditions (2021 Guidelines)
The guidelines allow analytics cookies to be treated like technical cookies (consent-free) only under minimization conditions. Sealmetrics does not use analytics cookies at all — but for completeness, here is the assessment against each condition, since the conditions express the Garante's substantive expectations for any audience-measurement tool.
### Criterion 3: Aggregate statistics only
**Requirement:** Analytics must be used only to produce aggregate statistics.
| Aspect | Compliance |
|--------|------------|
| Reports show aggregated data only | ✅ Yes |
| No individual user journeys across sessions | ✅ Not possible — no cross-session identifier |
| No unique-visitor or user-level metrics | ✅ Deliberately excluded (no unique visitors, no session duration) |
### Criterion 4: Minimized identifying power (IP masking)
**Requirement:** For analytics cookies, the identifying power must be minimized — e.g., masking significant portions of the IP address.
| Aspect | Compliance |
|--------|------------|
| IP masking | ✅ Exceeded — the IP is **never stored in the analytics database** (transient server-side use for anti-bot protection) |
| Geolocation method | ✅ Country from browser timezone, not IP; country-level only, no city/region |
| Identifiers in stored data | ✅ None — no user ID, device ID, or fingerprint |
**Note:** the Garante's masking condition presupposes a tool that stores IP-derived data. Sealmetrics goes beyond the condition: there is nothing to mask because no IP or IP-derived identifier is persisted in the analytics database.
### Criterion 5: No combination with other processing (no cross-referencing / enrichment)
**Requirement:** Analytics data must not be combined with other data or cross-referenced with other processing operations.
| Aspect | Compliance |
|--------|------------|
| Cross-referencing with CRM or advertising data | ✅ Not possible — no user-level key exists to join on |
| Data enrichment from third parties | ✅ None |
| Cross-site combination by the provider | ✅ None — each account's data is isolated |
### Criterion 6: No transmission to third parties
**Requirement:** Analytics data must not be disclosed to third parties.
| Aspect | Compliance |
|--------|------------|
| Data sales or sharing | ✅ Never — contractually excluded by the [DPA](https://sealmetrics.com/dpa) |
| Advertising network integrations | ✅ None exist in the product |
| Provider reuse of client data | ✅ Prohibited by the [Terms of Service](https://sealmetrics.com/terms) |
### Criterion 7: Per-publisher independence
**Requirement:** Where one provider serves multiple publishers, measurement must remain independent per publisher (no unified cross-site view).
| Aspect | Compliance |
|--------|------------|
| Account isolation | ✅ Each customer's dataset is fully isolated |
| Shared identifiers across sites | ✅ None — no identifiers exist at all |
| Cross-account analysis | ✅ Not performed |
---
## Part 3: International Transfers — the Google Analytics Precedent
### Criterion 8: No transfers to the United States or other third countries
In June 2022 the Garante ruled (Caffeina Media decision, and subsequent cases) that Google Analytics transferred personal data — including IP addresses and browser identifiers — to the US without adequate safeguards, in breach of Chapter V GDPR.
| Aspect | Sealmetrics Compliance |
|--------|----------------------|
| Data processing location | ✅ Dublin, Ireland (EU) exclusively |
| Transfers of analytics data outside the EU | ✅ None — no SCCs or adequacy mechanisms needed because no transfer occurs |
| US-hosted subprocessing of analytics data | ✅ None — see [Subprocessors](/compliance/subprocessors) |
| Data that could be transferred | ✅ Even hypothetically minimal — stored records contain no personal identifiers |
**Assessment:** ✅ The transfer problem that ended Google Analytics' compliant use in Italy does not arise for Sealmetrics.
---
## Part 4: Transparency Obligations
### Criterion 9: User information
**Requirement:** Users must be informed about the processing (Art. 13 GDPR; the guidelines require clear cookie/privacy notices).
| Aspect | Compliance |
|--------|------------|
| Privacy policy template provided | ✅ Yes (below) |
| Cookie banner required for Sealmetrics | ✅ No — no cookies or trackers requiring consent are used |
| Cookie policy entry | ✅ Sealmetrics can be truthfully listed as "no cookies used" |
**Recommended Privacy Policy Text (Italian):**
```
Questo sito utilizza Sealmetrics per la misurazione del traffico.
Sealmetrics non utilizza cookie né altri strumenti di tracciamento,
non memorizza informazioni sul dispositivo dell'utente e non raccoglie
dati personali: gli indirizzi IP non vengono conservati e non esistono
identificatori individuali. I dati, in forma aggregata e anonima, sono
trattati esclusivamente nell'Unione Europea (Dublino, Irlanda).
```
---
## Part 5: Configuration Checklist for Italian Publishers
### Required ✅
- [ ] Standard tracking mode (default configuration)
- [ ] No custom user IDs enabling cross-session tracking
- [ ] No PII in custom event properties
- [ ] Privacy policy (informativa) updated to mention Sealmetrics
### Prohibited ❌
- [ ] Do NOT pass email addresses or other PII as properties
- [ ] Do NOT combine Sealmetrics data with profiling or advertising tools and claim the analytics treatment
- [ ] Do NOT export data for individual-level analysis
---
## Part 6: Compliance Statement
Sealmetrics declares that:
1. Its standard configuration **uses no cookies and no other tracking tools** within the meaning of Article 122 of the Privacy Code and the Garante's 2021 guidelines, so **no consent banner is required** for the analytics function
2. It satisfies — and structurally exceeds — the Garante's minimization conditions for consent-free analytics (aggregate statistics, no stored IP, no cross-referencing, no third-party disclosure, per-publisher independence)
3. All customer analytics data is processed **exclusively in the EU (Dublin, Ireland)**, avoiding the third-country transfer issues identified in the Garante's 2022 analytics decisions
Publishers **cannot** claim Sealmetrics is "certified" or "approved" by the Garante — no such certification exists.
---
## Part 7: Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.0 | February 2026 | Initial self-assessment against the Garante's 2021 guidelines and Art. 122 Privacy Code |
---
## References
- [Garante — Linee guida sui cookie e altri strumenti di tracciamento (10 June 2021)](https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9677876)
- [Garante — Google Analytics decision (9 June 2022, doc. web 9782890)](https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9782890)
- [Codice Privacy (d.lgs. 196/2003), Art. 122](https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2003-06-30;196)
- [Sealmetrics Privacy Policy](https://sealmetrics.com/privacy)
- [Sealmetrics DPA](https://sealmetrics.com/dpa)
## Contact
- **Email:** privacy@sealmetrics.com
- **DPO Contact:** dpo@sealmetrics.com
## Related documentation
- [CNIL Self-Assessment](/compliance/cnil-self-assessment) — the equivalent self-assessment for France
- [Germany TDDDG Self-Assessment](/compliance/germany-ttdsg-self-assessment) — the equivalent self-assessment for Germany
- [Switzerland FADP Self-Assessment](/compliance/switzerland-fadp-self-assessment) — the equivalent self-assessment for Switzerland
- [Subprocessors](/compliance/subprocessors) — visitor analytics data processed exclusively in the EU
- [What We Track vs What We Don't](/security-privacy/what-we-track) — the full data inventory behind this assessment
## AI Act Amendments in the Digital Omnibus
URL: https://docs.sealmetrics.com/compliance/omnibus/ai-act-amendments
# AI Act Amendments in the Digital Omnibus
The EU Digital Omnibus addresses the intersection of AI development and data protection through a new GDPR provision—Article 88c—that provides a clear legal basis for processing personal data in AI system development. This change, combined with special category data safeguards, aims to enable European AI innovation while maintaining strong privacy protections.
## Context: Two Parallel AI Proposals
### Digital Omnibus (COM(2025) 837)
**This proposal** includes:
- GDPR-AI intersection provisions
- New Article 88c (AI processing legitimate interest)
- New Article 9(2)(k) (special categories exception for AI)
- Data protection framework for AI development
**Focus**: How GDPR applies to AI training and operation
### AI Omnibus (COM(2025) 836)
**Separate proposal** published same day includes:
- AI Act simplifications
- SME/SMC exemptions for AI compliance
- Conformity assessment streamlining
- High-risk classification clarifications
**Focus**: AI Act compliance burden reduction
**Relationship**: Both proposals work together for coherent GDPR-AI Act framework; this page focuses on GDPR amendments in Digital Omnibus.
## New Article 88c: Legitimate Interest for AI
**Note:**
The [Joint Opinion 2/2026](./edpb-edps-opinion.md) accepts the legitimate interest basis for AI development but requests stronger safeguards. Key concerns include large-scale web scraping, meaningful right to object implementation, and explicit stronger protections for children's data. The final text may include additional conditions.
### The Legal Basis Problem
**Before Article 88c**:
AI developers faced uncertainty about lawful basis for processing personal data in training and operation:
**Article 6(1)(a) Consent**:
- Impractical for large training datasets (billions of data points)
- Cannot obtain consent from all individuals in web-scraped data
- Consent withdrawal would require model retraining
**Article 6(1)(b) Contract**:
- Not applicable (no contractual relationship with training data subjects)
**Article 6(1)(f) Legitimate interest**:
- Unclear if AI development qualified
- Balance test uncertain
- Regulatory guidance lacking
- Risk of enforcement action
**Result**: Legal uncertainty deterred European AI investment; developers moved to jurisdictions with clearer rules.
### Article 88c: Clear Legal Basis
**New GDPR provision** (full text):
> "Where the processing of personal data is necessary for the interests of the controller in the context of the development and operation of an AI system as defined in Article 3, point (1), of Regulation (EU) 2024/1689 or an AI model, such processing may be pursued for legitimate interests within the meaning of Article 6(1)(f) of Regulation (EU) 2016/679, where appropriate, except where other Union or national laws explicitly require consent, and where such interests are overridden by the interests, or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child."
**Key components**:
1. **AI system/model development and operation** = legitimate interest
2. **Under Article 6(1)(f)** (not a new legal basis, but explicit recognition)
3. **Balance test still applies** (interests vs. rights)
4. **Exception: Laws requiring consent** (e.g., DMA for gatekeepers)
5. **Special protection for children**
### What Article 88c Covers
**Training AI models**:
- Collecting training data from various sources
- Preprocessing and cleaning datasets
- Training machine learning models
- Validation and testing
**Operating AI systems**:
- Processing inputs through trained models
- Generating outputs and predictions
- Monitoring and improving model performance
- Fine-tuning and updating models
**AI model development**:
- Developing foundation models
- Creating domain-specific models
- Transfer learning and adaptation
- Model evaluation and benchmarking
**Research and development**:
- Experimental AI techniques
- Novel architectures and algorithms
- Safety and alignment research
### What Article 88c Does NOT Override
**Laws explicitly requiring consent**:
**Digital Markets Act (DMA) Article 5(2)**:
- Gatekeepers must obtain consent for combining personal data across core platform services
- Article 88c does NOT exempt gatekeepers from this
- DMA explicitly requires consent → Article 88c exception applies
**Other consent-specific requirements**:
- Sector-specific laws mandating consent
- National laws requiring consent for specific processing
**Fundamental rights balancing**:
- Balance test under Article 6(1)(f) still required
- Rights may override legitimate interest
- No blanket authorization
**Children's data**:
- "In particular where the data subject is a child"
- Higher bar for legitimate interest when children's data involved
- Special safeguards required
## Special Categories of Data (Article 9)
### The Challenge
**Article 9 GDPR**: Special categories (race, ethnicity, health, biometric, genetic, political opinions, religious beliefs, sexual orientation, trade union membership) generally prohibited unless exception applies.
**AI training problem**:
- Web-scraped data may contain special category information
- Image datasets may include faces (biometric data)
- Text may reveal health conditions or political opinions
- Impossible to guarantee 100% exclusion from large datasets
**Before**: Uncertainty whether AI training violated Article 9 if special category data residually processed despite filtering efforts.
### New Article 9(2)(k): Exception for AI
**New exception** added to Article 9(2):
Processing of special categories is permitted if:
1. **Processing is for AI development** (under Article 88c)
2. **Technical measures implemented** to avoid collecting special categories
3. **Data minimization** during source selection, training, testing
4. **Special category data removed or protected** if identified despite safeguards
5. **Only residual processing** (not intentional targeting)
**Key principle**: If you tried to exclude special categories and implemented appropriate measures, residual processing doesn't violate Article 9.
### Required Technical Measures
**During data source selection**:
- Filter datasets for special category indicators
- Exclude sources known to contain sensitive data
- Implement automated screening
- Manual review where feasible
**During training and testing**:
- Data minimization techniques
- Anonymization and pseudonymization
- Differential privacy
- Federated learning (where appropriate)
**If special category data identified**:
- Remove from training set
- Protect through encryption or other safeguards
- Document remediation measures
- Update filtering for future iterations
**Protection against disclosure**:
- Ensure special category data not revealed in model outputs
- Test for memorization and leakage
- Implement output filtering
- Monitor for unintended disclosures
### What This Means in Practice
**Permitted**:
- Training image recognition model on web photos that may include faces (biometric)
- **If**: Implemented filtering, removed identified faces where possible, model doesn't output special category data
- Training language model on internet text that may mention health
- **If**: Filtered medical records and health forums, minimized health data, protected residual mentions
**Still prohibited**:
- Intentionally collecting special category data for AI training without Article 9 exception
- Training model specifically on health data without legal basis (research exception, consent, etc.)
- Deliberately targeting special categories without safeguards
**Best practice**:
- Document filtering and minimization efforts
- Maintain audit trails
- Regular testing for special category leakage
- Update safeguards as techniques improve
## Required Safeguards Under Article 88c
Beyond special category measures, Article 88c mandates:
### 1. Appropriate Technical and Organizational Measures
**Technical measures**:
- Data minimization at source selection stage
- Anonymization and pseudonymization
- Encryption and access controls
- Output filtering and monitoring
- Privacy-enhancing technologies (differential privacy, federated learning, secure computation)
**Organizational measures**:
- AI governance frameworks
- Data protection by design and default
- Staff training on privacy-preserving AI
- Vendor management for third-party data
- Regular audits and reviews
### 2. Respect for Data Minimization
**During source selection**:
- Collect only necessary data for AI purpose
- Prefer synthetic data where feasible
- Filter unnecessary personal information
- Limit scope of data collection
**During training/testing**:
- Use only required data points
- Remove or aggregate where possible
- Implement federated or distributed learning
- Avoid overtraining on personal data
### 3. Protection Against Disclosure
**Model outputs**:
- Must not disclose personal data from training set
- Test for memorization (can model reproduce training examples?)
- Implement output sanitization
- Monitor for data leakage
**Model sharing**:
- Ensure models don't encode personal data in parameters
- Model inversion and membership inference protections
- Secure model deployment
### 4. Enhanced Transparency
**To data subjects**:
- Inform about AI processing where feasible
- Explain purposes and logic (to extent possible without IP disclosure)
- Provide meaningful information about automated decision-making
- Accessible privacy policies
**Transparency obligations**:
- Article 13/14 information requirements apply
- Must explain AI training and operation
- Layered approach (summary + details)
**Limitations**:
- Disproportionate effort exemption may apply (amended Article 13)
- Trade secret protections balanced with transparency
### 5. Unconditional Right to Object
**Article 21 GDPR**: Data subjects have right to object to processing under Article 6(1)(f)
**For AI processing**:
- **Unconditional right to object** to processing of their data for AI purposes
- Controller must stop processing that individual's data
- Includes removal from training sets (to extent feasible)
- No requirement to prove "particular situation" (unlike normal Article 21(1))
**Practical challenges**:
- Identifying specific data subject's data in large training set
- Removing data from already-trained model (may require retraining)
- Balancing individual rights with model integrity
**Approaches**:
- Maintain source-to-model traceability
- Implement machine unlearning techniques
- Document deletion efforts
- Update future model versions
## Balance Test Still Applies
### Article 6(1)(f) Three-Part Test
Even with Article 88c, the standard legitimate interest assessment applies:
**1. Legitimate interest exists**:
- ✅ Article 88c explicitly recognizes AI development as legitimate interest
- Must still demonstrate specific interest (research, product development, service improvement)
**2. Processing is necessary**:
- Is there a less invasive alternative?
- Can you use synthetic data instead?
- Is anonymized data sufficient?
- Necessity test still required
**3. Balancing test**:
- Controller's interests vs. data subject's rights and freedoms
- Consider: nature of data, context of collection, reasonable expectations, impact on individuals
- Special consideration for children
**Result**: Not every AI processing automatically qualifies; balance test may still tip against processing in high-risk scenarios.
### When Balance May Favor Data Subjects
**High-risk scenarios**:
- AI systems making decisions with severe consequences (credit, employment, law enforcement)
- Large-scale processing of vulnerable populations
- Opaque or unexplainable AI
- Processing special categories at scale
- Children's data for commercial AI
**Safeguards to tip balance**:
- Enhanced transparency
- Stronger technical protections
- Human oversight
- Individual control mechanisms
- Impact assessments
## Coordination with AI Act
### AI Act Risk-Based Framework
**Regulation (EU) 2024/1689** classifies AI systems by risk:
**Prohibited AI**: Banned practices (social scoring, real-time biometric in public, etc.)
**High-risk AI**: Strict requirements (biometric identification, critical infrastructure, education, employment, law enforcement, migration, justice)
**Limited risk AI**: Transparency obligations (chatbots, deepfakes, emotion recognition)
**Minimal risk AI**: No specific requirements
### How Article 88c Interacts
**Article 88c provides GDPR legal basis** for data processing in AI development
**AI Act provides AI-specific requirements** (technical documentation, risk management, human oversight, accuracy, cybersecurity)
**Both must be satisfied**:
- Article 88c → Personal data processing lawful under GDPR
- AI Act → AI system complies with risk-appropriate requirements
- Different regulatory concerns, complementary frameworks
**Example: High-risk employment AI**
**GDPR (Article 88c)**:
- Legitimate interest for AI development
- Balance test (employment decisions impact = high)
- Safeguards: Transparency, data minimization, right to object
- Special categories protection
**AI Act**:
- High-risk classification (employment decisions)
- Requirements: Risk management, data governance, technical documentation, human oversight, accuracy, robustness, cybersecurity
- Conformity assessment
- Registration in EU database
**Both frameworks apply**: AI developer must satisfy GDPR Article 88c AND AI Act high-risk requirements.
## SME/SMC Extensions (via AI Omnibus)
### Extended Compliance Timelines
**AI Omnibus (COM(2025) 836)** proposes:
**For SMEs and SMCs developing AI**:
- Longer deadlines for high-risk AI compliance
- Phased implementation of requirements
- Grace periods for conformity assessment
**Benefit**: Small AI developers have time to build compliance infrastructure without cliff-edge obligations
### Simplified Documentation
**Reduced burden**:
- Lighter technical documentation for SME/SMC high-risk AI
- Proportionate record-keeping
- Simplified conformity assessment procedures
**Coordination**: Works with Article 88c to create viable path for European SME/SMC AI innovation
**Learn more**: [SME and Small Mid-Cap Exemptions](./smes-small-midcaps.md)
## Practical Guidance for AI Developers
### Step 1: Determine if Article 88c Applies
**Your processing qualifies if**:
- ✅ Developing or operating AI system/model
- ✅ Processing personal data as part of AI workflow
- ✅ No other law explicitly requires consent
**Your processing does NOT qualify if**:
- ❌ You're a DMA gatekeeper combining data across core platform services (consent required)
- ❌ Sector-specific law requires consent
- ❌ Not actually developing/operating AI (just using AI tools = different analysis)
### Step 2: Conduct Balance Test
**Document**:
- Your legitimate interest (research, product, service)
- Necessity of personal data processing
- Alternatives considered (synthetic data, anonymization)
- Data subject rights and freedoms impacted
- Safeguards implemented
**Higher bar if**:
- Children's data involved
- High-risk AI system
- Large-scale processing
- Special categories present
### Step 3: Implement Technical Safeguards
**Data minimization**:
- [ ] Filter training data sources
- [ ] Remove unnecessary personal information
- [ ] Prefer aggregated or synthetic data where feasible
- [ ] Document minimization efforts
**Special categories**:
- [ ] Implement automated filtering for special category indicators
- [ ] Remove identified special category data
- [ ] Protect residual data if cannot be fully removed
- [ ] Document measures and exceptions
**Output protection**:
- [ ] Test for memorization and data leakage
- [ ] Implement output filtering
- [ ] Monitor model behavior
- [ ] Regular security assessments
### Step 4: Transparency and Rights
**Information to data subjects**:
- [ ] Update privacy policy for AI processing
- [ ] Explain purposes and logic (Article 13/14)
- [ ] Provide meaningful information about AI
- [ ] Accessible and understandable language
**Right to object**:
- [ ] Implement mechanism to receive objections
- [ ] Process for removing individual's data from training sets
- [ ] Machine unlearning or model retraining procedures
- [ ] Document objection handling
### Step 5: Documentation and Accountability
**Maintain records**:
- Legitimate interest assessment
- Balance test documentation
- Technical safeguards implemented
- Data sources and processing
- Objections and responses
- Special category filtering efforts
**Regular reviews**:
- Update safeguards as technology improves
- Reassess balance test if processing changes
- Monitor regulatory guidance
- Adapt to best practices
## Comparison with Other Jurisdictions
### United States
**No federal AI data protection framework**:
- State laws (CCPA, CPRA, Virginia, Colorado, etc.) vary
- No explicit legitimate interest for AI
- Relies on consent or legitimate business purpose
**EU advantage**: Article 88c provides clear, harmonized legal basis for AI development across 27 Member States
### United Kingdom
**Post-Brexit**:
- Retained GDPR framework
- Considering AI-specific data processing provisions
- Likely to adopt similar approach for competitiveness
### China
**Personal Information Protection Law (PIPL)**:
- Requires consent for most processing (stricter than EU)
- Limited exceptions for AI development
- More restrictive than Article 88c
**EU balance**: Article 88c enables innovation while maintaining safeguards
## Future Developments
### EDPB Guidance Expected
**European Data Protection Board** will likely issue:
- Guidelines on Article 88c application
- Balance test factors for AI processing
- Technical safeguards best practices
- Special categories in AI training
- Right to object implementation
**Timeline**: 2027-2028 (after Omnibus adoption)
### AI Act Implementation
**Parallel implementation**:
- AI Act enforcement begins August 2026 (phased)
- Article 88c effective 6 months after Omnibus entry into force (≈Q1 2028)
- Coordinated guidance from Commission, EDPB, AI Office
### Evolving Technology
**Privacy-enhancing technologies**:
- Differential privacy improvements
- Federated learning maturity
- Synthetic data generation
- Machine unlearning techniques
**Standards development**:
- Technical standards for AI data minimization
- Conformity assessment procedures
- Best practices for safeguards
## Related Resources
- [GDPR Amendments](./gdpr-changes.md) - Complete list of GDPR changes including Article 88c
- [Timeline and Implementation](./timeline-implementation.md) - When Article 88c takes effect
- [SME and Small Mid-Cap Exemptions](./smes-small-midcaps.md) - AI Act SME/SMC extensions
- [EDPB-EDPS Joint Opinion](./edpb-edps-opinion.md) - Regulatory position on AI processing provisions
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [Legal FAQ — Sealmetrics Compliance Questions](/compliance/compliance-overview/legal-faq) - Whether Sealmetrics reuses data to train models (it does not)
- [What We Track vs What We Don’t](/security-privacy/what-we-track) - Why Sealmetrics collects no data usable for AI profiling
## Key Takeaways
1. **New Article 88c**: Explicit legitimate interest for AI development and operation
2. **Legal certainty**: Clear GDPR basis for processing personal data in AI training
3. **Balance test still applies**: Not blanket authorization; rights vs. interests
4. **Special categories exception**: Article 9(2)(k) permits residual processing if safeguards implemented
5. **Required safeguards**: Data minimization, output protection, transparency, right to object
6. **Unconditional right to object**: Data subjects can demand removal from AI training
7. **Exception for consent laws**: DMA gatekeepers still need consent
8. **Children's data**: Higher protection standard
9. **Coordination with AI Act**: Both GDPR and AI Act must be satisfied
10. **SME/SMC benefits**: Extended timelines and simplified compliance via AI Omnibus
Article 88c represents Europe's attempt to balance AI innovation with fundamental rights protection. By providing legal certainty through explicit recognition of AI development as a legitimate interest, while maintaining robust safeguards and the balance test, the provision aims to enable European AI competitiveness without sacrificing the GDPR's core protections. The success of this approach will depend on implementation: careful balance testing, effective safeguards, and meaningful enforcement of data subject rights. If executed well, Article 88c could position Europe as the global leader in trustworthy, rights-respecting AI development.
## Single Entry Point for Incident Reporting
URL: https://docs.sealmetrics.com/compliance/omnibus/incident-reporting
# Single Entry Point for Incident Reporting
The EU Digital Omnibus introduces a unified incident reporting system operated by ENISA (European Union Agency for Cybersecurity). This "report once, share many" approach eliminates duplicate submissions across multiple regulations and promises to save businesses millions in compliance costs while improving regulatory response.
## The Current Reporting Nightmare
### Multiple Overlapping Obligations
Organizations operating in the EU face a fragmented landscape of incident reporting requirements:
#### 1. NIS2 Directive (Cybersecurity Incidents)
**Regulation**: Directive (EU) 2022/2555
**Who reports**: Essential and important entities (telecom, energy, transport, healthcare, digital infrastructure, etc.)
**What to report**: Significant cybersecurity incidents
**Timeline**:
- Early warning: Within 24 hours
- Incident notification: Within 72 hours
- Final report: Within 1 month
**To whom**: National CSIRT or competent authority
#### 2. GDPR Article 33 (Data Breaches)
**Regulation**: GDPR (EU) 2016/679
**Who reports**: All data controllers
**What to report**: Personal data breaches posing risk to individuals
**Timeline**: Within 72 hours of becoming aware
**To whom**: Supervisory authority (Data Protection Authority)
**Additional**: Article 34 requires communication to data subjects if high risk
#### 3. DORA (Digital Operational Resilience)
**Regulation**: Regulation (EU) 2022/2554
**Who reports**: Financial entities (banks, insurers, investment firms, payment providers)
**What to report**: Major ICT-related incidents
**Timeline**:
- Initial notification: As soon as possible
- Intermediate reports: As investigation progresses
- Final report: Within specified timeframes
**To whom**: Financial supervisory authorities (EBA, EIOPA, ESMA)
#### 4. eIDAS (Trust Services)
**Regulation**: Regulation (EU) 910/2014
**Who reports**: Qualified trust service providers
**What to report**: Security breaches and incidents affecting trust services
**Timeline**: Within 24 hours
**To whom**: National supervisory body
#### 5. CER Directive (Critical Entities Resilience)
**Regulation**: Directive (EU) 2022/2557
**Who reports**: Critical entities in essential sectors
**What to report**: Incidents affecting critical services
**Timeline**: As defined by Member States
**To whom**: National competent authority
### The Complexity Problem
**For a financial institution operating digital services**:
- NIS2 incident to CSIRT (24-72 hours)
- GDPR breach to DPA (72 hours)
- DORA incident to financial supervisor (immediately)
- Potentially CER report if critical entity
**Result**:
- Four separate reports
- Different formats and platforms
- Different timelines
- Risk of inconsistencies
- Duplication of effort
- Compliance team overwhelmed
**For the business**:
- 4+ hours per incident preparing multiple reports
- Legal review for each submission
- Coordination across compliance, IT, legal teams
- Risk of missing deadlines or providing inconsistent information
**For regulators**:
- Fragmented information
- Difficulty coordinating response
- Duplication across authorities
- Incomplete picture of incident landscape
## The Solution: Single Entry Point
### "Report Once, Share Many"
The Digital Omnibus establishes a **unified incident reporting system** operated by ENISA.
**Core principle**: Organizations submit one report through one interface; ENISA distributes to all relevant authorities.
### How It Works
**Step 1: Single submission**
- Organization determines an incident is reportable under any regulation
- Logs into ENISA single entry point portal
- Completes unified report form
- Indicates which regulations apply (NIS2, GDPR, DORA, etc.)
**Step 2: Automatic routing**
- ENISA system validates submission
- Report is automatically routed to:
- National CSIRT (if NIS2)
- Data Protection Authority (if GDPR)
- Financial supervisor (if DORA)
- eIDAS supervisor (if trust service)
- Other relevant authorities
- Secure information sharing protocols ensure confidentiality
**Step 3: Authority access**
- Each authority receives relevant portions of report
- Authorities can access shared information as permitted
- Cross-authority coordination facilitated
- Single source of truth for incident details
**Step 4: Follow-up**
- Updates submitted through same portal
- All authorities automatically notified
- Final reports centralized
### What Organizations Report
**Single unified form** covering:
- Incident description and classification
- Affected systems and data
- Number of individuals affected (if data breach)
- Impact assessment
- Response and mitigation measures
- Timeline of events
- Technical details (as required)
**Smart form**: Only shows fields relevant to applicable regulations
- If GDPR breach: Data subject impact questions appear
- If NIS2 incident: Cybersecurity-specific fields appear
- If DORA: Financial resilience questions appear
### Operated by ENISA
**ENISA (European Union Agency for Cybersecurity)**:
- EU agency responsible for cybersecurity policy and implementation
- Expertise in incident management
- Existing infrastructure (EU CyCLONe network)
- Trusted by Member States and industry
**Technical infrastructure**:
- Secure portal with encryption
- Multi-factor authentication
- API access for automated reporting (optional)
- Integration with existing incident management tools
- Audit logging and access controls
**Support**:
- Technical helpdesk
- Guidance on classification and reporting
- Templates and examples
- Training for compliance teams
## Implementation Timeline
### 18 Months After Entry Into Force
**Deadline**: Approximately Q1 2029 (based on estimated Q3 2027 entry into force)
**What happens**:
- ENISA launches single entry point portal
- Organizations transition to new reporting system
- Authorities integrate with ENISA platform
- Legacy reporting systems remain available during transition
**Possible extension**: Commission may extend deadline to 24 months (Q3 2029) if technical implementation requires more time
### Phased Rollout Expected
**Phase 1 (Months 1-6)**:
- Portal development and testing
- Authority integration
- Pilot with volunteer organizations
**Phase 2 (Months 7-12)**:
- Gradual sector onboarding (likely NIS2 entities first)
- Parallel running with legacy systems
- Feedback and refinement
**Phase 3 (Months 13-18)**:
- Full deployment across all sectors
- Legacy systems phased out
- Mandatory use begins
**Technical specifications**: To be developed by ENISA in consultation with Member States and stakeholders
### Coordination with Member States
**National competent authorities** must:
- Integrate their systems with ENISA portal
- Accept reports via single entry point
- Maintain secure information sharing protocols
- Provide national language support (where required)
**Data protection authorities** must:
- Integrate GDPR breach reporting with single entry point
- Maintain independence (GDPR requirement)
- Ensure confidentiality of personal data in reports
## GDPR Breach Notification Changes
### Threshold Raised to "High Risk"
**Article 33 amendment**: Data breach notification to supervisory authority now required only for **HIGH RISK** breaches.
**Current rule (Article 33)**:
> Notify supervisory authority within 72 hours if breach poses "risk" to rights and freedoms of individuals
**New rule (amended Article 33)**:
> Notify supervisory authority within 72 hours if breach poses "HIGH RISK" to rights and freedoms of individuals
**Impact**: Aligns Article 33 (notification to authority) with Article 34 (communication to data subjects), which already requires "high risk."
### What Constitutes "High Risk"?
**EDPB to create**:
- Common breach notification template
- List of circumstances constituting "high risk"
- Assessment criteria and guidance
**Expected "high risk" factors** (based on current Article 34 guidance):
- Large scale (thousands of individuals)
- Sensitive data (health, financial, credentials, special categories)
- Vulnerable populations (children)
- Severe consequences (identity theft, fraud, discrimination)
- Irreversible harm
**Expected NOT "high risk"**:
- Small-scale incidents (few individuals)
- Non-sensitive data
- Effective mitigating measures already in place
- Technical incidents with no real-world impact
- Isolated events with limited data
### Low-Risk Breaches
**No longer require notification** to supervisory authority if only "risk" (not "high risk").
**Still required**:
- Internal documentation (Article 33(5): all breaches must be documented)
- Investigation and response
- Notification IF situation escalates to high risk
- Accountability and demonstrable compliance
**Benefit**:
- Reduced administrative burden
- Supervisory authorities focus on serious incidents
- Organizations can focus resources on remediation instead of paperwork
### How This Interacts with Single Entry Point
**High-risk GDPR breaches**:
- Reported through ENISA single entry point
- Automatically forwarded to relevant DPA
- DPA receives standardized EDPB template format
- Other authorities (CSIRT, financial supervisors) also notified if applicable
**Low-risk breaches**:
- No reporting to DPA required
- May still be reportable under other regulations (e.g., NIS2 if significant cybersecurity incident)
- Organizations should document why breach was assessed as not high-risk
**Article 34 (data subject communication)**:
- Still required for high-risk breaches
- Timeline and requirements unchanged
- Not handled through ENISA portal (direct communication to individuals)
## Benefits of Single Entry Point
### For Organizations
**Time savings**:
- One report instead of 4+ separate submissions
- Estimated 75% reduction in reporting time per incident
- Faster submission (familiar interface, unified form)
**Cost savings**:
- Reduced legal review costs (single report)
- Less duplication of effort
- Simplified compliance training
- Lower risk of errors or inconsistencies
**Better compliance**:
- Easier to meet deadlines (one timeline instead of multiple)
- Clear guidance on what to report
- Reduced risk of missing an obligation
- Audit trail in single system
**Operational efficiency**:
- Streamlined incident response process
- Centralized records and documentation
- API integration with incident management tools
- Less context-switching between platforms
### For Regulators and Supervisory Authorities
**Complete picture**:
- See all aspects of incident (cyber, data, operational)
- Understand cross-sectoral impacts
- Better situational awareness
**Faster response**:
- Immediate access to incident information
- Real-time coordination with other authorities
- Ability to launch joint investigations
- More effective crisis management
**Resource efficiency**:
- No duplicate intake processes
- Shared technical infrastructure
- Coordinated follow-up and enforcement
- Better data for trend analysis
**Improved oversight**:
- Unified incident statistics
- Cross-sector threat intelligence
- Early warning of systemic issues
- Evidence-based policy making
### For the EU as a Whole
**Cybersecurity resilience**:
- Better understanding of threat landscape
- Faster identification of cross-border incidents
- Coordinated EU-level response
- Shared learning across sectors
**Data protection**:
- DPAs informed of cybersecurity context
- Cyber authorities aware of data protection impacts
- Holistic incident management
**Regulatory efficiency**:
- Reduced burden on businesses
- Better use of public resources
- Harmonized enforcement approach
## Practical Guidance
### Preparing for the Single Entry Point
**Now - Q1 2029 (deadline)**:
**Step 1: Inventory your reporting obligations**
- Which regulations apply to your organization?
- NIS2? GDPR? DORA? eIDAS? CER?
- Who in your organization handles each?
**Step 2: Map current incident response process**
- How do you detect incidents?
- Who assesses reportability?
- What's your current reporting workflow?
- What tools do you use?
**Step 3: Identify integration opportunities**
- Can your incident management tool integrate with ENISA API?
- Do you need to update incident classification?
- How will you assess "high risk" for GDPR?
**Step 4: Update procedures and training**
- Incident response playbooks
- Compliance team training
- Legal review processes
- Communication templates
**Step 5: Monitor ENISA developments**
- Technical specifications publication
- Portal pilot programs
- Industry guidance
- Member State implementation
### Using the Single Entry Point
**When an incident occurs**:
1. **Detect and assess**:
- Is this reportable under any regulation?
- NIS2: Significant cybersecurity incident?
- GDPR: High-risk data breach?
- DORA: Major ICT incident?
- Other?
2. **Classify**:
- Severity level
- Affected systems/data
- Number of individuals (if data breach)
- Potential impact
3. **Report via single entry point**:
- Log into ENISA portal
- Select applicable regulations
- Complete unified form
- Attach supporting documentation
- Submit
4. **Meet specific timelines**:
- NIS2 early warning: 24 hours
- GDPR/NIS2 full report: 72 hours
- DORA: As soon as possible
- System will show relevant deadlines
5. **Follow up**:
- Submit updates through same portal
- Respond to authority inquiries
- Final report when investigation complete
6. **Document**:
- Save confirmation and report reference
- Maintain internal records
- Track authority responses
### GDPR High-Risk Assessment
**Factors to consider** (EDPB guidance expected):
**Scale**:
- How many individuals affected?
- Large numbers increase likelihood of high risk
**Sensitivity**:
- What type of data?
- Special categories (Article 9) = likely high risk
- Financial/health data = likely high risk
- Basic contact info only = likely NOT high risk
**Consequences**:
- Could individuals suffer identity theft?
- Financial loss?
- Discrimination?
- Reputational damage?
- Physical harm?
**Vulnerability**:
- Are data subjects vulnerable (children)?
- Are they in precarious situations?
**Mitigation**:
- Have you implemented effective measures?
- Is data encrypted (keys not compromised)?
- Have you recovered data quickly?
**Rule of thumb**: If you're unsure whether it's "high risk," err on the side of reporting. Better to report a borderline case than miss a high-risk breach.
## Comparison with Other Regions
### United States
**Fragmented landscape**:
- Federal: SEC (securities), HHS (health), FTC (consumer), OCC (banking)
- State: 50+ different data breach notification laws
- No unified reporting system
**Impact**: EU single entry point is major competitive advantage for simplicity
### United Kingdom
**Post-Brexit**:
- Maintains GDPR-like breach notification (ICO)
- Considering unified cybersecurity reporting
- May adopt similar single entry point
### Asia-Pacific
**Varied**:
- Japan: Personal Information Protection Commission
- Australia: Notifiable Data Breaches scheme
- Singapore: Personal Data Protection Commission
- Generally single-regulator systems but no cross-regulatory unification
**EU leadership**: Single entry point across multiple regulations is globally innovative
## Related Resources
- [GDPR Amendments](./gdpr-changes.md) - Details on Article 33 threshold change
- [Timeline and Implementation](./timeline-implementation.md) - When single entry point launches
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [EDPB-EDPS Joint Opinion on the Digital Omnibus](./edpb-edps-opinion.md) - Regulators' view on the raised breach-notification threshold
- [Compliance Overview](/compliance/compliance-overview) - Sealmetrics' overall privacy and security posture
## Key Takeaways
1. **Single entry point for all incident reporting** operated by ENISA
2. **"Report once, share many"** eliminates duplicate submissions
3. **Implementation: 18 months** after entry into force (≈Q1 2029)
4. **Possible extension to 24 months** if technical needs require
5. **GDPR threshold raised to "high risk"** (aligns with Article 34)
6. **EDPB to create common template** and high-risk criteria
7. **Major time and cost savings** for organizations (75% reduction in reporting time)
8. **Better regulatory coordination** and incident response
9. **Covers**: NIS2, GDPR, DORA, eIDAS, CER, and future regulations
10. **Prepare now**: Inventory obligations, update procedures, monitor ENISA
The single entry point represents a rare win-win in regulation: businesses save time and money while regulators gain better information and coordination. By eliminating the absurdity of submitting near-identical reports to multiple authorities, the Digital Omnibus demonstrates that simplification and strong oversight are not mutually exclusive—they're mutually reinforcing.
## Switzerland FADP Self-Assessment: Sealmetrics Compliance
URL: https://docs.sealmetrics.com/compliance/switzerland-fadp-self-assessment
# Switzerland FADP Self-Assessment: Sealmetrics
This document provides the self-assessment of Sealmetrics against the revised **Swiss Federal Act on Data Protection** (**nFADP / revDSG**, in force since 1 September 2023), and against **Article 45c(b) of the Swiss Telecommunications Act (TCA/FMG)**, the Swiss rule on storing data on third-party terminal equipment.
**Info:**
This self-assessment follows the published Swiss legal framework and guidance from the Federal Data Protection and Information Commissioner (FDPIC), but **does not constitute certification or approval by the FDPIC**. This document demonstrates how Sealmetrics meets the applicable requirements when properly configured.
---
## Executive Summary
| Category | Status |
|----------|--------|
| **Personal data of visitors under FADP** | ✅ None stored — no identifiers by design |
| **FADP processing principles (Art. 6)** | ✅ Compliant |
| **Privacy by design & default (Art. 7)** | ✅ Compliant |
| **Data security (Art. 8)** | ✅ Compliant |
| **Cross-border disclosure (Art. 16–17)** | ✅ EU only — adequate under the Federal Council's country list |
| **Art. 45c(b) TCA — terminal equipment** | ✅ Not triggered — nothing stored on the device |
| **Consent banner required** | ✅ No |
| **Last Assessment Date** | February 2026 |
---
## Background: The Swiss Model
Switzerland's framework differs from the EU's in two ways that matter for analytics:
1. **No general consent requirement.** Under the FADP, processing personal data is generally lawful **without consent**, provided the processing principles (Art. 6) are respected and personality rights are not unlawfully breached (Art. 30–31). Consent becomes relevant mainly for sensitive personal data, high-risk profiling, or where principles are departed from.
2. **Terminal equipment rule is opt-out, not opt-in.** Article 45c(b) TCA permits processing data on third-party terminal equipment if users are informed about it and about how they can refuse — an information-plus-refusal model, not the EU's consent model.
This makes Switzerland structurally more permissive than the EU. Sealmetrics nonetheless assesses itself against the stricter reading on every criterion, because most Swiss customers also serve EU visitors and prefer one uniform standard.
---
## Part 1: Applicability — Is Visitor Data "Personal Data"?
### Criterion 1: Personal data (Art. 5 lit. a FADP)
**Requirement:** The FADP applies to data relating to an identified or identifiable natural person. Swiss law follows a **relative approach** to identifiability: what counts is whether identification is reasonably possible for the data holder with proportionate effort.
| Data point stored | Identifiable? |
|-------------------|---------------|
| Timestamp | ✅ No — cannot single out a person |
| Page URL / referrer | ✅ No (publishers must not put PII in URLs — see checklist) |
| User agent (category signal) | ✅ No — never joined to any identity; no identifier exists to join on |
| Country (from browser timezone) | ✅ No — country-level only |
| Short-lived session marker (~2h, server-side) | ✅ No — expires, never persisted to the device, cannot recognize a returning visitor |
| IP address | ✅ **Not stored** — ephemeral in-memory use for anti-bot protection only |
**Assessment:** ✅ Stored visitor analytics records are not personal data under the FADP's relative approach: neither Sealmetrics nor the publisher can identify a person from them with any means reasonably likely to be used. For visitor data, the FADP's material obligations therefore largely do not attach — a conclusion reached by design, not by exception.
**Honest nuance:** identifiability is always assessed in context. If a publisher injected identifying data (e.g., an email in a URL or custom property), the analysis would change. The configuration checklist below exists precisely to keep implementations on the right side of this line.
---
## Part 2: Processing Principles (Art. 6 FADP)
Even where visitor data falls outside the FADP, Sealmetrics applies the Art. 6 principles as an engineering baseline — and they apply fully to **account data** (dashboard users' email, name, billing details).
### Criterion 2: Lawfulness, good faith, proportionality (Art. 6 paras. 1–2)
| Aspect | Compliance |
|--------|------------|
| Lawful processing | ✅ Aggregate statistics for the publisher's own audience measurement |
| Good faith / transparency | ✅ Documented publicly; privacy policy template provided |
| Proportionality (data minimization) | ✅ Four non-identifying variables per hit; no IP stored; country-level geo only |
### Criterion 3: Purpose limitation (Art. 6 para. 3)
| Aspect | Compliance |
|--------|------------|
| Purpose stated and recognizable | ✅ Audience measurement only |
| No secondary use | ✅ No advertising, profiling, resale, or model training on client data |
| Provider reuse prohibited | ✅ Contractually excluded ([Terms](https://sealmetrics.com/terms), [DPA](https://sealmetrics.com/dpa)) |
### Criterion 4: Accuracy and retention (Art. 6 paras. 4–5)
| Aspect | Compliance |
|--------|------------|
| Retention limited | ✅ 24 months for analytics data, then automatic deletion |
| Account data | ✅ Deleted within 30 days of account closure; backups purged within 90 days |
---
## Part 3: Privacy by Design and by Default (Art. 7 FADP)
The nFADP made privacy by design and by default a statutory duty — one of the notable additions over the old law.
| Aspect | Compliance |
|--------|------------|
| Data protection built into the architecture | ✅ No cookies, no identifiers, no stored IP — irrespective of configuration |
| Most protective default settings | ✅ The consentless, identifier-free mode is the default — and currently the only mode. The one optional feature designed on top of it (Agent Analytics bot detection) is **not live and cannot be enabled** |
| Cannot be degraded by misconfiguration alone | ✅ Individual-level tracking is architecturally unavailable, not merely disabled |
**Assessment:** ✅ Compliant. Sealmetrics is a working example of Art. 7: the privacy properties are structural, not settings.
---
## Part 4: Data Security (Art. 8 FADP)
| Measure | Status |
|---------|--------|
| Encryption in transit | ✅ TLS 1.3 |
| Encryption at rest | ✅ AES-256 |
| Access control | ✅ Role-based access, audit logging, 2FA available |
| Breach notification readiness (Art. 24) | ✅ Processes in place; note that stored analytics data contains no personal identifiers, which drastically limits breach impact |
---
## Part 5: Cross-Border Disclosure (Art. 16–17 FADP)
**Requirement:** Personal data may be disclosed abroad only to countries with adequate protection (per the Federal Council's country list in the Data Protection Ordinance) or with appropriate safeguards.
| Aspect | Compliance |
|--------|------------|
| Processing location | ✅ Dublin, Ireland (EU) |
| Ireland / EU on the Federal Council's adequacy list | ✅ Yes — EU/EEA states are recognized as providing adequate protection |
| Transfers to the US or other non-adequate countries | ✅ None |
| Additional safeguards needed (SCCs, etc.) | ✅ Not required — disclosure is only to adequate territory, and stored visitor records contain no personal data in any case |
**Assessment:** ✅ For Swiss publishers, data leaving Switzerland for the EU is a disclosure to an adequate jurisdiction. There are no transfers outside EU/CH-adequate territory. See [Subprocessors](/compliance/subprocessors) for the (short) processing chain.
---
## Part 6: Terminal Equipment — Art. 45c(b) TCA
**Requirement:** Processing data on third-party terminal equipment (the Swiss "cookie rule") is permitted if users are informed and told how to refuse.
| Aspect | Sealmetrics Compliance |
|--------|----------------------|
| Data stored on the terminal | ✅ **None** — no cookies, no localStorage, nothing written |
| Stored information accessed | ✅ None read |
| Information duty | ✅ Satisfied via the publisher's privacy policy (template below) |
| Refusal mechanism | ✅ Standard browser controls / ad blockers; nothing individual to refuse in any case |
**Assessment:** ✅ The rule is not meaningfully triggered — there is no storage on the device — and the information/refusal duties are satisfied regardless.
---
## Part 7: Duties That Do Not Arise (and Why)
For completeness, the nFADP duties that a Swiss publisher might worry about, assessed against Sealmetrics:
| Duty | Analysis |
|------|----------|
| Information duty (Art. 19) | Applies to personal data collection; for Sealmetrics, satisfied by a short privacy-policy mention (template below). Recommended regardless of strict necessity. |
| Right of access (Art. 25) | For visitor analytics data, no record can be linked to a requester — no identifiers exist. See [Data Subject Rights](/compliance/data-subject-rights). Applies normally to dashboard account data. |
| DPIA (Art. 22) | No high-risk processing: no profiling, no sensitive data, no systematic monitoring of individuals. A DPIA for the analytics function is not indicated; publishers can reference this document in their records. |
| Records of processing (Art. 12) | Publishers should include their Sealmetrics use in their records where they maintain them; this page provides the needed facts. |
| Profiling / high-risk profiling (Art. 5 lit. f–g) | Not performed — no individual-level data exists to profile. |
**Recommended Privacy Policy Text (German — adapt for FR/IT):**
```
Diese Website verwendet Sealmetrics zur Reichweitenmessung. Sealmetrics
setzt keine Cookies, speichert nichts auf Ihrem Gerät und erhebt keine
Personendaten: IP-Adressen werden nicht gespeichert, und es bestehen
keine individuellen Identifikatoren. Die aggregierten Daten werden
ausschliesslich in der EU (Dublin, Irland) verarbeitet — einem Land mit
angemessenem Datenschutzniveau gemäss Verordnung des Bundesrates.
Sie können das Analyse-Skript jederzeit über Ihre Browser-Einstellungen
blockieren.
```
---
## Part 8: Configuration Checklist for Swiss Publishers
### Required ✅
- [ ] Standard tracking mode (default configuration)
- [ ] No custom user IDs enabling cross-session tracking
- [ ] No PII in custom event properties or URLs
- [ ] Privacy policy updated to mention Sealmetrics (information duty, Art. 19 FADP / Art. 45c TCA)
### Prohibited ❌
- [ ] Do NOT pass email addresses or other PII as properties
- [ ] Do NOT combine Sealmetrics data with profiling or advertising tools
- [ ] Do NOT export data for individual-level analysis
---
## Part 9: Compliance Statement
Sealmetrics declares that:
1. Stored visitor analytics data **contains no personal data** within the meaning of Art. 5 lit. a FADP — no identifiers of any kind are created or kept
2. Its architecture satisfies the FADP's processing principles, **privacy by design and by default** (Art. 7), and data security (Art. 8) requirements
3. Customer analytics data is processed **exclusively in Dublin, Ireland (EU)** — adequate territory under the Federal Council's country list — with **no transfers outside EU/CH-adequate jurisdictions**
4. Nothing is stored on or read from the visitor's device, so the Swiss terminal-equipment rule (Art. 45c(b) TCA) imposes no consent or banner obligation
5. Swiss publishers can use Sealmetrics **without a consent banner** when configured per this document
Publishers **cannot** claim Sealmetrics is "certified" or "approved" by the FDPIC — no such certification exists.
---
## Part 10: Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.0 | February 2026 | Initial self-assessment against the nFADP (in force 1 September 2023) and Art. 45c TCA |
---
## References
- [Federal Act on Data Protection (FADP, SR 235.1) — official text](https://www.fedlex.admin.ch/eli/cc/2022/491/en)
- [Data Protection Ordinance (DPO, SR 235.11) — including the adequacy country list](https://www.fedlex.admin.ch/eli/cc/2022/568/en)
- [FDPIC — Federal Data Protection and Information Commissioner](https://www.edoeb.admin.ch/)
- [Telecommunications Act (TCA, SR 784.10), Art. 45c](https://www.fedlex.admin.ch/eli/cc/1997/2187_2187_2187/en)
- [Sealmetrics Privacy Policy](https://sealmetrics.com/privacy)
- [Sealmetrics DPA](https://sealmetrics.com/dpa)
## Contact
- **Email:** privacy@sealmetrics.com
- **DPO Contact:** dpo@sealmetrics.com
## Related documentation
- [CNIL Self-Assessment](/compliance/cnil-self-assessment) — the equivalent self-assessment for France
- [Germany TDDDG Self-Assessment](/compliance/germany-ttdsg-self-assessment) — the equivalent self-assessment for Germany
- [Italy Garante Self-Assessment](/compliance/italy-garante-self-assessment) — the equivalent self-assessment for Italy
- [Data Subject Rights (DSAR)](/compliance/data-subject-rights) — how access requests work with identifier-free data
- [Data Location & Retention](/security-privacy/data-location) — Dublin hosting and retention schedules
## SME and Small Mid-Cap Exemptions
URL: https://docs.sealmetrics.com/compliance/omnibus/smes-small-midcaps
# SME and Small Mid-Cap Exemptions
The EU Digital Omnibus introduces a new category of protected businesses: **Small Mid-Caps (SMCs)**. By extending exemptions and simplifications to companies with up to 749 employees, the regulation eliminates the "cliff edge" compliance burden that hits growing businesses and saves an estimated €5-19 million annually across the European economy.
## The Growth Problem
### The SME Cliff Edge
Under current EU law, businesses enjoy lighter regulatory treatment while they qualify as **SMEs (Small and Medium Enterprises)**:
**SME definition (Commission Recommendation 2003/361/EC)**:
- Fewer than 250 employees
- AND either:
- Annual turnover ≤ €50 million, OR
- Balance sheet total ≤ €43 million
**Examples of SME exemptions**:
- GDPR Article 30: No processing record requirement (with exceptions)
- Simplified audit requirements
- Lighter reporting obligations
- Reduced fees for certifications
### What Happens at 250 Employees
**The cliff edge**: A company crossing from 249 to 250 employees suddenly faces:
- Full GDPR Article 30 processing records
- Complete Data Act compliance
- All AI Act obligations without transition
- Higher fees for data access requests
- Maximum regulatory burden overnight
**Real-world impact**:
- Growth deterrent (companies delay hiring)
- Compliance shock (sudden cost increase)
- Resource strain (must rapidly build compliance infrastructure)
- Competitive disadvantage vs. companies that stayed below threshold
**Economic inefficiency**: A company with 250 employees is not fundamentally different from one with 249, yet faces drastically different regulatory treatment.
## The Solution: Small Mid-Caps (SMCs)
### New Category: SMCs
The Digital Omnibus creates an intermediate category between SMEs and large enterprises:
**Small Mid-Cap (SMC) definition**:
- **250-749 employees**
- AND either:
- Annual turnover ≤ €150 million, OR
- Balance sheet total ≤ €129 million
**Rationale**: Companies in this range are still growing, resource-constrained, and deserve proportionate regulation.
### How Many Companies Qualify?
**Approximately 38,000 companies** across the EU fall into the SMC category.
**Sectors with high SMC presence**:
- Technology and software
- Manufacturing
- Professional services
- Healthcare providers
- Logistics and transportation
- Hospitality and tourism
**Geographic distribution**: Concentrated in larger Member States (Germany, France, Italy, Spain) but present in all EU countries.
## Extended Exemptions for SMCs
### 1. Public Sector Data Access Fees
**Current rule (Data Act)**: SMEs can request waiver of fees for accessing public sector data
**Extended**: SMCs also qualify for fee waivers
**Savings**: Approximately €500 per data access application
**Use cases**:
- Weather data for logistics optimization
- Geographic data for urban planning services
- Traffic data for mobility applications
- Public procurement data for market analysis
**Annual impact**: €5-19 million savings across SMC sector (based on estimated application volumes)
**Benefit**: Levels playing field with large enterprises that can more easily absorb data access costs
### 2. Data Intermediation Compliance
**Current complexity**: Data intermediation service providers face heavy compliance burden
**Extended**: SMCs receive simplified compliance pathways for data intermediation services
**Simplifications**:
- Lighter monitoring requirements
- Reduced documentation burden
- Proportionate transparency obligations
- Risk-based supervision
**Impact**: Encourages SMCs to offer data intermediation services (data marketplaces, sharing platforms, cooperatives) without prohibitive compliance costs
**Market effect**: More competition in data intermediation market; benefits data providers and users
**Learn more**: [Data Intermediation Services](./data-intermediation.md)
### 3. Cloud Switching Requirements
**Data Act Chapter V**: Rules for switching between cloud and data processing services
**Extended**: SMCs receive lighter regime for:
- Switching assistance obligations (as providers)
- Contract transparency (as users)
- Data portability implementation (as providers)
**Rationale**: SMC cloud providers don't have resources of hyperscalers; proportionate rules enable competition
**Benefit**: SMC cloud providers can compete without matching compliance investment of AWS/Azure/Google Cloud
### 4. Browser Signal Implementation (GDPR Article 88b)
**Article 88b(6)**: Browsers must provide technical means for consent signals
**Exemption**: **SME browser providers are exempt**
**Extended to SMCs**: Since browsers are software products, SMC browser vendors (if any) would also be exempt
**Practical impact**: Limited (most browsers are from large tech companies), but removes barrier for innovative browser startups that grow into SMC size
**Examples**: Brave, Vivaldi, or regional browsers could grow to SMC size without facing Article 88b(6) implementation burden
### 5. AI Act Compliance (via AI Omnibus)
**Separate proposal**: AI Omnibus (COM(2025) 836) extends AI Act exemptions to SMCs
**Extended provisions**:
- Longer compliance timelines for high-risk AI systems
- Simplified conformity assessment procedures
- Reduced technical documentation requirements
- Lighter post-market monitoring obligations
**Coordination**: AI Omnibus and Digital Omnibus work together for coherent SME/SMC treatment across digital regulations
**Impact**: SMC AI developers can innovate without compliance burden designed for large AI labs
## GDPR Article 30 Extension (Proposed)
### Current GDPR Article 30
**Article 30(5)** exempts SMEs from maintaining processing records **unless**:
- Processing is high-risk
- Processing includes special categories (Article 9) or criminal data (Article 10)
- Processing is regular and systematic
**In practice**: Most SMEs must maintain records anyway due to exceptions
### Omnibus IV Proposal
**Separate legislative proposal** (Omnibus IV) currently under discussion:
**Proposal**: Extend Article 30(5) exemption to SMCs
**Status**: Being negotiated by European Parliament and Council (not part of Digital Omnibus COM(2025) 837)
**Expected timeline**: Adoption in 2026-2027
**If adopted**: SMCs would not need processing records unless high-risk/special categories/regular systematic processing
**Savings**: Significant reduction in administrative burden for SMCs (records require substantial compliance resources)
**Note**: This is separate from the Digital Omnibus but demonstrates broader EU policy of proportionate SMC treatment
## Size Thresholds Comparison
### Visual Overview
```
┌─────────────────────────────────────────────────────────────┐
│ MICRO ENTERPRISE │
│ < 10 employees │
│ Turnover/Balance Sheet ≤ €2M │
│ → Maximum exemptions and simplifications │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ SMALL ENTERPRISE │
│ < 50 employees │
│ Turnover/Balance Sheet ≤ €10M │
│ → SME exemptions apply │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ MEDIUM ENTERPRISE (SME) │
│ < 250 employees │
│ Turnover ≤ €50M OR Balance Sheet ≤ €43M │
│ → SME exemptions apply │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ SMALL MID-CAP (SMC) ← NEW CATEGORY │
│ 250-749 employees │
│ Turnover ≤ €150M OR Balance Sheet ≤ €129M │
│ → SME exemptions EXTENDED by Digital Omnibus │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ LARGE ENTERPRISE │
// ... see full example at https://docs.sealmetrics.com/compliance/omnibus/smes-small-midcaps
```
### Determining Your Category
**Step 1**: Count employees
- Include full-time equivalent (FTE)
- Include employees in parent and subsidiary companies (group concept)
**Step 2**: Calculate annual turnover OR balance sheet total
- Based on last approved accounting period
- Consolidate group accounts if applicable
**Step 3**: Apply thresholds
| Category | Employees | Turnover | Balance Sheet |
|----------|-----------|----------|---------------|
| **Micro** | < 10 | ≤ €2M | ≤ €2M |
| **Small** | < 50 | ≤ €10M | ≤ €10M |
| **Medium (SME)** | < 250 | ≤ €50M | ≤ €43M |
| **SMC (NEW)** | 250-749 | ≤ €150M | ≤ €129M |
| **Large** | ≥ 750 | > €150M | > €129M |
**Note**: You must meet employee threshold AND (turnover OR balance sheet). If you exceed both turnover AND balance sheet but are under employee threshold, you're still in the category.
**Example 1**:
- 300 employees
- €80M turnover
- €60M balance sheet
- **Result**: SMC (employees 250-749, turnover ≤ €150M)
**Example 2**:
- 600 employees
- €200M turnover
- €180M balance sheet
- **Result**: Large enterprise (exceeds SMC thresholds)
**Example 3**:
- 240 employees
- €70M turnover
- €50M balance sheet
- **Result**: SME (under 250 employees, even though financials exceed SME limits)
## Benefits Summary
### For SMCs (Direct Benefits)
**Financial savings**:
- €500 per public sector data access request (fee waiver)
- Reduced compliance costs (lighter data intermediation regime)
- Lower certification and audit costs
- Delayed AI Act compliance costs
**Operational benefits**:
- Simpler compliance processes
- Proportionate documentation requirements
- Risk-based supervision (less frequent audits)
- More time to implement new obligations
**Competitive advantages**:
- Can offer data services without prohibitive costs
- Compete with large enterprises for data-driven innovation
- Attract investment (lower regulatory risk)
- Scale without cliff-edge compliance shock
### For the EU Economy (Indirect Benefits)
**Encourages growth**:
- Companies less hesitant to hire 250th employee
- Smooth transition from SME to mid-cap
- Reduced "threshold gaming" (deliberately staying small)
**Promotes innovation**:
- More SMC participation in data economy
- More data intermediation providers (competition)
- More AI development by mid-sized companies
- More diverse market (not just tech giants)
**Job creation**:
- Companies can grow to 750 employees without regulatory deterrent
- High-skill jobs in tech, data, AI sectors
- Regional employment (SMCs often rooted in local communities)
**Market competition**:
- SMCs can challenge large incumbents
- More diverse data service offerings
- Consumer choice and innovation
## Comparison with Other Jurisdictions
### United States
**No equivalent**: U.S. generally does not create intermediate regulatory categories between small business and large enterprise
**CCPA/CPRA**: Some exemptions for businesses under revenue thresholds, but no mid-cap category
**Impact**: EU SMCs have regulatory advantage over U.S. mid-sized companies
### United Kingdom
**Post-Brexit**: UK considering similar SME/SMC distinctions in data and digital regulation
**Status**: Proposals under discussion; no implemented SMC category yet
**Convergence**: Likely UK will adopt similar approach for competitiveness
### Asia-Pacific
**Varied approaches**:
- Japan: Some SME exemptions in data protection law
- South Korea: Tiered compliance based on business size
- Australia: Limited SME exemptions
**EU leadership**: SMC category is innovative; may influence global regulatory design
## Practical Guidance for SMCs
### If You Qualify as SMC
**Step 1**: Verify your status
- Calculate employees, turnover, balance sheet
- Confirm you meet 250-749 employee threshold
- Check financial thresholds
**Step 2**: Identify applicable exemptions
- Public sector data access: Apply for fee waivers
- Data intermediation: Use simplified compliance
- Cloud services: Leverage lighter switching regime
- AI Act: Monitor AI Omnibus adoption for extended timelines
**Step 3**: Update compliance documentation
- Privacy policies: Reflect proportionate obligations
- Data processing records: Check if GDPR Article 30(5) extension applies (Omnibus IV)
- Vendor contracts: Negotiate based on SMC status
**Step 4**: Engage with regulators
- National competent authorities may have SMC-specific guidance
- Participate in industry consultations
- Seek clarification on borderline cases
### If You're Growing Toward SMC Status
**Plan ahead**:
- Track employee count and financials
- Anticipate threshold crossing
- Budget for compliance changes
**Smooth transition from SME to SMC**:
- Incremental compliance build-up
- No cliff edge (extended exemptions continue)
- More time to mature compliance functions
**Growing from SMC to large enterprise**:
- At 750 employees or financial thresholds, exemptions end
- Plan 6-12 months ahead for full compliance
- Consider phased hiring to manage transition
## Limitations and Conditions
### Not All Exemptions Apply
**SMC status does NOT exempt from**:
- Core GDPR obligations (lawful basis, transparency, security)
- Fundamental data subject rights
- High-risk processing safeguards
- Sector-specific regulations (financial services, healthcare)
**SMC exemptions are limited to**:
- Proportionate administrative requirements
- Fee reductions
- Simplified reporting
- Lighter documentation (where risk permits)
### Group Company Rules
**Parent-subsidiary relationships**:
- Employee count includes entire group
- Financial thresholds consolidate group accounts
- Cannot split company to qualify for SMC status
**Example**: Parent company with 100 employees and subsidiary with 200 employees = 300 total (SMC category)
### Monitoring and Enforcement
**Abuse prevention**:
- Supervisory authorities can challenge SMC status claims
- Must demonstrate genuine compliance with thresholds
- Artificial structuring to gain SMC status may be disregarded
**Verification**:
- Based on audited accounts where applicable
- Self-certification with potential spot checks
- Penalties for fraudulent claims
## Future Developments
### Omnibus IV (Ongoing)
**Proposal**: Extend GDPR Article 30(5) to SMCs
**Status**: Co-legislators negotiating
**Expected**: Adoption 2026-2027
**Impact**: Major administrative relief for SMCs (no processing records unless high-risk)
### AI Omnibus (Parallel)
**Proposal**: COM(2025) 836
**SMC provisions**:
- Extended AI Act timelines
- Simplified conformity assessment
- Lighter documentation
**Status**: Legislative process (parallel to Digital Omnibus)
**Expected**: Adoption 2026-2027
### Broader SMC Policy
**EU trend**: Recognizing SMCs as distinct category across regulations
**Future areas**:
- Tax simplifications
- State aid eligibility
- Public procurement preferences
- Research funding access
**Policy goal**: Enable European SMCs to scale and compete globally
## Related Resources
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [Data Intermediation Services](./data-intermediation.md) - How SMCs benefit from voluntary regime
- [Timeline and Implementation](./timeline-implementation.md) - When SMC exemptions take effect
- [GDPR Amendments](./gdpr-changes.md) - GDPR changes that may affect SMCs
- [AI Act Amendments in the Digital Omnibus](./ai-act-amendments.md) - SMC extensions delivered via the parallel AI Omnibus
- [EDPB-EDPS Joint Opinion on the Digital Omnibus](./edpb-edps-opinion.md) - Regulators' position on the wider proposal
## Key Takeaways
1. **New SMC category**: 250-749 employees, extending SME protections
2. **Approximately 38,000 EU companies** qualify as SMCs
3. **€5-19M annual savings** across SMC sector from fee exemptions alone
4. **Eliminates cliff edge**: Smooth transition from SME (249 employees) to SMC (250-749)
5. **Extended exemptions**: Public data fees, data intermediation, cloud switching, browser signals
6. **Coordination with AI Omnibus**: SMC treatment extends to AI regulation
7. **Economic benefits**: Encourages growth, innovation, job creation, competition
8. **Verify your status**: Calculate employees and financials to determine if you qualify
The SMC category represents a sophisticated understanding of business lifecycle. By recognizing that a company with 250 employees is not suddenly a large enterprise, the Digital Omnibus enables European mid-sized companies to grow, innovate, and compete without being crushed by regulatory burden designed for tech giants. This proportionate approach to regulation may prove to be one of the Omnibus's most significant contributions to European competitiveness.
## Subprocessors
URL: https://docs.sealmetrics.com/compliance/subprocessors
# Subprocessors
The authoritative, always-current list of Sealmetrics subprocessors is published
as **Annex 3 of our Data Processing Agreement**:
👉 **[sealmetrics.com/dpa](https://sealmetrics.com/dpa/)** · [versión en español](https://sealmetrics.com/es/dpa/)
You will be redirected automatically in a few seconds. To subscribe to
subprocessor change notifications, email **privacy@sealmetrics.com** with the
subject "Subprocessor updates".
## Data Subject Rights (DSAR)
URL: https://docs.sealmetrics.com/compliance/data-subject-rights
# Data Subject Rights (DSAR) and SealMetrics
If you use SealMetrics on your website, sooner or later your DPO will receive a data subject access request (DSAR) and need to answer a simple question: *"What does our analytics tool hold about this person?"*
With SealMetrics, the answer is structurally simple — and this page explains why, what it means in practice, and where data subject rights **do** fully apply (your dashboard account).
---
## Two very different data categories
| Category | Who it concerns | Contains personal data? | Rights requests |
|----------|----------------|-------------------------|-----------------|
| **Visitor analytics data** | Visitors to your website | No — no identifiers by design | Cannot be linked to any individual (see below) |
| **Account data** | You and your team (dashboard users) | Yes — email, name, billing details | Fully applicable, standard process |
---
## Visitor rights requests: no data to link to
### Why requests cannot be matched to records
SealMetrics stores **no personal data and no identifiers** for website visitors:
- No IP addresses stored (used ephemerally in memory for anti-bot protection, never persisted)
- No cookies or terminal storage
- No user IDs, device IDs, or fingerprints
- No cross-session identifiers — the short-lived session marker (~2h) expires and cannot recognize a returning visitor
- Country derived from the browser timezone, not from the IP
- User agent stored as a category signal, never joined to any identity
Because no record in the analytics database relates to an identified or identifiable person, there is **no key by which a rights request could be matched to any stored record**. If a visitor asks "show me my data" or "delete my data", there is no technical means — for SealMetrics or for you — to determine which rows (if any) were generated by that person's visits.
### The legal frame: GDPR Article 11
GDPR anticipates exactly this situation. **Article 11** (processing which does not require identification) provides that where a controller's purposes do not require the identification of a data subject, the controller is **not obliged to acquire additional information** just to identify the data subject for the purpose of complying with the Regulation. Where the controller can demonstrate it is not in a position to identify the data subject, Articles 15–20 (access, rectification, erasure, restriction, portability) do not apply — unless the data subject themselves provides additional information enabling identification, which with SealMetrics is not possible because no identifier exists to match it against.
**Info:**
This is not a workaround to avoid answering DSARs. It is the direct consequence of not collecting personal data in the first place: data minimization taken to its logical conclusion. The best DSAR response is having nothing to search.
### What this means in practice for your DPO
When a visitor rights request mentions your website analytics:
1. **You can respond substantively** — explain that your analytics tool (SealMetrics) stores no personal data or identifiers about visitors, so no stored record can be attributed to the requester.
2. **You do not need to ask SealMetrics to search** — there is nothing to search by: no email, no IP, no ID exists in the analytics data.
3. **Document the reasoning** — reference your records of processing (ROPA) entry for SealMetrics, which should describe the tool as processing anonymous, aggregate statistics. This page and [What We Track vs What We Don't](/security-privacy/what-we-track) can be attached as supporting documentation.
4. **Remember Article 12(2)** — you must still facilitate rights requests in general; the point is that for this specific processing, identification is impossible and Article 11(2) applies.
**Warning:**
This analysis holds for SealMetrics as designed. If your implementation passes personal data into custom event properties (for example, an email address in a conversion property), you have introduced personal data into the system against our [configuration guidance](/compliance/cnil-self-assessment#part-5-configuration-checklist), and your DSAR analysis changes. Never send PII in custom properties.
---
## Account-holder rights: fully applicable
Data subject rights apply in full to **account data** — the personal data of you and your team as SealMetrics dashboard users (email address, name, password hash, billing information, audit logs).
### What you can do yourself
| Right | How |
|-------|-----|
| Access / portability | Export your data from the dashboard (CSV) or via the API |
| Rectification | Edit your profile and account details in the dashboard |
| Erasure | Close your account — all data deleted within 30 days, backups purged within 90 days |
### How to submit a rights request
For anything you cannot do self-service, or to exercise any GDPR right formally:
- **Email:** privacy@sealmetrics.com
- **DPO contact:** dpo@sealmetrics.com
Include the email address associated with your SealMetrics account so we can verify your identity. We respond within the timelines required by GDPR Article 12(3) (one month, extendable in complex cases with notice).
### Roles under the DPA
For visitor analytics data, you (the website operator) are the controller and SealMetrics is your processor under the [SealMetrics DPA](https://sealmetrics.com/dpa). For account data (your dashboard login, billing), SealMetrics acts as a controller in its own right. Rights requests for account data go directly to us at the addresses above.
---
## Quick reference for DPOs
| Scenario | Answer |
|----------|--------|
| Visitor asks your company for their analytics data | No record can be attributed to them — no identifiers exist (GDPR Art. 11) |
| Visitor asks for erasure of their analytics data | Same — no record can be located; nothing identifiable is stored |
| Visitor objects to processing | No individual-level processing occurs; visitors can additionally block the script via browser settings or ad blockers |
| Dashboard user asks for their account data | Standard DSAR — self-service export or privacy@sealmetrics.com |
| Regulator asks where analytics data is stored | Dublin, Ireland (EU), 24-month retention — see [Data Location & Retention](/security-privacy/data-location) |
---
## Related documentation
- [What We Track vs What We Don't](/security-privacy/what-we-track) — the full inventory of what is (and is not) collected
- [Subprocessors](/compliance/subprocessors) — who touches what data, and where
- [Data Location & Retention](/security-privacy/data-location) — storage location and deletion schedules
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) — the consent-free model behind this analysis
- [CNIL Self-Assessment](/compliance/cnil-self-assessment) — configuration rules that keep PII out of the system
## Implementation Timeline
URL: https://docs.sealmetrics.com/compliance/omnibus/timeline-implementation
# Implementation Timeline
The EU Digital Omnibus follows a carefully phased implementation schedule that gives businesses and regulators time to adapt while delivering benefits as quickly as possible. This page provides all key dates and milestones.
## Legislative Process
**Info:**
This timeline reflects the current state of the legislative process. Dates are estimates based on typical EU procedures.
### November 19, 2025: Proposal Published ✅
**Status**: Complete
**Documents released**:
- Proposed Regulation text
- Explanatory Memorandum
- Staff Working Document (Impact Assessment)
- Annexes (correlation tables, repeals)
**What happened**: European Commission initiated the ordinary legislative procedure under Articles 16 and 114 TFEU.
### January 2026: Committee Assignments ✅
**Status**: Complete
The proposal (procedure 2025/0360(COD)) has been assigned to **joint committee responsibility**:
| Committee | Full Name | Focus |
|-----------|-----------|-------|
| **ITRE** | Industry, Research and Energy | Data Act consolidation, technical aspects |
| **LIBE** | Civil Liberties, Justice and Home Affairs | GDPR amendments, privacy aspects |
**Rapporteurs**: Not yet appointed (as of late January 2026)
### Open Feedback Periods 🔄
**Status**: Currently open
| Consultation | Deadline | Link |
|--------------|----------|------|
| Digital Omnibus feedback | **9 March 2026** | [Have Your Say](https://ec.europa.eu/info/law/better-regulation/have-your-say_en) |
| Digital Fitness Check | **11 March 2026** | [Have Your Say](https://ec.europa.eu/info/law/better-regulation/have-your-say_en) |
Organizations can submit formal positions during these periods.
### Q1-Q2 2026: Parliamentary and Council Review 🔄
**Status**: In progress
**European Parliament**:
- ✅ Committee assignment (ITRE + LIBE joint)
- 🔄 Rapporteur appointment (expected Q1 2026)
- ⏳ Draft report and amendments
- ⏳ Committee vote
- ⏳ Plenary vote
**Council of the European Union**:
- ✅ Antici Group presentation (November 21, 2025)
- 🔄 Working Party examination
- ⏳ COREPER review
- ⏳ Council position adoption
**Expected duration**: Parliament/Council positions by Q2 2026
### 2026-2027: Trilogue Negotiations
**Trilogue** = informal negotiations between:
- European Parliament
- Council of the European Union
- European Commission (mediator)
**Goal**: Reach compromise text acceptable to both Parliament and Council
**Expected duration**: 6-12 months
**What can change**: Any provision may be amended, deleted, or added during negotiations. Timeline dates may shift.
### Late 2026 or 2027: Final Adoption
**Parliament**: Plenary vote on final compromise text
**Council**: Formal adoption of final text
**Publication**: Official Journal of the European Union (typically 30-60 days after adoption)
**Entry into force**: 20 days after publication in Official Journal
## Entry Into Force
### Estimated: Q3 2027
**Trigger**: 20 days after publication in Official Journal
**What it means**:
- Regulation becomes part of EU law
- Repeals take effect (P2B, FFDR, DGA, ODD)
- Implementation timelines start counting
- Transitional provisions activate
**Note**: This is an estimate based on typical legislative timeline. Actual date depends on legislative process speed.
## Implementation Deadlines
All timelines below are calculated **from entry into force** (estimated Q3 2027).
### 6 Months: Cookie Consent Framework
**Provision**: Article 88a GDPR (cookie consent rules)
**Deadline**: Approximately Q1 2028
**What becomes applicable**:
- Consent exemption for aggregated audience measurement (Article 88a(3)(c))
- Consent exemption for service functionality (Article 88a(3)(b))
- Single-click refuse requirement (Article 88a(4)(a))
- 6-month re-asking prohibition (Article 88a(4)(c))
- No re-asking during valid consent period (Article 88a(4)(b))
**Impact**:
- First-party analytics without consent becomes lawful
- Better consent UX where consent is required
- Third-party tracking still requires consent
**Note:**
While the Commission projects 60% of cookies will no longer need consent, legal analysts note that:
- Information obligations may still require some form of notification
- Hybrid banner solutions are expected for sites with mixed tracking tools
- Full cookie banner elimination applies mainly to sites using **only** first-party, aggregated analytics
See [Cookie Consent Reform](./cookies-eprivacy.md) for detailed analysis.
**What to do before this deadline**:
- [x] Audit analytics and tracking tools
- [x] Identify exempt vs. consent-required processing
- [x] Update privacy policies
- [x] Implement single-click refuse if keeping banners
- [x] Plan banner removal for exempt processing
**Learn more**: [Cookie Consent Reform](./cookies-eprivacy.md)
### 18 Months: Single Entry Point for Incident Reporting
**Provision**: Single entry point for incident reporting (ENISA-operated)
**Deadline**: Approximately Q1 2029
**Extension possible**: Commission may extend to 24 months if technical implementation requires more time
**What becomes applicable**:
- Unified incident reporting portal
- Single submission satisfies multiple obligations
- ENISA coordinates distribution to relevant authorities
- Secure information sharing between regulators
**What to do before this deadline**:
- [x] Review current incident reporting procedures
- [x] Identify all applicable reporting obligations (NIS2, GDPR, DORA, etc.)
- [x] Prepare for single portal integration
- [x] Update incident response plans
- [x] Train security teams on new process
**Learn more**: [Single Entry Point for Incident Reporting](./incident-reporting.md)
### 24 Months: Website Browser Signal Support
**Provision**: Article 88b(1)-(5) GDPR (machine-readable consent signals)
**Deadline**: Approximately Q3 2029
**What becomes applicable**:
- Websites must accept automated consent signals from browsers
- Websites must accept automated refusal/objection signals
- Controllers must respect user choices communicated via browser
**Exemption**: Media service providers are exempt and can still show consent dialogs
**What to do before this deadline**:
- [x] Monitor European standardisation body standards development
- [x] Prepare technical infrastructure for signal interpretation
- [x] Test compatibility with signal formats
- [x] Update consent management systems
- [x] Plan fallback for users without signal-capable browsers
**Note**: Standards for signal format will be developed during this period. Early preparation recommended.
**Learn more**: [Cookie Consent Reform - Browser Signals](./cookies-eprivacy.md#browser-signals-the-future-of-consent)
### 48 Months: Browser Implementation
**Provision**: Article 88b(6)-(7) GDPR (browser consent controls)
**Deadline**: Approximately Q3 2031
**Who is affected**: Non-SME browser providers
**What becomes applicable**:
- Browsers must provide technical means for users to give consent
- Browsers must provide technical means for users to refuse consent
- Consent/refusal must be automated and machine-readable
**Exemption**: SME browser providers are exempt (browsers from small/medium enterprises)
**Major browsers affected**:
- Google Chrome
- Apple Safari
- Microsoft Edge
- Mozilla Firefox
- Opera (if not SME)
**User impact**: Users will be able to set privacy preferences once in their browser, which will be automatically communicated to websites.
**Timeline reasoning**: 48 months gives browser vendors ample time to:
- Participate in standards development
- Design user interfaces
- Implement technical infrastructure
- Test interoperability
- Roll out to billions of users
## Parallel and Related Processes
### Digital Fitness Check (Ongoing)
**Status**: Currently underway
**Scope**: Comprehensive review of EU digital legislation effectiveness
**Regulations under review**:
- Digital Services Act (DSA)
- Digital Markets Act (DMA)
- eCommerce Directive
- Consumer protection rules
**Expected outcome**: Additional simplification proposals in 2026-2027
**Relationship to Omnibus**: Fitness Check may identify further consolidation opportunities beyond what Omnibus already achieves.
### AI Omnibus (Parallel Proposal)
**Document**: COM(2025) 836 (published same day as Digital Omnibus)
**Scope**: Amendments to AI Act (Regulation (EU) 2024/1689)
**Key changes**:
- Extended SME/SMC exemptions for AI compliance
- Simplified conformity assessment
- Reduced documentation burden
- Clarifications on high-risk AI classification
**Relationship to Digital Omnibus**:
- Separate legislative process
- Article 88c in Digital Omnibus references AI Act
- Both proposals work together for coherent AI framework
**Timeline**: Similar to Digital Omnibus (adoption 2026-2027)
### Scheduled Reviews of Related Regulations
#### DMA Review (2026)
**Regulation**: Digital Markets Act (EU) 2022/1925
**Article 33**: Commission must review effectiveness by May 2026
**Topics**:
- Gatekeeper designation criteria
- Effectiveness of obligations
- Need for additional core platform services
- Interoperability requirements
**Potential impact**: May affect how Article 88a consent exemptions interact with DMA requirements
#### DSA Evaluation (2027)
**Regulation**: Digital Services Act (EU) 2022/2065
**Article 91**: Commission report on application by November 2027
**Topics**:
- Platform accountability effectiveness
- Illegal content enforcement
- Transparency requirements
- User redress mechanisms
**Note**: P2B Regulation repeal by Omnibus assumes DSA adequately covers platform-business relationships
#### Data Act Evaluation (2028)
**Regulation**: Data Act (EU) 2023/2854
**Article 48**: Commission evaluation report by September 2028
**Topics** (as consolidated by Omnibus):
- Data access rights effectiveness
- Switching service adoption
- Data intermediation market development
- Public sector data access
- International data access framework
**Note**: This will be first evaluation of consolidated Data Act including absorbed DGA/ODD provisions
#### AI Act Evaluation (2029)
**Regulation**: AI Act (EU) 2024/1689
**Article 112**: Commission evaluation by August 2029
**Topics**:
- High-risk classification effectiveness
- Conformity assessment procedures
- Market surveillance
- Innovation impact
- Need for amendments
**Relationship**: Will evaluate Article 88c implementation (AI processing under GDPR)
## Preparation Timeline for Organizations
### Now - Late 2026: Planning Phase
**Monitor legislative process**:
- Track amendments during Parliament/Council review
- Watch for changes to timelines or provisions
- Engage with industry associations for input
**Conduct readiness assessment**:
- Which provisions affect your organization?
- What changes are needed to systems and processes?
- What are the resource requirements?
**Begin strategic planning**:
- Cookie banner strategy (remove vs. keep vs. hybrid)
- Analytics tool evaluation
- Data governance framework updates
### Late 2026 - Q3 2027: Pre-Implementation
**Finalize compliance strategy** based on adopted text:
- Detailed gap analysis
- Implementation roadmap
- Budget allocation
- Vendor selection (if needed)
**Update policies and procedures**:
- Privacy policies
- Cookie policies
- Data processing agreements
- Internal compliance manuals
**Training preparation**:
- Identify training needs
- Develop materials
- Schedule sessions
### Q3 2027 - Q1 2028: Article 88a Preparation
**Deadline**: 6 months after entry into force
**Critical actions**:
- [x] Implement Article 88a(3)(c) exemptions
- [x] Remove unnecessary cookie banners
- [x] Update consent mechanisms if retaining banners
- [x] Single-click refuse implementation
- [x] Privacy policy updates
- [x] User communication about changes
**Testing and validation**:
- Consent flow testing
- Analytics implementation verification
- Cross-browser compatibility
- Mobile experience
### Q1 2028 - Q1 2029: Incident Reporting Preparation
**Deadline**: 18 months after entry into force (possibly 24)
**Critical actions**:
- [x] Monitor ENISA portal development
- [x] Update incident response procedures
- [x] Integrate with single entry point
- [x] Train security and compliance teams
- [x] Test reporting workflows
### Q1 2029 - Q3 2029: Browser Signal Preparation
**Deadline**: 24 months after entry into force
**Critical actions**:
- [x] Implement European standards for signal interpretation
- [x] Update consent management platforms
- [x] Test signal handling
- [x] Fallback mechanisms for non-supporting browsers
- [x] User communication about browser-based consent
**Monitor**:
- Standards publication by European standardisation bodies
- Browser vendor implementation progress
- Industry best practices emerging
### Q3 2029 - Q3 2031: Browser Implementation Phase
**Deadline**: 48 months after entry into force (for browsers)
**For website operators**:
- Monitor browser adoption rates of consent controls
- Adapt to changing user behavior (more browser-level blocking)
- Optimize consent strategies for new landscape
**For browser vendors**:
- Standards implementation
- User interface design
- Testing and rollout
- User education
## Risk Factors and Contingencies
### Legislative Process Delays
**Risk**: Trilogue negotiations extend beyond expected timeframe
**Impact**: Later entry into force, shifted implementation deadlines
**Mitigation**: Begin planning based on proposal text; adjust timeline as final text approaches
### Technical Standard Delays
**Risk**: European standardisation bodies take longer than expected to develop browser signal standards
**Impact**: Difficulty implementing Article 88b compliance
**Mitigation**: 24-month website deadline provides buffer; participate in standards development; prepare flexible implementation
### Compliance Challenges
**Risk**: Ambiguities in final text create interpretation difficulties
**Impact**: Uncertain compliance pathways
**Mitigation**: Monitor EDPB and Commission guidance; engage with supervisory authorities; participate in industry coordination
### Market Readiness
**Risk**: Consent management platforms slow to update for Article 88b
**Impact**: Organizations struggle to meet deadlines
**Mitigation**: Early vendor engagement; evaluate multiple solutions; plan custom development if needed
## Quick Reference: Key Dates
| Milestone | Estimated Date | Description |
|-----------|----------------|-------------|
| **Proposal published** | Nov 19, 2025 | Commission proposes Digital Omnibus |
| **Parliament/Council review** | 2026 | First reading, amendments, debate |
| **Trilogue negotiations** | 2026-2027 | Parliament-Council compromise |
| **Final adoption** | Late 2026 or 2027 | Final votes by Parliament and Council |
| **Publication** | 30-60 days after adoption | Official Journal publication |
| **Entry into force** | 20 days after publication | Estimated Q3 2027 |
| **Article 88a deadline** | EIF + 6 months | Estimated Q1 2028 |
| **Single entry point** | EIF + 18 months | Estimated Q1 2029 (ext. Q3 2029) |
| **Article 88b websites** | EIF + 24 months | Estimated Q3 2029 |
| **Article 88b browsers** | EIF + 48 months | Estimated Q3 2031 |
**EIF** = Entry Into Force
**Note**: All dates are estimates based on typical EU legislative timelines. Actual dates will be confirmed once the Regulation is adopted and published.
## Tracking the Process
### Official Sources
**EUR-Lex**: Proposal and final text
- Search: COM(2025) 837
**European Parliament**: Legislative progress
- Procedure file: Check OEIL database after assignment
**Council**: Council positions
- Public register: Consult document register
**EDPB**: Data protection guidance
- Website: edpb.europa.eu
**ENISA**: Incident reporting portal
- Website: enisa.europa.eu
### What to Watch For
**Amendments during legislative process**:
- Changes to timelines (longer or shorter)
- New exemptions or obligations
- Scope adjustments
**Commission delegated/implementing acts**:
- Technical specifications for browser signals
- Common breach notification template
- High-risk breach criteria
**Supervisory authority guidance**:
- EDPB guidelines on Articles 88a/88b
- National DPA positions
- Enforcement priorities
## Related Resources
- [Cookie Consent Reform](./cookies-eprivacy.md) - Details on Articles 88a and 88b
- [Single Entry Point for Incident Reporting](./incident-reporting.md) - ENISA portal details
- [GDPR Amendments](./gdpr-changes.md) - All GDPR changes in Omnibus
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [Impact on Web Analytics and Tracking](./impact-analytics.md) - Action items for analytics at each deadline
- [EDPB-EDPS Joint Opinion on the Digital Omnibus](./edpb-edps-opinion.md) - How the timeline may shift during negotiations
## Key Takeaways
1. **Entry into force estimated Q3 2027** (20 days after Official Journal publication)
2. **Most urgent: Article 88a at 6 months** (cookie consent framework)
3. **Phased implementation**: 6, 18, 24, and 48-month deadlines
4. **Browser signals in two stages**: Websites (24 months), browsers (48 months)
5. **Legislative process ongoing**: Final text and dates may change during 2026-2027 negotiations
6. **Begin planning now**: Don't wait for final adoption to assess impact
7. **Monitor official sources**: EUR-Lex, Parliament, Council, EDPB, ENISA
The phased timeline reflects the complexity of the changes while giving organizations reasonable time to adapt. The shortest deadline (6 months for Article 88a) affects the most organizations but also delivers the biggest benefits—eliminated cookie banners and simplified analytics compliance. Organizations that begin planning now will be well-positioned to capture these benefits as soon as they become available.
## Global Privacy Control (GPC) and Do Not Track (DNT)
URL: https://docs.sealmetrics.com/compliance/gpc-dnt-signals
# GPC and DNT Signals: Why Sealmetrics Doesn't Respond to Them
Auditors and privacy-conscious teams sometimes ask why Sealmetrics does not
react to the Global Privacy Control (GPC) or Do Not Track (DNT) browser
signals. It is a fair question, and the answer is deliberate — not an
oversight.
## What these signals mean
**GPC** is a browser signal through which an individual tells a website:
*"do not sell or share my personal information."* It has legal force in
certain jurisdictions (notably under California's CCPA/CPRA) for businesses
that sell or share personal data.
**DNT** was an earlier attempt at a universal opt-out from cross-site
tracking. It never acquired legal standing, and its own standardization
effort was abandoned.
Both signals share one premise: **there is an identifiable person being
tracked, and that person wants out.**
## Why that premise does not apply here
Honoring an individual opt-out only makes sense when individuals are being
measured. Sealmetrics measures **audiences, not people**:
- **No cookies, no browser storage of any kind.** There is nothing on the
device to opt out of.
- **No cross-site identifiers.** The ephemeral session identifier is derived
per website and cannot link a visitor across sites.
- **No IP addresses in the analytics database**, and country is derived from
the browser's timezone — not from the IP.
- **Raw technical events live for 1 day**; everything retained long-term is
aggregate statistics.
You cannot opt out of an anonymous count for the same reason you cannot opt
out of a turnstile at a stadium entrance: the count contains no *you* to
remove. Responding to GPC would imply that Sealmetrics processes personal
data that could be "sold or shared" — which is precisely what the
architecture is designed to make impossible.
## Protection by default beats opt-out on request
Opt-out models protect only the minority of visitors who know the signal
exists and have it enabled. Sealmetrics' model protects **100% of visitors,
by default, with no action required on their part**. That is a strictly
stronger guarantee than honoring an opt-out — it is the opt-out made
structural.
## What this does *not* change for you
If your business sells or shares personal data through **other** tools
(advertising pixels, data brokers, CRM enrichment), your obligation to honor
GPC for those tools is unaffected. Sealmetrics simply is not part of that
category: it has nothing to stop selling or sharing.
We monitor the regulatory evolution of these signals. If any framework ever
assigns GPC a meaning applicable to exempt, aggregate-only audience
measurement, we will reassess this position — and document any change here.
## Impact on Web Analytics and Tracking
URL: https://docs.sealmetrics.com/compliance/omnibus/impact-analytics
# Impact on Web Analytics and Tracking
**Info:**
The EU Digital Omnibus is a **legislative proposal still under negotiation**; article numbers and text may change before it is in force. Any statement about how Sealmetrics would fall under it is our own reading and a **self-assessment**, not a certification — no supervisory authority certifies analytics tools.
The EU Digital Omnibus fundamentally reshapes the web analytics landscape. By creating a clear exemption for aggregated audience measurement, the regulation validates privacy-first analytics while maintaining restrictions on invasive tracking.
This page analyzes how the Omnibus affects different analytics approaches, who wins and loses, and what website operators should do to prepare.
## The Current Analytics Landscape
### Pre-Omnibus Reality
**Cookie banners everywhere:**
- Approximately 41% of EU websites display cookie banners
- Most analytics tools trigger consent requirements
- Even basic traffic measurement often requires banners
**High rejection rates:**
- 26% of users click "reject all"
- 54% accept without reading (consent fatigue)
- Result: Incomplete or unreliable data
**Data loss from consent denial:**
- Missing traffic from 20-30% of visitors
- Skewed analytics (privacy-conscious users underrepresented)
- Difficulty measuring true website performance
- Business decisions based on incomplete data
**Complex compliance burden:**
- Legal review of cookie policies
- Consent Management Platform (CMP) implementation
- Regular audits of tracking tools
- Vendor assessments and Data Processing Agreements
- Average cost: €400-€5,000+/year depending on site size
### The Analytics Consent Dilemma
Website operators face a difficult choice:
**Option 1: Require consent for analytics**
- ❌ Lose 20-30% of traffic data
- ❌ Cookie banner costs
- ❌ Poor user experience
- ✅ Use full-featured analytics tools
**Option 2: Skip analytics to avoid consent**
- ✅ No cookie banner needed
- ✅ Better user experience
- ❌ Fly blind (no performance data)
- ❌ Cannot optimize conversion, content, or UX
**Option 3: Use consentless analytics**
- ✅ No cookie banner
- ✅ Complete traffic data
- ⚠️ Limited features vs. traditional tools
- ⚠️ Legal uncertainty (until now)
## What the Omnibus Changes for Analytics
**Tip:**
The European data protection authorities **support** the audience measurement exemption in their [Joint Opinion 2/2026](./edpb-edps-opinion.md). They also recommend adding a **contextual advertising exemption** for ads based on page content (not user tracking). This reinforces the legal basis for privacy-first analytics like Sealmetrics.
### The Game-Changing Exemption
**Article 88a(3)(c)** provides a clear legal basis for audience measurement:
> "Creating aggregated information about the usage of an online service to measure the audience of such a service, where it is carried out by the controller of that online service solely for its own use"
**No consent required when:**
1. ✅ Data is **aggregated** (not individual user tracking)
2. ✅ Processing is by the **controller** (website owner)
3. ✅ For the controller's **own use only** (not shared/sold)
### What "Aggregated" Means
**Permitted under exemption:**
- Total page views
- Unique visitors (counted, not tracked)
- Traffic sources (referrer data)
- Geographic location (country/city level)
- Device types and browsers
- Popular pages and content
- Conversion funnels (aggregate)
- Session duration statistics
**Still requires consent:**
- Individual user journey tracking across sessions
- User-level behavioral profiles
- Cross-device tracking
- Persistent user identifiers for non-aggregate purposes
- Retargeting pixels
- Detailed individual-level analytics
**The distinction**: You can **measure the audience** (how many, from where, what they view) without **tracking individuals** (who specifically, what they do over time).
### What "Controller's Own Use" Means
**Permitted:**
- Analyzing traffic to your own website
- Understanding your audience demographics
- Measuring content performance
- Optimizing user experience
- Internal business intelligence
**Requires consent:**
- Sharing analytics data with third parties
- Selling audience insights to advertisers
- Cross-site tracking networks
- Data brokers aggregating across properties
- Advertising platforms using data for targeting
**Key test**: If analytics data never leaves your control and is only used to understand your own service, you're likely exempt.
### First-Party vs. Third-Party Analytics
**First-party analytics (typical exemption scenario):**
- Analytics code on your own domain
- Data stored by you (or processor acting on your behalf)
- Data used only for your own insights
- **Result: NO CONSENT NEEDED**
**Third-party analytics (usually needs consent):**
- Analytics provider tracks across multiple sites
- Provider uses data for their own purposes (ad networks, benchmarking)
- Data shared with other parties
- Cross-site tracking and profiling
- **Result: CONSENT REQUIRED**
**Important nuance**: Using a third-party analytics **tool** is fine if:
- You remain the controller
- Provider is your processor (GDPR Article 28)
- Data is not shared beyond processing your site
- Provider doesn't use your data for their purposes
**Example:**
- ✅ **Sealmetrics**: First-party, consentless, data not shared = EXEMPT
- ✅ **Self-hosted Matomo**: First-party, your data only = EXEMPT
- ⚠️ **Google Analytics 4** (configured for no data sharing): Likely exempt if properly configured
- ❌ **Google Analytics with ads features**: Needs consent (data used for advertising)
- ❌ **Facebook Pixel**: Needs consent (cross-site tracking, ad targeting)
- ❌ **Ad network tracking**: Needs consent (third-party profiling)
## Winners and Losers
### Winners
#### 1. Consentless Analytics Providers
Platforms that already operate under privacy-first principles are **validated and advantaged**:
**Characteristics:**
- No cookies or cookieless design
- First-party data collection
- Aggregated measurement focus
- No cross-site tracking
- No data sharing or selling
**Examples:**
- Sealmetrics
- Plausible Analytics
- Fathom Analytics
- Simple Analytics
- Self-hosted Matomo (privacy mode)
**Advantage**: These tools are already compliant with Article 88a(3)(c) and can market "no consent needed under EU Digital Omnibus."
#### 2. First-Party Data Solutions
**Server-side analytics:**
- Data processed on website's own servers
- Complete control over data
- No third-party dependencies
- Naturally fits "controller's own use" requirement
**Data warehouses and BI tools:**
- Tools that aggregate first-party data
- Business intelligence platforms
- Internal analytics dashboards
#### 3. Privacy-by-Design Platforms
**Privacy-enhancing technologies (PETs):**
- Differential privacy
- Federated analytics
- On-device computation
- Aggregated-only outputs
These technologies align perfectly with the "aggregated measurement" exemption.
#### 4. Website Operators (Small to Medium)
**Small businesses and SMEs:**
- Can finally get analytics without cookie banner costs
- No CMP subscription needed (€400-€2,000/year savings)
- No legal review expenses
- Simplified compliance
**Content publishers:**
- Understand audience without consent barriers
- Optimize content based on complete data
- Improve user experience (no banners)
**Public sector:**
- Government websites can measure usage
- Universities and research sites simplified
- Public services more accessible
### Losers
#### 1. Cross-Site Tracking Networks
**Ad tech platforms relying on third-party cookies:**
- Still require consent under Article 88a(3)(c)
- Cannot benefit from audience measurement exemption
- Browser signal adoption will further impact them
**Behavioral advertising networks:**
- Cross-site profiling requires consent
- Retargeting pixels need consent
- Audience segmentation across properties needs consent
#### 2. Third-Party Cookie-Dependent Solutions
**Traditional analytics with data sharing:**
- Google Analytics with advertising features
- Analytics platforms that benchmark across clients
- Tools that monetize via data sharing
**Impact:** Must either:
- Restructure to be first-party only, OR
- Continue requiring consent (competitive disadvantage)
#### 3. Consent Management Platforms (CMPs)
**Reduced market:**
- 60% of websites may no longer need cookie banners
- Smaller addressable market for CMP vendors
- Pressure on pricing
**Counterbalance:**
- Remaining consent requirements are more complex
- Browser signal integration creates new opportunities
- Article 88a(4) compliance requires sophisticated UX
**Likely outcome:** Market contracts but remaining use cases become more sophisticated.
#### 4. Advertising Platforms Relying on Consent
**High-consent-friction models:**
- Platforms requiring granular consent
- Retargeting and behavioral advertising
- Cross-device tracking
**Challenge:** Users may set browser signals to reject tracking by default, reducing consent rates even further when Article 88b browser controls arrive (48 months).
## Browser Signals Impact on Analytics
### Article 88b Timeline
**24 months**: Websites must support machine-readable consent signals
**48 months**: Browser vendors must provide user controls
### Expected User Behavior
**Privacy-conscious defaults:**
- Browsers may ship with "reject tracking" as default
- Users who care will configure strict settings once
- Most users may keep defaults
**Impact on consent-required analytics:**
- Lower consent rates than current cookie banners
- One-time browser decision vs. per-site decision
- Could reduce tracking consent to 10-30% of users
**Impact on exempted analytics:**
- No impact—exempt is exempt
- Consentless analytics unaffected by browser signals
- Competitive advantage grows larger
### Media Service Provider Exemption
**Article 88b(3)**: Media service providers (news sites, publishers) are **EXEMPT** from browser signal requirements.
**What this means:**
- News publishers can still show cookie banners
- Can override browser signals for their own consent requests
- Protects publisher revenue models dependent on advertising
**Analytics implications:**
- Publishers can still ask for analytics + advertising consent
- May create two-tier system: publishers vs. other sites
- User experience: Some sites respect browser, others still ask
## Sealmetrics Positioning
### Already Compliant with Article 88a(3)(c)
Sealmetrics is designed precisely for the exemption criteria:
**✅ Aggregated measurement:**
- No individual user tracking across sessions
- Privacy-first architecture
- Anonymized data collection
**✅ First-party data only:**
- Data belongs to the website owner (controller)
- Sealmetrics acts as processor
- No cross-site tracking
**✅ For controller's own use:**
- Data not shared with third parties
- Not sold or monetized by Sealmetrics
- Used solely for client's audience insights
### No Consent Banners Needed
**Current advantage, future certainty:**
- Sealmetrics already operates without consent requirements
- Article 88a(3)(c) provides explicit legal basis
- Clients can confidently deploy without cookie banners
### Competitive Advantages Post-Omnibus
**1. Legal certainty:**
- Clear alignment with Article 88a(3)(c)
- No ambiguity about consent requirements
- Simplified compliance for clients
**2. Complete data:**
- No data loss from consent rejection
- Accurate audience measurement
- Better business intelligence
**3. Cost savings:**
- No cookie banner implementation
- No CMP subscription
- No ongoing legal review
**4. Better user experience:**
- No interruptions
- Faster page loads
- Privacy-respecting
**5. Future-proof for browser signals:**
- Exempt analytics unaffected by Article 88b
- No dependency on consent rates
- Stable data quality regardless of browser defaults
## Recommendations for Website Operators
### Audit Your Current Analytics Setup
**Identify consent-dependent tools:**
Create an inventory:
1. **Analytics platforms**: Which tools track users?
2. **Advertising pixels**: Facebook, Google Ads, retargeting?
3. **Third-party scripts**: Social media widgets, embedded content?
4. **Cross-site tracking**: Affiliate networks, attribution tools?
**Classify each tool:**
- ✅ **Exempt** (first-party, aggregated, own use)
- ⚠️ **Consent required** (third-party, tracking, profiling)
- ❓ **Uncertain** (need further analysis)
### Evaluate Consentless Alternatives
**For basic analytics needs:**
If you currently use consent-dependent analytics for basic traffic measurement, consider switching to:
- Consentless platforms (Sealmetrics, Plausible, Fathom)
- Self-hosted privacy-focused solutions (Matomo privacy mode)
- Server-side analytics (custom logging)
**Cost-benefit analysis:**
- Compare CMP costs + partial data vs. consentless + complete data
- Factor in user experience improvements
- Consider compliance simplification
**For advanced tracking needs:**
If you need individual user tracking, cross-device tracking, or behavioral profiling:
- Consent will still be required
- Focus on Article 88a(4) compliance (single-click refuse, 6-month cooldown)
- Prepare for Article 88b browser signals
- Optimize consent rates through transparency and value exchange
### Prepare for Browser Signal Era
**Timeline awareness:**
- 24 months (≈2027-2028): Implement browser signal support
- 48 months (≈2029-2030): Browsers deploy user controls
**Technical preparation:**
- Monitor European standardisation body standards development
- Plan infrastructure for machine-readable signals
- Consider how to handle consent/rejection programmatically
- Test compatibility with expected signal formats
**Strategic preparation:**
- Reduce dependency on consent-based tracking
- Shift to first-party data strategies
- Build direct relationships with users
- Invest in owned analytics infrastructure
### Hybrid Approach
**Many websites will use:**
**Tier 1 - No consent (Article 88a(3)(c) exempt):**
- First-party audience measurement
- Basic traffic analytics
- Content performance
- User experience optimization
**Tier 2 - Consent required:**
- Advanced behavioral tracking
- Advertising pixels
- Retargeting
- Cross-device attribution
**Implementation:**
- Load Tier 1 immediately (no consent needed)
- Request consent for Tier 2
- Ensure Tier 1 provides enough value to operate without Tier 2
### Document Your Compliance
**Privacy policy updates:**
- Explain use of Article 88a(3)(c) exemption
- Document which analytics are exempt vs. consent-based
- Describe data flows and retention
**Internal documentation:**
- Legal basis for each processing activity
- Data Processing Agreements with analytics vendors
- Technical safeguards for aggregation
**Be ready to demonstrate:**
- Data is aggregated
- Processing is for your own use only
- No sharing beyond necessary processing
## Comparison Matrix
| Analytics Type | Consent Needed? | Article 88a Basis | Browser Signals Impact | Data Quality |
|---------------|----------------|-------------------|----------------------|--------------|
| **First-party, aggregated** | ❌ No | 88a(3)(c) exemption | None (exempt) | 100% |
| **First-party, individual tracking** | ⚠️ Depends | 88a(1) or Art 6 | High (if consent basis) | Varies |
| **Third-party analytics (no sharing)** | ❌ No | 88a(3)(c) if structured properly | None (exempt) | 100% |
| **Third-party with data sharing** | ✅ Yes | 88a(1) consent | High | 10-70% |
| **Ad networks, retargeting** | ✅ Yes | 88a(1) consent | Very high | 10-30% |
| **Cross-site tracking** | ✅ Yes | 88a(1) consent | Very high | 10-30% |
## Timeline and Action Items
### Immediate (Now - 6 months after entry into force)
- [ ] Audit current analytics and tracking tools
- [ ] Classify tools as exempt vs. consent-required
- [ ] Evaluate consentless alternatives for basic analytics
- [ ] Update privacy policies to reference Article 88a
- [ ] Consider removing unnecessary cookie banners
### Short-term (6-24 months)
- [ ] Implement Article 88a(4) compliant consent UX (single-click refuse, 6-month cooldown)
- [ ] Migrate to first-party data strategies where possible
- [ ] Monitor standardization efforts for browser signals
- [ ] Train teams on new compliance requirements
- [ ] Optimize analytics stack for post-Omnibus landscape
### Medium-term (24-48 months)
- [ ] Implement browser signal support (Article 88b)
- [ ] Prepare infrastructure for machine-readable consent
- [ ] Test interoperability with browser controls
- [ ] Reduce dependency on consent-dependent tracking
- [ ] Build resilient analytics architecture
## Frequently Asked Questions
### Can I use Google Analytics without consent under the Omnibus?
**It depends on configuration:**
- **GA4 with no data sharing, no advertising features, configured for first-party use only**: Likely exempt under Article 88a(3)(c)
- **GA4 with advertising features, cross-site tracking, or data shared with Google for their purposes**: Consent required
**Key factors:**
- Are you the sole controller or is Google a joint controller?
- Is data used only for your audience measurement?
- Are advertising or remarketing features enabled?
**Recommendation**: Consult with privacy counsel on your specific GA4 configuration, or use a clearly exempt platform like Sealmetrics.
### Does "aggregated" mean I cannot see any individual page views?
**No.** "Aggregated" in Article 88a(3)(c) means the **purpose** is aggregate measurement, not that you can never see granular data.
**Permitted:**
- Viewing individual page view events (to calculate aggregates)
- Seeing a specific referrer for a specific session
- Analyzing a particular conversion path in aggregate
**Not permitted without consent:**
- Building persistent individual user profiles
- Tracking specific users across sessions for behavioral analysis
- Creating detailed dossiers on individual visitors
**Analogy**: A store can count customers and see what each person buys (to calculate totals), but cannot track individuals over time to profile their behavior.
### What about heatmaps and session recordings?
**Session recordings (Hotjar, FullStory, etc.)**: Almost certainly **require consent**.
**Reasoning:**
- Individual-level tracking
- Detailed behavioral data
- Not "aggregated measurement"
- High privacy risk
**Heatmaps**: **Possibly exempt** if truly aggregated.
**Exempt approach:**
- Aggregate click positions across all users
- No individual session identification
- Used only for UX optimization on your site
**Requires consent:**
- Individual session heatmaps
- Linked to user identities
- Shared with third parties
**Recommendation**: If you want to avoid consent, use truly aggregated heatmaps or A/B testing tools that don't track individuals.
### Can I share analytics data with my agency or consultants?
**Yes, if they are processors acting on your behalf** under GDPR Article 28.
**Structure:**
- Data Processing Agreement in place
- Processor acts only on your instructions
- Data used solely for your purposes (audience measurement)
- No independent use by processor
**No, if:**
- Processor uses data for their own purposes
- Data is shared with processor's other clients
- Processor becomes a joint controller
**Article 88a(3)(c) requires "solely for its own use"**—this is satisfied when processors provide services to you, but not when data is shared more broadly.
## Related Resources
- [Cookie Consent Reform](./cookies-eprivacy.md) - Full details on Article 88a
- [GDPR Amendments](./gdpr-changes.md) - Other GDPR changes in the Omnibus
- [EDPB-EDPS Joint Opinion](./edpb-edps-opinion.md) - Regulatory validation of analytics exemption
- [EU Digital Omnibus Overview](./index.md) - Complete regulation guide
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) - The GDPR basis for first-party, aggregated measurement
- [What We Track vs What We Don’t](/security-privacy/what-we-track) - Exactly what Sealmetrics collects under the exemption
## Key Takeaways
1. **First-party, aggregated analytics = NO CONSENT NEEDED** under Article 88a(3)(c)
2. **Third-party tracking, profiling, ad tech = CONSENT REQUIRED**
3. **Winners**: Consentless analytics, first-party data, privacy-first platforms
4. **Losers**: Cross-site trackers, third-party cookie networks, consent-dependent models
5. **Browser signals coming** in 24-48 months will further impact consent-based tracking
6. **Sealmetrics expects to fall within** the Article 88a(3)(c) exemption once it is in force — our own reading, on a text still under negotiation
7. **Audit your analytics** to identify what needs consent and what doesn't
8. **Prepare for first-party future** by reducing consent dependencies now
The Digital Omnibus creates a clear path for privacy-respecting analytics while cracking down on invasive tracking. Website operators who embrace consentless, first-party measurement will gain competitive advantages in data quality, user experience, and compliance simplicity.
## EDPB-EDPS Joint Opinion on the Digital Omnibus
URL: https://docs.sealmetrics.com/compliance/omnibus/edpb-edps-opinion
# EDPB-EDPS Joint Opinion on the Digital Omnibus
On February 10, 2026, the **European Data Protection Board (EDPB)** and the **European Data Protection Supervisor (EDPS)** published their official Joint Opinion on the Digital Omnibus proposal. This document represents the authoritative position of European data protection authorities on the proposed changes.
**Info:**
The Joint Opinion is a **consultative document**—it expresses the regulators' position but does not change the legislative proposal. The European Parliament and Council may consider these recommendations during negotiations, but are not bound by them. The original Commission proposal (COM(2025) 837) remains the basis for legislation.
## Document Details
| | |
|---|---|
| **Title** | EDPB-EDPS Joint Opinion 2/2026 on the Proposal for a Regulation as regards the simplification of the digital legislative framework (Digital Omnibus) |
| **Adopted** | 10 February 2026 |
| **Published** | 11 February 2026 |
| **Official page** | [EDPB Website](https://www.edpb.europa.eu/our-work-tools/our-documents/edpbedps-joint-opinion/edpb-edps-joint-opinion-22026-proposal_en) |
| **PDF** | [Full document (PDF)](https://www.edpb.europa.eu/system/files/2026-02/edpb_edps_jointopinion_202602_digitalomnibus_en.pdf) |
| **Press release** | [EDPB News](https://www.edpb.europa.eu/news/news/2026/digital-omnibus-edpb-and-edps-support-simplification-and-competitiveness-while_en) |
## Overall Position
The EDPB and EDPS **support the simplification objectives** of the Digital Omnibus while raising **significant concerns** about specific provisions that could adversely affect protection levels.
### What They Support
- Simplification of the digital regulatory framework
- Reducing compliance burden for businesses
- Strengthening effective exercise of individual rights
- Boosting EU competitiveness
- Changes to scientific research provisions
- Raised threshold for breach notifications (with caveats)
- New exception for biometric authentication under individual's control
- Cookie consent fatigue solutions (in principle)
### What Concerns Them
- Personal data definition changes
- Implementing acts for pseudonymization
- Potential reduction in protection levels
- Fragmentation of terminal equipment rules
- Some AI processing provisions
---
## Key Positions by Topic
### 1. Personal Data Definition
**Warning:**
The regulators **firmly oppose** the proposed changes to the personal data definition, recommending their complete removal from the proposal.
**Commission proposal**: Codify "reasonably likely to be used" standard with entity-specific determination.
**EDPB-EDPS concerns**:
1. **Unnecessary changes**: The current GDPR definition, interpreted through CJEU case law, works well. Changes risk creating new uncertainties.
2. **Reduced protection**: Entity-specific determination could exclude data from GDPR protection when it should be covered.
3. **Legal fragmentation**: Different entities having different obligations for the same data creates complexity, not simplification.
4. **Undermining CJEU jurisprudence**: The proposed wording may contradict established case law rather than codify it.
**EDPB-EDPS recommendation**:
> "The EDPB and the EDPS recommend that the proposed amendments to the concept of personal data are removed from the Proposal."
**Implication**: If Parliament/Council follows this recommendation, Articles related to personal data definition would remain unchanged from current GDPR.
---
### 2. Pseudonymization and Implementing Acts
**Warning:**
The regulators oppose giving the Commission power to determine what constitutes personal data through implementing acts.
**Commission proposal**: Commission can adopt implementing acts specifying criteria for effective pseudonymization.
**EDPB-EDPS concerns**:
1. **Competence question**: Whether data is "personal" is a matter of fundamental rights law, not technical specification. The Commission should not have authority to make this determination.
2. **Scope creep risk**: Implementing acts could be used to narrow GDPR's scope by declaring certain data "not personal."
3. **EDPB role**: The EDPB already provides guidance on pseudonymization. Commission implementing acts could conflict with or undermine this guidance.
**EDPB-EDPS recommendation**:
> Technical guidance on pseudonymization should remain with the EDPB, not be transferred to Commission implementing acts.
---
### 3. Cookie Consent and Article 88a
**Tip:**
The regulators **strongly support** addressing cookie banner fatigue, while requesting specific improvements.
**What they support**:
- Moving cookie consent under GDPR framework
- Exemption for audience measurement (Article 88a(3)(c))
- Single-click refuse requirement
- 6-month cooldown after refusal
**Concerns and recommendations**:
1. **Contextual advertising exception**: The EDPB-EDPS recommends creating an **explicit exemption for contextual advertising** that doesn't involve tracking. This would allow ads based on page content without consent, while tracking-based ads still require consent.
2. **Terminal equipment fragmentation**: Moving only personal data cookies to GDPR while leaving non-personal data cookies in ePrivacy creates two parallel regimes. They recommend either full integration or clearer coordination.
3. **Browser signals (Article 88b)**: Support the concept but want clearer technical standards and interoperability requirements.
**Notable quote**:
> "The EDPB and the EDPS strongly support the objective of providing for a regulatory solution to address consent fatigue and the proliferation of cookie banners."
---
### 4. AI Processing (Article 88c)
**Note:**
The regulators accept the legitimate interest basis for AI but request stronger safeguards.
**What they accept**:
- Recognizing AI development as a legitimate interest under Article 6(1)(f)
- The balance test approach
- Special category data safeguards (Article 9(2)(k))
**Concerns**:
1. **Web scraping**: Specific concern about large-scale web scraping for AI training without adequate safeguards.
2. **Right to object**: Want stronger guarantees that the unconditional right to object is meaningful and enforceable.
3. **Balance test application**: Request clearer criteria for when data subject rights override AI development interests.
4. **Children's data**: Want explicit, stronger protections beyond "in particular."
**EDPB-EDPS recommendation**:
> More specific safeguards needed, particularly for web scraping scenarios and effective right to object implementation.
---
### 5. Data Breach Notification Threshold
**Note:**
The regulators accept the raised threshold but want to ensure it doesn't reduce accountability.
**Commission proposal**: Change notification threshold from "risk" to "high risk."
**EDPB-EDPS position**:
1. **Accept in principle**: Reducing notification burden for minor incidents is reasonable.
2. **Template control**: The EDPB wants to **maintain control** over breach notification templates and "high risk" criteria lists, rather than merely being "consulted" by the Commission.
3. **Supervisory authority information**: Ensure that streamlined reporting still gets necessary information to national DPAs.
**EDPB-EDPS recommendation**:
> "The EDPB should have the competence to adopt the templates and lists, rather than the Commission after consultation."
---
### 6. Right of Access and "Abusive" Requests
**Warning:**
The regulators worry the lower burden of proof could enable unjustified refusals.
**Commission proposal**: Lower burden of proof for controllers to refuse "abusive" access requests.
**EDPB-EDPS concerns**:
1. **Fundamental right**: Right of access is a fundamental right; lowering barriers to refusal could undermine it.
2. **Abuse of the abuse exception**: Controllers might too easily label legitimate requests as "abusive."
3. **Burden shift**: The proposal shifts burden of proof in a way that may disadvantage data subjects.
**EDPB-EDPS recommendation**:
> Maintain sufficient safeguards to ensure legitimate access requests are not refused under the guise of being "abusive."
---
### 7. Data Acquis Consolidation
**Tip:**
The regulators support consolidating data laws but want clarity on oversight.
**Areas addressed**:
1. **Data intermediation services**: Support integration into Data Act but want clear rules on how DPAs interact with intermediary oversight.
2. **Data altruism organizations**: Want maintained oversight mechanisms.
3. **Coordination between authorities**: Request clear delineation of responsibilities between data protection and other authorities.
---
### 8. Additional Recommendations
The Joint Opinion includes recommendations **not addressed** in the original proposal:
1. **Collective representation**: EDPB-EDPS recommends allowing organizations to represent data subjects in complaints **without requiring individual mandates** (expanding Article 80 GDPR).
2. **Legitimate interest lists**: The regulators **oppose** any Commission power to create binding lists of legitimate interests, as this could expand lawful processing beyond what the GDPR intended.
3. **NIS2 coordination**: Request clearer rules for coordination between cybersecurity authorities (under NIS2) and data protection authorities.
---
## What This Means for the Digital Omnibus
### Possible Outcomes
| EDPB-EDPS Recommendation | Likelihood of Adoption | Impact if Adopted |
|-------------------------|----------------------|-------------------|
| Remove personal data definition changes | Medium-High | Status quo maintained |
| Remove Commission implementing acts for pseudonymization | Medium | EDPB retains guidance role |
| Add contextual advertising exception | Medium | Broader cookie banner relief |
| Stronger AI safeguards | Medium-High | More conditions on Article 88c |
| EDPB controls breach templates | High | Technical change only |
| Maintain access request protections | Medium | Balance preserved |
### Timeline Implications
The Joint Opinion was published during the **feedback period** (deadline: March 9, 2026). The European Parliament's ITRE and LIBE committees will consider this input as they develop their positions.
**Expected impact on timeline**:
- Committee rapporteur appointments: Q1 2026 (ongoing)
- Parliament/Council positions: Q2 2026 (may incorporate EDPB-EDPS recommendations)
- Trilogue negotiations: Summer 2026 (contested provisions will be negotiated)
- Final text: May differ significantly from Commission proposal
---
## Implications for Analytics and Sealmetrics
### Cookie Consent Exemption: Strengthened
The EDPB-EDPS **supports** the Article 88a(3)(c) exemption for audience measurement. Their recommendation for a contextual advertising exception, if adopted, would further reduce consent requirements.
**For Sealmetrics users**: The Joint Opinion **reinforces** the legal basis for consentless analytics. The regulators are not challenging the audience measurement exemption.
### First-Party Analytics: Validated
The regulators' concerns focus on:
- Third-party tracking
- Cross-site profiling
- Web scraping for AI
First-party, aggregated analytics (Sealmetrics' model) is **not targeted** by EDPB-EDPS concerns.
### Contextual Advertising: Potential New Exemption
If the EDPB-EDPS recommendation for contextual advertising is adopted:
- Ads based on page content (not user tracking) would be exempt
- This benefits privacy-respecting advertising models
- Could expand the "no consent needed" category
---
## How to Follow Developments
### Official Sources
- **EDPB**: [edpb.europa.eu](https://www.edpb.europa.eu/)
- **European Parliament**: [europarl.europa.eu](https://www.europarl.europa.eu/)
- **EUR-Lex**: [eur-lex.europa.eu](https://eur-lex.europa.eu/) (for official texts)
- **Have Your Say portal**: [ec.europa.eu/info/law/better-regulation/have-your-say](https://ec.europa.eu/info/law/better-regulation/have-your-say_en)
### Key Dates
| Date | Event |
|------|-------|
| November 19, 2025 | Commission proposal published |
| February 10, 2026 | EDPB-EDPS Joint Opinion adopted |
| **March 9, 2026** | **Digital Omnibus feedback deadline** |
| March 11, 2026 | Digital Fitness Check feedback deadline |
| Q2 2026 | Expected Parliament/Council positions |
| Summer 2026 | Trilogue negotiations |
| Late 2026 / Early 2027 | Expected final adoption |
---
## Related Resources
- [EU Digital Omnibus Overview](./index.md) - Complete guide to the proposal
- [Cookie Consent Reform](./cookies-eprivacy.md) - Article 88a details
- [GDPR Amendments](./gdpr-changes.md) - Personal data definition, AI processing
- [AI Act Amendments](./ai-act-amendments.md) - Article 88c legitimate interest
- [Impact on Web Analytics](./impact-analytics.md) - What this means for analytics
- [Is Sealmetrics GDPR, ePrivacy, CCPA, and PECR Compliant?](/compliance/compliance-overview/is-sealmetrics-privacy-compliant) - How the audience-measurement model stands today
- [Why Sealmetrics Can Measure Without Consent](/security-privacy/why-no-consent) - Why first-party analytics is not the regulators' concern
## Key Takeaways
1. **Joint Opinion is consultative** - It expresses regulators' views but doesn't change the proposal
2. **Strong support for simplification goals** - EDPB-EDPS agrees with reducing complexity
3. **Personal data definition: opposed** - Regulators recommend removing these changes
4. **Cookie exemption: supported** - Article 88a(3)(c) is not challenged
5. **Contextual advertising: new recommendation** - Could expand exemptions if adopted
6. **AI processing: cautious acceptance** - With requests for stronger safeguards
7. **Breach threshold: accepted** - But EDPB wants control over templates
8. **Final text may differ** - Parliament/Council negotiations will determine outcome
The Joint Opinion provides valuable insight into how European data protection authorities view the Digital Omnibus. While they support simplification, they're vigilant about maintaining protection levels. The final regulation will likely reflect compromises between the Commission's efficiency goals and the regulators' protection concerns.
---
# Use Cases
## Use Cases
URL: https://docs.sealmetrics.com/use-cases
# Use Cases
Complete implementation guides tailored to your business type. Each guide includes ready-to-use code examples for tracking the full customer journey.
## Choose Your Business Type
---
## Quick Comparison
| Use Case | Key Conversion | Typical Funnel |
|----------|----------------|----------------|
| **E-commerce** | `purchase` with revenue | Product → Cart → Checkout → Purchase |
| **SaaS** | `signup`, `subscription` | Pricing → Trial → Onboarding → Paid |
| **Lead Gen** | `lead`, `demo_request` | Content → CTA → Form → Submit |
| **Content** | `newsletter_signup` | Article → Engage → Subscribe |
---
## What's Included in Each Guide
Every use case guide includes:
- **Step-by-step installation** with content grouping
- **Ready-to-use code** for your tracking events
- **Platform-specific examples** (WordPress, Shopify, React, etc.)
- **Complete funnel diagram** showing all events
- **Key metrics** to analyze in your dashboard
---
## Not Sure Which to Choose?
Most businesses combine elements from multiple use cases:
| Your Business | Primary | Secondary |
|---------------|---------|-----------|
| Online store with blog | E-commerce | Content |
| Software with free trial | SaaS | Lead Gen |
| Agency with case studies | Lead Gen | Content |
| News site with subscriptions | Content | SaaS |
Start with your primary business model, then add tracking from secondary guides as needed.
---
## Need Something Different?
These guides cover the most common scenarios. For custom implementations:
- **[Tracker API Reference](/implementation/tracker/api-reference)** - Complete technical documentation
- **[Step-by-Step Guide](/implementation/tracker/step-by-step-guide)** - General implementation walkthrough
- **Support**: support@sealmetrics.com
## Related documentation
- [Installation](/implementation/tracker/installation) — add the tracking script before following any use-case guide
- [Understanding Event Properties in Sealmetrics](/implementation/custom-properties/event-properties) — the event and property model shared by every guide
- [E-commerce Conversion Tracking](/implementation/ecommerce-conversion-tracking) — reference for the purchase and revenue events
- [Conversions Report](/reports/conversions) — where your tracked conversions appear
- [Funnel Report](/reports/funnel) — build the funnels described in each guide
## E-commerce Store
URL: https://docs.sealmetrics.com/use-cases/ecommerce
# E-commerce Implementation Guide
To track an online store with Sealmetrics, add the tracking script to your store's header, then instrument three event types across the funnel: **pageviews** (automatic, for product and category pages), **microconversions** via `sealmetrics.micro()` (add to cart, begin checkout), and **conversions** via `sealmetrics.conv()` (purchase, with revenue and items). This guide covers each step with copy-paste examples for WooCommerce, Shopify, Magento, and PrestaShop.
## What You'll Track
| Event Type | Example | Purpose |
|------------|---------|---------|
| Pageviews | Product page, category, cart | Traffic analysis |
| Microconversions | Add to cart, begin checkout | Funnel analysis |
| Conversions | Purchase | Revenue attribution |
---
## Step 1: Basic Installation
Add the tracking script to your store's header:
```html
```
### With Content Grouping
Use different groups for different page types:
```html
```
---
## Step 2: Track Add to Cart
Track when users add products to their cart.
### Basic Implementation
```javascript
document.querySelectorAll('.add-to-cart-button').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('add_to_cart', {
product_id: this.dataset.productId,
product_name: this.dataset.productName,
price: this.dataset.price,
currency: 'EUR'
});
});
});
```
### WooCommerce (WordPress)
```php
// In functions.php or custom plugin
add_action('wp_footer', function() {
if (!is_product()) return;
?>
```
### Magento 2
```javascript
// In custom module or theme JS
require(['jquery'], function($) {
$(document).on('click', '#product-addtocart-button', function() {
var form = $('#product_addtocart_form');
sealmetrics.micro('add_to_cart', {
product_id: $('[name="product"]').val(),
product_name: $('.page-title span').text(),
price: $('.price-final_price .price').first().text().replace(/[^0-9.,]/g, ''),
quantity: $('#qty').val()
});
});
});
```
### PrestaShop
```javascript
// In custom.js or theme
document.addEventListener('click', function(e) {
if (e.target.matches('.add-to-cart')) {
var productInfo = document.querySelector('[data-product]');
if (productInfo) {
var product = JSON.parse(productInfo.dataset.product);
sealmetrics.micro('add_to_cart', {
product_id: product.id,
product_name: product.name,
price: product.price_amount,
currency: prestashop.currency.iso_code
});
}
}
});
```
---
## Step 3: Track Checkout Funnel
Track each step of the checkout process.
### Complete Funnel Example
```javascript
// Step 1: View cart
// On cart page load
sealmetrics.micro('view_cart', {
items_count: document.querySelectorAll('.cart-item').length.toString(),
cart_value: document.querySelector('.cart-total').dataset.value
});
// Step 2: Begin checkout
document.querySelector('.checkout-button').addEventListener('click', function() {
sealmetrics.micro('begin_checkout', {
cart_value: this.dataset.cartTotal
});
});
// Step 3: Add contact info
document.querySelector('#contact-form').addEventListener('submit', function() {
sealmetrics.micro('add_contact_info');
});
// Step 4: Add shipping info
document.querySelector('#shipping-form').addEventListener('submit', function() {
sealmetrics.micro('add_shipping_info', {
shipping_method: document.querySelector('[name="shipping"]:checked').value
});
});
// Step 5: Add payment info
document.querySelector('#payment-form').addEventListener('submit', function() {
sealmetrics.micro('add_payment_info', {
payment_method: document.querySelector('[name="payment"]:checked').value
// ... see full example at https://docs.sealmetrics.com/use-cases/ecommerce
```
### WooCommerce Checkout
```php
add_action('wp_footer', function() {
if (!is_checkout()) return;
?>
// Track checkout completion steps based on page
{% if checkout.shipping_address %}
sealmetrics.micro('add_shipping_info', {
shipping_method: '{{ checkout.shipping_rate.title | escape }}'
});
{% endif %}
{% endif %}
```
---
## Step 4: Track Purchases
Track completed orders on the thank-you page.
### Basic Implementation
```html
```
**Tip:**
### WooCommerce
```php
add_action('woocommerce_thankyou', function($order_id) {
// Prevent duplicate tracking on refresh
if (get_post_meta($order_id, '_sealmetrics_tracked', true)) return;
$order = wc_get_order($order_id);
// Build items array
$items = array();
foreach ($order->get_items() as $item) {
$product = $item->get_product();
$items[] = array(
'product_name' => $item->get_name(),
'product_id' => $product ? $product->get_id() : '',
'sku' => $product ? $product->get_sku() : '',
'price' => $item->get_total() / max($item->get_quantity(), 1),
'quantity' => $item->get_quantity(),
'category' => wp_strip_all_tags(wc_get_product_category_list($product ? $product->get_id() : 0)),
);
}
?>
// ... see full example at https://docs.sealmetrics.com/use-cases/ecommerce
```
### Shopify
In **Settings → Checkout → Additional scripts**:
```html
{% if first_time_accessed %}
{% endif %}
```
### Magento 2
```php
// In success.phtml or via layout XML
getOrder();
if ($order && !$order->getSealmetricsTracked()):
$items = array();
foreach ($order->getAllVisibleItems() as $item) {
$items[] = array(
'product_name' => $item->getName(),
'product_id' => $item->getProductId(),
'sku' => $item->getSku(),
'price' => $item->getPrice(),
'quantity' => (int)$item->getQtyOrdered(),
);
}
?>
setSealmetricsTracked(true)->save();
endif;
?>
```
### PrestaShop
```php
// In OrderConfirmationController or hook
public function hookDisplayOrderConfirmation($params)
{
$order = $params['order'];
if ($order->sealmetrics_tracked) return '';
$items = array();
foreach ($order->getProducts() as $product) {
$items[] = array(
'product_name' => $product['product_name'],
'product_id' => $product['product_id'],
'sku' => $product['product_reference'],
'price' => (float)$product['unit_price_tax_incl'],
'quantity' => (int)$product['product_quantity'],
'category' => $product['category'],
);
}
$output = '';
$order->sealmetrics_tracked = true;
$order->save();
// ... see full example at https://docs.sealmetrics.com/use-cases/ecommerce
```
---
## Step 5: Additional E-commerce Events
### Wishlist
```javascript
document.querySelectorAll('.add-to-wishlist').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('add_to_wishlist', {
product_id: this.dataset.productId,
product_name: this.dataset.productName
});
});
});
```
### Product Quick View
```javascript
document.querySelectorAll('.quick-view').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('quick_view', {
product_id: this.dataset.productId
});
});
});
```
### Remove from Cart
```javascript
document.querySelectorAll('.remove-from-cart').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('remove_from_cart', {
product_id: this.dataset.productId
});
});
});
```
### Apply Coupon
```javascript
document.querySelector('#apply-coupon').addEventListener('click', function() {
var couponCode = document.querySelector('#coupon-input').value;
sealmetrics.micro('apply_coupon', {
coupon_code: couponCode
});
});
```
### Search
```javascript
document.querySelector('#search-form').addEventListener('submit', function() {
var query = document.querySelector('#search-input').value;
sealmetrics.micro('search', {
search_term: query
});
});
```
---
## Complete E-commerce Funnel
```
┌─────────────────────────────────────────────────────────────────┐
│ E-COMMERCE FUNNEL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Landing Page ──► Product Page ──► Add to Cart ──► Cart │
│ (pageview) (pageview) (micro) (micro) │
│ │
│ │ │ │
│ ▼ ▼ │
│ Begin Checkout ──► Shipping Info ──► Payment ──► Purchase │
│ (micro) (micro) (micro) (CONV) │
│ │
└─────────────────────────────────────────────────────────────────┘
```
| Step | Event Type | Function |
|------|------------|----------|
| Landing | Pageview | Automatic |
| Product view | Pageview | Automatic |
| Add to cart | Micro | `sealmetrics.micro('add_to_cart')` |
| View cart | Micro | `sealmetrics.micro('view_cart')` |
| Begin checkout | Micro | `sealmetrics.micro('begin_checkout')` |
| Add shipping | Micro | `sealmetrics.micro('add_shipping_info')` |
| Add payment | Micro | `sealmetrics.micro('add_payment_info')` |
| **Purchase** | **Conversion** | `sealmetrics.conv('purchase', amount)` |
---
## Dashboard Analysis
After implementing, you can analyze:
### Traffic Sources
- Which campaigns drive the most revenue
- ROAS by utm_source/utm_medium
- Best performing ad creatives
### Funnel Drop-off
- Cart abandonment rate
- Checkout step completion rates
- Where users exit the funnel
### Product Performance
- Which products are viewed vs purchased
- Add-to-cart rate by category
- Revenue by product (if passing properties)
### Content Grouping
- Compare conversion rates: home → product → checkout
- Identify high-performing page types
## Related documentation
- [E-commerce Conversion Tracking](/implementation/ecommerce-conversion-tracking) — full reference for the purchase and revenue events used in this guide
- [E-commerce Setup Guide](/implementation/ecommerce-conversion-tracking/ecommerce-setup-guide) — step-by-step store setup with deduplication patterns
- [Installation](/implementation/tracker/installation) — detailed guide for adding the tracking script
- [Conversions Report](/reports/conversions) — analyze purchases and revenue by source once data flows
- [Funnel Report](/reports/funnel) — measure cart abandonment and checkout drop-off
## SaaS Application
URL: https://docs.sealmetrics.com/use-cases/saas
# SaaS Implementation Guide
Complete guide to implement Sealmetrics tracking for your SaaS product. Track the full user journey from landing to paid subscription.
## What You'll Track
| Event Type | Example | Purpose |
|------------|---------|---------|
| Pageviews | Pricing, features, blog | Traffic analysis |
| Microconversions | Plan selection, form steps | Funnel optimization |
| Conversions | Trial signup, subscription | Revenue attribution |
---
## Step 1: Basic Installation
Add the tracking script to your marketing site and app:
```html
```
### Content Grouping for SaaS
```html
```
---
## Step 2: Track Pricing Page Interactions
### Plan Selection
```javascript
// Track when user clicks on a plan
document.querySelectorAll('.plan-card').forEach(function(card) {
card.addEventListener('click', function() {
sealmetrics.micro('select_plan', {
plan: this.dataset.plan, // 'starter', 'pro', 'enterprise'
billing: document.querySelector('.billing-toggle.active').dataset.billing // 'monthly', 'yearly'
});
});
});
```
### Billing Toggle
```javascript
// Track monthly/yearly toggle
document.querySelectorAll('.billing-toggle').forEach(function(toggle) {
toggle.addEventListener('click', function() {
sealmetrics.micro('toggle_billing', {
selected: this.dataset.billing // 'monthly' or 'yearly'
});
});
});
```
### CTA Clicks
```javascript
// Track "Start Trial" or "Get Started" clicks
document.querySelectorAll('.cta-start-trial').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('click_start_trial', {
plan: this.dataset.plan,
location: this.dataset.location // 'hero', 'pricing', 'footer'
});
});
});
```
### Feature Comparison
```javascript
// Track when user opens feature comparison
document.querySelector('.compare-plans').addEventListener('click', function() {
sealmetrics.micro('view_comparison');
});
```
---
## Step 3: Track Signup Funnel
### Multi-step Signup Form
```javascript
// Step 1: Email entered
document.querySelector('#signup-email').addEventListener('blur', function() {
if (this.value && this.checkValidity()) {
sealmetrics.micro('signup_step_1', {
step: 'email_entered'
});
}
});
// Step 2: Password created
document.querySelector('#signup-password').addEventListener('blur', function() {
if (this.value) {
sealmetrics.micro('signup_step_2', {
step: 'password_created'
});
}
});
// Step 3: Company info
document.querySelector('#company-form').addEventListener('submit', function() {
sealmetrics.micro('signup_step_3', {
step: 'company_info',
company_size: document.querySelector('[name="company_size"]').value
});
});
// Final: Account created (CONVERSION)
// Track on the post-signup/welcome page
sealmetrics.conv('signup', 0, {
plan: 'trial',
// ... see full example at https://docs.sealmetrics.com/use-cases/saas
```
### Single-page Signup
```javascript
document.querySelector('#signup-form').addEventListener('submit', function(e) {
// Track before form submits
sealmetrics.micro('signup_submitted', {
plan: document.querySelector('[name="plan"]').value
});
});
// On success callback or success page
function onSignupSuccess(user) {
sealmetrics.conv('signup', 0, {
plan: user.plan,
trial_days: '14'
});
}
```
---
## Step 4: Track Onboarding
Track how users progress through onboarding to identify drop-off points.
### Onboarding Checklist
```javascript
// Generic onboarding step tracker
function trackOnboardingStep(stepName, stepNumber, data) {
sealmetrics.micro('onboarding_' + stepName, {
step_number: stepNumber.toString(),
...data
});
}
// Step 1: Profile completed
trackOnboardingStep('profile_completed', 1, {
has_avatar: document.querySelector('#avatar').src ? 'yes' : 'no'
});
// Step 2: First project created
trackOnboardingStep('project_created', 2, {
project_type: projectType
});
// Step 3: Team member invited
trackOnboardingStep('team_invited', 3, {
invites_sent: inviteCount.toString()
});
// Step 4: Integration connected
trackOnboardingStep('integration_connected', 4, {
integration: integrationName // 'slack', 'github', 'jira'
});
// Step 5: First action completed
trackOnboardingStep('first_action', 5, {
// ... see full example at https://docs.sealmetrics.com/use-cases/saas
```
### Onboarding Completed
```javascript
// When user completes all onboarding steps
sealmetrics.micro('onboarding_completed', {
time_to_complete: calculateDays(signupDate, new Date()),
steps_completed: '5'
});
```
### Skip Onboarding
```javascript
document.querySelector('.skip-onboarding').addEventListener('click', function() {
sealmetrics.micro('onboarding_skipped', {
last_step: currentStep.toString()
});
});
```
---
## Step 5: Track Feature Usage
Track which features users engage with to understand product-market fit.
### Feature Activation
```javascript
// First time using a feature
function trackFeatureActivation(featureName) {
if (!localStorage.getItem('activated_' + featureName)) {
sealmetrics.micro('feature_activated', {
feature: featureName
});
localStorage.setItem('activated_' + featureName, 'true');
}
}
// Examples
trackFeatureActivation('dashboard');
trackFeatureActivation('reports');
trackFeatureActivation('exports');
trackFeatureActivation('api');
trackFeatureActivation('integrations');
```
### Key Actions
```javascript
// Track important user actions
sealmetrics.micro('create_report', {
report_type: reportType
});
sealmetrics.micro('export_data', {
format: 'csv',
rows: rowCount.toString()
});
sealmetrics.micro('invite_team_member', {
role: memberRole
});
sealmetrics.micro('connect_integration', {
integration: integrationName
});
```
---
## Step 6: Track Subscription Conversions
### Trial to Paid
```javascript
// When user enters payment info and subscribes
sealmetrics.conv('subscription', monthlyPrice, {
plan: 'pro',
billing_cycle: 'monthly',
currency: 'USD',
trial_days_used: trialDaysUsed.toString()
});
```
### Plan Upgrade
```javascript
// When user upgrades to a higher plan
sealmetrics.conv('upgrade', priceDifference, {
from_plan: 'starter',
to_plan: 'pro',
billing_cycle: 'monthly',
currency: 'USD'
});
```
### Plan Downgrade
```javascript
// Track downgrades for churn analysis
sealmetrics.micro('downgrade', {
from_plan: 'pro',
to_plan: 'starter',
reason: selectedReason // from exit survey
});
```
### Annual Upgrade
```javascript
// When user switches from monthly to annual
sealmetrics.conv('annual_upgrade', annualPrice, {
plan: 'pro',
previous_billing: 'monthly',
savings: savingsAmount.toString(),
currency: 'USD'
});
```
---
## Step 7: Track Churn Signals
### Cancel Flow
```javascript
// User clicks cancel
sealmetrics.micro('cancel_initiated');
// User selects reason
sealmetrics.micro('cancel_reason', {
reason: selectedReason // 'too_expensive', 'not_using', 'missing_feature', etc.
});
// Offer accepted (save)
sealmetrics.micro('cancel_saved', {
offer: acceptedOffer // 'discount', 'pause', 'downgrade'
});
// Final cancellation
sealmetrics.micro('cancel_confirmed', {
reason: finalReason,
days_as_customer: customerDays.toString(),
plan: currentPlan
});
```
### Reactivation
```javascript
// When a churned user returns and subscribes again
sealmetrics.conv('reactivation', monthlyPrice, {
plan: 'pro',
days_churned: daysSinceCancellation.toString(),
previous_plan: previousPlan
});
```
---
## Complete SaaS Funnel
```
┌─────────────────────────────────────────────────────────────────┐
│ SaaS FUNNEL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ACQUISITION │
│ ─────────── │
│ Landing ──► Pricing ──► Select Plan ──► Start Trial │
│ (pv) (pv) (micro) (micro) │
│ │
│ ACTIVATION │
│ ────────── │
│ Signup ──► Onboarding Steps ──► Feature Activation │
│ (CONV) (micro x N) (micro) │
│ │
│ REVENUE │
│ ─────── │
│ Trial End ──► Enter Payment ──► Subscribe │
│ (micro) (CONV) │
│ │
│ EXPANSION │
│ ───────── │
│ Feature Usage ──► Upgrade ──► Annual │
│ (micro) (CONV) (CONV) │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Example: Complete Implementation
### Marketing Site (Next.js)
```tsx
// components/PricingCard.tsx
export function PricingCard({ plan, price, billing }) {
const handleSelect = () => {
if (typeof sealmetrics !== 'undefined') {
sealmetrics.micro('select_plan', {
plan: plan,
billing: billing,
price: price.toString()
});
}
router.push(`/signup?plan=${plan}&billing=${billing}`);
};
return (
{/* Plan details */}
);
}
```
### Signup Page
```tsx
// pages/signup.tsx
export default function Signup() {
const searchParams = useSearchParams();
const plan = searchParams.get('plan') || 'starter';
const handleSubmit = async (formData) => {
try {
const user = await createAccount(formData);
// Track signup conversion
if (typeof sealmetrics !== 'undefined') {
sealmetrics.conv('signup', 0, {
plan: plan,
source: document.referrer.includes('pricing') ? 'pricing' : 'other'
});
}
router.push('/onboarding');
} catch (error) {
// Handle error
}
};
return (
);
}
```
### App Dashboard
```tsx
// components/UpgradeButton.tsx
export function UpgradeButton({ toPlan, price }) {
const handleUpgrade = async () => {
const result = await processUpgrade(toPlan);
if (result.success && typeof sealmetrics !== 'undefined') {
sealmetrics.conv('upgrade', price, {
from_plan: currentPlan,
to_plan: toPlan,
billing_cycle: billingCycle,
currency: 'USD'
});
}
};
return (
);
}
```
---
## Key Metrics to Track
| Metric | How to Calculate | Events Needed |
|--------|------------------|---------------|
| **Visitor → Trial** | signup / entrances | pageview, signup |
| **Trial → Paid** | subscription / signup | signup, subscription |
| **Onboarding Completion** | onboarding_completed / signup | signup, onboarding_* |
| **Feature Adoption** | feature_activated / active users | feature_activated |
| **Expansion Revenue** | upgrade + annual_upgrade value | upgrade, annual_upgrade |
| **Churn Rate** | cancel_confirmed / active subscriptions | cancel_confirmed |
---
## Dashboard Analysis
After implementing, analyze:
### Acquisition
- Which channels drive trial signups
- Pricing page conversion rate
- Plan preference by source
### Activation
- Onboarding completion rate
- Time to first value
- Feature activation patterns
### Revenue
- Trial to paid conversion by plan
- MRR by acquisition source
- Upgrade patterns
### Retention
- Churn reasons
- Feature usage before churn
- Reactivation success
## Related documentation
- [Understanding Event Properties in Sealmetrics](/implementation/custom-properties/event-properties) — enrich signup, onboarding, and upgrade events with custom properties
- [Installation](/implementation/tracker/installation) — add the tracking script to your marketing site and app
- [Funnel Report](/reports/funnel) — visualize the trial-to-paid and onboarding funnels
- [Conversions Report](/reports/conversions) — analyze subscriptions, upgrades, and MRR by channel
- [Lead Generation](/use-cases/lead-generation) — a sibling guide for tracking demo requests and B2B forms
## Lead Generation
URL: https://docs.sealmetrics.com/use-cases/lead-generation
# Lead Generation Implementation Guide
Complete guide for tracking lead generation on service websites, agency sites, and B2B platforms. Track the journey from visitor to qualified lead.
## What You'll Track
| Event Type | Example | Purpose |
|------------|---------|---------|
| Pageviews | Service pages, case studies | Traffic analysis |
| Microconversions | Form interactions, content downloads | Engagement analysis |
| Conversions | Form submissions, demo requests | Lead attribution |
---
## Step 1: Basic Installation
```html
```
### Content Grouping
```html
```
---
## Step 2: Track Form Interactions
### Contact Form
```javascript
// Form field focus (intent signal)
document.querySelectorAll('#contact-form input, #contact-form textarea').forEach(function(field) {
field.addEventListener('focus', function() {
if (!this.dataset.tracked) {
sealmetrics.micro('form_start', {
form_name: 'contact',
first_field: this.name
});
this.dataset.tracked = 'true';
}
}, { once: true });
});
// Form submission (CONVERSION)
document.querySelector('#contact-form').addEventListener('submit', function(e) {
sealmetrics.conv('lead', 0, {
form_name: 'contact',
service_interest: document.querySelector('[name="service"]')?.value || 'general',
source: document.querySelector('[name="how_did_you_hear"]')?.value || 'not_specified'
});
});
```
### Quote Request Form
```javascript
document.querySelector('#quote-form').addEventListener('submit', function() {
var budget = document.querySelector('[name="budget"]').value;
var estimatedValue = getBudgetValue(budget); // Map budget range to number
sealmetrics.conv('quote_request', estimatedValue, {
service: document.querySelector('[name="service"]').value,
budget_range: budget,
timeline: document.querySelector('[name="timeline"]').value,
company_size: document.querySelector('[name="company_size"]').value
});
});
function getBudgetValue(budget) {
var values = {
'under_5k': 2500,
'5k_10k': 7500,
'10k_25k': 17500,
'25k_50k': 37500,
'over_50k': 75000
};
return values[budget] || 0;
}
```
### Demo Request
```javascript
document.querySelector('#demo-form').addEventListener('submit', function() {
sealmetrics.conv('demo_request', 0, {
product: document.querySelector('[name="product"]')?.value,
company_size: document.querySelector('[name="employees"]')?.value,
role: document.querySelector('[name="job_title"]')?.value
});
});
```
---
## Step 3: Track Content Downloads
### Lead Magnets (Ebooks, Whitepapers, Guides)
```javascript
// Gated content - form submission
document.querySelector('#download-form').addEventListener('submit', function() {
var resourceName = document.querySelector('[name="resource"]').value;
sealmetrics.conv('content_download', 0, {
resource_name: resourceName,
resource_type: 'ebook', // 'whitepaper', 'guide', 'template'
topic: document.querySelector('[name="topic"]')?.value
});
});
// Direct download links (if not gated)
document.querySelectorAll('a[download]').forEach(function(link) {
link.addEventListener('click', function() {
sealmetrics.micro('file_download', {
file_name: this.getAttribute('download') || this.href.split('/').pop(),
file_type: this.href.split('.').pop()
});
});
});
```
### Case Study Views
```javascript
// Track case study engagement
document.querySelectorAll('.case-study-card').forEach(function(card) {
card.addEventListener('click', function() {
sealmetrics.micro('view_case_study', {
case_study: this.dataset.title,
industry: this.dataset.industry,
service: this.dataset.service
});
});
});
```
---
## Step 4: Track Engagement Signals
### Scroll Depth on Key Pages
```javascript
// Only on service/landing pages
if (document.body.classList.contains('service-page') ||
document.body.classList.contains('landing-page')) {
var scrollMilestones = {};
window.addEventListener('scroll', function() {
var scrollPercent = Math.round(
(window.scrollY / (document.documentElement.scrollHeight - window.innerHeight)) * 100
);
[25, 50, 75, 100].forEach(function(milestone) {
if (scrollPercent >= milestone && !scrollMilestones[milestone]) {
scrollMilestones[milestone] = true;
sealmetrics.micro('scroll_' + milestone, {
page_type: document.body.dataset.pageType
});
}
});
});
}
```
### Time on Page
```javascript
// Track engaged visitors (30+ seconds on page)
setTimeout(function() {
sealmetrics.micro('engaged_visit', {
page: window.location.pathname,
page_type: document.body.dataset.pageType
});
}, 30000);
```
### Video Testimonials
```javascript
document.querySelectorAll('.testimonial-video').forEach(function(video) {
video.addEventListener('play', function() {
sealmetrics.micro('testimonial_play', {
client: this.dataset.client,
industry: this.dataset.industry
});
});
video.addEventListener('ended', function() {
sealmetrics.micro('testimonial_complete', {
client: this.dataset.client
});
});
});
```
---
## Step 5: Track CTA Interactions
### Primary CTAs
```javascript
// "Get a Quote" buttons
document.querySelectorAll('.cta-quote').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('cta_click', {
cta_type: 'quote',
location: this.dataset.location, // 'header', 'hero', 'footer', 'sidebar'
page: window.location.pathname
});
});
});
// "Contact Us" buttons
document.querySelectorAll('.cta-contact').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('cta_click', {
cta_type: 'contact',
location: this.dataset.location
});
});
});
// "Schedule a Call" buttons
document.querySelectorAll('.cta-schedule').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('cta_click', {
cta_type: 'schedule_call',
location: this.dataset.location
});
});
});
```
### Phone Number Clicks
```javascript
document.querySelectorAll('a[href^="tel:"]').forEach(function(link) {
link.addEventListener('click', function() {
sealmetrics.conv('phone_call', 0, {
phone_number: this.href.replace('tel:', ''),
page: window.location.pathname,
location: this.dataset.location || 'unknown'
});
});
});
```
### Live Chat
```javascript
// If using Intercom, Drift, or similar
document.querySelector('.chat-launcher').addEventListener('click', function() {
sealmetrics.micro('chat_opened', {
page: window.location.pathname
});
});
// Track chat completion (if your chat tool supports callbacks)
window.Intercom('onConversationStarted', function() {
sealmetrics.conv('chat_lead', 0, {
page: window.location.pathname
});
});
```
---
## Step 6: Track Calendar Bookings
### Calendly / Cal.com / HubSpot Meetings
```javascript
// Calendly
window.addEventListener('message', function(e) {
if (e.data.event === 'calendly.event_scheduled') {
sealmetrics.conv('meeting_booked', 0, {
meeting_type: e.data.payload.event_type.name,
invitee_email: e.data.payload.invitee.email
});
}
});
// Cal.com
if (typeof Cal !== 'undefined') {
Cal('on', 'bookingSuccessful', function(e) {
sealmetrics.conv('meeting_booked', 0, {
meeting_type: e.data.eventType,
duration: e.data.duration
});
});
}
```
---
## Step 7: Multi-Step Forms
### Wizard-style Quote Forms
```javascript
var currentStep = 1;
function trackFormStep(stepNumber, stepName, data) {
sealmetrics.micro('form_step_' + stepNumber, {
step_name: stepName,
form_name: 'quote_wizard',
...data
});
}
// Step 1: Service selection
document.querySelector('#step1-next').addEventListener('click', function() {
trackFormStep(1, 'service_selected', {
service: document.querySelector('[name="service"]:checked').value
});
currentStep = 2;
});
// Step 2: Project details
document.querySelector('#step2-next').addEventListener('click', function() {
trackFormStep(2, 'details_provided', {
budget: document.querySelector('[name="budget"]').value,
timeline: document.querySelector('[name="timeline"]').value
});
currentStep = 3;
});
// Step 3: Contact info (final submission)
document.querySelector('#quote-wizard').addEventListener('submit', function() {
var budget = document.querySelector('[name="budget"]').value;
// ... see full example at https://docs.sealmetrics.com/use-cases/lead-generation
```
---
## Platform-Specific Implementations
### WordPress (Contact Form 7)
```php
// In functions.php
add_action('wp_footer', function() {
?>
', {
container: document.querySelector('#typeform'),
onSubmit: function(payload) {
sealmetrics.conv('lead', 0, {
form_name: 'typeform_intake',
response_id: payload.responseId
});
}
});
```
---
## Complete Lead Gen Funnel
```
┌─────────────────────────────────────────────────────────────────┐
│ LEAD GENERATION FUNNEL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ AWARENESS │
│ ───────── │
│ Blog Post ──► Service Page ──► Case Study │
│ (pageview) (pageview) (micro: view_case_study) │
│ │
│ INTEREST │
│ ──────── │
│ Scroll 50% ──► Video Watch ──► Resource Download │
│ (micro) (micro) (CONV: content_download) │
│ │
│ CONSIDERATION │
│ ───────────── │
│ CTA Click ──► Form Start ──► Form Steps │
│ (micro) (micro) (micro x N) │
│ │
│ CONVERSION │
│ ────────── │
│ Form Submit ──► Demo/Call Booked │
│ (CONV: lead) (CONV: meeting_booked) │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Lead Scoring with Properties
Use properties to enable lead scoring in your CRM:
```javascript
sealmetrics.conv('lead', 0, {
// Lead source
source: getUtmSource(),
medium: getUtmMedium(),
campaign: getUtmCampaign(),
// Qualification signals
company_size: formData.employees, // 'small', 'medium', 'enterprise'
budget_range: formData.budget, // 'under_5k', '5k_10k', etc.
timeline: formData.timeline, // 'immediate', '1_month', '3_months'
decision_maker: formData.role, // 'ceo', 'director', 'manager'
// Engagement signals
pages_viewed: sessionStorage.getItem('pages_viewed'),
time_on_site: Math.round((Date.now() - sessionStart) / 1000).toString(),
content_downloaded: sessionStorage.getItem('downloads') || '0'
});
```
---
## Key Metrics to Track
| Metric | Formula | Events |
|--------|---------|--------|
| **Visitor → Lead** | leads / visitors | pageview, lead |
| **Form Start Rate** | form_start / page visitors | pageview, form_start |
| **Form Completion** | lead / form_start | form_start, lead |
| **Content Download Rate** | downloads / visitors | pageview, content_download |
| **Lead by Source** | leads by utm_source | lead (with properties) |
| **Lead Quality** | weighted by budget/company size | lead (with properties) |
---
## Dashboard Analysis
After implementing:
### Traffic Analysis
- Which channels bring the most leads
- Best performing landing pages
- Content that drives conversions
### Funnel Optimization
- Form abandonment points
- CTA click-through rates
- Time from first visit to lead
### Lead Quality
- Leads by company size
- Budget distribution
- Timeline urgency
### Content Performance
- Case studies that influence leads
- Blog posts in conversion paths
- Download-to-lead correlation
## Related documentation
- [Understanding Event Properties in Sealmetrics](/implementation/custom-properties/event-properties) — attach lead-scoring signals like budget and company size to your conversions
- [Installation](/implementation/tracker/installation) — add the tracking script to your service site
- [Conversions Report](/reports/conversions) — see leads and demo bookings attributed by source
- [Funnel Report](/reports/funnel) — pinpoint where multi-step forms lose prospects
- [SaaS Application](/use-cases/saas) — a sibling guide for trial-signup and subscription funnels
## Content & Media Sites
URL: https://docs.sealmetrics.com/use-cases/content-media
# Content & Media Implementation Guide
Complete guide for tracking content sites, blogs, news publishers, and media platforms. Measure reader engagement, subscription conversions, and content performance.
## What You'll Track
| Event Type | Example | Purpose |
|------------|---------|---------|
| Pageviews | Articles, categories, homepage | Traffic analysis |
| Microconversions | Scroll depth, video plays, shares | Engagement metrics |
| Conversions | Newsletter signups, subscriptions | Audience building |
---
## Step 1: Basic Installation
```html
```
### Content Grouping
Group content by type for better analysis:
```html
```
### Dynamic Grouping (WordPress)
```php
```
---
## Step 2: Track Reading Engagement
### Scroll Depth
```javascript
(function() {
var tracked = {};
var articleHeight = document.querySelector('article, .post-content, .entry-content');
if (!articleHeight) return;
var articleTop = articleHeight.offsetTop;
var articleBottom = articleTop + articleHeight.offsetHeight;
window.addEventListener('scroll', function() {
var scrollPosition = window.scrollY + window.innerHeight;
var articleProgress = Math.min(100, Math.max(0,
Math.round(((scrollPosition - articleTop) / (articleBottom - articleTop)) * 100)
));
[25, 50, 75, 100].forEach(function(milestone) {
if (articleProgress >= milestone && !tracked[milestone]) {
tracked[milestone] = true;
sealmetrics.micro('read_' + milestone, {
article_id: document.body.dataset.postId,
category: document.body.dataset.category
});
}
});
});
})();
```
### Time on Article
```javascript
(function() {
var startTime = Date.now();
var engagementThresholds = [30, 60, 120, 300]; // seconds
var tracked = {};
function checkEngagement() {
var timeSpent = Math.floor((Date.now() - startTime) / 1000);
engagementThresholds.forEach(function(threshold) {
if (timeSpent >= threshold && !tracked[threshold]) {
tracked[threshold] = true;
sealmetrics.micro('time_on_article', {
seconds: threshold.toString(),
article_id: document.body.dataset.postId
});
}
});
}
// Check every 10 seconds
setInterval(checkEngagement, 10000);
// Also check on visibility change (tab switch)
document.addEventListener('visibilitychange', function() {
if (document.visibilityState === 'hidden') {
checkEngagement();
}
});
})();
```
### Engaged Reader (Combined)
```javascript
// Fire when user has scrolled 50%+ AND spent 30+ seconds
(function() {
var hasScrolled50 = false;
var hasSpent30s = false;
var hasFiredEngaged = false;
window.addEventListener('scroll', function() {
if (getScrollPercent() >= 50) {
hasScrolled50 = true;
checkEngaged();
}
});
setTimeout(function() {
hasSpent30s = true;
checkEngaged();
}, 30000);
function checkEngaged() {
if (hasScrolled50 && hasSpent30s && !hasFiredEngaged) {
hasFiredEngaged = true;
sealmetrics.micro('engaged_reader', {
article_id: document.body.dataset.postId,
category: document.body.dataset.category,
author: document.body.dataset.author
});
}
}
function getScrollPercent() {
// ... see full example at https://docs.sealmetrics.com/use-cases/content-media
```
---
## Step 3: Track Newsletter Signups
### Inline Newsletter Form
```javascript
document.querySelectorAll('.newsletter-form').forEach(function(form) {
form.addEventListener('submit', function(e) {
sealmetrics.conv('newsletter_signup', 0, {
form_location: this.dataset.location, // 'header', 'footer', 'inline', 'popup'
article_id: document.body.dataset.postId || 'none',
category: document.body.dataset.category || 'none'
});
});
});
```
### Popup/Modal Signup
```javascript
// Track popup shown
function onNewsletterPopupShown() {
sealmetrics.micro('newsletter_popup_shown', {
trigger: 'exit_intent' // or 'scroll', 'time'
});
}
// Track popup closed without signup
function onNewsletterPopupClosed(didSignup) {
if (!didSignup) {
sealmetrics.micro('newsletter_popup_dismissed');
}
}
// Track signup
function onNewsletterSignup(email) {
sealmetrics.conv('newsletter_signup', 0, {
form_location: 'popup',
trigger: 'exit_intent'
});
}
```
### Double Opt-in Confirmation
```javascript
// On the confirmation page (after clicking email link)
if (window.location.pathname.includes('/confirm')) {
sealmetrics.conv('newsletter_confirmed', 0, {
source: new URLSearchParams(window.location.search).get('src')
});
}
```
---
## Step 4: Track Social Shares
### Share Button Clicks
```javascript
document.querySelectorAll('.share-button').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('social_share', {
platform: this.dataset.platform, // 'twitter', 'facebook', 'linkedin', 'email'
article_id: document.body.dataset.postId,
article_title: document.title
});
});
});
```
### Copy Link
```javascript
document.querySelector('.copy-link').addEventListener('click', function() {
sealmetrics.micro('copy_link', {
article_id: document.body.dataset.postId
});
});
```
### Native Share API
```javascript
document.querySelector('.native-share').addEventListener('click', async function() {
if (navigator.share) {
try {
await navigator.share({
title: document.title,
url: window.location.href
});
sealmetrics.micro('native_share', {
article_id: document.body.dataset.postId
});
} catch (err) {
// User cancelled
}
}
});
```
---
## Step 5: Track Comments
### Comment Form Interaction
```javascript
// Focus on comment field
document.querySelector('#comment-field').addEventListener('focus', function() {
sealmetrics.micro('comment_started', {
article_id: document.body.dataset.postId
});
}, { once: true });
// Comment submitted
document.querySelector('#comment-form').addEventListener('submit', function() {
sealmetrics.micro('comment_submitted', {
article_id: document.body.dataset.postId,
is_reply: this.querySelector('[name="parent"]').value ? 'yes' : 'no'
});
});
```
### Comment Reactions (if using reactions)
```javascript
document.querySelectorAll('.comment-reaction').forEach(function(button) {
button.addEventListener('click', function() {
sealmetrics.micro('comment_reaction', {
reaction_type: this.dataset.reaction, // 'like', 'helpful', 'disagree'
article_id: document.body.dataset.postId
});
});
});
```
---
## Step 6: Track Video/Audio Content
### Video Player
```javascript
document.querySelectorAll('video, .video-player').forEach(function(video) {
var videoId = video.dataset.videoId || video.id;
var tracked = {};
video.addEventListener('play', function() {
if (!tracked.play) {
tracked.play = true;
sealmetrics.micro('video_play', {
video_id: videoId,
video_title: video.dataset.title
});
}
});
video.addEventListener('timeupdate', function() {
var percent = Math.round((this.currentTime / this.duration) * 100);
[25, 50, 75].forEach(function(milestone) {
if (percent >= milestone && !tracked[milestone]) {
tracked[milestone] = true;
sealmetrics.micro('video_progress_' + milestone, {
video_id: videoId
});
}
});
});
video.addEventListener('ended', function() {
sealmetrics.micro('video_complete', {
video_id: videoId,
// ... see full example at https://docs.sealmetrics.com/use-cases/content-media
```
### Podcast Player
```javascript
var podcast = document.querySelector('.podcast-player');
if (podcast) {
var audio = podcast.querySelector('audio');
var episodeId = podcast.dataset.episodeId;
var tracked = {};
audio.addEventListener('play', function() {
if (!tracked.play) {
tracked.play = true;
sealmetrics.micro('podcast_play', {
episode_id: episodeId,
episode_title: podcast.dataset.title
});
}
});
audio.addEventListener('ended', function() {
sealmetrics.micro('podcast_complete', {
episode_id: episodeId
});
});
// Track download
podcast.querySelector('.download-episode').addEventListener('click', function() {
sealmetrics.micro('podcast_download', {
episode_id: episodeId
});
});
}
```
### YouTube Embeds
```javascript
// YouTube IFrame API
function onYouTubeIframeAPIReady() {
document.querySelectorAll('.youtube-embed').forEach(function(container) {
var player = new YT.Player(container, {
events: {
onStateChange: function(event) {
var videoId = player.getVideoData().video_id;
if (event.data === YT.PlayerState.PLAYING) {
sealmetrics.micro('youtube_play', { video_id: videoId });
}
if (event.data === YT.PlayerState.ENDED) {
sealmetrics.micro('youtube_complete', { video_id: videoId });
}
}
}
});
});
}
```
---
## Step 7: Track Paid Subscriptions
### Paywall Interactions
```javascript
// Paywall shown
document.addEventListener('paywallShown', function(e) {
sealmetrics.micro('paywall_shown', {
article_id: document.body.dataset.postId,
content_type: e.detail.contentType // 'premium', 'members_only'
});
});
// Plan selection
document.querySelectorAll('.subscription-plan').forEach(function(plan) {
plan.addEventListener('click', function() {
sealmetrics.micro('plan_selected', {
plan: this.dataset.plan,
price: this.dataset.price,
billing: this.dataset.billing
});
});
});
```
### Subscription Purchase
```javascript
// On subscription success
function onSubscriptionComplete(subscription) {
sealmetrics.conv('subscription', subscription.price, {
plan: subscription.plan,
billing_cycle: subscription.billing, // 'monthly', 'yearly'
currency: subscription.currency,
source: document.body.dataset.postId ? 'article_paywall' : 'pricing_page'
});
}
```
### Subscription Upgrade
```javascript
sealmetrics.conv('subscription_upgrade', priceDifference, {
from_plan: currentPlan,
to_plan: newPlan,
currency: 'USD'
});
```
---
## Step 8: Track Internal Navigation
### Related Articles
```javascript
document.querySelectorAll('.related-articles a').forEach(function(link) {
link.addEventListener('click', function() {
sealmetrics.micro('related_article_click', {
from_article: document.body.dataset.postId,
to_article: this.dataset.postId,
position: this.dataset.position // '1', '2', '3'
});
});
});
```
### Category Navigation
```javascript
document.querySelectorAll('.category-nav a').forEach(function(link) {
link.addEventListener('click', function() {
sealmetrics.micro('category_click', {
category: this.dataset.category,
location: 'navigation'
});
});
});
```
### Search
```javascript
document.querySelector('#search-form').addEventListener('submit', function() {
var query = document.querySelector('#search-input').value;
sealmetrics.micro('search', {
search_term: query,
results_page: 'true'
});
});
```
---
## Complete Content Funnel
```
┌─────────────────────────────────────────────────────────────────┐
│ CONTENT ENGAGEMENT FUNNEL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ DISCOVERY │
│ ───────── │
│ Homepage ──► Category ──► Article │
│ (pageview) (pageview) (pageview) │
│ │
│ ENGAGEMENT │
│ ────────── │
│ Read 25% ──► Read 50% ──► Read 75% ──► Read 100% │
│ (micro) (micro) (micro) (micro) │
│ │
│ INTERACTION │
│ ─────────── │
│ Comment ──► Share ──► Related Click │
│ (micro) (micro) (micro) │
│ │
│ CONVERSION │
│ ────────── │
│ Newsletter Popup ──► Signup ──► Confirm │
│ (micro) (CONV) (CONV) │
│ │
│ MONETIZATION │
│ ──────────── │
│ Paywall ──► Plan Select ──► Subscribe │
│ (micro) (micro) (CONV) │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Key Metrics for Content Sites
| Metric | Formula | Events Needed |
|--------|---------|---------------|
| **Engaged Readers** | engaged_reader / pageviews | pageview, engaged_reader |
| **Read Completion** | read_100 / article pageviews | pageview, read_100 |
| **Newsletter Rate** | signups / entrances | pageview, newsletter_signup |
| **Share Rate** | shares / article pageviews | pageview, social_share |
| **Comment Rate** | comments / article pageviews | pageview, comment_submitted |
| **Video Completion** | video_complete / video_play | video_play, video_complete |
| **Subscription Rate** | subscriptions / paywall_shown | paywall_shown, subscription |
---
## Content Performance Analysis
After implementing, analyze in your dashboard:
### Traffic
- Top articles by pageviews
- Traffic sources per article
- Category performance
### Engagement
- Average scroll depth by category
- Time on page by author
- Engaged reader rate by topic
### Conversion
- Newsletter signup sources
- Best converting content
- Subscription paths
### Content ROI
- Revenue per article (if subscriptions)
- Lifetime value by acquisition content
- Author performance
## Related documentation
- [Understanding Event Properties in Sealmetrics](/implementation/custom-properties/event-properties) — tag engagement events with article, author, and category properties
- [Installation](/implementation/tracker/installation) — add the tracking script to your publishing platform
- [Content Grouping](/implementation/content-site-structure/content-grouping) — organize articles, categories, and video into groups for reporting
- [Funnel Report](/reports/funnel) — measure the path from article read to newsletter or paid subscription
- [Conversions Report](/reports/conversions) — track newsletter signups and subscription revenue by source
---
# GA4 Migration
## GA4 Migration Guide
URL: https://docs.sealmetrics.com/ga4-migration
# Migrating from Google Analytics 4 to Sealmetrics
Moving from Google Analytics 4 (GA4) to Sealmetrics takes most teams **1–2 weeks** end to end. This guide walks through what to prepare, how GA4 concepts map to Sealmetrics, and how to run both platforms in parallel so you can validate data before cutting GA4 off.
## Before you start
Document the following from your current GA4 property:
- Core metrics you rely on (sessions, users, pageviews, conversions, revenue).
- Custom events and the parameters they carry.
- E-commerce tracking implementation (GA4 events or GTM-based).
- Audiences and custom definitions.
- Connected integrations (Google Ads, Search Console, Data Studio, BigQuery export).
- Retention settings and historical data you need to export before shutdown.
## How GA4 concepts map to Sealmetrics
| GA4 | Sealmetrics |
|---|---|
| Session | Session (cookieless, ~2-hour inactivity window) |
| Engaged session | Engaged session (configurable engagement threshold) |
| User | Visitor (first-party, consent-free identifier) |
| Event | Event (typed: pageview, conversion, micro-conversion, custom) |
| Conversion | Conversion (native) + Micro-conversion |
| Audience | Segment |
| Data streams | Sites |
| Custom dimensions / metrics | Custom properties on events |
| BigQuery export | [Exports API](/api/exports) |
## Migration steps
1. **Install the Sealmetrics tracker** alongside GA4 — see [Tracker installation](/implementation/tracker/installation). Both can run in parallel without conflict.
2. **Map events.** Re-declare your GA4 custom events as Sealmetrics events. See [Conversion tracking](/implementation/ecommerce-conversion-tracking).
3. **Configure attribution.** Set channel groupings, attribution windows, and excluded domains via the Platform settings — see [Bypass POS or referrer](/platform/tracking-and-attribution-settings/bypass-pos-or-referrer).
4. **Validate in parallel** for 2–4 weeks. Expect Sealmetrics to report **5–8× more traffic** in EU markets because it captures consent-rejected visitors.
5. **Export GA4 history** you want to keep — raw events via BigQuery, reports via CSV. Sealmetrics retains data for 24 months without consent; GA4 maxes out at 14 months under consent-free operation.
6. **Update dashboards.** Rebuild Data Studio / BI reports against [Sealmetrics exports](/api/exports) or the [Batch API](/api/batch).
7. **Cut GA4 off** once parallel validation passes your QA.
## What's different
- **No cookies, no consent banner.** Sealmetrics captures 100% of traffic without collecting personal data, so there is nothing to obtain consent for.
- **Google Ads tracking, no audience sync.** Sealmetrics tracks Google Ads campaigns via UTM parameters end-to-end (source, medium, campaign, term, content) and provides ROAS reporting. What it does **not** do is push audience segments back to Google Ads for automated bidding — that requires GA4 with consented users. Teams commonly run both: GA4 for Ads audience/bidding, Sealmetrics as the source of truth for total traffic and conversions.
- **No predictive metrics** (purchase probability, churn probability). Sealmetrics reports observed behavior.
- **Simpler attribution model.** Last non-direct click by default; configurable.
- **Reporting in the account's timezone, not UTC.** Every preset ("today", "7d", "this month") is resolved with "today in the account's timezone" — matching how GA4 calls it the "reporting timezone". Set it correctly in **Site settings → General** before you start validating side-by-side; a mismatch between GA4's reporting timezone and Sealmetrics's will shift daily rollups by up to a day at the seam.
## Related
- [Google Analytics 4 vs Sealmetrics](/blog/google-analytics-vs-sealmetrics) — feature-by-feature comparison.
- [GA4 vs Sealmetrics FAQ](/faq/ga4-vs-sealmetrics) — common migration questions.
- [Compliance overview](/compliance) — GDPR, ePrivacy, CNIL, UK PECR posture.
---
# Guides
## Guides
URL: https://docs.sealmetrics.com/guides
# Guides
Welcome to the Sealmetrics guides section. Here you'll find step-by-step tutorials and best practices for getting the most out of Sealmetrics.
## Available Guides
- [Complete Guide to Cookieless Analytics 2025](/guides/complete-guide-cookieless-analytics) - Learn how cookieless analytics captures 100% of visitor data without consent banners. Complete technical guide covering GDPR compliance, implementation, and Sealmetrics advantages.
- [UTM Governance: Naming Conventions That Keep Attribution Clean](/guides/utm-governance) - A practical UTM playbook: naming conventions, a source/medium taxonomy aligned with Sealmetrics default channels, the mistakes that corrupt attribution, a spreadsheet template, and how Sealmetrics processes UTMs end to end.
- [GA4 to Sealmetrics: The Complete Migration Checklist](/guides/ga4-migration-checklist) - Phase-by-phase migration checklist: audit your GA4 events, map them to conv()/micro(), install the tracker, run 30 days in parallel, know which data differences to expect, and switch GA4 off safely.
- [Tracker Performance Report: Sealmetrics vs GA4](/guides/tracker-performance-report) - A technical comparison of tracking pixel weight, protocol, latency, and traffic capture against gtag.js, with methodology, measured data from an anonymized reference site, and modeled network scenarios.
- [Tracker Performance: Sealmetrics vs GA4 vs Adobe Analytics](/guides/tracker-performance-three-way) - The three-way comparison in one table set: script weight, delivery chains, time to first hit, transport, consent, and measured traffic differences across all three trackers.
- [Tracker Performance Report: Sealmetrics vs Adobe Analytics](/guides/tracker-performance-adobe-analytics) - Field-measured comparison against the Adobe Launch + AppMeasurement stack on an anonymized dual-vendor site: script weight, delivery chain, time to first hit, and a 30-day dual-tag validation.
## Complete Guide to Cookieless Analytics 2026
URL: https://docs.sealmetrics.com/complete-guide-cookieless-analytics
Website analytics is fundamental to understanding visitor behavior. Yet a large share of EU visitors never consent — some reject, many simply ignore the banner — and cookie-based analytics typically lose 15-60% of their data as a result, depending on sector, brand strength and traffic mix. This represents the critical challenge of modern analytics: how do you capture meaningful insights when cookie-based solutions fail across Europe?
The answer lies in cookieless analytics—a technical approach that captures visitor data without relying on cookies or requiring consent banners. Unlike traditional analytics that depend on third-party cookies or consent mechanisms, cookieless analytics uses alternative tracking methods to provide complete data capture while maintaining GDPR compliance.
This guide explains how cookieless analytics works, why it matters for your business, and how to implement it effectively. By the end, you'll understand why industry leaders like Sealmetrics are moving toward cookieless tracking as the future of web analytics.
## What is Cookieless Analytics?
Cookieless analytics is a method of tracking website visitors and their behavior without using HTTP cookies. Instead of storing persistent identifiers in user browsers, cookieless analytics platforms use alternative mechanisms—such as session-based identifiers, server-side tracking, or request-based tracking—to maintain visitor context and measure analytics events.
### The Core Difference from Cookie-Based Analytics
Traditional cookie-based analytics (including Google Analytics) stores a persistent identifier in the user's browser. This cookie follows the user across sessions, allowing platforms to build comprehensive visitor profiles. The process works like this:
1. User visits website
2. Analytics code creates a cookie in browser
3. Cookie persists for months or years
4. Each subsequent visit references that same cookie
5. Platform links all visits to same user ID
Cookieless analytics eliminates this dependency. Instead, it might use:
- **Session-based tracking**: Generate temporary identifiers that reset each session
- **Server-side tracking**: Process analytics data on your server rather than user's browser
- **Request-based tracking**: Associate data with each request without persistent storage
- **Zero-IP approach**: Avoid storing or hashing IP addresses (as Sealmetrics does)
The difference is profound: cookieless analytics doesn't require persistent cookies, doesn't mandate consent mechanisms, and doesn't suffer from banner ghosting — the phenomenon where users ignore cookie banners without making a decision, which analytics platforms must treat as a refusal.
### Why Cookieless Analytics Matters Now
In 2024, three forces converge to make cookieless analytics essential:
**1. Browser Privacy Changes**: Apple's Intelligent Tracking Prevention (ITP) and Safari's default privacy settings have eliminated third-party cookies for Safari users (representing 25-30% of traffic). Firefox Enhanced Tracking Protection and other privacy features continue eroding cookie reliability.
**2. Regulatory Pressure**: GDPR, CNIL guidance, and TTDSG (German privacy law) establish that cookie-based analytics require explicit user consent or a clear legal basis. Sealmetrics sidesteps the question: it stores no personal data, so the stored dataset falls outside the GDPR's material scope (Recital 26) and no Article 6 legal basis is needed for it.
**3. Data Loss Crisis**: with a large share of EU visitors never consenting, cookie-based analytics become unreliable — typically losing 15-60% of EU visitor data depending on sector, brand strength and traffic mix, and creating blind spots you cannot see from inside the tool.
Cookieless analytics solves all three challenges simultaneously.
## The Data Loss Problem: Why Standard Analytics Fail
Understanding why you need cookieless analytics requires examining how severely cookie-based approaches fail in modern environments.
### The Cone of Data Loss
When a user visits your website with Google Analytics or similar cookie-based platforms, multiple points of data loss occur:
**Banner ghosting**: users see the cookie banner and ignore it entirely — neither accepting nor rejecting. No consent means no data collection, so these visitors are invisible even though they never said no.
**Active rejection**: users click reject, which prevents any tracking.
**Browser privacy**: Safari, Firefox and other privacy-focused browsers block third-party cookies and restrict tracking regardless of what the visitor chose.
**Cumulative effect**: in practice these add up to **15–60% of visitor data lost**. Where a given site lands inside that range depends on three things — its sector, the strength of its brand, and its traffic mix. A recognised consumer brand whose visitors mostly arrive direct sits near the bottom; a site running mostly cold paid acquisition in a privacy-sensitive market sits near the top.
The point is not the exact percentage, which nobody can quote for your site without measuring it. The point is that the loss is invisible in your own reports: GA4 shows you 100% of what it captured, not what actually happened.
### Banner Ghosting: The Hidden Problem
Banner ghosting deserves special attention because it's invisible to most analytics practitioners. When users ignore cookie banners:
- No consent decision is recorded
- No rejection event is captured
- Analytics platforms default to "no consent"
- Visitor is excluded from tracking
- You lose all data about that user
Regulations support this approach. GDPR Article 4(11) defines consent as "freely given, specific, informed and unambiguous." Ignoring a banner doesn't constitute consent. Therefore, GDPR-compliant platforms cannot track banner ghosters.
Banner ghosters are often the largest of the three groups. They are genuinely interested visitors, but you see nothing about them.
Cookieless analytics solves this by eliminating the consent requirement. Sealmetrics and similar platforms don't need consent because they don't rely on cookies or third-party tracking. This means Sealmetrics captures data from banner ghosters, active rejectors, and privacy-focused browsers—groups entirely invisible to Google Analytics.
## How Cookieless Analytics Works
The technical architecture of cookieless analytics varies by platform, but the core principle remains: capture visitor data without persistent cookies.
### Sealmetrics' Dual-Method Approach
Sealmetrics uses a sophisticated approach combining:
**1. Session-Based Tracking (Session-ID Method)**:
- Generate temporary session identifier when user visits
- Identifier resets at end of session or after inactivity
- Server associates all events with that session ID
- No persistent cookies stored in browser
- GDPR compliant: no personal data retained beyond necessary period
**2. Isolated Hit Method**:
- Track individual events without requiring persistent session
- Each pageview or interaction is independently captured
- Server correlates related events through patterns
- Provides fallback when session tracking unavailable
- Maintains privacy by avoiding persistent user profiles
### Key Technical Advantages
**Zero IP Storage**: Unlike Plausible (which hashes IPs) or Matomo (which stores hashed IPs), Sealmetrics doesn't store IP addresses at all. This provides additional privacy benefits and simplifies GDPR compliance.
**No Consent Required**: nothing is written to or read from the visitor's device, and no personal data is stored, so neither the ePrivacy consent rule nor the GDPR's personal-data obligations are triggered. That removes the banner and captures data from all visitors.
**100% Data Capture**: Because consent isn't required, Sealmetrics captures visitor data from:
- Banner ghosters (typically the largest missing group)
- Cookie rejectors (20-30%)
- Privacy-focused browsers (10-20%)
- Complete visitor profiles with no data loss
### Comparison: Technical Approaches
Different cookieless analytics platforms use different technical methods:
| Aspect | Session-Based | Server-Side | Fingerprinting | Sealmetrics |
|--------|---------------|-------------|----------------|------------|
| Persistent Cookies | ❌ No | ❌ No | ⚠️ Optional | ❌ No |
| Requires Consent | ❌ No | ❌ No | ✅ Yes | ❌ No |
| IP Storage | ❌ No | ❌ No | ✅ Yes | ❌ **No** |
| Data Accuracy | ✅ 95-98% | ✅ 95-98% | ⚠️ 70-80% | ✅ **100%** |
| GDPR Compliant | ✅ Yes | ✅ Yes | ❌ No | ✅ **Yes** |
| Implementation Time | 2-5 min | 15-30 min | 5-10 min | **2 min** |
| Cost | $ | $$$ | $$ | **$** |
## Cookieless vs Cookie-Based Analytics: Complete Comparison
| Feature | Google Analytics 4 | Plausible | Matomo | Sealmetrics |
|---------|-------------------|-----------|--------|------------|
| **Requires Cookies** | ✅ Yes (required) | ❌ No | ❌ No | ❌ **No** |
| **Requires Consent** | ✅ Yes (in EU) | ❌ **No** | ❌ **No** | ❌ **No** |
| **Data Loss Rate** | 15-60% | **0%** | **0%** | **0%** |
| **Stores IP Address** | ✅ Yes (basic) | ✅ Hashed | ✅ Hashed | ❌ **Never** |
| **GDPR Compliant** | ⚠️ With DPA + consent | ✅ Yes | ✅ Yes | ✅ **Yes** |
| **No Consent Required** | ❌ No | ❌ No | ❌ No | ✅ **Yes** |
| **Data Retention** | 14 months | Configurable | Configurable | **24 months** |
| **Setup Time** | 30-60 min | 10 min | 20-30 min | **2 min** |
| **Price** | Free (basic) | $23/mo | Free (self-hosted) | **$9/mo** |
| **Captures Banner Ghosters** | ❌ No (40-60% loss) | ⚠️ Only with consent | ⚠️ Only with consent | ✅ **Yes** |
| **Full EU Compliance** | ❌ Not recommended | ✅ Yes | ✅ Yes | ✅ **Yes** |
## Why GDPR Compliance Matters More Than You Think
Many websites believe Google Analytics is GDPR-compliant if they have:
- A privacy policy
- A Data Processing Agreement (DPA)
- Explicit consent mechanism
This approach creates significant legal risk. Multiple EU data protection authorities have clarified that Google Analytics violates GDPR because:
1. **Transfers to US**: Data transfers to Google's US servers lack adequate legal basis post-Schrems II
2. **Excessive Data Collection**: Google Analytics collects more data than necessary for analytics
3. **Google's Own Use**: User data is used for Google's own purposes (advertising, profiling)
4. **Legitimacy Questions**: Even with DPA, the fundamental transfer violates GDPR
CNIL (French data protection authority) explicitly stated in 2022 that Google Analytics use is non-compliant, recommending tools like Sealmetrics instead.
Cookieless analytics platforms like Sealmetrics solve this by:
- Processing data in EU (no US transfers)
- Collecting only necessary analytics data
- Not using data for secondary purposes
- No personal data stored, so no Article 6 legal basis is required for the analytics dataset
- Eliminating the need for complex consent mechanisms
For a German e-commerce site, the choice between Google Analytics and Sealmetrics isn't just about data accuracy—it's about legal risk versus compliance.
## How to Implement Cookieless Analytics
Implementing cookieless analytics depends on your platform, but the general process is straightforward.
### Sealmetrics Implementation (Simplest Option)
**Step 1: Create Account**
Visit Sealmetrics.com and sign up. Your card will not be charged during the 14-day free trial.
**Step 2: Add Tracking Code**
Sealmetrics provides a single JavaScript snippet. Add this to your website's `` section.
**Step 3: Verify Installation**
Go to Sealmetrics dashboard. If you see today's visitor count, installation is complete. Most websites complete this in 2 minutes.
**Step 4: (Optional) Remove Old Analytics**
Once you confirm Sealmetrics data is flowing, you can remove Google Analytics if desired.
### Verification Checklist
```
☐ Sealmetrics code added to
☐ Dashboard shows visitor count
☐ Page views appear in real-time
☐ Conversion tracking configured (if needed)
☐ No console errors in browser DevTools
☐ Privacy policy updated (mention Sealmetrics)
```
## Cookieless Analytics Best Practices
Once implemented, follow these practices to maximize data quality and insights:
### 1. Use Clear UTM Parameters
Cookieless analytics captures UTM parameters like utm_source, utm_medium, utm_campaign. Structure these consistently:
```
utm_source=google_ads
utm_medium=cpc
utm_campaign=gdpr_compliance
utm_content=video_ad
```
### 2. Track Meaningful Conversions
Define conversion events that matter to your business:
- Form submissions
- Product purchases
- Demo requests
- Newsletter signups
- Download completion
Sealmetrics and similar platforms allow custom event tracking without code changes.
### 3. Implement Regularly Scheduled Reviews
Review analytics weekly for:
- Traffic trends
- Top-performing pages
- Conversion rates
- Geographic distribution
Monthly deeper analysis:
- Device/browser trends
- Seasonal patterns
- ROI by traffic source
### 4. Avoid Common Mistakes
**Mistake 1**: Ignoring data quality
- Verify UTM parameters are applied correctly
- Check that conversion events fire reliably
- Monitor for bot traffic
**Mistake 2**: Expecting overnight improvements
- Analytics changes take 2-4 weeks to show trends
- Don't adjust strategy based on single-day data
- Let data accumulate before drawing conclusions
## Frequently Asked Questions About Cookieless Analytics
### Is cookieless analytics accurate?
Yes, cookieless analytics is as accurate as—or more accurate than—cookie-based analytics. Sealmetrics captures 100% of visitors because it doesn't rely on cookies or consent. Cookie-based platforms lose 15-60% of EU data to banner ghosting and rejections, depending on sector, brand strength and traffic mix.
### Do I need consent for cookieless analytics?
No. Sealmetrics needs no consent because it sets nothing on the device and stores no personal data — there is nothing to consent to. You should still mention analytics in your privacy policy, but you do not need a cookie banner or consent popup.
### Will my visitors see a cookie banner?
Not with Sealmetrics. Because no cookies are involved, you don't need a cookie banner. This improves user experience and increases consent rates for other necessary elements (like contact forms).
### How long does data persist?
Sealmetrics retains aggregated analytics data for 24 months — a fixed period, identical for every plan, enforced by database TTLs (event-level detail is purged after 14 days). This is significantly longer than Google Analytics (14 months default) and sufficient for annual trend analysis.
### Is cookieless analytics GDPR compliant?
Yes, when implemented correctly. Sealmetrics is designed so that no personal data is stored — no IP addresses, no identifiers — which is what keeps the analytics outside the GDPR's personal-data obligations. You should still update your privacy policy to mention analytics.
### What happens with cross-domain tracking?
Cookieless analytics handles cross-domain scenarios differently than cookie-based approaches. Sealmetrics tracks each domain separately unless you configure specific cross-domain setup. Consult documentation for your specific platform.
### Can I migrate from Google Analytics to Sealmetrics?
Yes. Historical Google Analytics data cannot be imported, but you can implement Sealmetrics alongside GA4 temporarily. After 2-3 months of Sealmetrics data, switch completely.
### How does cookieless analytics handle mobile users?
Mobile browsers increasingly block third-party cookies and tracking. Sealmetrics captures mobile traffic reliably because it doesn't depend on cookies or third-party mechanisms. Mobile data is typically more accurate with cookieless platforms.
### What about bot traffic?
Sealmetrics filters obvious bot traffic automatically. However, sophisticated bots can occasionally appear as real visitors. Regularly review traffic sources and set up exclusions if needed.
### Is cookieless analytics cheaper than Google Analytics?
Google Analytics 4 is free. Cookieless alternatives like Sealmetrics cost $9-100+ monthly depending on volume. The tradeoff is: free but dependent on consent — and on the data that consent costs you — versus paid but measuring every visit.
### Can I use both Google Analytics and cookieless analytics simultaneously?
Yes. Many companies run both initially. Google Analytics provides additional features; cookieless analytics ensures GDPR compliance and captures data GA4 misses. Eventually, you'll likely consolidate on cookieless.
## The Future of Analytics: Why Cookieless is Inevitable
Multiple trends guarantee cookieless analytics becomes dominant:
**1. Chrome's Deprecation Timeline**: Google announced third-party cookie deprecation for late 2024-early 2025. This eliminates a core pillar of cookie-based analytics for millions of websites.
**2. EU Regulatory Pressure**: CNIL, GDPR enforcement, and similar bodies continue pressuring cookie-based approaches. Cookieless becomes legally preferred.
**3. Privacy-Conscious Users**: Consumer demand for privacy increases annually. Cookieless analytics aligns with user values.
**4. Better Business Outcomes**: Platforms like Sealmetrics capture complete data that cookie-based solutions miss. Better data drives better decisions.
The question isn't whether your analytics approach will eventually become cookieless—it's when you'll make the transition.
## Conclusion: Moving to Cookieless Analytics
Cookieless analytics represents the modern standard for privacy-compliant, accurate website tracking. Unlike cookie-based approaches that lose 15-60% of EU visitor data, consentless analytics like Sealmetrics capture 100% of your actual traffic.
The business case is clear:
- **Better Insights**: see every visitor, not only the 40-85% who consented
- **GDPR Compliance**: measure without processing personal data in the first place
- **No Consent Complexity**: Eliminate cookie banners and consent flows
- **Faster Implementation**: Set up in minutes, not hours
Starting with Sealmetrics takes 2 minutes. The result is clearer understanding of your visitors, better-informed marketing decisions, and full GDPR compliance.
Your competitors are already making this shift. The websites that understand their complete visitor behavior will outperform those relying on incomplete cookie-based data.
## Related documentation
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — the consentless concept behind cookieless measurement
- [How Consentless Tracking Works](/security-privacy/how-consentless-works) — technical deep dive into the Four-Variable System
- [GDPR and Cookieless Analytics](/compliance/gdpr-cookieless-analytics) — full legal analysis with GDPR article references
- [GA4 vs Sealmetrics — Complete Comparison](/faq/ga4-vs-sealmetrics) — feature-by-feature comparison with Google Analytics
- [First Steps with Sealmetrics](/getting-started/quick-start) — implement cookieless analytics in a few minutes
## UTM Governance: Naming Conventions That Keep Attribution Clean
URL: https://docs.sealmetrics.com/utm-governance
Every marketing report you will ever read starts with a decision someone made while pasting a link: what to type after `utm_source=`. Get that decision right consistently and your Sources report tells you exactly which channels make money. Get it wrong — `Facebook` here, `facebook` there, `fb` in the ESP — and the same channel splinters into three rows, your channel grouping misfires, and every downstream decision is made on fragmented data.
This is what UTM governance means: a small set of written rules, applied by everyone who creates a link, forever. This guide gives you the complete playbook — naming conventions, a source/medium taxonomy that matches Sealmetrics's default channel definitions, the errors that silently corrupt attribution, a spreadsheet template your team can adopt today, and a walkthrough of how Sealmetrics actually processes UTM parameters so you understand *why* the rules matter.
It matters even more in Sealmetrics than in cookie-based tools. Sealmetrics reads UTM parameters **directly from the URL on every page load, without cookies** — attribution works for 100% of your visitors, including the ones who reject or ignore consent banners. That's the good news. The flip side: your UTMs are the primary attribution signal, so their quality *is* your attribution quality.
## The Five UTM Parameters, and What Each Is Actually For
Sealmetrics recognizes the five standard UTM parameters:
| Parameter | URL format | Answers | Example values |
|-----------|------------|---------|----------------|
| Source | `utm_source=` | *Which site or platform sent the click?* | `google`, `facebook`, `newsletter` |
| Medium | `utm_medium=` | *What kind of channel is it?* | `cpc`, `organic`, `email` |
| Campaign | `utm_campaign=` | *Which initiative paid for or produced the link?* | `spring-sale`, `brand-2025` |
| Term | `utm_term=` | *Which keyword (paid search)?* | `running+shoes` |
| Content | `utm_content=` | *Which variant of the ad or link?* | `banner-a`, `text-link` |
A fully tagged URL looks like this:
```
https://example.com/landing?utm_source=google&utm_medium=cpc&utm_campaign=spring-sale&utm_term=running+shoes&utm_content=banner-a
```
Two of these carry almost all the analytical weight. **Source** and **medium** together determine which row of the Sources report the visit lands in and — critically — which **channel** it's assigned to (more on that below). **Campaign** is how you compare initiatives against each other. **Term** and **content** are refinements: keyword-level analysis and creative A/B testing respectively.
The most common conceptual mistake is blurring the source/medium boundary. A useful mental test:
- **Source is a proper noun** — the name of a specific place: `google`, `facebook`, `mailchimp`, `partner-blog`.
- **Medium is a category** — a type of traffic that many sources can share: `cpc`, `email`, `social`, `affiliate`.
If you find yourself typing `utm_medium=facebook`, stop — Facebook is a source. The medium is `social` (organic posts) or `cpc`/`paid` (ads).
## What happens when a parameter is missing
When a UTM parameter is absent from the URL, Sealmetrics reports **"(not set)"** for that field — except `utm_medium`, which shows as **"(none)"**, aligned with GA4's convention. Untagged visits aren't lost: a visit arriving from an untagged external link is attributed to its **referring domain** with medium `referrer` (e.g. `reddit.com / referrer`), and a visit with no referrer at all is `direct`. See [Understanding the "(not set)" value](/reports/insights/understanding-not-set) and [Referral vs Direct Traffic](/reports/insights/referral-vs-direct-traffic).
Governance implication: you only need to tag links **you control** (ads, emails, social posts, partner placements). Organic search, untagged referrals, and direct traffic classify themselves.
## Naming Conventions: The Non-Negotiables
These four rules prevent 90% of UTM chaos. Put them at the top of your governance doc.
### 1. Always lowercase
Sealmetrics reports group by the **exact string value**. `Facebook`, `facebook`, and `FACEBOOK` are three different sources — three separate rows in your report, three separate inputs to channel classification. There is no automatic case normalization at ingest (and deliberately so: silently rewriting your data would be its own problem).
The fix is procedural, not technical: **every UTM value is lowercase, no exceptions.** It's the single highest-leverage rule in this guide because case errors are invisible in the URL bar and only surface weeks later as duplicate rows.
### 2. snake_case or hyphens — pick one separator, never spaces
Multi-word values need a separator. Use underscores (`black_friday_2026`) or hyphens (`black-friday-2026`) — both are fine; what matters is that your team picks **one** and uses it everywhere. Mixed separators (`black_friday` in email, `black-friday` in ads) split one campaign into two rows exactly like a case mismatch does.
**Never use spaces.** A space in a URL gets encoded as `%20` or `+` depending on the tool that built the link, which means "summer sale" can arrive as `summer%20sale`, `summer+sale`, or break the URL entirely. Spaces are how you end up with unexplainable garbage values in the Campaigns tab.
Avoid other special characters too (`&`, `?`, `#`, `=` have structural meaning in URLs). Stick to `a–z`, `0–9`, and your chosen separator.
### 3. One canonical name per entity
Decide the one true spelling of every recurring source and medium, write it down, and outlaw the synonyms:
- `facebook` — not `fb`, not `facebook.com`, not `meta`
- `google` — not `google.com`, not `adwords`
- `newsletter` — not `news_letter`, not `nl`
Domains make bad source values (`facebook.com` vs `facebook`) because they look plausible and thus survive review. Pick the bare platform name.
### 4. Stable, structured campaign names
Campaign names live forever in your historical data, so make them self-describing. A structure that scales well:
```
{year}_{initiative}_{detail}
2026_black_friday_early_access
2026_brand_awareness_q3
2026_product_launch_alpine
```
Prefixing the year keeps recurring campaigns comparable across editions (`2025_black_friday` vs `2026_black_friday`) without ambiguity. Whatever structure you choose, the governance rule is the same: campaign names are **created in the spreadsheet first** (see below), never improvised in the ad platform at publish time.
## A Source/Medium Taxonomy Aligned with Sealmetrics Channels
Here's why medium discipline pays off directly in Sealmetrics: the **Channels** tab of the [Sources report](/reports/sources) buckets every session into a marketing channel by matching its `utm_source`, `utm_medium`, and `utm_campaign` against channel grouping rules. Sealmetrics ships with default channels — from **Paid Search** and **Paid Social** down to **Referral** and **Direct** — whose rules match on exactly the source and medium values in the canonical table on that page. Traffic that matches no rule lands in **Unassigned**.
So the taxonomy below isn't arbitrary: each recommended medium is one the **default channel rules already recognize**. Use these values and your Channels tab works out of the box, with zero custom configuration.
| Traffic type | `utm_source` (examples) | `utm_medium` | Default channel it lands in |
|---|---|---|---|
| Paid search ads | `google`, `bing` | `cpc` | **Paid Search** |
| Paid social ads | `facebook`, `instagram`, `linkedin`, `tiktok` | `cpc` (or `paid`) | **Paid Social** |
| Paid video ads | `youtube`, `vimeo`, `twitch` | `cpc` (or a paid/video medium) | **Paid Video** |
| Display / banners | ad network name | `display` | **Display** |
| Shopping ads | `google`, `bing` | `shopping` | **Paid Shopping** |
| Organic social posts | `facebook`, `instagram`, `linkedin`, `x` | `social` | **Organic Social** |
| Email campaigns | `newsletter`, `mailchimp`, `klaviyo` | `email` | **Email** |
| AI assistants | `chatgpt`, `perplexity` | `ai` | **AI** |
| Affiliate partners | partner name | `affiliate` | **Affiliates** |
| SMS campaigns | your brand or tool name | `sms` | **SMS** |
| Push notifications | your tool name | `push` | **Push** |
| Podcast / audio | `spotify`, podcast name | audio medium | **Audio** |
A few notes on using this table:
- **Don't tag what classifies itself.** Organic search (`Organic Search`), untagged referrals (`Referral`), and direct visits (`Direct`) are detected without UTMs. Tagging is for the links you place.
- **The default rules are forgiving; your taxonomy shouldn't be.** The Paid Search rule matches several paid mediums (`cpc`, `ppc`, `paid`, `sem`) precisely because teams are inconsistent. Pick **one** — we recommend `cpc` for all paid click inventory — so your Mediums tab stays clean even though the channel layer would have caught the synonyms.
- The full, canonical channel-by-channel matching table lives in the [Sources report documentation](/reports/sources#default-channels). If you go beyond the defaults — Brand vs Non-Brand splits, per-partner affiliate channels — that's what custom [Channel Grouping](/platform/settings/tracking/channel-grouping) rules are for, with a safe draft → test → publish workflow.
## The Errors That Silently Corrupt Attribution
Every one of these comes from a real-world pattern. Screen your links against this list.
### Case and synonym drift
Covered above, but worth restating as the #1 offender: `utm_source=Facebook` vs `facebook`, `fb` vs `facebook`, `Email` vs `email`. Each variant is a separate row and a separate input to channel rules. The symptom is a Sources report where the same logical channel appears multiple times with split metrics.
### Spaces and encoding surprises
`utm_campaign=spring sale` becomes `spring%20sale` or `spring+sale` depending on which tool encoded it — potentially both, in the same campaign, from different tools. Use your separator instead.
### UTMs on internal links — never
UTM parameters describe **how a visitor arrived at your site from outside**. Putting them on internal links — a homepage banner tagged `utm_source=homepage_banner`, a menu item tagged `utm_campaign=nav_test` — is the most destructive mistake on this list: mid-visit, you're overwriting the *acquisition* signal with *navigation* trivia. The visitor who actually came from your expensive Google Ads campaign now shows up in reports attributed to "homepage_banner". Your acquisition data gets polluted by on-site behavior, and no report can un-mix them afterwards.
For measuring internal elements, use [microconversions](/getting-started/measure-conversions) (`sealmetrics.micro('cta_click')`) or [Content Grouping](/platform/settings/tracking/content-grouping) — that's what they're for. UTMs are for external links only. No exceptions.
### Medium/source role confusion
`utm_medium=facebook` (a source in the medium slot), `utm_source=cpc` (a medium in the source slot). Both cause the channel rules to see nonsense — the Paid Social rule expects a social network in *source* and a paid medium in *medium*, so an inverted pair falls through to **Unassigned**. Apply the proper-noun/category test from above.
### Redundant or overloaded parameters
Stuffing everything into one parameter (`utm_campaign=facebook_cpc_black_friday_banner_a`) wastes the structure that makes reports filterable. That string contains a source, a medium, a campaign, and a content variant — put each in its own parameter and the Sources report's drill-downs (source → campaigns → terms) work for free.
### Tagging your own domain in emails-to-site handoffs
Watch out for tools that append their own tracking parameters (some affiliate networks and CMSes do). If a vendor's parameter carries real attribution value under a non-UTM name, don't rewrite your links — map it with [UTM Mapping](/platform/settings/tracking/utm-mapping) (see below).
## The Governance Spreadsheet
The difference between having conventions and having *governance* is a living document. One shared spreadsheet, one owner, and a rule: **no tagged link ships unless its campaign row exists in the sheet.**
A battle-tested structure — one row per tagged link (or per link family):
| Column | Example | Notes |
|---|---|---|
| Date created | `2026-07-23` | |
| Owner | `maria` | Who to ask when the row is unclear |
| Landing URL | `https://example.com/landing` | Without parameters |
| `utm_source` | `facebook` | **Dropdown** from your canonical source list |
| `utm_medium` | `cpc` | **Dropdown** from your canonical medium list |
| `utm_campaign` | `2026_black_friday_early_access` | Free text, but validated against the naming pattern |
| `utm_term` | `running_shoes` | Paid search only |
| `utm_content` | `banner_a` | Only when A/B testing creatives |
| Final URL | *(formula)* | Concatenated automatically — humans never hand-assemble URLs |
| Status | `live` | `draft` / `live` / `ended` |
Three practices make the sheet actually work:
1. **Dropdown validation on source and medium.** Free-text fields are where `Facebook` sneaks in. Data-validation dropdowns make the canonical list the only possible input — the spreadsheet becomes your enforcement mechanism, not just your record.
2. **A URL-building formula.** The Final URL column concatenates the landing URL and parameters (lowercasing on the way is cheap insurance). Marketers copy the finished URL; nobody types `?utm_` by hand.
3. **A named owner.** Someone approves new campaign names, prunes ended rows, and owns the canonical value lists. Governance without an owner decays in about one quarter.
Review the sheet against your live data monthly: open the Sources report, sort each tab, and look for rows that shouldn't exist — an unfamiliar source, a `(not set)` where a campaign should be, a near-duplicate value. Every anomaly traces back to either an untagged link (add it to the sheet) or a rule violation (fix the link, remind the human).
## How Sealmetrics Processes Your UTMs
Understanding the pipeline turns the rules above from dogma into engineering. When a visit arrives, Sealmetrics processes attribution in this order:
```
URL arrives → UTMs extracted → Your UTM Mappings applied
→ Channel rules evaluated (custom → default)
→ Channel assigned to the visit
```
### Stage 1: UTMs are read from the URL — every load, no cookies
The tracker reads the query string on each page load. There is no consent gate and no cookie dependency, which is why Sealmetrics attributes campaigns correctly even for visitors that cookie-based tools lose entirely. Your tagged URL *is* the attribution record.
### Stage 2: UTM Mappings translate custom parameters
If your ESP, CRM, or ad platform emits its own parameter names — `campaign_id`, `email_source`, `ad_medium` — [UTM Mapping](/platform/settings/tracking/utm-mapping) lets you declare, per site, "treat `campaign_id` as `utm_campaign`". The mapping is applied at ingest, before classification, with well-defined semantics: **explicit UTMs always win** over mapped values, mappings copy (never move) the value, and empty parameters are a no-op. Mappings take effect in ~5 minutes and apply to future traffic only.
Governance implication: UTM Mapping is your integration escape hatch, not an excuse to skip conventions. The *values* still need to follow your taxonomy — mapping renames the parameter, it never rewrites `Facebook` into `facebook`. There's deliberately no value transformation at ingest.
### Stage 3: Channel rules classify the visit
With final UTM values in hand, Sealmetrics evaluates [channel grouping rules](/platform/settings/tracking/channel-grouping) in priority order — your account's custom rules first, then the defaults — and the first match wins. This is where your source/medium discipline cashes out: rules are regex patterns over `utm_source`, `utm_medium`, and `utm_campaign`, so consistent values mean deterministic channels.
Two governance-relevant features of the channel settings:
- **Test before you trust.** The **Test a visit** tool in Channel Grouping settings lets you type any source/medium/campaign combination and see exactly which rule catches it — including draft rules that aren't live yet. Make it a habit: when you add a new taxonomy value, test it before the campaign launches, not after a week of Unassigned traffic.
- **Drafts → test → publish.** Custom rules are created as drafts and only affect real classification when a human publishes them, so experimenting is safe. Rules can also be bulk-managed via CSV import/export.
### Where it all shows up
The [Sources report](/reports/sources) presents the result across seven tabs — Channels (the default view), Sources, Mediums, Campaigns, Terms, Content, and Referrers — each with entrances, bounce rate, conversions, and revenue per row. Clean UTMs in, clean seven-way breakdown out.
## Your UTM Governance Checklist
Condensed version to copy into your team wiki:
- [ ] All UTM values are **lowercase**, always
- [ ] One separator (`_` or `-`), no spaces, no special characters
- [ ] One canonical name per source and medium — synonyms are outlawed in writing
- [ ] Mediums come from the [default-channel-compatible taxonomy](/reports/sources#default-channels)
- [ ] Campaign names follow a documented structure and are created in the spreadsheet first
- [ ] **Zero UTMs on internal links** — use microconversions or Content Grouping instead
- [ ] Links are generated by the spreadsheet formula, never hand-typed
- [ ] Custom vendor parameters are handled via [UTM Mapping](/platform/settings/tracking/utm-mapping), values still follow the taxonomy
- [ ] New values are checked in the [Channel Grouping "Test a visit" tool](/platform/settings/tracking/channel-grouping#using-test-a-visit) before launch
- [ ] Monthly audit of the Sources report against the spreadsheet, with a named owner
## Related documentation
- [Sources Report](/reports/sources) — the canonical default-channel table and all seven analysis tabs
- [UTM Mapping](/platform/settings/tracking/utm-mapping) — custom parameter names → standard UTMs at ingest
- [Channel Grouping](/platform/settings/tracking/channel-grouping) — custom channels, the rule tester, and the draft workflow
- [How to Track Google Ads Campaigns](/reports/insights/how-to-track-google-ads-campaigns) — UTM templates for paid search
- [How to Track Social Ads Campaigns](/reports/insights/how-to-track-social-ads-campaigns) — UTM tagging for Meta Ads
- [How to Change UTM Parameters](/reports/insights/how-to-change-utm-parameters) — the UTM Mappings UI walkthrough
## GA4 to Sealmetrics: The Complete Migration Checklist
URL: https://docs.sealmetrics.com/ga4-migration-checklist
Migrating from Google Analytics 4 to Sealmetrics is not technically hard — the tracker is one script tag and conversions are one JavaScript call. What trips teams up is everything *around* the install: forgetting an event that a monthly report depends on, comparing metrics that aren't defined the same way, or switching GA4 off before anyone validated the new numbers.
This guide is the antidote: a phase-by-phase checklist that takes you from a GA4 audit to a confident GA4 shutdown, with a full metric-equivalence table and a realistic picture of what the side-by-side data **should** look like — because if you don't know in advance that Sealmetrics will report substantially more traffic than GA4, the first parallel-running week will look like a bug instead of the whole point.
Most teams complete the migration in **1–2 weeks of work spread over ~5 weeks of calendar time** (the parallel-validation month is deliberately slow). Both platforms coexist without conflict, so there is no risky cutover moment: GA4 keeps running until you choose to stop it.
**Tip:**
This checklist goes deep on process. For the concept-by-concept overview see the [GA4 Migration Guide](/ga4-migration), and for the full product comparison (features, pricing, compliance) see [GA4 vs Sealmetrics](/faq/ga4-vs-sealmetrics).
## Phase 0 — Audit What You Actually Use in GA4 (2–4 hours)
Before touching any code, inventory your GA4 property. The goal is a written list of everything the migration must preserve — and, just as valuable, everything it doesn't need to.
- [ ] **List the core metrics your team reports on.** Sessions, users, pageviews, conversions, revenue — note which reports and dashboards consume each.
- [ ] **Export the event inventory.** In GA4, list every event and which ones are marked as key events (conversions). For each: what triggers it, what parameters it carries, who looks at it.
- [ ] **Flag the zombie events.** Most GA4 properties accumulate events nobody has looked at in a year. Mark them — you will *not* migrate them, and that's a feature.
- [ ] **Document your e-commerce implementation.** Which e-commerce events fire (`purchase`, `add_to_cart`, `begin_checkout`, `view_item`), whether they're implemented via gtag or Google Tag Manager, and where the purchase value comes from.
- [ ] **List audiences and custom definitions** (custom dimensions/metrics) that reports depend on.
- [ ] **List connected integrations.** Google Ads links, Search Console, Data Studio dashboards, BigQuery export. For each: who consumes it and what breaks without it.
- [ ] **Note your GA4 reporting timezone.** You'll need it in Phase 2 — timezone mismatch is the most common cause of "the daily numbers don't line up".
- [ ] **Note your data-retention settings** and decide what history you need to export before shutdown (Phase 5).
One integration deserves a decision now, not later: **Google Ads audience sync**. Sealmetrics tracks Google Ads campaigns end to end via UTM parameters and provides ROAS reporting, but it does not push audience segments back to Google Ads for automated bidding — that requires GA4 with consented users. If your bidding strategy depends on GA4 audiences, plan to keep GA4 running for that single purpose while Sealmetrics becomes the source of truth for traffic and conversions. Many teams run exactly this split permanently.
## Phase 1 — Map GA4 Events to `conv()` and `micro()` (half a day)
Sealmetrics has a deliberately simpler event model than GA4. Instead of one undifferentiated event stream where anything can be promoted to a "key event", there are two explicit calls:
- **`sealmetrics.conv(type, amount)`** — a **conversion**: a goal completion, optionally with monetary value.
- **`sealmetrics.micro(type)`** — a **microconversion**: a funnel step or engagement signal on the way to a conversion.
The mapping exercise is to sort your surviving GA4 events into those two buckets. The dividing line: *would you celebrate this event on its own?* Purchases, leads, signups — conversions. Add-to-carts, video plays, scroll milestones — microconversions.
### Recommended event mapping
| GA4 event | Sealmetrics call | Notes |
|---|---|---|
| `purchase` | `sealmetrics.conv('purchase', value)` | Pass the order total; it feeds Revenue and AOV |
| `generate_lead` | `sealmetrics.conv('lead')` | Amount optional |
| `sign_up` | `sealmetrics.conv('signup')` | |
| Subscription started | `sealmetrics.conv('subscription', value)` | |
| Booking / reservation | `sealmetrics.conv('booking', value)` | |
| `view_item` | `sealmetrics.micro('view_item')` | |
| `add_to_cart` | `sealmetrics.micro('add_to_cart')` | |
| `begin_checkout` | `sealmetrics.micro('begin_checkout')` | |
| Form submitted (non-lead) | `sealmetrics.micro('form_submit')` | |
| Newsletter subscription | `sealmetrics.micro('newsletter_signup')` | |
| CTA / button click | `sealmetrics.micro('cta_click')` | |
| `video_start` | `sealmetrics.micro('video_play')` | |
| `video_complete` | `sealmetrics.micro('video_complete')` | |
| `scroll` (90% default) | `sealmetrics.micro('scroll_50')` / `sealmetrics.micro('scroll_100')` | Pick the milestones you care about |
| `file_download` | `sealmetrics.micro('file_download')` | |
| `view_search_results` | `sealmetrics.micro('search')` | |
Naming rules (they matter for data continuity):
- [ ] **snake_case, descriptive, stable.** `add_to_cart`, not `addToCart`; `begin_checkout`, not `step2`. Changing a name later breaks historical continuity.
- [ ] **Never put personal data in events.** No order IDs, no user IDs, no emails — neither in the type name nor in properties. This is core to Sealmetrics's consentless model, and the platform's verification tooling actively rejects PII it detects.
- [ ] **Write the mapping down** as a two-column table (GA4 event → Sealmetrics call) before writing any code. It becomes your Phase 3 test plan.
- [ ] **Map custom dimensions to event properties.** GA4 custom dimensions become properties on the call: `sealmetrics.conv('purchase', 99.99, { currency: 'EUR', payment_method: 'card' })`. Only migrate the ones your reports actually use.
- [ ] **Map audiences to Segments** and **data streams to Sites** — see the concept table in the [GA4 Migration Guide](/ga4-migration#how-ga4-concepts-map-to-sealmetrics).
**Tip:**
If you use Claude or another MCP-capable assistant, the [AI setup flow](/getting-started/install-with-ai) can drive this phase: the assistant fetches the canonical instrumentation guide for your account, writes the `conv()`/`micro()` calls, and verifies each event arrives — rejecting typos and PII automatically.
## Phase 2 — Install Sealmetrics Alongside GA4 (1–2 hours)
Do **not** remove GA4 yet. The two coexist cleanly — Sealmetrics's tracker is 1.3 KB, sets zero cookies, and doesn't interfere with gtag.
- [ ] **Create your account and site** — [First Steps](/getting-started/quick-start) walks through it (or let [your AI assistant do it from a chat](/getting-started/install-with-ai)).
- [ ] **Set the site timezone to match your GA4 reporting timezone** (Site settings → General) *before* collecting comparison data. Sealmetrics resolves every date preset in the site's timezone; a mismatch with GA4's reporting timezone shifts daily rollups by up to a day at the seams and will poison your Phase 3 comparison.
- [ ] **Install the tracker** on every page — one script tag in the ``, or via the [WordPress plugin, Google Tag Manager](/getting-started/quick-start#installation-methods), or your platform's [integration](/integrations).
- [ ] **Verify the pixel:** open your site, then check the **Overview** report's *Last hit* timestamp — it updates within seconds.
- [ ] **Instrument the mapped events** from your Phase 1 table with `sealmetrics.conv()` / `sealmetrics.micro()` — see [How to Measure Conversions](/getting-started/measure-conversions) for placement patterns (thank-you pages, form handlers, button clicks).
- [ ] **Fire each event once and confirm it arrives** in the Conversions report with the date range set to today. Check the browser Network tab for requests to `t.sealmetrics.com` when the event fires.
- [ ] **Configure attribution settings** if you customized them in GA4: [channel grouping rules](/platform/settings/tracking/channel-grouping), [UTM mappings](/platform/settings/tracking/utm-mapping) for any custom parameter names, and [IP exclusions](/platform/settings/tracking/ip-exclusions) for office/QA traffic.
- [ ] **Keep your UTM conventions intact.** Sealmetrics reads standard UTMs automatically — no retagging needed. (This is also the ideal moment to clean up your taxonomy: see the [UTM Governance guide](/guides/utm-governance).)
## Phase 3 — Run 30 Days in Parallel (calendar time, low effort)
Now both platforms measure the same site. Give it **30 days** — enough to cover weekly cycles, at least one campaign, and enough conversion volume for stable ratios.
- [ ] Week 1: confirm all pages are tracked (compare pageview coverage, spot-check key templates)
- [ ] Week 1: confirm every mapped event fires in production, not just in your test
- [ ] Weekly: record the GA4-vs-Sealmetrics ratio for entrances/sessions, conversions, and revenue
- [ ] Weekly: compare the *shape* of traffic (top sources, top pages, device split) — shapes should correlate even where totals differ
- [ ] Rebuild one key dashboard on Sealmetrics data early, so stakeholders acclimate before cutover
### What the comparison SHOULD look like
This is the phase where unprepared teams panic, because **the numbers will not match — by design**. Here's what to expect and why:
**Sealmetrics will report substantially more traffic.** GA4 only records visitors who accept cookies; in EU markets, rejection plus banner-ghosting means GA4 typically captures only 15–50% of actual traffic. Sealmetrics requires no consent and captures everyone. EU-heavy sites commonly see Sealmetrics report **several times** GA4's session count. If Sealmetrics shows *more*, that's the migration working. If it shows *less*, something's wrong — check tracker coverage.
**GA4's "Direct" share will look inflated by comparison.** When a visitor rejects cookies, GA4 loses the UTM/attribution context and often misfiles paid and organic traffic as "Direct / (none)". Sealmetrics reads UTMs from the URL on every load, consent or not, so campaign attribution stays intact for 100% of visits. Expect Sealmetrics to show more campaign-attributed traffic and proportionally less direct.
**The ratio, not the absolute, is your validation metric.** You can't reconcile the totals — they measure different populations. What you *can* validate: the GA4:Sealmetrics ratio should be roughly **stable week over week**, and relative rankings (top campaigns, top landing pages) should broadly agree. A stable ratio plus consistent shapes means both tools are healthy; a swinging ratio means an instrumentation problem.
**Some metrics won't exist to compare.** See the equivalence table below — GA4's users and session duration have no Sealmetrics counterpart, on purpose.
**Engagement metrics use different formulas.** GA4 counts a session as engaged if it lasted 10+ seconds *or* had a key event *or* had 2+ pageviews. Sealmetrics defines engaged strictly as **2+ pageviews** — computed in aggregate, with no individual tracking. Expect Sealmetrics's bounce rate to read somewhat higher and engagement rate somewhat lower than GA4's on the same traffic. Neither is wrong; they answer with different yardsticks.
### Metric equivalence table
| GA4 metric | Sealmetrics metric | Comparable? | Notes |
|---|---|---|---|
| Sessions | **Entrances** | Roughly | Same idea — a visit. Sealmetrics starts a session on arrival with an external (or no) referrer and groups follow-up hits within a ~2-hour inactivity window, with **no persistent identifier**. Expect higher counts (no consent loss). See [How Sealmetrics Calculates Entrances](/reports/insights/how-sealmetrics-calculates-entrances) |
| Users / Total users | **Not tracked** | No | Identifying unique visitors requires a persistent identifier — personal data under GDPR. Use Entrances as the audience-size signal. See [Metrics Reference](/reports/definitions#unique-visitors--not-tracked) |
| Views (`page_view`) | **Pageviews** | Yes | Same definition: one page load = one pageview |
| Engaged sessions | **Engaged Entrances** | Formula differs | Sealmetrics: strictly sessions with 2+ pageviews. GA4 also counts 10s duration or a key event |
| Engagement rate | **Engagement Rate** | Formula differs | Engaged Entrances / Entrances × 100. Expect a lower reading than GA4's |
| Bounce rate | **Bounce Rate** | Formula differs | (Entrances − Engaged Entrances) / Entrances × 100, aggregate-only. Expect a higher reading than GA4's |
| Views per session | **Pages per Session** | Yes | Pageviews / Entrances |
| Average engagement time / session duration | **Not tracked** | No | Requires following an individual across page loads — excluded by design |
| Key events (conversions) | **Conversions** | Yes | Each `sealmetrics.conv()` call counts as 1; a session can convert more than once |
| Events (non-key) | **Microconversions** | Yes | Each `sealmetrics.micro()` call counts as 1 |
| Purchase revenue | **Revenue** | Yes | Sum of amounts passed to `sealmetrics.conv(type, amount)` |
| — | **AOV** | — | Revenue / Conversions, built in |
| Session conversion rate | **Conversion Rate** | Roughly | Conversions / Entrances × 100 — not deduplicated per session, capped at 100% |
| Session default channel group | **Channels** | Yes | Default channel rules (Paid Search, Organic Social, Email, AI…) — see the [Sources report](/reports/sources#default-channels), customizable via [Channel Grouping](/platform/settings/tracking/channel-grouping) |
| Audiences | **Segments** | Yes | Saved filter sets |
| Custom dimensions | **Custom properties** | Yes | Properties on `conv()`/`micro()` calls, reported under [Properties](/reports/properties) |
| Predictive metrics (purchase/churn probability) | **Not available** | No | Sealmetrics reports observed behavior only |
### Sign-off criteria to exit Phase 3
- [ ] Every event in the Phase 1 mapping table has produced production data
- [ ] The GA4:Sealmetrics entrance ratio has been stable (±~10%) for 2+ consecutive weeks
- [ ] Top-5 sources, campaigns, and landing pages broadly agree in ranking across both tools
- [ ] Revenue totals are explainable (Sealmetrics ≥ GA4, with the gap consistent with your consent-rejection rate)
- [ ] Stakeholders have seen a Sealmetrics-based version of their key report and accepted the definitional differences above
## Phase 4 — Preserve GA4 History and Repoint Consumers (half a day)
Sealmetrics starts collecting from day one; it does not import GA4 history. Whatever you'll want to reference later must be exported **while GA4 still works**.
- [ ] **Export the reports you'll want as reference** — monthly traffic, top campaigns, conversion totals — via CSV, or raw events via BigQuery export if you have it. GA4's retention window (14 months on the free tier) means this history disappears on its own schedule anyway.
- [ ] **Rebuild dashboards** (Data Studio, BI) against Sealmetrics's [Exports API](/api/exports) or [Batch API](/api/batch), and use per-report CSV/PDF export for one-off needs.
- [ ] **Repoint every consumer** from the Phase 0 integration list: dashboards, scheduled reports, internal tools.
- [ ] **Brief the team on the new vocabulary** — entrances not sessions, no users metric, the engagement formula difference. The equivalence table above is the handout.
## Phase 5 — Switch GA4 Off (1 hour, plus a decision)
Only after Phase 3 sign-off and Phase 4 exports:
- [ ] **Remove the GA4 tag** (gtag snippet or the GTM tag) from your site — unless you decided in Phase 0 to keep GA4 alive for Google Ads audience sync, in which case scope it to that and stop using it for reporting.
- [ ] **Archive, don't delete, the GA4 property** — it costs nothing to keep and preserves whatever history remains accessible.
- [ ] **Revisit your consent banner.** With GA4 gone, analytics no longer requires consent — Sealmetrics operates consentless because it stores no personal data. If other cookie-setting tools remain (ad pixels, etc.) you still need consent for *those*; if analytics was the only reason for the banner, you can now remove it. See the [compliance overview](/compliance).
- [ ] **Announce the cutover date** internally: from this date, Sealmetrics is the source of truth and GA4 numbers are historical reference only. Comparing across the boundary without the equivalence table above is banned in polite company.
## Common Migration Pitfalls
- **Comparing absolutes instead of ratios in Phase 3.** The totals will never match; the stability of the gap is the signal.
- **Skipping the timezone alignment.** A GA4/Sealmetrics reporting-timezone mismatch shifts daily numbers at the day boundary and makes honest data look broken.
- **Migrating every GA4 event.** The zombie events you flagged in Phase 0 stay dead. Migrate what reports consume.
- **Putting IDs in events.** GA4 tolerated `purchase_12345`-style event data; Sealmetrics's model (and its verification tooling) forbids personal data and order/user IDs in events. Keep types stable and generic; details go in non-PII properties.
- **Switching off GA4 before exporting.** Retention limits make this a one-way door.
- **Expecting session duration or users.** They're not late features — they're deliberately excluded because they require individually tracking people. The privacy-safe substitutes are pages per session, engaged entrances, and entrances.
## Related documentation
- [GA4 Migration Guide](/ga4-migration) — concept-mapping overview and what's different
- [GA4 vs Sealmetrics — Complete Comparison](/faq/ga4-vs-sealmetrics) — features, compliance, and pricing side by side
- [First Steps with Sealmetrics](/getting-started/quick-start) — the installation walkthrough
- [Set Up Sealmetrics with Your AI Assistant](/getting-started/install-with-ai) — let an AI agent run the install and event verification
- [How to Measure Conversions](/getting-started/measure-conversions) — `conv()`/`micro()` implementation patterns
- [Metrics Reference](/reports/definitions) — every formula behind the equivalence table
## Tracker Performance Report: Sealmetrics vs GA4
URL: https://docs.sealmetrics.com/tracker-performance-report
The current Sealmetrics tracker weighs **1.1 KB on the wire** — 12× less than the legacy Sealmetrics v1 tracker and roughly 132× less than GA4's `gtag.js`. That weight, combined with a single-step dispatch chain and an ingestion pipeline rebuilt from scratch (Go → RabbitMQ → ClickHouse), translates into more hits captured: dual-tagged sites (running both Sealmetrics trackers in parallel) measure **25–30% more traffic on average with the current tracker than with v1**, with the gain concentrated in mobile traffic and in visitors geographically far from our Dublin servers.
**Key numbers at a glance:**
| | vs legacy v1 | vs GA4 |
|---|---|---|
| Wire weight advantage | 12× lighter | ~132× lighter |
| Measured traffic difference | +25–30% (dual-tag average) | +25–45% (EU markets, estimate) |
**Note:**
Script weights re-measured **9 August 2026** from each vendor's production CDN: one GET with `Accept-Encoding: gzip`, bytes counted on disk. Vendor scripts change — `gtag.js` alone went from ~171 KB to ~146 KB between passes — so treat these as a dated snapshot.
## Methodology
The weight and latency figures in this report come from **direct measurements** taken in July 2026 against production scripts, downloaded exactly as a real browser receives them (`Accept-Encoding: gzip`, 3 samples per measurement, fiber connection from Spain):
- **Sealmetrics (current)**: `t.sealmetrics.com/t.js` — the production script.
- **Sealmetrics v1 (legacy)**: `app.sealmetrics.com/tag/v3/tracker` (version `sm 16.x`).
- **GA4**: `googletagmanager.com/gtag/js` with the ID of a real GA4 property in production.
Script URLs and tag configurations were extracted from the **real Google Tag Manager container** of a European e-commerce site that runs both Sealmetrics trackers in parallel alongside GA4. To preserve the site's anonymity, the GA4 figures and latency values have been rounded and lightly adjusted; orders of magnitude and ratios between systems are preserved. The Sealmetrics tracker weights are exact — they are product scripts, identical for every customer.
### What is measured and what is modeled
- **Measured**: script weights (exact bytes, compressed and uncompressed), HTTP protocol and headers, the latency table below (median of 3 samples from a single location), IP addresses, and GTM configuration. Absolute latency values depend on the origin network; the relative differences between systems hold.
- **Modeled**: the four network scenarios (round-trip, bandwidth, and CPU arithmetic built on top of the measurements) and the per-device parse costs. These are always labeled as estimates.
- **Business data**: the +25–30% traffic difference vs v1 comes from Sealmetrics accounts running both trackers in parallel on the same site (dual-tagging). The +25–45% vs GA4 is a reasoned estimate, not a measurement of any single site.
### How consent is treated
Every GA4 measurement and model in this report represents its technical chain *once the tag fires* — that is, GA4's **best case** (a visitor who has already granted consent). The cost of the consent banner is quantified separately, as volume loss, in the traffic impact section. Sealmetrics trackers have no such wait: they are consentless measurement by design (no cookies, no personal identifiers).
## Script weight
What travels over the network determines when the first hit can fire. The legacy v1 tracker is also served **uncompressed**, so its wire weight is its raw weight.
| | Sealmetrics (current) | Sealmetrics v1 (legacy) | GA4 (gtag.js) |
|---|---|---|---|
| **Transferred over the network** | **1.1 KB** (gzip) | 13.7 KB (no gzip) | ~146 KB (gzip) |
| **Uncompressed (what the CPU parses)** | 2.0 KB | 13.7 KB | ~409 KB |
| **Relative wire weight** | 1× | 12× | ~132× |
**The TCP detail that matters:** the current tracker's 1.1 KB fits in a single packet and arrives in the first round-trip. The v1 tracker's 13.7 KB uncompressed sits right at the edge of TCP's initial congestion window (~14.6 KB), and GA4's ~146 KB needs 4–5 slow-start round-trips. When the visitor is far from the server, every extra round-trip multiplies latency.
## Delivery protocol and infrastructure
| | Sealmetrics (current) | Sealmetrics v1 (legacy) | GA4 |
|---|---|---|---|
| Protocol | HTTP/2 | HTTP/1.1 | HTTP/2 + HTTP/3 |
| Compression | gzip (1.1 KB) | none | gzip |
| Origin | Dedicated Go service (Dublin) | nginx (Dublin) | Google global anycast CDN |
| Requests until first hit | 1 script → immediate beacon | loader + script + hit (2 steps) | gtag ~146 KB + collect on a 2nd domain |
| Hit transport | `sendBeacon` — survives page close | standard request after tracker loads | beacon/fetch after evaluating ~409 KB |
| Data pipeline | Go → RabbitMQ → ClickHouse (columnar, real time) | legacy monolithic stack | batch processing; reports lag 24–48 h with thresholds |
## Measured latency (fiber, Spain)
Median of 3 samples with warm DNS. Even in the best possible network scenario, the current tracker completes its download in roughly half the time of v1 and GA4.
| Phase | Sealmetrics (current) | Sealmetrics v1 | GA4 |
|---|---|---|---|
| TCP connect (≈ RTT) | ~34 ms | ~48 ms | ~19 ms (local edge) |
| TLS established | ~80 ms | ~95–100 ms | ~55–70 ms |
| Time to first byte | ~110 ms | ~190–280 ms | ~110–140 ms |
| Script fully downloaded | **~110 ms** | ~190–340 ms | ~210–290 ms |
GA4 wins on network proximity (a Google edge in every city) but loses it all on volume: even with a better RTT, downloading ~146 KB takes twice as long as downloading 1.1 KB from Dublin — and after that, ~409 KB of JavaScript still has to be parsed on the visitor's device.
## Time to first hit: four network scenarios
The tables below break the full pageview path into four phases: **connection** (DNS + TCP + TLS — driven by distance to the server), **download** (driven by script weight), **CPU** (parsing and executing the JavaScript — driven by uncompressed weight and device), and **hit dispatch** (v1 needs an extra round-trip; GA4 connects to a second domain; in the current tracker the beacon fires inside the execution phase). These are **modeled estimates** built on the measurements above. This is the time from tag fire until the pageview leaves the device — the window during which an abandonment is a lost hit.
**Note:**
They model the technical chain from the moment the tag fires — a visitor with consent already granted. For a new EU visitor, GA4 additionally requires prior banner acceptance: an extra delay of seconds (or forever, if they never accept) that does not appear in these numbers.
**Fiber / fast 4G · Spain** (RTT ~30 ms to Dublin, ~15 ms to Google edge, fast CPU):
| | Connection | Download | CPU | Hit dispatch | Total |
|---|---|---|---|---|---|
| Sealmetrics (current) | ~80 ms | ~30 ms | ~2 ms | included | **~0.1 s** |
| Sealmetrics v1 | ~95 ms | ~145 ms | ~15 ms | ~45 ms | ~0.2–0.3 s |
| GA4 | ~60 ms | ~170 ms | ~180 ms | ~60 ms | ~0.5–0.7 s |
GA4's connection phase is the shortest of the three — its edge is 15 ms away. It still finishes last: download and CPU consume the advantage twenty times over.
**Mid 4G · mobile** (RTT ~80 ms to Dublin, ~50 ms to edge, 8 Mbps, mid-range CPU):
| | Connection | Download | CPU | Hit dispatch | Total |
|---|---|---|---|---|---|
| Sealmetrics (current) | ~180 ms | ~90 ms | ~5 ms | included | **~0.3 s** |
| Sealmetrics v1 | ~260 ms | ~250 ms | ~35 ms | ~80 ms | ~0.6–0.9 s |
| GA4 | ~120 ms | ~380 ms | ~400 ms | ~100 ms | ~1.0–1.5 s |
On a mid-range phone, CPU becomes GA4's largest phase: parsing ~409 KB costs more than the current tracker's entire chain.
**3G / weak signal** (RTT ~200 ms, 1.5 Mbps, slow CPU):
| | Connection | Download | CPU | Hit dispatch | Total |
|---|---|---|---|---|---|
| Sealmetrics (current) | ~430 ms | ~220 ms | ~10 ms | included | **~0.7 s** |
| Sealmetrics v1 | ~650 ms | ~800 ms | ~100 ms | ~250 ms | ~1.6–2.2 s |
| GA4 | ~350 ms | ~1.8 s | ~1.6 s | ~400 ms | ~3.5–5 s |
At 1.5 Mbps, GA4 spends ~3.4 s just downloading and parsing. The current tracker has had the hit delivered for 3 seconds by the time gtag is still downloading.
**Remote visitor · e.g. LATAM → Dublin** (RTT ~220 ms to Dublin, ~30 ms to local Google edge, 10 Mbps):
| | Connection | Download | CPU | Hit dispatch | Total |
|---|---|---|---|---|---|
| Sealmetrics (current) | ~460 ms | ~280 ms | ~10 ms | included | **~0.7–0.9 s** |
| Sealmetrics v1 | ~680 ms | ~500 ms | ~40 ms | ~250 ms | ~1.4–1.9 s |
| GA4 | ~80 ms | ~330 ms | ~450 ms | ~140 ms | ~0.9–1.4 s |
The most illustrative case: GA4 has its best connection here (an edge in the visitor's own city) and Sealmetrics its worst (2 round-trips of ~220 ms to Dublin). Even with that network disadvantage, **the current tracker delivers the hit first**: its download and CPU phases are so small that distance is the only thing it pays for. GA4 wins the connection and loses the race on volume and CPU.
### Round-trips and bytes
| | Sealmetrics (current) | Sealmetrics v1 | GA4 |
|---|---|---|---|
| TLS connections needed | 1 | 1 | 2 (gtag + collect) |
| Round-trips until the hit | ~3 | ~5–6 | ~7–9 |
| Bytes over the network | 1.1 KB | 13.7 KB | ~170 KB |
| JavaScript to parse | 2.0 KB | 13.7 KB | ~510 KB |
### The hidden cost: parsing JavaScript has no CDN
A global edge brings bytes closer, but parsing always happens on the visitor's device. Estimated parse + execution cost by device class:
| Device | Sealmetrics · 2 KB | v1 · 13.7 KB | GA4 · ~510 KB |
|---|---|---|---|
| Laptop / high-end | under 1 ms | ~5 ms | ~120–250 ms |
| Mid-range phone | ~2 ms | ~15 ms | ~300–500 ms |
| Low-end phone | ~5 ms | ~40 ms | ~800–1,500 ms |
This is the structural reason GA4 cannot compensate for its weight with infrastructure: Google can put an edge in every city, but it cannot put a faster CPU in every visitor's pocket. The current tracker attacks the problem from the other side — making sure there is almost nothing to download or parse.
## Why the current tracker captures hits the others lose
Every visit that abandons the page **before** the pixel fires is invisible traffic. The current tracker's vulnerability window is ~0.1–0.9 s depending on network; v1's is 2–3× larger — and v1 can also lose the hit to a race condition even when the visitor stays.
**Legacy v1 chain — two steps with a race:**
1. An inline loader snippet creates the `sealmetrics.q` queue.
2. The 13.7 KB tracker downloads (HTTP/1.1, no gzip).
3. The script parses and executes; tags call `window.sm`.
4. If the tracker has not loaded yet: `"sm2 plugin is not available"` — **hit lost, no retry**.
5. The hit request fires (an additional round-trip).
**Current tracker chain — one step:**
1. `t.js` downloads: 1.1 KB, HTTP/2, one packet.
2. The pageview fires from inside the script itself via `sendBeacon` — no dependencies, no race.
3. The beacon survives even if the visitor closes or navigates away: the browser delivers it anyway.
4. The Go ingestion service acknowledges in milliseconds → RabbitMQ → ClickHouse.
### The hit's life insurance: sendBeacon
There is a transport difference that multiplies everything above. A classic request (`XMLHttpRequest`, `fetch`) is **tied to the page's lifetime**: if the visitor closes the tab or navigates to another URL while the request is in flight, the browser cancels it and the hit is lost. `navigator.sendBeacon()` inverts the model: the page **hands the packet to the browser** and steps aside — the browser queues it internally and delivers it even after the page no longer exists. It is the API browsers themselves designed for telemetry.
Verified against the production scripts: the **current tracker uses `sendBeacon`** (with `fetch keepalive` as fallback, which has the same property), while the **legacy v1 tracker does not use it at all** — it sends via a cancelable `XMLHttpRequest`. In practice: as soon as the current tracker executes (~0.1–0.3 s), the hit already belongs to the browser and closing the page cannot lose it; v1 additionally needs to **complete the round-trip to the server** with the page still alive.
The band of visits lasting **between ~0.3 s and ~1.5–2 s** — instant bounces from paid traffic, accidental taps on mobile, abandonments due to slowness — is captured systematically by the current tracker and lost systematically by v1. It is one of the clearest signatures of the dual-tag gap: segmented by visit duration, the current tracker's surplus should concentrate in the shortest visits.
| Hit transport | Sealmetrics (current) | Sealmetrics v1 | GA4 |
|---|---|---|---|
| Mechanism | `sendBeacon` + `fetch keepalive` | `XMLHttpRequest` | `sendBeacon`/`fetch keepalive` |
| Survives page close? | Yes | No — canceled | Yes |
| Moment the hit is secured | ~0.1–0.3 s | ~0.5–2 s (when the XHR completes) | ~0.5–1.5 s (after parsing gtag, and only with consent) |
**Note:**
GA4 also uses beacon-style transport — its problem is not the transport but that it reaches the dispatch point much later (weight + CPU) and only after consent. And `sendBeacon` is *best effort*: if the browser crashes or the OS kills the process, the beacon can be lost — practical reliability is very high, but not literally 100%. The current tracker also cannot measure a visitor who leaves before `t.js` executes; loading it through GTM widens that window, which is one more reason to install the snippet directly in the ``.
## Impact on measured traffic
| Comparison | Traffic difference | Where it comes from |
|---|---|---|
| Current vs legacy v1 | **+25–30% on average** | Observed on dual-tagged accounts (both trackers in parallel on the same site). Gain concentrated in mobile traffic, slow connections, and visitors far from Dublin: earlier fire, race-free chain, `sendBeacon`, HTTP/2, and compression. |
| Current vs GA4 (EU markets) | **+25–45% (estimate)** | Three GA4 losses the Sealmetrics tracker does not have: consent banner rejection/ignoring (~20–35% of visitors), blocking of Google domains by browsers and filter lists (~10–15%, partially overlapping), and abandonment before gtag fires (~2–5% on mobile). |
### Session window change ("Rejoined Traffic"): 6 h → 2 h
There is also a **definitional** factor that pushes the current tracker's numbers up, worth keeping in mind when reading the gap: the session re-entry window. In v1, if a visitor clicked through to the site again within **6 hours** of their entrance, that visit was classified as *Rejoined* — it did not open a new entrance. In the current tracker that window is **2 hours**.
Example: a user with 2 clicks 5 hours apart — v1 counted **1 entrance + 1 pageview** (the second click became Rejoined); the current tracker counts **2 entrances + 2 pageviews**. Same user behavior, more entrances and pageviews recorded.
This effect is **more granular measurement, not newly captured traffic**: it adds to the real capture gains (timing, `sendBeacon`, race-free chain) in the total v1-vs-current difference. To isolate it in your own data, look at the segment of re-entries between 2 and 6 hours — that is exactly the band where the two definitions diverge.
## Deployment recommendations
- **Do not gate Sealmetrics tags behind consent in GTM.** A frequent misconfiguration: if Sealmetrics tags sit behind the CMP's consent state, you give up their main advantage — Sealmetrics can measure without consent by design (no cookies, no personal identifiers). Fire them on *Consent Initialization* or with no consent condition.
- **Install the snippet directly in the ``, outside GTM.** Loaded through GTM, the tracker inherits the container's latency (typically 100–250 KB): if GTM is slow, blocked, or the visitor leaves before it loads, the tracker cannot measure either. With the snippet directly in the `` you capture the full advantage shown above.
- **Compare v1 and the current tracker with homogeneous metrics.** When evaluating a dual-tag, compare pageviews with pageviews and entrances with entrances — and account for the different session windows (Rejoined at 6 h in v1 vs 2 h in the current tracker, see above): mixing metrics or ignoring the window inflates or hides differences.
- **Keep the dual-tag for a validation period.** Running both trackers in parallel lets you quantify the capture difference with your own data, segmented by device and geography, before retiring v1.
## Limitations and honest notes
- Latencies were measured from a single location (fiber, Spain) in July 2026; the four network scenarios are **models**, not field measurements, and should be cited as such.
- The GA4 timings above are its **best case**: they exclude the consent wait, which for new EU visitors adds seconds or prevents measurement entirely.
- The +25–30% vs v1 is an average across dual-tagged accounts; each site will have its own figure depending on its device, network, and geography mix. The GA4 range depends critically on each site's CMP acceptance rate.
- Part of the entrance increase vs v1 is definitional, not capture: the Rejoined session window changed from 6 h (v1) to 2 h (current tracker).
- EasyPrivacy includes the rule `||sealmetrics.com^$third-party`: visitors with uBlock/AdGuard block both Sealmetrics tracker versions equally. The advantage over GA4 lies in consent and timing, not in ad blockers.
- To preserve the anonymity of the reference site, GA4 figures and latencies are rounded and lightly adjusted (see methodology); Sealmetrics tracker weights are exact.
## Tracker Performance Report: Sealmetrics vs Adobe Analytics
URL: https://docs.sealmetrics.com/tracker-performance-adobe-analytics
The Sealmetrics tracker weighs **1.1 KB on the wire**. The Adobe Analytics stack it competed against on a real page — Adobe Launch container, AppMeasurement, ActivityMap module, and rule payloads — weighs **~170 KB on the wire and ~730 KB once decompressed**. And the difference is not just weight: measured on a real European media site that runs both vendors side by side, **Adobe's pageview left the device at ~3.0 seconds** into the page load, while the Sealmetrics hit was secured at ~1.8 seconds — despite Sealmetrics being loaded late through the site's own tag chain. Installed directly in the ``, Sealmetrics secures the hit at ~0.1–0.3 s.
**Key numbers at a glance:**
| | Sealmetrics | Adobe Analytics stack |
|---|---|---|
| Wire weight (scripts) | 1.1 KB | ~170 KB (~155× more) |
| JavaScript to parse | 2.0 KB | ~730 KB (~365× more) |
| Pageview hit secured (field, fiber) | ~1.8 s (late tag-chain load) / ~0.1–0.3 s (`` install) | ~3.0 s |
| Measured traffic (30-day dual-tag, reference site) | **+25% pageviews** | baseline |
## Methodology
This report combines two kinds of measurement, both taken in July 2026:
- **Field measurements** via the browser's Resource Timing API during a real page load of a **European media platform that runs Sealmetrics and Adobe Analytics in parallel** (site anonymized). This captures the actual sequence: when each script started, how long it took, and when each vendor's pageview hit left the device — same page, same visit, same network.
- **Direct downloads** of the production scripts with `curl` (`Accept-Encoding: gzip`, 3 samples, fiber connection from Spain) for exact byte sizes and latency.
To preserve the reference site's anonymity, figures are rounded and lightly adjusted; orders of magnitude and ratios are preserved. The Sealmetrics tracker weights are exact — they are product scripts, identical for every customer.
The Adobe stack analyzed is the most common one: **Adobe Launch (Tags) + AppMeasurement 2.x** with the ActivityMap module, ECID/Audience Manager ID calls, and Adobe Target on the same container. Installs using the newer Web SDK (alloy.js) have a different chain; the weight-and-sequence logic of this report still applies, but the specific numbers do not.
### How consent is treated
On the reference site, the Adobe stack fired **without any prior consent interaction** — so the timings below are Adobe's realistic best case there. In many EU installs, Adobe Analytics is gated behind the CMP: everything in this report would then apply only *after* banner acceptance, and the consent-rejection loss (typically 20–35% of visitors) comes on top. Sealmetrics is consentless by design (no cookies, no personal identifiers) and has no such gate.
## The Adobe delivery chain
What has to happen before Adobe Analytics registers a pageview, as observed on the reference site:
1. The **Launch container** downloads: ~150 KB gzipped, **~670 KB of JavaScript** to parse. It is served from Akamai's edge (fast delivery — the weight is in the parse, not the network).
2. The **ECID / Audience Manager identity calls** fire (demdex round-trips).
3. **AppMeasurement + ActivityMap** download and execute (~14 KB gzipped, ~37 KB decoded).
4. **Rule payloads** (per-site logic split into separate files) download and run.
5. Other Experience Cloud calls on the same container (Adobe Target delivery, in this case) execute.
6. The **pageview finally fires as an image GET request** to a first-party collection domain (`smetrics.` + the site's domain, a CNAME that resolves to Adobe's `data.adobedc.net`).
The Sealmetrics chain, for comparison: `t.js` downloads (1.1 KB, one TCP packet), executes, and dispatches the pageview via `sendBeacon` from inside the script. One script, no identity round-trips, no rule payloads.
## Field timeline: the same page load, both vendors
Measured with the Resource Timing API on a fiber connection (values rounded):
| Moment (from navigation start) | Event |
|---|---|
| ~0.2 s | Adobe Launch container starts downloading |
| ~0.8 s | Launch container loaded (~670 KB parsed after) · identity calls fire |
| ~1.1 s | AppMeasurement loaded |
| ~1.2–1.9 s | Rule payloads + Adobe Target delivery calls |
| ~1.5–1.6 s | Sealmetrics `t.js` loads (late — through the site's tag chain) |
| **~1.8 s** | **Sealmetrics pageview events dispatched (`sendBeacon` — secured)** |
| **~3.0 s** | **Adobe Analytics pageview fires** (image GET to the collection domain) |
Two readings of this table:
- **Adobe's hit fires ~1.2 s after Sealmetrics'** on the same page, same visit, same network — and this is fiber. On a mid-range phone over 4G, parsing ~730 KB of JavaScript alone adds several hundred milliseconds to seconds; the Adobe hit realistically moves past ~4–6 s (estimate), while the Sealmetrics window barely grows.
- Sealmetrics was **handicapped on this site** — loaded through the tag chain at ~1.5 s instead of from the ``. Even so it beat the Adobe hit by more than a second. With the snippet in the ``, the hit is secured at ~0.1–0.3 s: an order of magnitude earlier.
A note of fairness: part of Adobe's ~3.0 s is this site's specific rule sequencing (identity and personalization calls run before the analytics hit). That ordering is common — Target and ECID exist precisely to run early — but a leaner Adobe install can fire earlier. The structural floor remains: ~730 KB to parse and a multi-stage chain before any hit can leave the device.
## Weight comparison
| | Sealmetrics | Adobe: Launch container | Adobe: AppMeasurement + modules + rules | Adobe total |
|---|---|---|---|---|
| Transferred (gzip) | **1.1 KB** | ~150 KB | ~20 KB | **~170 KB** |
| Uncompressed (what the CPU parses) | 2.0 KB | ~670 KB | ~55 KB | **~730 KB** |
The parse cost has no CDN: Adobe serves its container from Akamai's edge in every region, but ~730 KB of JavaScript is parsed on the visitor's device every time the cache is cold. On a low-end phone that is commonly over a second of CPU work — before rules, identity calls, or the hit itself.
## Hit transport: image GET vs sendBeacon
| Hit transport | Sealmetrics | Adobe Analytics (AppMeasurement) |
|---|---|---|
| Mechanism | `sendBeacon` + `fetch keepalive` fallback | image GET request (beacon transport only for exit-link tracking) |
| Survives page close? | Yes — the browser owns delivery | No — an in-flight image request is canceled on unload |
| Moment the hit is secured (field) | ~0.1–0.3 s (`` install) | ~3.0 s on the reference site |
Every visit shorter than the vulnerability window is invisible traffic. With Adobe's hit at ~3.0 s, **any visit that bounces within the first ~3 seconds never existed** in Adobe Analytics: instant bounces from paid and social traffic, accidental taps, impatient mobile visitors. That band of very short visits is precisely where mobile and campaign traffic concentrates.
## Ad blockers and filter lists
- EasyPrivacy carries **28+ rules against `omtrdc.net`** and several against `demdex.net` — Adobe's collection and identity endpoints are extensively targeted.
- First-party CNAME collection (`smetrics.` subdomains pointing to `data.adobedc.net`) is **uncloaked and blocked by uBlock Origin on Firefox**, which resolves CNAMEs before matching.
- In fairness: `sealmetrics.com` also appears in EasyPrivacy as a third-party rule. The Sealmetrics advantage over Adobe lies in consent, weight, and timing — not in ad-blocker immunity.
## What this means for measured traffic
The mechanisms above give the loss structure (ranges are estimates, clearly labeled as such — the field validation below puts a real number on them):
| Loss mechanism for Adobe | Typical range | Applies when |
|---|---|---|
| Visits shorter than the hit window (~3 s on the reference site) | ~3–8% | Always; highest on mobile/campaign-heavy traffic |
| Collection endpoints blocked (filter lists, CNAME uncloaking) | ~10–15% | Always; overlaps partially with the above |
| Consent banner rejection/ignoring | ~20–35% | Only where the install is CMP-gated (common in the EU) |
Combined, a Sealmetrics tracker running in parallel typically measures **~15–25% more traffic than a non-consent-gated Adobe install, and ~25–45% more where Adobe sits behind a CMP** (estimates; ranges overlap and do not add linearly).
### Field validation: a month of dual-tag data
The reference site runs both vendors in parallel, and its **June 2026 data (30 days of daily pageviews from both platforms)** puts a real number on the estimate:
| | Sealmetrics | Adobe Analytics |
|---|---|---|
| Daily pageviews (month range) | ~0.9–1.6 M | ~0.7–1.2 M |
| Average difference | **+25% over Adobe** | — (Adobe misses ~1 in 5 pageviews Sealmetrics records) |
| Ratio stability | The gap holds ~constant across all 30 days — peaks and troughs, weekdays and weekends | |
Three conclusions from that month of data:
- **The estimated range is validated at its high end**: +25% observed, with Adobe firing without a consent gate on this site — meaning the gap is fully explained by the structural mechanisms (blocked collection endpoints, the ~3 s hit window, cancelable transport), not by consent. Where Adobe sits behind a CMP, expect a larger gap.
- **A constant ratio is the signature of a systematic cause**: bot traffic, an outage, or a one-off event would make the gap fluctuate. A stable ~25% while traffic swings 1.5× points to a fixed fraction of the audience Adobe structurally cannot see.
- **The metric is homogeneous**: pageviews against pageviews — the clean comparison, free of session- or visit-definition effects.
## Recommendations for Adobe Analytics sites evaluating Sealmetrics
- **Install the Sealmetrics snippet directly in the ``, not through your tag manager.** The reference site loads it through the tag chain and still beats Adobe's hit by over a second — but a `` install secures the hit at ~0.1–0.3 s and removes the container dependency entirely.
- **Do not gate Sealmetrics behind your CMP.** It measures without consent by design; gating it recreates Adobe's biggest loss for no benefit.
- **Run both in parallel for a validation period.** Keep Adobe untouched, add Sealmetrics, and compare 30 days of data segmented by device and traffic source. Expect the gap to concentrate in mobile and short visits.
- **Map metric definitions before comparing.** Adobe *visits* use a 30-minute inactivity timeout; Sealmetrics *entrances* are click-based with a 2-hour re-entry window. Compare page views with page views first — it is the cleanest apples-to-apples metric.
## Limitations and honest notes
- The field timeline comes from **one real page load of one site** (plus 3-sample curl measurements for sizes/latency, from a single location). It is a representative illustration, not a statistical sample; the ~3.0 s figure includes that site's specific rule sequencing.
- The stack analyzed is Launch + AppMeasurement 2.x; Web SDK (alloy.js) installs have a different chain and different numbers.
- Cross-origin Resource Timing entries without `Timing-Allow-Origin` hide transfer sizes; where the browser hid them, sizes come from direct downloads instead.
- Figures are rounded and lightly adjusted to preserve the reference site's anonymity; Sealmetrics tracker weights are exact.
- The traffic-impact ranges are estimates built from the measured mechanisms. The +25% figure comes from one month of dual-tag data on a single site (June 2026); every site will have its own number depending on its audience mix, so run the parallel test on your own site.
## Tracker Performance: Sealmetrics vs GA4 vs Adobe Analytics
URL: https://docs.sealmetrics.com/tracker-performance-three-way
This guide puts the three trackers side by side: the **Sealmetrics tracker**, **GA4's `gtag.js`**, and the **Adobe Analytics stack** (Launch + AppMeasurement). It condenses our two detailed reports — [Sealmetrics vs GA4](/guides/tracker-performance-report) and [Sealmetrics vs Adobe Analytics](/guides/tracker-performance-adobe-analytics) — into one comparison table set, with the same methodology and the same anonymized reference sites.
**Everything at a glance:**
| | Sealmetrics | GA4 | Adobe Analytics |
|---|---|---|---|
| Wire weight (scripts, gzip) | **1.1 KB** | ~146 KB (~132×) | ~170 KB (~155×) |
| JavaScript to parse | **2.0 KB** | ~409 KB (~255×) | ~730 KB (~365×) |
| Hit secured (`` install, fiber) | **~0.1–0.3 s** | ~0.5–0.7 s (best case) | ~3.0 s (field-measured) |
| Hit transport | `sendBeacon` — survives page close | beacon-style | image GET — cancelable |
| Consent required in the EU | **No — consentless by design** | Yes (Consent Mode models the gap) | Yes in most installs |
| Traffic measured in parallel runs | baseline | ~25–45% less (estimate, EU) | ~20% less (30-day dual-tag, field) |
**Note:**
Script weights re-measured **9 August 2026** from each vendor's production CDN: one GET with `Accept-Encoding: gzip`, bytes counted on disk. Vendor scripts change — `gtag.js` alone went from ~171 KB to ~146 KB between passes — so treat these as a dated snapshot.
## Methodology
All figures come from measurements taken in July 2026:
- **Direct downloads** of the three production scripts with `curl` (`Accept-Encoding: gzip`, 3 samples, fiber from Spain) for exact byte sizes and latencies. GA4 was measured with the ID of a real production property; the Adobe chain with the real container of a production site.
- **Field measurements** via the browser's Resource Timing API on an **anonymized European media platform** that runs Sealmetrics and Adobe Analytics in parallel — capturing when each script started, how long it took, and when each vendor's pageview left the device in the same page load.
- **Parallel-run traffic data**: 30 days of daily pageviews from that dual-vendor site (June 2026) for the Adobe comparison; the GA4 range is an estimate built from published consent, blocker, and timing studies.
To preserve the anonymity of the reference sites, third-party figures are rounded and lightly adjusted; ratios and orders of magnitude are preserved. Sealmetrics tracker weights are exact — they are product scripts, identical for every customer. GA4 and Adobe timings represent their chains *once their tags fire*: the best case for both, since any consent wait comes on top.
## Script weight
| | Sealmetrics | GA4 (gtag.js) | Adobe (Launch + AppMeasurement + rules) |
|---|---|---|---|
| Transferred over the network | **1.1 KB** | ~146 KB | ~170 KB |
| Uncompressed | **2.0 KB** | ~409 KB | ~730 KB |
Two structural notes:
- The Sealmetrics tracker fits in **a single TCP packet** and arrives in the first round-trip. Both competitor payloads need 4–5 slow-start round-trips just for the download.
- **Parsing has no CDN.** Google and Adobe both serve from excellent global edges — but ~409 KB or ~730 KB of JavaScript is parsed on the visitor's device, every time the cache is cold. On a low-end phone that is commonly 0.8–1.5 s of CPU work before any hit can fire.
## Delivery chains
**Sealmetrics** — one step: `t.js` downloads (1.1 KB), executes, and dispatches the pageview via `sendBeacon` from inside the script. Own work, measured in the field: **~0.26 s** from script start to hit delivered.
**GA4** — `gtag.js` downloads (~146 KB), parses (~409 KB), runs its config, then sends the pageview to `google-analytics.com` on a **second connection**. In the EU, none of this starts for a new visitor until the consent banner is accepted.
**Adobe** — the longest chain: Launch container (~670 KB of JS) → ECID/Audience Manager identity round-trips → AppMeasurement + modules → rule payloads → other Experience Cloud calls (Target) → pageview as an **image GET** to a first-party CNAME collection domain. Field-measured on the reference site: the pageview left the device at **~3.0 s**.
## Time to first hit
The window between page start and the hit leaving the device is the window where an abandoning visitor is invisible traffic.
| Scenario | Sealmetrics | GA4 (best case) | Adobe (as observed) |
|---|---|---|---|
| Fiber, `` install | **~0.1–0.3 s** | ~0.5–0.7 s | ~3.0 s (field) |
| Mid-range 4G mobile (estimate) | ~0.3 s | ~1.0–1.5 s | ~4–6 s |
| Consent wait (new EU visitor) | none | + seconds or forever | + seconds or forever (where gated) |
A fairness note on Adobe's ~3.0 s: part of it is the reference site's rule sequencing (identity and personalization run before the analytics hit). That ordering is common — it is what the Experience Cloud chain is designed to do — but a leaner Adobe install can fire earlier. The structural floor (~730 KB to parse, multi-stage chain) remains.
## Transport: what happens when the visitor leaves
| | Sealmetrics | GA4 | Adobe (AppMeasurement) |
|---|---|---|---|
| Mechanism | `sendBeacon` + `fetch keepalive` | beacon-style transport | image GET (beacon only for exit links) |
| Survives page close? | **Yes** | Yes | No — canceled on unload |
| Practical vulnerability window | ~0.1–0.3 s | ~0.5–1.5 s (after parsing, with consent) | until the hit completes (~3 s observed) |
GA4's transport is fine — its problem is reaching the dispatch point late and only after consent. Adobe combines a late dispatch point with a cancelable transport: every visit shorter than its window never existed.
## Blockers and consent
- **Consent**: Sealmetrics measures without consent by design (no cookies, no personal identifiers). GA4 legally requires consent in the EU; rejection/ignore rates typically run 20–35% of visitors. Adobe requires it in most EU installs.
- **Filter lists**: EasyPrivacy targets Google's analytics domains extensively, carries 28+ rules against Adobe's `omtrdc.net` plus several against `demdex.net`, and uBlock Origin on Firefox uncloaks CNAME first-party collection domains. In fairness: `sealmetrics.com` is also listed as a third-party rule — the Sealmetrics advantage lies in consent, weight, and timing, not in ad-blocker immunity.
## Measured traffic differences
| Comparison | Difference | Basis |
|---|---|---|
| Sealmetrics vs GA4 (EU markets) | **+25–45% for Sealmetrics** | Estimate: consent rejection (~20–35%) + blocked domains (~10–15%) + late-fire abandonment (~2–5%); ranges overlap |
| Sealmetrics vs Adobe Analytics | **+25% for Sealmetrics** | 30 days of dual-tag pageview data on the reference site (June 2026), ratio stable across the whole month — with Adobe firing *without* a consent gate; expect more where Adobe sits behind a CMP |
The Adobe figure is the strongest evidence in this guide: same site, same visits, pageviews against pageviews, a full month — and a constant ~25% gap, which is the signature of a structural cause (a fixed fraction of the audience the heavy tracker cannot see), not of bots or incidents.
## Recommendations
- **Install the Sealmetrics snippet directly in the ``**, not through a tag manager — the tag-manager route delays the hit by whatever the container costs (the dual-vendor reference site loads it through its tag chain at ~1.5 s and still beats Adobe's hit by over a second).
- **Never gate Sealmetrics behind a CMP.** It recreates the incumbents' biggest loss for no benefit.
- **Run in parallel for 30 days** before drawing conclusions, and segment the comparison by device and traffic source — the gap concentrates in mobile and short visits.
- **Map metric definitions first**: GA4 sessions (30-min timeout, event-based), Adobe visits (30-min timeout), Sealmetrics entrances (click-based, 2-hour re-entry window). Page views against page views is the cleanest first comparison.
## Limitations and honest notes
- Latencies were measured from a single location; the mobile scenarios are models, labeled as such. The Adobe field timeline comes from one real page load of one site.
- GA4 and Adobe timings are their best case — they exclude the consent wait.
- The stacks analyzed are the most common ones (gtag.js; Launch + AppMeasurement 2.x). Server-side tagging setups and Adobe Web SDK installs have different chains and different numbers.
- Third-party figures are rounded and lightly adjusted to preserve the reference sites' anonymity; Sealmetrics weights are exact.
---
# Platform Settings
## Platform
URL: https://docs.sealmetrics.com/platform
# Platform Overview
The **Platform** section covers everything about running Sealmetrics day-to-day: how to configure your account, manage users and organizations, tune tracking and attribution settings, and administer billing.
## What you can configure
- **Account setup** — timezone, domains, multi-account structure. Start with [Add a new account](/platform/account-setup/how-to-add-new-account) and [Change timezone](/platform/account-setup/how-to-change-timezone).
- **[Organizations](/platform/organizations)** — multi-site and multi-team organization structure.
- **User management** — [Add a new user](/platform/user-management/how-to-add-new-user), [Roles management](/platform/user-management/roles-management), [Authorized IPs](/platform/user-management/authorized-ips), and [password changes](/platform/user-management/change-password).
- **Tracking & attribution** — fine-tune attribution with [Bypass POS or referrer](/platform/tracking-and-attribution-settings/bypass-pos-or-referrer).
- **[Platform settings](/platform/settings)** — integrations, tracking defaults, advanced controls, and LLM access.
## Related areas
- **[Billing](/billing)** — plans, invoices, and payment methods.
- **Security & privacy** — data handling, retention, and compliance posture. See [adblocker bypass](/security-privacy/adblocker-bypass) and [first-party tracking](/implementation/tracker/first-party).
- **[API](/api)** — programmatic access to platform resources.
## How to Delete a Site
URL: https://docs.sealmetrics.com/platform/account-setup/how-to-delete-account
# How to Delete a Site
**Warning:**
## Steps
1. In the left sidebar, expand **Organization** and click **Sites** (`/settings/sites`).
2. Find the site you want to delete in the **Your Sites** list.
3. Click the **trash icon** on the right side of the site row.
4. Confirm in the browser dialog ("Are you sure you want to delete this site?").
The site will be removed from your list immediately.
---
Only the organization **Owner** can delete sites — Admins and Members cannot. If you don't see the delete button, contact your organization owner.
## Organizations
URL: https://docs.sealmetrics.com/platform/organizations
# Organizations
An **Organization** is the top-level entity in Sealmetrics. It groups together your websites (called **Sites**) and your team members. Everything in Sealmetrics -- billing, analytics, team access -- is managed within the context of an organization.
---
## How It Works
```
Organization
|
|-- Sites (your websites)
| |-- example.com
| |-- store.example.com
| |-- blog.example.com
|
|-- Members (your team)
|-- You (Owner)
|-- teammate@company.com (Admin)
|-- analyst@agency.com (Member)
```
- Each **Site** represents a website you want to track with Sealmetrics.
- Each **Member** is a person on your team who can access your analytics data.
- **Sites** always belong to exactly one organization.
- **Members** can belong to multiple organizations (for example, an agency working with several clients).
---
## Creating Your Organization
After you register and verify your email, Sealmetrics will ask you to create your first organization.
1. Choose a name for your organization (typically your company name)
2. Click **Create Organization**
You are automatically assigned the **Owner** role, which gives you full access to everything.
---
## Adding Sites
Once your organization is set up, you can add the websites you want to track.
1. In the left sidebar, expand **Organization** and click **Sites** (`/settings/sites`)
2. Click **New Site**
3. Enter the **Site Name** and an optional **Primary Domain**, then set the **Timezone** and **Currency**
4. Click **Create Site**, then follow the setup instructions to install the tracking code
Each site gets a unique **Site ID** that is used in the tracking code. You can add as many sites as your plan allows.
---
## Inviting Team Members
Share access with your team by inviting members to your organization.
1. In the left sidebar, expand **Organization** and click **Members** (`/settings/organizations/{slug}/members`)
2. Click **Invite Member**
3. Enter their email address and choose a role:
- **Admin** -- manage members and all sites, no billing access
- **Member** -- access only to specific sites you assign
4. For Members, select which sites they can see
5. Click **Send Invitation**
Invitations can only be sent with the **Admin** or **Member** role. To make someone an **Owner**, invite them first and then promote them from the Members list (only an existing Owner can do this).
The invited person will receive an email with a link to join. If they do not have a Sealmetrics account yet, they can create one as part of the invitation process.
For more details on managing your team, see [Users & Teams](./settings/account/users).
---
## Roles Overview
Sealmetrics uses a two-tier role system:
**Organization roles** determine what a person can do across the organization:
| Role | Sites Access | Manage Members | Billing |
|------|-------------|---------------|---------|
| **Owner** | All sites | Yes | Yes |
| **Admin** | All sites | Yes (except owners) | No |
| **Member** | Assigned sites only | No | No |
**Site-level roles** determine what a person can do within a specific site:
| Role | Description |
|------|-------------|
| **Editor** | Can view data and modify site configuration |
| **Viewer** | Can view data only (read-only) |
For the full permissions breakdown, see [Roles & Permissions](./user-management/roles-management).
---
## Multiple Organizations
Some users may need access to more than one organization -- for example, agency staff managing multiple clients. When a user belongs to multiple organizations, an **organization switcher** appears in the left sidebar (just below **Sites**), letting them switch between organizations at any time. The switcher is hidden for users who belong to a single organization.
---
## Deleting an Organization
Only the Owner can delete an organization. Deleting an organization removes access for all members. This action requires confirming the organization name and cannot be undone.
## Site Settings
URL: https://docs.sealmetrics.com/platform/settings/account/general
# Site Settings
Each site in Sealmetrics has its own basic settings: a name, a timezone, and a default currency.
## Accessing Site Settings
1. Open the sidebar and go to the **Site Config** group
2. Click **Settings**
This opens the settings page for the currently selected site. The **General** tab is shown first.
**Info:**
## General Tab
The General tab contains the core configuration for the site.
### Site Name
The display name for the site, shown across the dashboard and in reports.
You can edit this field directly. A **Save Changes** button appears whenever you have unsaved edits.
### Site ID
Your unique site identifier. This field is **read-only** and can be copied with the copy button next to it.
The Site ID is used for:
- API calls
- Support requests
- Integration configuration
### Timezone
All report dates and ranges are displayed in the site's timezone.
Click the timezone selector to open a searchable list — you can search by timezone name (for example, `Europe/Madrid`) or by country name.
### Currency
The default currency used to display revenue and conversion values.
Available options include:
| Code | Currency |
|------|----------|
| EUR | Euro |
| USD | US Dollar |
| GBP | British Pound |
| CHF | Swiss Franc |
| JPY | Japanese Yen |
| CAD | Canadian Dollar |
| AUD | Australian Dollar |
| MXN | Mexican Peso |
| BRL | Brazilian Real |
## Saving Changes
After editing the name, timezone, or currency:
1. A **Save Changes** button appears below the fields.
2. Click **Save Changes** to apply, or **Cancel** to discard your edits.
Changes take effect immediately.
**Note:**
Only users who can edit the site (organization owners and admins) see the editable fields and the Save button. Members with view-only access see the values but cannot change them.
## Other Tabs
The Site Settings page also includes additional tabs beyond General:
- **Domains** — domains authorized to send tracking data to this site
- **UTM Mappings** — map custom URL parameters to standard UTM fields
- **Channels** — custom channel grouping rules for this site
- **Pixel Code** — installation code and conversion tracking snippets
- **IP Exclusions** — exclude traffic from specific IP addresses (e.g. your office)
- **IP Allowlist** — restrict tracking to specific IP addresses (Enterprise plan)
Team members and their access are managed at the organization level, under **Organization → Members** — see [Users & Teams](./users). API keys are managed under **My Account → API Keys**.
## Audit Logs
URL: https://docs.sealmetrics.com/platform/settings/advanced/audit-log
# Audit Logs
Audit Logs record significant actions taken across your Sealmetrics organization, providing a trail of who did what and when.
## Accessing Audit Logs
In the sidebar, go to **Organization → Audit Logs**.
Visibility is scoped to your organization: you see entries generated by members of the organization(s) you belong to. Access requires permission to manage members.
## What's Logged
Each entry is a single action with an actor, a resource it affected, and the time it happened. The actions that are recorded are:
### User
| Action | Meaning |
|--------|---------|
| User Created | A user account was created |
| User Updated | A user account was modified |
| User Deactivated / Reactivated | A user account was disabled or re-enabled |
| Login / Logout | A user signed in or signed out |
| Password Changed | A user changed their password |
| Email Verified | A user verified their email address |
| 2FA Enabled / Disabled | Two-factor authentication was turned on or off |
| Backup Codes Regenerated | 2FA backup codes were regenerated |
### Invitations
| Action | Meaning |
|--------|---------|
| Invitation Sent / Resent | A member invitation was sent or resent |
| Invitation Revoked | A pending invitation was cancelled |
| Invitation Accepted | An invited user joined |
### Accounts
| Action | Meaning |
|--------|---------|
| Account Created | A tracking account was created |
| Account Updated | Account settings were changed |
| Account Deactivated | An account was deactivated |
### Configuration
| Action | Meaning |
|--------|---------|
| Conversion Created / Updated / Deleted | A conversion definition changed |
| Content Group Created / Updated / Deleted | A content group changed |
| Settings Updated | A settings change was applied |
### API & Billing
| Action | Meaning |
|--------|---------|
| API Token Created / Revoked | An API token was issued or revoked |
| Plan Changed | The billing plan changed |
| Payment Method Updated | The payment method was updated |
**Note:**
## What Each Entry Contains
Every entry stores:
- **Actor** — the user's name and email
- **Action** — one of the actions listed above
- **Resource** — the resource type and, when available, its ID
- **Timestamp** — when the action occurred
- **IP address** — the IP the action came from, when available
- **Details** — an optional JSON object with action-specific context
Entries do **not** record device, browser, geographic location, or before/after ("old value → new value") snapshots.
## Viewing the Log
The Audit Logs page shows a chronological list. Each row displays the actor, an action badge, the affected resource (type and ID when present), the timestamp, the IP address (when available), and any additional details captured for that action.
## Filtering
You can filter the list by **resource type** (User, Invitation, Account, Conversion, Content Group, API Token, Billing). The list is paginated.
There is no full-text search, no CSV export, no scheduled export, and no configurable audit alerts in the dashboard.
## Retention
Audit log retention is not configurable from the dashboard. There is no per-plan retention setting, export schedule, or self-serve deletion control. If you have specific retention requirements, contact support.
## Settings Overview
URL: https://docs.sealmetrics.com/platform/settings
# Settings Overview
The Settings area lets you configure every aspect of your Sealmetrics account. Settings live in the left sidebar, organized into three collapsible groups:
- **My Account** -- your personal settings: Profile, Security, API Keys, LLM Providers, and Connected Apps.
- **Organization** (owners and admins only) -- Settings, Members, Billing, Sites, Pixels, and Audit Logs.
- **Site Config** (per selected site) -- Settings, Integrations, and Properties.
## Settings Categories
### Account Settings
Configure your account and organization.
| Setting | Description |
|---------|-------------|
| [General](/platform/settings/account/general) | Account name, timezone, default date range |
| [Users & Teams](/platform/settings/account/users) | Manage team members and permissions |
| [Security](/platform/settings/account/security) | Two-factor authentication (2FA), backup codes, active sessions |
| [Connected Apps](/platform/settings/account/connected-apps) | AI assistants authorized via OAuth (remote MCP server) |
| [API Keys](/api/api-tokens) | Personal API tokens for programmatic access |
### Tracking Settings
Configure how data is collected.
| Setting | Description |
|---------|-------------|
| [Pixel Builder](/platform/settings/tracking/pixel-builder) | Generate and customize your tracking code |
| [Content Grouping](/platform/settings/tracking/content-grouping) | Group pages into content categories |
| [Custom Dimensions](/platform/settings/tracking/custom-dimensions) | Define custom data fields |
### Integrations
Connect external services.
| Setting | Description |
|---------|-------------|
| [BigQuery](/platform/settings/integrations/bigquery) | Export data to Google BigQuery |
| [Webhooks](/platform/settings/integrations/webhooks) | Send data to external endpoints |
### Advanced
Power user settings.
| Setting | Description |
|---------|-------------|
| [Audit Log](/platform/settings/advanced/audit-log) | View account activity history |
| [LLM Providers](/platform/settings/llm) | Choose the AI provider for the Lens chat (Seal AI Private or BYOK) |
| [Seal AI Usage](/platform/settings/seal-ai-usage) | Monthly token consumption, pack balance, and extra token packs |
## Quick Access
## Settings by Role
Access to settings depends on your organization role and site-level role:
| Role | Can Access |
|------|------------|
| **Owner** | All settings, including billing and organization management |
| **Admin** | Tracking, integrations, member management (no billing) |
| **Member (Editor)** | Site-specific settings for assigned sites only |
| **Member (Viewer)** | View settings only, cannot modify |
## Common Tasks
### Set Up Tracking
1. Go to **Settings → Sites → [your site]** (`/settings/sites/{siteId}`)
2. Open the **Pixel Code** tab, which holds the base tracking snippet for that site
3. Copy the generated code
4. Install on your website
To build a **conversion or microconversion** pixel rather than the base snippet, use the Pixel Builder — a separate, organization-level screen at **Organization → Pixels** (`/settings/pixels`), which also shows pixel status across your sites.
[Pixel Builder guide →](/platform/settings/tracking/pixel-builder)
### Add Team Members
1. In the sidebar, expand **Organization** and click **Members**
2. Click **Invite Member**
3. Enter email and select role
4. Click **Send Invitation** -- the user receives an invitation email
[User management guide →](/platform/settings/account/users)
### Connect BigQuery
1. In the sidebar, expand **Site Config** and click **Integrations**
2. Create a GCP service account
3. Upload credentials
4. Configure sync options
[BigQuery setup guide →](/platform/settings/integrations/bigquery)
### View Activity History
1. In the sidebar, expand **Organization** and click **Audit Logs**
2. Browse or search activity
3. Filter by user, action, or date
[Audit log guide →](/platform/settings/advanced/audit-log)
## BigQuery Integration
URL: https://docs.sealmetrics.com/platform/settings/integrations/bigquery
# BigQuery Integration
Export your Sealmetrics data to Google BigQuery for custom SQL analysis, machine learning, and integration with your data warehouse.
## Prerequisites
- Any Sealmetrics plan (Growth, Scale, or Enterprise)
- Google Cloud Platform (GCP) account
- BigQuery API enabled in GCP
- GCP service account with BigQuery permissions
## Setup Overview
1. Create a GCP service account
2. Grant BigQuery permissions
3. Generate and download credentials
4. Configure in Sealmetrics
5. Choose sync settings
6. Create the dataset and verify the export
## Step 1: Create GCP Service Account
### In Google Cloud Console
1. Go to [console.cloud.google.com](https://console.cloud.google.com)
2. Select your project (or create one)
3. Navigate to **IAM & Admin → Service Accounts**
4. Click **+ Create Service Account**
```
Service Account Details:
Name: sealmetrics-export
ID: sealmetrics-export
Description: Service account for Sealmetrics BigQuery export
```
5. Click **Create and Continue**
## Step 2: Grant Permissions
Grant the service account BigQuery access:
```
Grant this service account access to project:
Role 1: BigQuery Data Editor
(roles/bigquery.dataEditor)
Role 2: BigQuery Job User
(roles/bigquery.jobUser)
[Continue]
```
Alternatively, create a custom role with these permissions:
- `bigquery.datasets.create`
- `bigquery.tables.create`
- `bigquery.tables.updateData`
- `bigquery.jobs.create`
## Step 3: Generate Credentials
1. Click on the created service account
2. Go to **Keys** tab
3. Click **Add Key → Create new key**
4. Choose **JSON** format
5. Click **Create**
6. Save the downloaded JSON file securely
```json
// Downloaded file looks like:
{
"type": "service_account",
"project_id": "your-project-id",
"private_key_id": "abc123...",
"private_key": "-----BEGIN PRIVATE KEY-----\n...",
"client_email": "sealmetrics-export@your-project.iam.gserviceaccount.com",
"client_id": "123456789...",
...
}
```
## Step 4: Configure in Sealmetrics
1. Open the site you want to export, then go to **Site Config → Integrations → BigQuery** in the sidebar
2. Upload your **Service Account JSON** key file (drag-and-drop or click to select)
When you upload the file, Sealmetrics validates that it is a Google Cloud Service Account key (`"type": "service_account"`) and automatically fills in the **GCP Project ID** from the file.
3. Confirm the GCP Project ID matches the project where the dataset should be created
## Step 5: Configure Sync Settings
### Dataset Settings
| Setting | Details |
|---------|---------|
| **GCP Project ID** | Pre-filled from your Service Account JSON |
| **Dataset Name** | Defaults to `sealmetrics`. Letters, numbers, and underscores only; must start with a letter or underscore. Created automatically if it doesn't exist. |
| **Dataset Location** | `EU (European Union)` or `US (United States)` |
Tables are created with fixed star-schema names (for example, `fact_traffic_daily`). There is no table prefix to configure.
### Sync Frequency
Choose how often Sealmetrics pushes data to BigQuery:
| Option | Behavior |
|--------|----------|
| **Hourly** | Syncs every hour |
| **Daily** | Syncs once per day (default) |
| **Manual only** | No automatic sync; you trigger it with **Sync Now** |
### Data Types to Sync
Select which datasets to export. Each maps to a dedicated BigQuery table:
| Data Type | Table | Recommended |
|-----------|-------|-------------|
| **Daily Traffic** | `fact_traffic_daily` | Yes |
| **Hourly Traffic** | `fact_traffic_hourly` (90-day retention, higher storage cost) | No |
| **Conversions** | `fact_conversions` | Yes |
| **Microconversions** | `fact_microconversions` | Yes |
| **Pages** | `fact_pages` | Yes |
| **Landing Pages** | `fact_landing_pages` | Yes |
| **Account Metadata** | `dim_accounts` | No |
The lookup table `dim_countries` and a `sync_metadata` table are always created.
### Initial Data Export
On first run, choose how much history to load:
- **Last X days** — backfill a preset (30, 60, or 90 days) or a custom number of days
- **Custom date range** — pick an explicit start and end date
After setup, data syncs automatically from today onward at the chosen frequency. You can run larger historical loads later from the **Historical Data Backfill** card.
## Step 6: Create the Dataset and Verify
1. Click **Configure BigQuery Integration** to save your configuration
2. If prompted with **Setup Required**, click **Setup Dataset** to create the dataset and tables in your project
3. Click **Sync Now** to run the first sync (historical backfills may take a while)
4. The integration dashboard shows the current status, last sync time, number of tables created, and a **Recent Sync History** card with rows and bytes synced per run
From the dashboard you can **Pause/Resume Sync**, run **Sync Now**, edit the selected data types, start a **Backfill**, or **Delete** the integration. Deleting removes the configuration from Sealmetrics but never deletes the data already in your BigQuery project.
## BigQuery Schema
Tables follow a star-schema design. Below are two of the most-used fact tables. The exact, authoritative schema for every table is also available from the integration screen.
### Daily Traffic Table (`fact_traffic_daily`)
| Column | Type | Description |
|--------|------|-------------|
| `sync_id` | STRING | Identifier of the sync that wrote the row |
| `synced_at` | TIMESTAMP | When the row was synced |
| `account_id` | STRING | Sealmetrics account (site) ID |
| `date` | DATE | Day of the metrics |
| `utm_source` | STRING | UTM source |
| `utm_medium` | STRING | UTM medium |
| `utm_campaign` | STRING | UTM campaign |
| `utm_term` | STRING | UTM term |
| `utm_content` | STRING | UTM content |
| `channel_group` | STRING | Marketing channel group |
| `country` | STRING | ISO country code |
| `device_type` | STRING | desktop/mobile/tablet |
| `browser` | STRING | Browser name |
| `os` | STRING | Operating system |
| `day_of_week` | INT64 | ISO weekday (1=Mon, 7=Sun) |
| `entrances` | INT64 | Sessions started |
| `engaged_entrances` | INT64 | Sessions with more than one pageview |
| `page_views` | INT64 | Page views |
| `microconversions` | INT64 | Microconversions |
| `conversions` | INT64 | Conversions |
| `revenue` | NUMERIC | Revenue |
Partitioned by `date`; clustered by `account_id`, `utm_source`, `country`.
### Conversions Table (`fact_conversions`)
| Column | Type | Description |
|--------|------|-------------|
| `sync_id` | STRING | Identifier of the sync that wrote the row |
| `synced_at` | TIMESTAMP | When the row was synced |
| `account_id` | STRING | Sealmetrics account (site) ID |
| `date` | DATE | Day of the conversion |
| `conversion_type` | STRING | Conversion type/label |
| `utm_source` | STRING | Attributed source |
| `utm_medium` | STRING | Attributed medium |
| `utm_campaign` | STRING | Attributed campaign |
| `utm_term` | STRING | Attributed term |
| `utm_content` | STRING | Attributed content |
| `channel_group` | STRING | Marketing channel group |
| `country` | STRING | ISO country code |
| `device_type` | STRING | desktop/mobile/tablet |
| `browser` | STRING | Browser name |
| `os` | STRING | Operating system |
| `landing_page` | STRING | Landing page path |
| `click_id` | STRING | Ad platform click ID (gclid, fbclid, etc.) |
| `count` | INT64 | Number of conversions |
| `amount` | NUMERIC | Per-conversion value |
| `revenue` | NUMERIC | Total revenue |
| `properties` | JSON | Custom conversion properties |
Partitioned by `date`; clustered by `account_id`, `conversion_type`, `utm_source`.
## Example Queries
Replace `your-project` and `sealmetrics` with your GCP project ID and dataset name.
### Daily Traffic Summary
```sql
SELECT
date,
SUM(entrances) AS entrances,
SUM(page_views) AS page_views,
SUM(conversions) AS conversions
FROM `your-project.sealmetrics.fact_traffic_daily`
WHERE date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY date
ORDER BY date DESC
```
### Conversion Attribution
```sql
SELECT
utm_source,
utm_medium,
SUM(count) AS conversions,
SUM(revenue) AS revenue,
SAFE_DIVIDE(SUM(revenue), SUM(count)) AS avg_order_value
FROM `your-project.sealmetrics.fact_conversions`
WHERE date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY utm_source, utm_medium
ORDER BY revenue DESC
```
### Traffic by Content Grouping
```sql
SELECT
content_grouping,
SUM(page_views) AS page_views,
SUM(entrances) AS entrances
FROM `your-project.sealmetrics.fact_pages`
WHERE date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
AND content_grouping IS NOT NULL
GROUP BY content_grouping
ORDER BY page_views DESC
```
### Custom Conversion Properties
```sql
SELECT
JSON_VALUE(properties, '$.customer_type') AS customer_type,
SUM(count) AS conversions,
SUM(revenue) AS revenue
FROM `your-project.sealmetrics.fact_conversions`
WHERE date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY customer_type
ORDER BY conversions DESC
```
## Troubleshooting
### "Permission Denied" Error
Verify service account has:
- BigQuery Data Editor role
- BigQuery Job User role
- Access to the correct GCP project
### Sync Not Running
1. Check the integration status is "Active" (not paused)
2. Verify credentials haven't expired
3. Check GCP project billing is active
4. Review the **Recent Sync History** card on the integration screen for failed runs and error details
### Missing Data
1. Check the date range matches expected data
2. Verify the data type you expect is selected in **Data Types to Sync**
3. Check if data is still processing (1-2 hour delay)
4. Ensure the table wasn't manually modified in BigQuery
### High Costs
To reduce BigQuery costs:
- Tables are partitioned by `date` and clustered by default — filter queries on `date` to scan less data
- Limit the initial historical backfill
- Only sync the data types you need; skip Hourly Traffic unless you need intraday analysis
- Set up BigQuery budget alerts
## Data Retention
Once data is synced to your BigQuery project, you own it and control retention. Sealmetrics only pushes data — it never deletes data from your dataset.
The only exception is the **Hourly Traffic** table (`fact_traffic_hourly`), which is created with a 90-day partition expiration to keep storage costs down. All other tables retain data indefinitely until you remove it yourself.
## Costs
### Sealmetrics
BigQuery integration is included free with all plans (Growth, Scale, and Enterprise).
### Google Cloud
You pay GCP directly for:
- Storage: ~$0.02/GB/month
- Queries: ~$5/TB scanned
Typical costs for mid-size site (1M events/month):
- Storage: ~$1-2/month
- Queries: Depends on usage, typically $5-20/month
## Pixel Builder
URL: https://docs.sealmetrics.com/platform/settings/tracking/pixel-builder
# Pixel Builder
The Pixel Builder helps you generate tracking code for your website without writing it by hand. It produces ready-to-copy snippets for conversions and microconversions, and lets you save reusable pixel configurations per site.
It lives inside the **Pixels** (Pixel Management) page, alongside the installation guide and pixel status monitoring.
## Accessing Pixel Builder
1. Open **Organization → Pixels** in the sidebar
2. Select the account/site you want to work with from the **Pixel Status** list
3. Scroll to the **Pixel Builder** card
4. Click **Create Pixel**
**Note:**
## Creating a Pixel
Clicking **Create Pixel** opens the Pixel Builder dialog.
### Step 1: Name and Description
- **Pixel Name** (required) — a friendly name to identify the pixel in your list (e.g., "Black Friday Purchase Tracking")
- **Description** (optional) — a short note describing what the pixel tracks
### Step 2: Choose Pixel Type
Select the type of event to track:
| Type | Purpose | Function Generated |
|------|---------|-------------------|
| **Conversion** | Goal completions, optionally with a monetary value | `sealmetrics.conv()` |
| **Microconversion** | Smaller engagement events and funnel steps | `sealmetrics.micro()` |
### Step 3: Configure the Event
**Conversion Type** (for both conversions and microconversions): start typing to pick a common type from the suggestions, or enter your own value (e.g., `purchase`, `signup`, `lead`, `add_to_cart`).
**For Conversions only:**
- **Revenue** — the conversion value (defaults to `0` for non-monetary conversions)
- **Currency** — the currency code (defaults to `EUR`)
**Custom Properties** (optional, both types): add key/value pairs to attach extra data to the event.
### Step 4: Select Target Platform
Choose where you'll use the code:
| Platform | Output |
|----------|--------|
| **JavaScript** | Plain JavaScript snippet |
| **GTM** | Output formatted for Google Tag Manager |
| **Tealium** | Output formatted for Tealium |
### Step 5: Copy the Generated Code
The **Generated Code** preview updates in real time as you change the configuration. Click **Copy** to copy it to your clipboard. If the snippet references variables you must supply (for example, JS or GTM variables), they are listed under **Required Variables**.
### Step 6: Save the Pixel
Click **Save Pixel** (or **Update Pixel** when editing) to store the configuration. Saved pixels appear in the Pixel Builder list for the selected site.
## Value Types
When configuring Revenue, Currency, or property values, each value can be one of:
| Type | Description | Example |
|------|-------------|---------|
| **Literal** | A fixed value | `99.99`, `EUR` |
| **JS Variable** | A JavaScript variable name | `orderTotal` |
| **GTM Variable** | A Google Tag Manager variable | `{{Order Total}}` |
## Generated Code Examples
### Conversion (JavaScript)
```javascript
sealmetrics.conv('purchase', 99.99, {
currency: 'EUR'
});
```
### Microconversion (JavaScript)
```javascript
sealmetrics.micro('add_to_cart', {
product_id: 'SKU-123',
price: '89.99'
});
```
## Saved Pixels
Saved pixels are stored per site. In the Pixel Builder list you can:
- **Create Pixel** — open the builder to configure a new pixel
- **Edit** — reopen a saved pixel to update its configuration
- **Delete** — remove a saved pixel (asks for confirmation)
## Important Notes
### Tracker Must Be Installed First
The Pixel Builder generates event-tracking code only. The base tracker script must already be installed on your page. Use the **Installation Guide** on the same Pixels page (tabs for WordPress, Shopify, Wix, Next.js, GTM, and Manual HTML) to get the install snippet.
See the [Installation Guide](/implementation/tracker/installation) for setup instructions.
### Conversions Count as Pageviews
Every conversion and microconversion event also counts as a pageview. Do not call `sealmetrics()` separately on the same page where you fire a conversion.
### Privacy Note
Never include personal identifiers (order IDs, user IDs, emails, transaction IDs) in conversion calls. Only track event types and aggregate values to maintain user privacy.
### Debug Mode
Add `?debug=1` to any page URL to see tracking events logged in the browser console:
```
https://yoursite.com/thank-you?debug=1
```
## Related Documentation
- [Installation](/implementation/tracker/installation) — Install the base tracker
- [Conversions](/implementation/tracker/conversions) — Detailed conversion tracking guide
- [Microconversions](/implementation/tracker/microconversions) — Event tracking guide
- [API Reference](/implementation/tracker/api-reference) — Complete tracker API
## Referrer Mappings
URL: https://docs.sealmetrics.com/platform/tracking-and-attribution-settings/referrer-mappings
# Referrer Mappings
**Referrer Mappings** let you assign a specific source, medium, and campaign to traffic that arrives from a known referrer domain. When a visit comes from a domain you have mapped **and the URL carries no UTM parameters**, SealMetrics applies the UTM values you configured automatically.
This is useful for properly attributing traffic from:
- Partner sites
- Affiliates
- Internal domains
- Any referrer you want to label with a consistent source/medium
**Note:**
Referrer Mappings act on the **referrer domain** of an incoming visit. They are different from **UTM Mappings**, which rename or group UTM values that are already present in the URL. See [How to change UTM parameters](/reports/insights/how-to-change-utm-parameters) for UTM Mappings.
**Warning:**
The API endpoints work and mappings are stored per account, but the tracking pipeline **does not yet read this table** when classifying incoming traffic — saved mappings have no effect on attribution today. For traffic that needs to be re-attributed now, use [Channel Grouping rules](/api/channel-groups) or [UTM Mappings](/reports/insights/how-to-change-utm-parameters) instead. See the [Referrer Mappings API reference](/api/referrer-mappings) for details.
---
## How It Works
- When traffic comes from a matched referrer **without** UTM parameters in the URL, the configured UTM values are applied.
- **Existing UTM parameters in the URL are never overwritten.** An explicit `utm_source`/`utm_medium`/`utm_campaign` always wins.
- When several mappings could match, the one with the **highest priority** is applied first (priority is a `0`–`1000` scale).
---
## How to Set It Up
**Info:**
Referrer Mappings are currently managed through the **Sealmetrics API**, not from a dashboard screen. Create, update and inspect mappings with the API calls shown below. See the [Referrer Mappings API reference](/api/referrer-mappings) for the complete request/response schema.
Mappings are scoped to an account. Create one with your API key:
```bash
curl -X POST "https://my.sealmetrics.com/api/v1/referrer-mappings?account_id=YOUR_ACCOUNT_ID" \
-H "X-API-Key: sm_your_key" \
-H "Content-Type: application/json" \
-d '{
"referrer_pattern": "partner-site.com",
"match_type": "exact",
"utm_source": "partner-site",
"utm_medium": "referral",
"label": "Partner Site Traffic"
}'
```
All management is done through the API:
- **List** mappings (`GET /referrer-mappings?account_id=...`), optionally including inactive ones
- **Create, update, and delete** mappings
- **Deactivate** a mapping (`is_active: false`) without deleting it
See the [Referrer Mappings API reference](/api/referrer-mappings) for every endpoint and example. Creating or modifying mappings requires editor-or-higher (write) permissions.
---
## Match Types
The **Match Type** controls how the referrer domain of an incoming visit is compared against your pattern:
| Match type | Behavior |
|------------|----------|
| **Exact** | Matches the domain exactly |
| **Contains** | The domain contains the pattern |
| **Starts with** | The domain starts with the pattern |
| **Ends with** | The domain ends with the pattern |
| **Regex** | The domain matches a regular expression |
The referrer pattern is normalized when saved: the protocol (`http://`, `https://`) and any path are stripped, and the value is lowercased. Enter just the domain.
---
## Fields Reference
A referrer mapping stores the following fields:
| Field | Required | Default | Notes |
|-------|----------|---------|-------|
| `referrer_pattern` | Yes | — | Domain pattern to match (max 255 chars) |
| `match_type` | No | `exact` | One of `exact`, `contains`, `starts_with`, `ends_with`, `regex` |
| `utm_source` | Yes | — | Source to apply |
| `utm_medium` | No | `referral` | Medium to apply |
| `utm_campaign` | No | empty | Campaign to apply |
| `utm_term` | No | empty | Term to apply |
| `utm_content` | No | empty | Content to apply |
| `label` | No | — | Human-readable label |
| `description` | No | — | Optional description |
| `priority` | No | `0` | Higher priority mappings are checked first (`0`–`1000`) |
| `is_active` | No | `true` | Whether the mapping is applied |
---
## Related
- [How to change UTM parameters](/reports/insights/how-to-change-utm-parameters) — rename or group UTM values already present in the URL (UTM Mappings).
- [Passthrough Referrers](/platform/tracking-and-attribution-settings/passthrough-referrers) — preserve the original session source when visitors return from external domains such as payment gateways.
## Roles & Permissions
URL: https://docs.sealmetrics.com/platform/user-management/roles-management
# Roles & Permissions
Sealmetrics uses a two-tier role system to give you fine-grained control over who can access what:
1. **Organization roles** (Owner, Admin, Member) determine what a user can do across the organization — manage members, billing, settings, and which sites they can see.
2. **Site access roles** (Editor, Viewer) determine the access level a Member is granted when they are added to a specific site.
The user's effective management permissions are driven by their **organization role**. Site access roles control whether a Member has edit or view-only access to the sites assigned to them.
---
## Organization Roles
Every member of an organization has exactly one organization role: **Owner**, **Admin**, or **Member**.
The table below reflects the actual permissions enforced by the platform for each organization role.
| Permission | Owner | Admin | Member |
|------------|:-----:|:-----:|:------:|
| View all sites in the organization | Yes | Yes | -- |
| View only assigned sites | -- | -- | Yes |
| Create a site | Yes | Yes | -- |
| Edit a site | Yes | Yes | -- |
| Delete a site | Yes | -- | -- |
| View members | Yes | Yes | Yes |
| Invite members | Yes | Yes | -- |
| Remove members | Yes | Yes | -- |
| Change a member's role to Admin or Member | Yes | Yes | -- |
| Promote a member to Owner | Yes | -- | -- |
| Edit organization settings | Yes | -- | -- |
| Delete the organization | Yes | -- | -- |
| Manage integrations | Yes | Yes | -- |
| Manage pixels | Yes | Yes | -- |
| Manage properties | Yes | Yes | -- |
| Manage LLM providers | Yes | -- | -- |
| Manage API tokens | Yes | Yes | -- |
| Access account migration | Yes | Yes | -- |
### Owner
The organization creator is automatically the Owner. Owners have unrestricted access to everything in the organization, including billing, member management, organization settings, LLM providers, and all sites.
### Admin
Admins can manage the day-to-day operations of the organization. They can invite and remove members, manage site access, edit sites, and manage integrations, pixels, properties, and API tokens. Admins **cannot** delete a site, manage billing, edit or delete the organization, manage LLM providers, or promote a member to Owner.
### Member
Members have restricted access. They can only see the specific sites that an Owner or Admin has assigned to them. They can view the member list, but cannot invite, remove, or manage other members, and cannot change any organization or site configuration.
---
## Site Access Roles
When an Owner or Admin grants a Member access to a site, they assign a **site access role**:
| Role | Access |
|------|--------|
| **Editor** | View reports and modify the site's configuration and settings |
| **Viewer** | Read-only access to reports and analytics |
Site access itself is granted from **Organization → Members**: click the site access (globe) button next to a member and toggle the sites they should see. Choosing between the Editor and Viewer levels is currently done through the [Site Users API](/api/sites#site-user-endpoints), not from a dashboard screen.
**Info:**
---
## How Roles Combine
A user's effective permissions are the combination of their organization role and — for Members — the site access role they were granted on each site.
| Org Role | Site Access | What They Can Do |
|----------|-------------|------------------|
| **Owner** | All sites | Full access to everything — all sites, billing, members, org settings, LLM providers |
| **Admin** | All sites | All sites, member management, integrations, pixels, properties, API tokens — no billing, no org/site deletion, no LLM providers |
| **Member** | **Editor** | Only assigned sites; can view reports and edit configuration on those sites |
| **Member** | **Viewer** | Only assigned sites; read-only access |
**Tip:**
---
## Choosing the Right Roles
| Scenario | Recommended Org Role | Site Access |
|----------|---------------------|-------------|
| Business owner or account manager | Owner | -- (all sites) |
| Team lead managing the analytics setup | Admin | -- (all sites) |
| Marketing analyst on your team | Member | Editor |
| External client reviewing reports | Member | Viewer |
| Agency partner managing tracking | Member | Editor |
**Info:**
Keep the number of Owners to a minimum. Most team members work well as Admins, or as Members with the appropriate site access.
## How to Add Domains to Your Site
URL: https://docs.sealmetrics.com/platform/account-setup/how-to-add-domains
# How to Add Domains to Your Site
Domains define which websites are authorized to send tracking data to your Sealmetrics site. You need at least one domain configured for tracking to work.
Sealmetrics counts a new **entrance** when the referrer is empty or comes from a different domain than your own (e.g., facebook.com → yoursite.com).
---
## Add a Domain During Site Creation
When you create a new site, you can add one or more domains in the creation form:
1. In the left sidebar, expand **Organization** and click **Sites** (`/settings/sites`).
2. Click **New Site**.
3. Enter the **Site Name** and the **Primary Domain** (e.g., `example.com`).
4. Set the **Timezone** and **Currency**, then click **Create Site**.
You can add additional domains later from the site's **Domains** tab (see below).
---
## Add a Domain to an Existing Site
1. In the left sidebar, expand **Organization** and click **Sites** (`/settings/sites`).
2. Find the site and click **Configure**.
3. Open the **Domains** tab.
4. Type the domain (e.g., `example.com` or `sub.example.com`) in the input field.
5. Press **Enter** or click **Add**.
The domain will appear in the list and tracking will be authorized immediately.
---
## Remove a Domain
1. In the **Domains** tab, click the **trash icon** next to the domain you want to remove.
2. Confirm the removal in the dialog.
---
## Important Notes
- Domains must be in a valid format (e.g., `example.com`, `shop.example.com`).
- Subdomains are supported.
- Only one domain or its subdomains can be tracked per site (no cross-site tracking).
- If no domains are configured, you'll see a message: "No domains configured. Add your first domain to start tracking."
## Users & Teams
URL: https://docs.sealmetrics.com/platform/settings/account/users
# Users & Teams
Manage who has access to your Sealmetrics organization and control what they can see and do.
---
## Viewing Members
To see all members in your organization:
1. Open the sidebar and go to the **Organization** group
2. Click **Members**
You will see a list of all current members, their name, email, organization role, the number of assigned sites (for Members), and when they joined.
---
## Inviting Members
Owners and Admins can invite new members to the organization.
### How to send an invitation
1. Open the **Members** page for your organization
2. Click **Invite Member**
3. Enter the person's email address
4. Choose their organization role:
- **Admin** -- manage members and all sites, no billing
- **Member** -- access only to assigned sites
5. If you selected **Member**, select at least one site they should have access to (this is required)
6. Click **Send Invitation**
The invited person will receive an email with a link to accept the invitation. If they do not already have a Sealmetrics account, they will be asked to create one.
**Note:**
### Pending invitations
Invitations expire after 7 days. You can view pending invitations on the Members page and:
- **Resend** an invitation to extend the expiration
- **Cancel** an invitation if it is no longer needed
---
## Assigning Sites to Members
Members can only see the sites you explicitly assign to them. Owners and Admins see all sites automatically.
### To assign sites to a member
1. Go to the **Members** page
2. Find the member in the list
3. Click the **site access** (globe) button next to them
4. In the panel that opens, toggle the sites they should have access to
Changes apply immediately, and you can add or remove site access at any time without affecting the member's organization role.
There is currently no dashboard screen to choose between the Editor and Viewer access levels — per-site roles are managed through the [Site Users API](/api/sites#site-user-endpoints). See [Roles & Permissions](../../user-management/roles-management) for details.
---
## Changing a Member's Role
Owners and Admins can change organization roles for other members.
1. Go to the **Members** page
2. Find the member
3. Change their role using the role dropdown
4. Confirm the change
Role changes take effect immediately.
**Restrictions:**
- Admins cannot change the role of an Owner
- Only Owners can promote someone to Owner or demote an Owner
---
## Removing a Member
1. Go to the **Members** page
2. Find the member you want to remove
3. Click the remove option
4. Confirm the removal
The member will immediately lose access to all sites and data in the organization.
---
## User Limits
All Sealmetrics plans include **unlimited users**. There is no limit on the number of team members you can invite to your organization.
---
## Understanding Roles
Sealmetrics uses a two-tier role system:
- **Organization roles** (Owner, Admin, Member) drive a user's management permissions across the organization
- **Site access roles** (Editor, Viewer) set whether a Member has edit or view-only access to an assigned site
For a full breakdown of permissions, see [Roles & Permissions](../../user-management/roles-management).
## Data Studio Integration
URL: https://docs.sealmetrics.com/platform/settings/integrations/looker-studio
# Data Studio Integration
Build custom dashboards and visual reports in Google Data Studio using your SealMetrics analytics data. The official SealMetrics connector pulls traffic, sources, pages, conversions, and more directly into Data Studio charts and tables.
**Note:**
Google renamed Looker Studio back to **Data Studio** in April 2026, reversing the 2022 rebrand. Same product, same reports, same connector — only the name changed.
This page keeps its `looker-studio` URL on purpose: the SealMetrics Apps Script manifest points its `addOnUrl` and `supportUrl` here, and changing it would break those and any existing bookmarks.
## Prerequisites
- SealMetrics account with an active API key
- Google account with access to [Data Studio](https://datastudio.google.com)
## How It Works
The SealMetrics connector for Data Studio fetches data in real-time from the SealMetrics API using your API key. Each time you view a dashboard, Data Studio requests the latest data for your selected date range.
```
Data Studio → SealMetrics Connector → SealMetrics API → Your analytics data
```
Data is cached for 5 minutes to ensure fast loading. Data Studio may also apply its own caching.
**Note:**
The SealMetrics Data Studio connector is currently pending listing in the Data Studio Partner Connector Gallery. While the listing is being reviewed, your Google account must be granted **Viewer** access to the underlying connector. If the authorization page redirects you to the Data Studio home with no error, contact us at [support@sealmetrics.com](mailto:support@sealmetrics.com) with the Google email you want whitelisted and we'll grant access within one business day.
## Setup
### Step 1: Get Your API Key
1. In SealMetrics, go to **My Account > API Keys**
2. Create a new API key or copy an existing one
3. Keep it handy — you'll need it in the next step
**Tip:**
### Step 2: Open the Connector in Data Studio
1. Click the link below to open the SealMetrics connector in Data Studio:
**[Open SealMetrics Connector](https://datastudio.google.com/datasources/create?connectorId=AKfycbz0OeJk_X454_DijtnmO12DZeFBRL_u_-anvWX_f5oTvxUDlxdc6yIADlcRzOr2aOPAcg)**
2. You'll be asked to authorize the connector on first use — click **Authorize**
### Step 3: Configure the Data Source
The setup is a two-step configuration:
1. **Enter your API key** and click **Next**
2. **Select your site** from the dropdown (all sites linked to your API key are listed)
3. **Choose a report type** — this determines which dimensions and metrics are available
4. Click **Connect**
You now have a data source ready to use in any Data Studio report.
## Available Report Types
Each report type provides a different set of dimensions and metrics. You can create multiple data sources (one per report type) and combine them in a single dashboard.
### Traffic Overview
Daily traffic metrics with time-series data.
| Field | Type | Description |
|-------|------|-------------|
| Date | Dimension | Day of the data point |
| Entrances | Metric | Number of sessions started |
| Page Views | Metric | Total page views |
| Engaged Entrances | Metric | Sessions with more than one pageview |
| Conversions | Metric | Total conversions |
| Microconversions | Metric | Total microconversions |
| Revenue | Metric | Total revenue (EUR) |
| Bounce Rate | Metric | Percentage of single-page sessions |
### Traffic Sources
Traffic broken down by UTM parameters.
| Field | Type | Description |
|-------|------|-------------|
| Source | Dimension | UTM source |
| Medium | Dimension | UTM medium |
| Campaign | Dimension | UTM campaign |
| Term | Dimension | UTM term |
| Entrances | Metric | Sessions from this source |
| Conversions | Metric | Conversions attributed to this source |
| Revenue | Metric | Revenue from this source (EUR) |
| Bounce Rate | Metric | Bounce rate for this source |
### Pages
Page-level analytics with content grouping.
| Field | Type | Description |
|-------|------|-------------|
| Page Path | Dimension | URL path of the page |
| Content Group | Dimension | Content group assignment |
| Entrances | Metric | Sessions entering on this page |
| Page Views | Metric | Total views of this page |
| Conversions | Metric | Conversions on this page |
| Bounce Rate | Metric | Bounce rate for this page |
### Landing Pages
Entry page performance with conversion data.
| Field | Type | Description |
|-------|------|-------------|
| Landing Page | Dimension | URL path of the entry page |
| Entrances | Metric | Sessions starting on this page |
| Conversions | Metric | Conversions from this landing page |
| Revenue | Metric | Revenue from this landing page (EUR) |
| Bounce Rate | Metric | Bounce rate for this landing page |
### Countries
Geographic breakdown of your traffic.
| Field | Type | Description |
|-------|------|-------------|
| Country Code | Dimension | ISO country code |
| Country | Dimension | Country name |
| Entrances | Metric | Sessions from this country |
| Page Views | Metric | Page views from this country |
| Conversions | Metric | Conversions from this country |
| Bounce Rate | Metric | Bounce rate for this country |
### Devices
Traffic split by device type.
| Field | Type | Description |
|-------|------|-------------|
| Device Type | Dimension | Device category (desktop, mobile, tablet) |
| Entrances | Metric | Sessions from this device type |
| Page Views | Metric | Page views from this device type |
| Bounce Rate | Metric | Bounce rate for this device type |
### Channels
Traffic grouped by marketing channel.
| Field | Type | Description |
|-------|------|-------------|
| Channel | Dimension | Channel group (organic, paid, social, direct, etc.) |
| Entrances | Metric | Sessions from this channel |
| Conversions | Metric | Conversions from this channel |
| Revenue | Metric | Revenue from this channel (EUR) |
| Bounce Rate | Metric | Bounce rate for this channel |
## Building a Dashboard
### Creating Your First Report
1. Go to [Data Studio](https://datastudio.google.com) and click **+ Create > Report**
2. Select your SealMetrics data source (created during setup)
3. Start adding charts, tables, and scorecards using the available fields
### Combining Multiple Report Types
For a complete analytics dashboard, create one data source per report type and add them all to the same report:
1. **Traffic Overview** — for time-series charts (entrances, conversions, revenue over time)
2. **Traffic Sources** — for source/medium breakdown tables
3. **Landing Pages** — for top landing pages with conversion rates
4. **Channels** — for channel performance pie charts
5. **Countries** — for geo maps
6. **Devices** — for device split donut charts
To add a new data source to an existing report:
1. Click **Resource > Manage added data sources**
2. Click **Add a data source**
3. Search for "SealMetrics" and configure with a different report type
### Using Date Range Controls
The connector respects Data Studio's date range controls. Add a date range picker to let viewers filter all charts at once:
1. Click **Add a control > Date range control**
2. Place it at the top of your report
3. All SealMetrics charts will automatically filter to the selected range
## Tips
- **Data caching**: Data is cached for 5 minutes on the connector side. Data Studio may also cache on its side. To force a refresh, click the refresh button in the report viewer.
- **Multiple sites**: Create separate data sources for each site you want to report on. You can combine them in the same dashboard.
- **API key rotation**: If you rotate your API key, update it in each Data Studio data source by going to **Resource > Manage added data sources > Edit** for each SealMetrics source.
- **Sharing**: When you share a Data Studio report, viewers use the data source owner's API key — they don't need their own.
- **Blending data**: Use Data Studio's [data blending](https://docs.cloud.google.com/data-studio/create-edit-and-manage-blends) to combine metrics from different report types in a single chart (e.g., join Traffic Sources with Landing Pages by a common dimension).
## Troubleshooting
### "Invalid API Key" Error
1. Verify your API key is correct in **My Account > API Keys**
2. Make sure the key hasn't been revoked or expired
3. Re-enter the key in the data source: **Resource > Manage added data sources > Edit**
### No Sites Listed
1. Confirm your API key has access to at least one site
2. Check that sites are active in your SealMetrics account
### Data Not Loading
1. Verify the selected date range contains data
2. Check that your SealMetrics account is active
3. Try refreshing the data source (click the refresh icon in the report)
4. If the issue persists, create a new data source — the connector may need to be re-authorized
### Rate Limiting
The connector handles rate limits automatically with retry logic. If you experience slow loading:
- Reduce the date range
- Avoid refreshing multiple reports simultaneously
- Data is cached for 5 minutes, so repeated views load faster
## Data Studio + BigQuery
If you also use the [BigQuery integration](/platform/settings/integrations/bigquery), you can combine both approaches:
- **Data Studio connector** — best for quick dashboards with standard metrics, no setup required beyond an API key
- **BigQuery as data source in Data Studio** — best for custom SQL queries, cross-table joins, and advanced analysis
You can use BigQuery as a Data Studio data source by selecting **BigQuery** instead of the SealMetrics connector when creating a data source, and pointing it to your SealMetrics BigQuery dataset.
## Support
Need help with the connector? Email **[support@sealmetrics.com](mailto:support@sealmetrics.com)** and include:
- Your SealMetrics account email
- The report type that fails
- A screenshot of the error message
- The Data Studio data source URL (visible in the address bar)
We aim to respond within one business day.
## Legal
By using the SealMetrics Data Studio connector, you agree to:
- [SealMetrics Privacy Policy](https://sealmetrics.com/privacy/)
- [SealMetrics Terms of Service](https://sealmetrics.com/terms/)
The connector reads analytics data from your SealMetrics account via the SealMetrics REST API. It does not write to or modify your account. Your API key is stored by Data Studio in your data source configuration; rotate it from **Settings > API Keys** at any time.
## Content Grouping
URL: https://docs.sealmetrics.com/platform/settings/tracking/content-grouping
# Content Grouping
Content Grouping lets you organize your pages into logical categories, making it easier to analyze performance by section rather than individual URLs in the Pages report.
## What is Content Grouping?
Instead of analyzing hundreds of individual URLs:
```
Before Content Grouping:
─────────────────────────
/products/widget-a 234 views
/products/widget-b 189 views
/products/gadget-x 167 views
/blog/how-to-use-widgets 145 views
/blog/widget-comparison 132 views
/about 89 views
... (hundreds more)
```
You can analyze by content type:
```
After Content Grouping:
─────────────────────────
Products 1,234 views
Blog 892 views
Other 345 views
```
Pages that don't match any rule are grouped under **Other**.
**Info:**
Content grouping rules are saved in your **browser's local storage**, per site. They are not synced to the server or shared across browsers, devices, or teammates. Clearing your browser data removes your rules.
## How Rules Work
Each rule has just two fields:
| Field | Description |
|-------|-------------|
| **Group Name** | The label shown in reports (e.g., `Blog Posts`, `Products`) |
| **URL Pattern** | A path pattern, using `*` as a wildcard |
The pattern is matched against the page's URL path. Use `*` to match any sequence of characters:
| Pattern | Matches |
|---------|---------|
| `/blog/*` | `/blog/my-post` |
| `/products/*` | `/products/widget-pro` |
| `/products/*/reviews` | `/products/shoes/reviews` |
| `/pricing` | `/pricing` (exact) |
| `/` | `/` (homepage) |
The pattern must match the **entire** path (it is anchored at the start and end). Matching is case-insensitive. Patterns with no `*` only match that exact path.
## Quick Setup Templates
To get started fast, click **Quick Setup** to open a set of pre-built templates that match common website structures:
| Template | Example rules |
|----------|---------------|
| **E-commerce** | Homepage, Products, Categories, Cart, Checkout, Account, Orders |
| **Blog / Content** | Homepage, Blog Posts, Blog Categories, Authors, Archives, Tags |
| **SaaS / App** | Homepage, Dashboard, Settings, Billing, Profile, Reports, Integrations |
| **Documentation** | Homepage, Getting Started, Guides, API Reference, Tutorials, FAQ, Changelog |
| **Support Site** | Homepage, Help Articles, Knowledge Base, Contact, Tickets, Status |
| **Marketing Site** | Homepage, Features, Pricing, About, Case Studies, Resources, Contact, Legal |
In the template dialog you can either:
- **Apply all rules** from a template at once, or
- Click the **+** next to an individual rule to add just that one
After applying a template you can edit or delete any of the generated rules.
## How Pages Are Matched
When the Pages report is built, each page path is tested against your rules:
- Rules are evaluated in **priority order** (higher priority first). New rules are appended with an increasing priority value.
- The **first** rule whose pattern matches the path determines the group name.
- If no rule matches, the page falls into the **Other** group.
## Limitations
- Rules are stored in your browser's local storage only — they are **not** saved on the server, shared with teammates, or available on other devices/browsers.
- A rule matches on the **URL path** only. There is no matching by query parameter or page title.
- Grouping is applied when reports are computed; there is no separate reprocessing step for historical data.
## Passthrough Referrers
URL: https://docs.sealmetrics.com/platform/tracking-and-attribution-settings/passthrough-referrers
# Passthrough Referrers
A **passthrough referrer** is an external domain that your visitors temporarily pass through during a journey — and then return to your site. Instead of treating the return as a brand-new visit, SealMetrics keeps the **original session source** intact.
This is the right setting whenever a journey leaves your domain and comes back, for example:
- **Payment gateways** — Stripe, PayPal, Redsys, or a POS/checkout domain.
- **External authentication / SSO** — an identity provider or a shared accounts domain.
- **Booking and ticketing engines** — hotel booking engines, external ticketing, third-party checkout flows.
Without this configuration, when the visitor returns SealMetrics may detect the external domain as the referrer, count a new entrance, and overwrite the real acquisition source (Google Ads, Facebook, Email…) with **Referral** or **payment**.
---
## How a Passthrough Referrer Works
When a passthrough referrer is configured and a visit arrives from that domain:
- **If the original session still exists**, SealMetrics treats the hit as a continuation (a pageview) and **preserves the session's original UTMs** — source, medium, campaign, term, content. The external domain is *not* counted as a new source.
- **If no session exists** (for example, the visitor's session has expired), SealMetrics falls back to the UTM values you configured for that passthrough domain so the visit is still attributed sensibly instead of becoming an unknown referral.
This is the same preservation behavior used for payment gateways, applied per account to any external domain you choose.
---
## Relationship to the Session Window
Preservation depends on the original session still being active when the visitor returns:
- **2-hour session window** — the origin of the visit stays active for 2 hours, which covers virtually all checkout, login, and booking flows. See [Attribution Accuracy](/reports/insights/attribution-accuracy).
- If the visitor returns after the session has expired, there is no original session to preserve, so the configured fallback UTMs are used instead.
---
## How to Configure It
**Info:**
Passthrough referrers are currently managed through the **Sealmetrics API**, not from a dashboard screen. Create, update and inspect them with the API calls shown below. See the [Passthrough Referrers API reference](/api/passthrough-referrers) for the complete request/response schema.
Passthrough referrers are scoped to an account. Register one with your API key:
```bash
curl -X POST "https://my.sealmetrics.com/api/v1/passthrough-referrers?account_id=YOUR_ACCOUNT_ID" \
-H "X-API-Key: sm_your_key" \
-H "Content-Type: application/json" \
-d '{
"domain": "checkout.stripe.com",
"utm_source": "stripe",
"service_name": "Stripe Checkout"
}'
```
- `domain` is the external domain to exclude (protocol is stripped automatically).
- `utm_source` (required) and the optional `utm_medium` / `utm_campaign` fields are the **fallback UTMs** applied when no original session exists.
- `service_name` is an optional human-readable label.
All management is done through the API — list, create, update, deactivate (`is_active: false`), and delete. See the [Passthrough Referrers API reference](/api/passthrough-referrers) for every endpoint and example. Creating or modifying entries requires editor-or-higher (write) permissions.
Add **only** the external domains that visitors legitimately pass through — payment, auth, or booking domains. Do not add your own domains.
---
## When to Use Which Guide
This page is the canonical reference for the passthrough referrer concept. Two related guides cover specific scenarios that use the same configuration:
- [Bypass POS or Referrer](/platform/tracking-and-attribution-settings/bypass-pos-or-referrer) — step-by-step for excluding **payment gateway / POS** domains.
- [Preserve Attribution Through External Login or SSO Flows](/platform/tracking-and-attribution-settings/external-auth-sso-attribution) — step-by-step for excluding **external authentication / SSO** domains.
If you are mapping a known referrer domain to a custom source/medium (rather than preserving the original session), see [Referrer Mappings](/platform/tracking-and-attribution-settings/referrer-mappings) instead.
---
## Result
With the passthrough referrer configured:
✔ The session keeps its original acquisition source when the visitor returns
✔ Conversions on the thank-you / post-flow page inherit the real channel (SEO, Paid, Email…)
❌ No more conversions miscategorized as **Referral** or **payment** from a domain the visitor merely passed through
## How to Add an Organization Admin
URL: https://docs.sealmetrics.com/platform/user-management/create-admin-user
# How to Add an Organization Admin
If you need another person to help manage your organization's members and sites, you can invite them as an **Admin**.
An Admin can:
- Access all sites in the organization
- Add, remove, and manage members
- Assign sites to Members
- Manage integrations, pixels, properties, and API tokens
Admins **cannot** manage billing, edit or delete the organization, delete sites, manage LLM providers, or promote a member to Owner -- only the Owner can do those.
## Steps
1. In the sidebar, open the **Organization** group and click **Members**
2. Click **Invite Member**
3. Enter the person's email address
4. Set the role to **Admin**
5. Click **Send Invitation**
The person will receive an email invitation. Once they accept, they will have Admin access to your organization immediately.
---
For a full breakdown of what each role can do, see [Roles & Permissions](./roles-management).
## How to Find Your Site ID
URL: https://docs.sealmetrics.com/platform/account-setup/find-account-id
# How to Find Your Site ID
Your **Site ID** is a unique identifier assigned to each site in Sealmetrics. You need it to install the tracking pixel, configure API access, and set up integrations.
Some screens, plugins and integration fields label the same value **Account ID** — Site ID and Account ID are the same identifier.
The Site ID is set when the site is created and **cannot be changed** afterwards.
---
## Steps to Find Your Site ID
### 1. Open **Organization → Sites**
In the left sidebar, expand the **Organization** group and click **Sites** to open the **Site Management** page (`/settings/sites`).
### 2. Open your site's settings
Find your site in the **Your Sites** list and click **Configure**. This opens the site's settings page (`/settings/sites/{siteId}`).
### 3. Copy the Site ID
On the **General** tab, the **Site ID** is shown next to the **Site Name** field. Use the **copy button** beside it to copy it to your clipboard.
---
You can also see the Site ID listed next to each site under **Organization → Settings** (in the organization's **Sites** card).
## Security
URL: https://docs.sealmetrics.com/platform/settings/account/security
# Security
The Security screen manages your personal account security: **two-factor authentication (2FA)** with an authenticator app, **backup codes**, and the list of **active sessions** (devices where you are logged in), each of which can be revoked.
## Accessing Security
In the sidebar, open **My Account → Security** (`/settings/security`).
**Info:**
Everything on this screen belongs to **your user**, not to a site or organization. Changing your password is done on the **My Account → Profile** screen, not here.
## Security Status
The top card summarizes your account: it shows how many devices are currently logged in. When there is more than one session, a **Logout All Other Sessions** button appears — see [Active Sessions](#active-sessions) below.
## Two-Factor Authentication
2FA adds a second verification step at login using a **TOTP authenticator app** (Google Authenticator, 1Password, Authy, etc.).
### Enabling 2FA
If 2FA is not enabled, the card shows **2FA Not Enabled** with an **Enable 2FA** button. Setup is a guided four-step dialog:
1. **Password** — enter your account password to begin.
2. **Scan QR code** — scan the QR code with your authenticator app. If you can't scan, copy the secret shown below the code and enter it manually. This step also displays your **backup codes** — save them before continuing (there is a **Copy All Codes** button). Click **I've saved my backup codes** to proceed.
3. **Verify** — enter the 6-digit code from your authenticator app and click **Verify & Enable**.
4. **Success** — 2FA is now active on your account.
Cancelling the dialog before verification aborts the setup — nothing is enabled until the code is verified.
Once enabled, the next login asks for a 6-digit code (or a backup code) after your password.
### Backup codes
Backup codes let you log in if you lose your authenticator device. **10 codes** are generated at setup; each one is single-use. The card shows how many remain ("X of 10 codes remaining").
To generate a fresh set, click **Regenerate Codes**, enter a 6-digit code from your authenticator app, and click **Generate New Codes**. The new codes are displayed once with a **Copy All Codes** button.
**Warning:**
Regenerating backup codes **invalidates all previous codes** immediately.
### Disabling 2FA
Click **Disable 2FA**. The confirmation dialog requires **both**:
- Your account password
- A verification code — either a 6-digit code from your authenticator app or a backup code
After disabling, only your password is required to log in.
## Active Sessions
The **Active Sessions** card lists every device with a valid login session. For each session it shows:
- **Device and browser** — operating system (Windows, macOS, Linux, Android, iOS) and browser (Chrome, Firefox, Safari, Edge), derived from the user agent
- **Last active** — relative time of last use ("5 minutes ago", "2 days ago")
- **IP address** — where the session was created, when available
Your current session is highlighted with a **Current session** badge and cannot be terminated from the list.
### Revoking a single session
Each other session has a trash icon. Clicking it terminates that session immediately — the device is logged out and must authenticate again.
### Logout all other sessions
The **Logout All Other Sessions** button (in the Security Status card) opens a confirmation dialog. Confirming will:
- Log out every session except the current one
- Invalidate all existing tokens on those devices
- Require re-authentication on those devices
Use this if you suspect a session you don't recognize — and consider changing your password on the Profile screen as well.
## Related Documentation
- [2FA API](/api/2fa) - Full API reference for TOTP setup, verification, and backup codes
- [Advanced Authentication API](/api/auth-advanced) - Session listing/termination and the 2FA login flow
- [Connected Apps](/platform/settings/account/connected-apps) - AI assistants authorized via OAuth (separate from browser sessions)
- [Users & Teams](/platform/settings/account/users) - Organization roles and member access
## Webhooks
URL: https://docs.sealmetrics.com/platform/settings/integrations/webhooks
# Webhooks
Webhooks let Sealmetrics notify your servers in real time when something happens in your account — for example, when an alert triggers or a data export finishes. Sealmetrics sends an HTTP `POST` to a URL you control, signed so you can verify it came from us.
**Info:**
Webhooks are currently managed through the **Sealmetrics API**, not from a dashboard screen. Create, update and inspect endpoints with the API calls shown below. See the [Webhooks API reference](/api/webhooks) for the complete request/response schema, delivery logs, replay and statistics endpoints.
## What you can subscribe to
| Event | Fired when |
|-------|------------|
| `alert.triggered` | An anomaly alert starts firing |
| `alert.resolved` | An alert condition returns to normal |
| `export.completed` | A bulk export finishes and is ready to download |
| `export.failed` | A bulk export fails |
| `goal.reached` | A configured goal is reached |
The authoritative, up-to-date list is available from the API:
```http
GET /api/v1/webhooks/event-types
```
## Creating a webhook
Endpoints are scoped to an account. Create one with your API key:
```bash
curl -X POST "https://my.sealmetrics.com/api/v1/webhooks?account_id=YOUR_ACCOUNT_ID" \
-H "X-API-Key: sm_your_key" \
-H "Content-Type: application/json" \
-d '{
"name": "Slack Alerts",
"url": "https://my-app.com/webhooks/sealmetrics",
"event_types": ["alert.triggered", "export.completed"]
}'
```
The response returns a `secret` **once** — store it securely to verify signatures. The endpoint stays unverified until its first successful delivery (or test).
## Verifying signatures
Every delivery includes signature headers:
```
X-Sealmetrics-Signature: sha256=...
X-Sealmetrics-Timestamp: 1704898200
```
Compute `HMAC-SHA256` of `{timestamp}.{request_body}` with your webhook secret and compare it to the signature. Full Python and Node.js examples are in the [Webhooks API reference](/api/webhooks#signature-verification).
## Managing endpoints
All management is done through the API:
- **List / get / update / delete** endpoints
- **Send a test event** to verify your URL
- **Rotate the signing secret** (previous secret stays valid for 24 hours)
- **Inspect deliveries**, view payloads, and **replay** failed deliveries
- **Get delivery statistics** (success rate, response times, recent failures)
See the [Webhooks API reference](/api/webhooks) for every endpoint and example.
## Custom Dimensions
URL: https://docs.sealmetrics.com/platform/settings/tracking/custom-dimensions
# Custom Dimensions
Custom dimensions let you capture data beyond the standard analytics fields (page, referrer, device, country) for business-specific analysis — for example customer tier, product category, A/B test variant or subscription plan.
**Info:**
Sealmetrics does **not** have a settings screen where you pre-declare dimensions (with scopes, data types or default values). Instead, a custom dimension is simply a **custom property** you send with your tracking calls. The first time you send a property, it becomes available for filtering and breakdowns — no setup, no slot limit to manage.
## How to define a dimension
You "create" a dimension by sending it as a property on a conversion or microconversion. The last argument of `sealmetrics.conv()` and `sealmetrics.micro()` is a key–value object:
```javascript
// Conversion with custom dimensions (properties)
sealmetrics.conv('purchase', 149.99, {
product_category: 'Electronics',
customer_type: 'premium',
payment_method: 'credit_card'
});
// Microconversion with custom dimensions (properties)
sealmetrics.micro('add_to_cart', {
product_id: 'SKU-123',
product_category: 'Electronics',
customer_type: 'premium'
});
```
For the full reference on sending properties — including naming rules, value limits and server-side injection — see **[Custom Properties](/implementation/custom-properties)**.
### Hit, session and user scope
There are no configurable scopes. Whatever you attach to an event applies to that event, so to analyze data at "session" or "user" level you include the same property on every relevant event:
```javascript
// "Session" context: include it on each event of the visit
sealmetrics.micro('add_to_cart', { ab_variant: 'B', entry_campaign: 'summer-sale' });
sealmetrics.conv('purchase', 99.99, { ab_variant: 'B', entry_campaign: 'summer-sale' });
```
For "user" context (e.g. customer tier or plan), inject the value server-side so it's present on every event. See [User-scoped properties](/implementation/custom-properties/user-properties).
## Where to see your dimensions
- **Properties report** — break down and filter by any property you've sent. See [Properties report](/reports/properties).
- **Site Config → Properties** (`/settings/properties`) — lists the custom properties detected for the site. This page is informational (it shows what's being collected); it stays empty until property data arrives.
## Troubleshooting
**Dimension not appearing**
1. Confirm you're actually sending the property with your events (check in the browser network tab).
2. The property name is case-sensitive — it must match exactly between calls.
3. Confirm hits are arriving at all: the **Last hit** timestamp at the top right of the **Overview** report updates within seconds of a tracked visit. See [Data delay](/troubleshooting/data-delay).
**Values show as `(not set)`**
1. The property wasn't sent on that event.
2. The data predates when you started sending the property.
## How to Avoid Conversions Being Attributed to “Payment”
URL: https://docs.sealmetrics.com/platform/tracking-and-attribution-settings/avoid-conversions-attributed-to-payment
# How to Avoid Conversions Being Attributed to “Payment”
When a user makes a purchase and is redirected to a payment gateway (Stripe, PayPal, Redsys…), they temporarily leave your website.
When they return to your **thank-you page**, SealMetrics may treat it as a **new session**.
If the payment domain is not excluded, the conversion is attributed to source: **payment**.
---
## What This Means
✔ The conversion **is tracked**
❌ The original source (Google Ads, Facebook, Email…) **is lost**
For accurate marketing attribution, this must be corrected.
---
## Why SealMetrics Attributes “Payment” as a Source
Because SealMetrics is **privacy-first** and does not use cookies or fingerprinting.
We only detect:
- Browser
- OS
- Screen size
- Timestamp
So when the user returns from a third-party payment domain:
- SealMetrics creates a new session
- And assigns its domain as the referrer
Unless you register it as a **passthrough referrer**.
---
## When This Happens
Typical cases:
- Payment provider uses redirect flow
- Thank-you page loads after a new session
- Payment provider becomes the last referrer
Example:
1. User clicks a Google Ads ad
2. Adds items → proceeds to checkout
3. Pays via `payments.xyz.com`
4. Returns to your thank-you page
5. SealMetrics detects referrer = payment domain → Conversion is attributed incorrectly
---
## How to Fix It
Register the payment domain as a **passthrough referrer** through the Sealmetrics API — there is no dashboard screen for this:
```bash
curl -X POST "https://my.sealmetrics.com/api/v1/passthrough-referrers?account_id=YOUR_ACCOUNT_ID" \
-H "X-API-Key: sm_your_key" \
-H "Content-Type: application/json" \
-d '{
"domain": "payments.xyz.com",
"utm_source": "payment-gateway",
"service_name": "Payment Gateway"
}'
```
See the [Passthrough Referrers API reference](/api/passthrough-referrers) for the complete schema, and [Bypass POS or Referrer](/platform/tracking-and-attribution-settings/bypass-pos-or-referrer) for the step-by-step guide.
Add **only your payment provider domain**, not internal domains.
---
With this configuration, conversions retain the *real* traffic source.
## How to Change Your Password
URL: https://docs.sealmetrics.com/platform/user-management/change-password
# How to Change Your Password
Follow these steps to update your password securely.
## 1. Open Your Profile
In the sidebar, open the **My Account** group and click **Profile**.
The Profile page shows your account information and a **Change Password** section.
## 2. Update Your Password
In the **Change Password** section, fill in:
- **Current Password**
- **New Password** (must be at least 12 characters)
- **Confirm New Password**
Click **Change Password** to save your changes. A confirmation message appears once the password has been updated.
**Tip:**
You can add an extra layer of security by enabling two-factor authentication from **My Account → Security**, which is also where you manage your active sessions.
---
If you cannot access your account, you can request a reset link from the login screen.
## How to Add a New Site
URL: https://docs.sealmetrics.com/platform/account-setup/how-to-add-new-account
# How to Add a New Site
Each site represents a website you want to track with Sealmetrics. Sites belong to an organization.
## Steps
1. In the left sidebar, expand **Organization** and click **Sites** (`/settings/sites`)
2. Click **New Site**
3. Enter the **Site Name** (e.g., "My Blog" or "company.com")
4. Optionally enter a **Primary Domain** to track (you can add more later)
5. Set the site's **Timezone** — this determines how dates are calculated in your reports (default: Europe/Madrid)
6. Set the **Currency** for conversion tracking (default: EUR)
7. Click **Create Site**
Your new site will appear in the **Your Sites** list with a unique **Site ID**.
---
## Next steps
- **Install the tracker** on your website using the Site ID. See [Installation Guide](/implementation/tracker/installation).
- **Configure your domains** in the site's **Domains** tab (Site Config → Settings) to ensure proper attribution.
- **Set up conversions** to track goals and e-commerce transactions.
---
For more about how sites relate to organizations, see [Organizations](/platform/organizations).
## Connected Apps
URL: https://docs.sealmetrics.com/platform/settings/account/connected-apps
# Connected Apps
The Connected Apps screen lists the **remote MCP clients** — AI assistants such as claude.ai or ChatGPT — that you have granted **read-only** access to your analytics via OAuth, and lets you revoke that access at any time.
## Accessing Connected Apps
In the sidebar, open **My Account → Connected Apps** (`/settings/connections`).
**Info:**
Connected Apps only covers OAuth grants created through the **Sealmetrics remote MCP server**. Personal API tokens live under **My Account → API Keys**, and browser logins are managed on the [Security screen](/platform/settings/account/security).
## How a connection is created
An entry appears here when you connect the Sealmetrics remote MCP server from an AI client:
1. In claude.ai, ChatGPT, or another MCP-capable client, add the connector URL `https://mcp.sealmetrics.com/mcp`.
2. The client redirects you to the Sealmetrics **consent screen**, which shows the app's name and the domain it will return to.
3. You approve access for **one specific site** — each connection is scoped to a single site. Connecting the same client to another site creates a separate entry.
The full setup flow (per client) is described in the [MCP Server guide](/integrations/mcp-server).
## Authorized connections
Each connection is shown as a row with:
| Column | Meaning |
|--------|---------|
| **App** | The client's name as registered during authorization (e.g. Claude, ChatGPT) |
| **Site** | The site the connection can read |
| **Access** | Always **Read-only** — remote MCP connections are granted the `analytics:read` scope and can never modify anything |
| **Connected** | When you approved the connection |
| **Last used** | When the app last accessed your data |
If you have never connected an AI client, the list shows "No connected apps yet."
## Revoking access
1. Click the trash icon on the connection's row.
2. A confirmation dialog explains that the app will lose access to that site **within a minute**, and that reconnecting requires going through the authorization flow again.
3. Click **Revoke access**.
Revocation invalidates the connection's tokens on the server immediately; because access checks are cached for at most 60 seconds, the app is effectively cut off **within 60 seconds** — usually sooner. There is no way to "pause" a connection: revoke it and re-authorize later if needed.
**Tip:**
Check this screen occasionally and revoke connections you no longer use — especially after trying out a new AI tool.
## Related Documentation
- [MCP Server for AI Assistants](/integrations/mcp-server) - Setting up the Sealmetrics connector in Claude, ChatGPT, and other clients
- [Security](/platform/settings/account/security) - 2FA and browser session management
- [API Tokens](/api/api-tokens) - Personal API keys, scopes, and token management
## Channel Grouping
URL: https://docs.sealmetrics.com/platform/settings/tracking/channel-grouping
# Channel Grouping
Channel Grouping is how Sealmetrics buckets each visit into a marketing channel — **Paid Search**, **Organic Social**, **Email**, **Affiliates**, and so on — instead of showing a raw list of every `utm_source` / `utm_medium` combination. You see those channels in the **Sources → Channels** report.
Sealmetrics ships with a set of GA4-style default channels that work out of the box. When those aren't enough (a paid-social alias you use internally, a partner network, a "Brand vs Non-Brand" split for paid search…), you can define your own rules from the dashboard, via CSV, or through the MCP.
## Where to find it
1. Open **Settings** in the left sidebar (under **Site Config**).
2. Go to the **Channels** tab.
You'll see three areas:
- **Test a visit** — a live tester that classifies a `source / medium / campaign` combination exactly like the pixel would.
- **Your rules** — custom rules for this site (initially empty).
- **Default channels** — the GA4-style rules that ship with Sealmetrics. You can't edit or delete them, but you can override them (see below).
## How rules are evaluated
For every visit that comes in, the pixel checks the rules in this order:
1. **Your custom rules first**, sorted by **priority (highest first)**.
2. Then the **default channels**, also by priority.
3. The **first rule that matches wins** — its `channel_name` is stored with the hit.
4. If nothing matches, the hit is classified as **Unassigned**.
A rule matches when **all its non-empty patterns match** the incoming values. An empty pattern is a wildcard — it matches anything.
Matching is **case-insensitive** and applied to three fields:
- **Source** — usually `utm_source` (e.g. `google`, `newsletter-june`, `partnerize`).
- **Medium** — usually `utm_medium` (e.g. `cpc`, `email`, `referral`).
- **Campaign** — usually `utm_campaign` (e.g. `summer-sale`, `brand`).
Patterns are **regular expressions** in [RE2 syntax](https://github.com/google/re2/wiki/Syntax). Lookaheads, lookbehinds, and backreferences are not supported. The dashboard's rule tester uses the exact same engine as the pixel, so **if it matches in the tester, it will match in production**.
**Info:**
Channel classification happens **at ingest time**, when the visit is received. Editing, adding, or removing a rule affects **future traffic only** — historical rows keep the channel they were assigned when they came in.
New rules become live in the pixel within roughly **5 minutes** (the pixel refreshes its rule cache on that interval).
## The drafts → test → publish workflow
Every rule you create — whether from the form, CSV import, or MCP — is born as a **draft** (labeled *Not live*). The pixel only loads live rules, so **drafts never affect any traffic**. This gives you a safe space to build and validate rules before they touch your reports.
The typical flow:
1. **Create** a rule from the form (or import a CSV, or ask your MCP-connected assistant to draft one).
2. **Test** it against real visit values in the **Test a visit** panel. Toggle **"Include rules that are not live yet"** to include drafts in the evaluation.
3. When the tester returns the channel you expected, flip the **Live** switch on the rule. It's live for new traffic within ~5 min.
You can leave rules as drafts indefinitely — good for staging changes you plan to publish later.
## Using "Test a visit"
The rule tester is the single most important tool on the Channels tab. Before touching any live rule you should validate it here — the tester uses **exactly the same matching engine** as the pixel (same RE2 library, same ordering, same case-insensitive comparison), so a match in the tester is a guarantee that the pixel will match the same value in production.
### Where to find it
At the top of the **Site settings → Channels** tab, the **Test a visit** panel is always visible above the rules list. It's a small form with three inputs and a toggle.
### What to type in each field
Enter the raw values you expect the visitor's URL (or referrer) to produce. **Do not add regex** — this is not a pattern, it's a concrete test value:
- **Source** — the value that will land in `utm_source`. Examples: `google`, `newsletter-june`, `partnerize`, `(direct)`.
- **Medium** — the value that will land in `utm_medium`. Examples: `cpc`, `email`, `referrer`, `(none)`.
- **Campaign** — the value that will land in `utm_campaign`. Examples: `summer-sale-2026`, `brand`, `black-friday`. Leave empty if the campaign you want to simulate has no `utm_campaign`.
Two rules of thumb when picking test values:
- **Simulate real URLs**, not hypothetical ones. If your team never tags campaigns with `utm_source=Google` (capitalized), don't test with that value — test what the traffic actually looks like.
- **For direct traffic**, use `(direct)` for source and `(none)` for medium (that's what Sealmetrics normalizes untagged visits to, GA4-style).
- **For untagged referral traffic** (someone linked to you from a third-party site with no UTM), use `referrer` for both source and medium.
### The "Include rules that are not live yet" toggle
By default, the tester evaluates **only your live rules + the defaults** — exactly what the pixel is using right now.
Turn the toggle **on** to include **draft rules** in the evaluation. This is how you validate a rule *before* publishing it: you write the rule as a draft, turn the toggle on, and check that visits classify as expected. When the tester confirms it, you flip the Live switch on the rule.
Turn the toggle **off** again to double-check that live traffic is not being affected by an old rule you forgot about.
### Reading the result
Click **Test** and the panel shows:
- **The channel name** the visit would be assigned to (e.g., `Paid Search Brand`). If nothing matches, it shows **Unassigned**.
- **Which rule matched** — its channel name, its patterns, its priority, and whether it's a custom rule or one of the defaults. This is what tells you *why* the classification happened.
- **Whether the matched rule is live or a draft** — highlighted so you can't confuse "would happen if I published" with "is happening today".
If your rule doesn't match a value you expected it to, the fastest way to debug is:
1. Test with the toggle off — does it match a live rule you didn't expect (perhaps an old override)?
2. Test with the toggle on — does it match your new draft? If not, your pattern is wrong.
3. Look at each of your three patterns in isolation: an `AND` is only as forgiving as its strictest field.
### Six scenarios worth testing
Before publishing any change, run through the values you actually care about. A short checklist that catches most surprises:
| Scenario | Source | Medium | Campaign | What to check |
|----------|--------|--------|----------|---------------|
| Direct traffic | `(direct)` | `(none)` | *(empty)* | Falls into **Direct**. |
| Untagged referrer (external site links to you) | `referrer` | `referrer` | *(empty)* | Falls into **Referral**. |
| Your main paid-search campaign | `google` | `cpc` | your usual campaign value | Falls into your intended paid channel. |
| A campaign with a "brand" naming convention | `google` | `cpc` | `brand` | Falls into **Paid Search Brand** (or wherever your rule points). |
| A social alias your team uses | `fb` (or whatever alias) | `cpc` | *(empty)* | Falls into **Paid Social** (via your custom rule). |
| An affiliate partner | your affiliate source | *(empty)* | *(empty)* | Falls into **Affiliates**. |
If any of these classify differently than you expect, fix the rules **before** publishing — the tester is the whole point of the drafts flow.
### What the tester does not do
- **It doesn't send a real hit.** Nothing is stored in your reports; testing has no effect on data.
- **It doesn't backfill.** Even if the tester says "this visit would be Paid Search Brand", historical visits with those same UTM values keep whatever channel they had at ingest.
- **It doesn't validate business logic** (e.g., "this campaign should belong to team X") — only the classification. Naming and organizing your channels is up to you.
### Using it via the MCP
The same tester is exposed as `test_channel_rules` in the [MCP tools](#using-the-mcp), so you can ask a connected AI assistant to run scenarios in bulk. Example prompts:
- *"Test how our top 10 paid-search campaigns would classify with the current rules."*
- *"For each source/medium pair we've seen in the last week, tell me which channel it maps to."*
`test_channel_rules` is read-only — it does not create or modify anything, no matter what the assistant is prompted to do.
## Creating a rule from the form
Click **Add rule**. Fill in:
- **Channel name** — free text. If it matches an existing channel (e.g. `Paid Search`), the visit rolls up into that channel; if it's new (e.g. `Paid Search Brand`), a new channel appears in your reports.
- **Source / Medium / Campaign patterns** — leave any of them empty for a wildcard. **At least one must be filled** (a rule with all three empty would match every visit and is rejected).
- **Priority** — a number from `0` to `1000`. Only used to order your custom rules against each other. Leave it at `50` unless you need one rule to win over another.
- **Live** switch — off by default. Turn it on after testing.
Common patterns:
| Goal | Source pattern | Medium pattern | Campaign pattern | Channel name |
|------|----------------|----------------|------------------|--------------|
| Split brand campaigns from generic paid search | `^(google\|bing)$` | `^cpc$` | `brand` | Paid Search Brand |
| Map an internal alias like `fb` to Paid Social | `^fb$` | `^cpc$` | *(empty)* | Paid Social |
| Legacy `adwords/cpc` traffic | `^adwords$` | `^cpc$` | *(empty)* | Paid Search |
| Affiliate partners you use | `^(awin\|partnerize)$` | *(empty)* | *(empty)* | Affiliates |
| Internal email tools | *(empty)* | `^(crm\|internal-mail)$` | *(empty)* | Email |
## Overriding a default channel
You can't disable, edit, or delete the built-in default rules directly. Instead, Sealmetrics gives you a single, safe mechanism to redirect any default channel: the **Override** button.
### How Override actually works
Under the hood, Override is not "a special edit of the default" — it's just a **shortcut to create a custom rule with the same patterns as the default**. Because your custom rules are always evaluated **before** the defaults, that new custom rule wins the match. The default is still there; it's just never reached anymore for those values.
This has three practical consequences you should keep in mind:
- **The default is not modified.** If you delete your override later, the default automatically takes effect again. There is no "restore defaults" button — because you never actually changed them.
- **You can override with different intent**: redirect the traffic to another channel, split it into a new channel, tighten the patterns, or make it more permissive.
- **Overrides count against your 100-rule quota** just like any other custom rule.
### Step-by-step
1. Open **Site settings → Channels**.
2. Scroll to the **Default channels** table.
3. Find the default row you want to change. Click **Override**.
4. The **rule form** opens, **pre-filled** with:
- The default's `source_pattern`, `medium_pattern`, `campaign_pattern` — you don't have to figure them out.
- A copy of the default's `channel_name` — the field you'll normally change.
- Priority `50` and Live `off` — the same defaults as any new rule (born as a draft).
5. Adjust as needed:
- **To redirect the traffic to a different channel**: change `channel_name` only. Leave the patterns as they were.
- **To split the default in two**: narrow the patterns and pick a more specific `channel_name`. You can then click Override again on the same default to catch the rest under a different name (see the worked example further down).
- **To broaden a default**: loosen a pattern (e.g. add another engine to the OR list). Bear in mind you're only broadening it *for your account* — the default itself doesn't change.
6. **Test** the values you care about with the "Include rules that are not live yet" toggle **on** to confirm the classification is what you want.
7. Flip **Live** to publish. Effective in ~5 minutes.
### When to use Override vs "Add rule"
- Use **Override** when you want your rule to catch **the exact same values** as a default (or a narrower subset of them). Starting from the default's patterns is safer than typing them from scratch.
- Use **Add rule** when you want to catch **values the defaults don't cover**: an internal alias, an affiliate partner, an obscure source that currently ends up in Unassigned.
### "I want to hide a default channel from my reports"
There is no toggle to disable a default. The supported way to make a default disappear is to **override it into another existing channel**:
- Don't want an **AI** channel? Override its default(s) → change `channel_name` to `Referral` (or `Organic Search`, or whatever fits your model). Future AI traffic rolls into that channel and the "AI" name stops appearing.
- Don't want **Rejoined**-style splits? Same idea: Override → redirect into `Direct` or `Referral` depending on your interpretation.
Redirecting into an **existing** channel keeps your reports clean (no orphan channels). If you redirect into a brand-new name, that new name will show up in reports instead.
### Undoing an override
Just delete the custom rule. The default is untouched, so the moment your override is gone, matches fall through to the default rule again on new traffic (~5 min after the change).
### Common mistakes
- **Overriding a default without testing first.** The default's patterns can be more nuanced than they look (multiple values in an OR list, campaign qualifiers). Always run "Test a visit" for the values you actually care about before publishing.
- **Overriding to a name that already exists — with a typo.** `Paid search` and `Paid Search` are different channels in your reports (channel names are free text, not a fixed enum). If you want the traffic to roll into an existing channel, copy-paste the existing name.
- **Publishing an override while forgetting the priority.** The default priority `50` is normally enough. If you have multiple custom rules that could match the same values, remember that within custom rules **priority DESC wins** — a lower-priority override can be silently shadowed by a higher-priority custom rule of your own.
## Creating a rule from the form
## Import / Export (CSV)
For bulk changes or version-controlling your rules, use CSV.
### Export
Click **Export** — you get a `.csv` with all your custom rules. Defaults are not included (they can't be edited anyway).
### Import
Click **Import** and upload a `.csv` (or `.json`) file. Import is **replace-all and atomic**:
- The file becomes your **new complete set of custom rules**. Anything not in the file is removed. An empty file returns the site to defaults-only.
- If **any row is invalid**, nothing is imported (all-or-nothing) — you get a report telling you which row is wrong.
- Maximum: **100 rules per site**.
Live and draft rules can both be in the file — the `is_active` column controls it (see below).
### CSV format
The header row is mandatory. Order of columns is free, but all six must be present:
```csv
channel_name,source_pattern,medium_pattern,campaign_pattern,priority,is_active
Paid Search Brand,^(google|bing)$,^cpc$,brand,110,true
Paid Social,^fb$,^cpc$,,100,true
Affiliates,^(awin|partnerize)$,,,80,false
```
- **`channel_name`** — required.
- **`source_pattern` / `medium_pattern` / `campaign_pattern`** — RE2 regex. Empty = wildcard. At least one must be non-empty.
- **`priority`** — `0`–`1000`. Empty defaults to `50`.
- **`is_active`** — `true` or `false` (case-insensitive). Empty defaults to `true`. `false` = imported as a draft.
Excel-friendly quirks handled automatically:
- Delimiter can be `,` (standard) or `;` (Excel in Spanish/French locales).
- Quoted values follow RFC 4180 — a regex containing a comma like `^a{1,2}$` needs quoting (`"^a{1,2}$"`); Excel handles this for you when you paste.
- UTF-8 BOM and CRLF line endings are supported.
- The exported CSV includes BOM and CRLF so it opens cleanly in Excel.
## Using the MCP
If you've connected Sealmetrics to Claude, ChatGPT, or another MCP-compatible assistant, five tools are available for channel rules:
| Tool | What it does |
|------|--------------|
| `test_channel_rules` | Run the tester with any source/medium/campaign combination. Read-only. |
| `create_channel_rule` | Create a new rule **as a draft**. |
| `update_channel_rule` | Edit an existing rule — **drafts only**. |
| `delete_channel_rule` | Delete a rule — **drafts only**. |
| `import_channel_rules` | Bulk-import rules **as drafts**. Defaults to `dry_run=true` (validates without writing). |
### The draft-only invariant
To keep your live classification safe from anything an assistant might do (mistakes, prompt injection, misunderstood context), the MCP is subject to a strict invariant:
- **The MCP can never touch a live rule.** Editing or deleting is only allowed on drafts. If a rule is live, the API rejects the operation.
- **The MCP can never activate a rule.** Every rule it creates or imports is born as a draft.
- **Publishing is always a human action** — you flip the **Live** switch from the dashboard.
The worst case with the MCP is "too many drafts to review". Your live channels are never changed by an assistant.
To use the write tools, your MCP connection must have an API key with the **write** scope. Read tools (like `test_channel_rules`) work with any API key.
## Complete worked examples
Each example walks through a real scenario end-to-end: the goal, the rule, the values to test, and how to publish. Follow the same shape when you build your own.
### Example 1 — Split "Paid Search" into Brand vs Non-Brand
**Goal.** Your team runs Google/Bing paid search campaigns. You want to see brand campaigns (`utm_campaign` contains `brand`) as their own channel, separate from generic paid search.
**Rule to create** (click **Add rule**):
| Field | Value |
|-------|-------|
| Channel name | `Paid Search Brand` |
| Source pattern | `^(google\|bing)$` |
| Medium pattern | `^cpc$` |
| Campaign pattern | `brand` |
| Priority | `110` |
| Live | off (draft) |
Priority is bumped to `110` (above the default `50`) so this rule wins over any other custom rule you might add later that could also match `google/cpc`.
**Test with the tester** (toggle **"Include rules that are not live yet"** ON):
| Source | Medium | Campaign | Expected result |
|--------|--------|----------|-----------------|
| `google` | `cpc` | `brand-summer-2026` | Paid Search Brand |
| `google` | `cpc` | `nonbrand-generic-terms` | Paid Search *(default; unaffected)* |
| `bing` | `cpc` | `brand-uk` | Paid Search Brand |
| `google` | `organic` | `brand` | Organic Search *(medium doesn't match `^cpc$`)* |
If all four rows return the expected channel, flip **Live** on the rule. Wait ~5 min.
### Example 2 — Redirect the "AI" channel into "Referral"
**Goal.** You don't want the built-in AI channel in your reports; you want that traffic to appear as Referral.
**Steps:**
1. In **Default channels**, find the **AI** row. Click **Override**.
2. The form opens with the default's patterns pre-filled.
3. Change **only** the `channel_name` from `AI` to `Referral`.
4. Leave priority at `50`, leave Live off.
**Test** (toggle ON):
| Source | Medium | Campaign | Expected result |
|--------|--------|----------|-----------------|
| `chatgpt.com` | `referrer` | *(empty)* | Referral *(via your override)* |
| `perplexity.ai` | `referrer` | *(empty)* | Referral *(via your override)* |
| Any non-AI referrer | `referrer` | *(empty)* | Referral *(via the built-in Referral default — unchanged)* |
Publish. If the built-in AI default is later extended to cover more sources, your override — which uses the same pre-filled pattern — will keep matching whatever the current definition catches. If you want to freeze the behavior to the patterns *at the time of override*, that's exactly what an override does; if you'd rather track future changes, delete the override and let the default flow through again.
### Example 3 — Split a default into two custom channels
**Goal.** The default **Paid Social** covers all social networks with a paid medium. You want to split it into **Paid Social — Meta** (Facebook + Instagram) and **Paid Social — Others** (everything else).
**Steps:**
1. Click **Override** on the **Paid Social** default. The form pre-fills with the full list of social sources.
2. Narrow `source_pattern` to `^(facebook|instagram|fb|ig)$`. Set `channel_name` to `Paid Social — Meta`. Priority `110`. Save as draft.
3. Click **Override** on **Paid Social** again. This time set `channel_name` to `Paid Social — Others`. Keep the full pre-filled source list. Priority `100` (lower than Meta so Meta wins first).
You now have two draft rules. Both must be tested before publishing.
**Test:**
| Source | Medium | Campaign | Expected result |
|--------|--------|----------|-----------------|
| `facebook` | `cpc` | *(any)* | Paid Social — Meta |
| `instagram` | `paid` | *(any)* | Paid Social — Meta |
| `linkedin` | `cpc` | *(any)* | Paid Social — Others |
| `tiktok` | `paid` | *(any)* | Paid Social — Others |
Publish both. In your Sources → Channels report you'll now see the two channels instead of a single "Paid Social".
### Example 4 — Add a channel for affiliate partners
**Goal.** You work with two affiliate partners, `awin` and `partnerize`. Traffic from them currently ends up in Referral or Unassigned. You want a dedicated **Affiliates** channel.
**Rule to create:**
| Field | Value |
|-------|-------|
| Channel name | `Affiliates` |
| Source pattern | `^(awin\|partnerize)$` |
| Medium pattern | *(empty)* |
| Campaign pattern | *(empty)* |
| Priority | `50` |
| Live | off (draft) |
An empty medium/campaign is a wildcard — any `medium/campaign` from those two sources will be classified as Affiliates. That's usually what you want for affiliate traffic (each partner picks its own medium naming).
**Test:**
| Source | Medium | Campaign | Expected result |
|--------|--------|----------|-----------------|
| `awin` | `affiliate` | *(any)* | Affiliates |
| `partnerize` | *(empty)* | *(any)* | Affiliates |
| `awin` | `email` | *(any)* | Affiliates *(source wins; medium wildcard)* |
| `impact` | `affiliate` | *(any)* | Referral *(source doesn't match)* — if you also want Impact, extend the source pattern to `^(awin\|partnerize\|impact)$` |
Publish.
### Example 5 — Track a single big newsletter as its own channel
**Goal.** Your monthly newsletter drives a lot of revenue. You want to see it as its own channel (not just bucketed with generic Email).
**Prerequisite.** You have to be tagging the newsletter URLs consistently. In this example, we assume the newsletter uses `utm_source=newsletter&utm_medium=email&utm_campaign=monthly-YYYY-MM`.
**Rule to create:**
| Field | Value |
|-------|-------|
| Channel name | `Monthly Newsletter` |
| Source pattern | `^newsletter$` |
| Medium pattern | `^email$` |
| Campaign pattern | `^monthly-` |
| Priority | `120` |
| Live | off (draft) |
The campaign pattern uses `^monthly-` (anchored at the start) so any month/year suffix matches. Priority `120` ensures this wins over any other Email-related rule.
**Test:**
| Source | Medium | Campaign | Expected result |
|--------|--------|----------|-----------------|
| `newsletter` | `email` | `monthly-2026-07` | Monthly Newsletter |
| `newsletter` | `email` | `monthly-2026-08` | Monthly Newsletter |
| `newsletter` | `email` | `black-friday-launch` | Email *(default; campaign doesn't match)* |
| `mailchimp` | `email` | `monthly-2026-07` | Email *(default; source doesn't match)* |
Publish.
### Example 6 — Bulk migration via CSV import
**Goal.** You already run a Google Analytics or GA4 property with custom channel groupings and want to bring the same set into Sealmetrics.
**Steps:**
1. In **Site settings → Channels**, click **Export**. You get a CSV with your current custom rules (empty on a fresh site).
2. Open the file in Excel/Google Sheets. Add the rows you need. Set `is_active` to `false` for everything you want to review before publishing.
3. Save as CSV (UTF-8). If Excel offers "CSV UTF-8 (Comma delimited)", pick that.
4. Back in the dashboard, click **Import** and pick the file. The dashboard shows a preview.
5. Confirm the import. All rules are created as drafts (because you set `is_active=false`) and any previous custom rules are **replaced entirely** (import is replace-all).
6. Test each rule with the tester (toggle ON). When you're satisfied, flip Live on the ones you want to publish.
Example CSV content:
```csv
channel_name,source_pattern,medium_pattern,campaign_pattern,priority,is_active
Paid Search Brand,^(google|bing)$,^cpc$,brand,110,false
Paid Social — Meta,^(facebook|instagram|fb|ig)$,^(cpc|paid|paid-social)$,,110,false
Paid Social — Others,^(linkedin|twitter|x|tiktok|pinterest|snapchat|reddit)$,^(cpc|paid|paid-social)$,,100,false
Affiliates,^(awin|partnerize|impact)$,,,50,false
Monthly Newsletter,^newsletter$,^email$,^monthly-,120,false
```
After importing, your Channels tab shows five drafts. Review them in the tester and publish the ones you're happy with.
## Limits and edge cases
- **Maximum 100 custom rules per site** (drafts included).
- **Cache refresh: ~5 minutes.** After you activate or edit a rule, expect a few minutes before the pixel picks it up.
- **Not retroactive.** Historical hits keep the channel they had at ingest time. A new rule only affects new traffic.
- **Regex compile errors are surfaced immediately.** If you save an invalid pattern, the form (or import) rejects it with the exact error — you never end up with a rule that silently fails to match.
- **Rejoined / rejoined-traffic** stays in `Unassigned` by design (GA4 parity). If you want to classify it, create your own rule.
## Related
- [UTM Mapping](/platform/settings/tracking/utm-mapping) — if your team uses custom URL parameters (`campaign_id`, `source_id`…), map them to standard UTMs *before* writing channel rules. UTM Mapping runs first at ingest; channel rules then see the mapped UTMs as if they were explicit.
- [IP Exclusions](/platform/settings/tracking/ip-exclusions) — discard traffic from specific IPs (offices, QA, uptime robots) entirely, before any channel classification happens.
- [Sources report](/reports/sources) — where the channels are shown.
- [Referral vs direct traffic](/reports/insights/referral-vs-direct-traffic) — how those two default channels are decided.
- [MCP Server](/integrations/mcp-server) — how to connect an AI assistant to your Sealmetrics data.
## Bypass POS or Referrer
URL: https://docs.sealmetrics.com/platform/tracking-and-attribution-settings/bypass-pos-or-referrer
# Bypass POS or Referrer
When a user completes a purchase through a **POS (Point of Sale)** or external payment page (Stripe, PayPal, Redsys…), they temporarily leave your site.
When they return to your **thank-you page**, Sealmetrics may detect this as a new session and attribute the referrer incorrectly.
This causes conversions to appear as coming from:
❌ *payment* instead of
✔️ the original source (Google Ads, Facebook, Email, etc.)
---
## How Bypass POS / Referrer Works
You can configure Sealmetrics to **ignore specific referrers**, ensuring that once users return from a payment domain, the system keeps the original traffic source instead of overwriting it.
---
## How to Set It Up
**Info:**
Payment/POS domains are excluded by registering them as **passthrough referrers** through the **Sealmetrics API** — there is no dashboard screen for this. See the [Passthrough Referrers API reference](/api/passthrough-referrers) for the complete schema.
Register the payment domain for your account with your API key:
```bash
curl -X POST "https://my.sealmetrics.com/api/v1/passthrough-referrers?account_id=YOUR_ACCOUNT_ID" \
-H "X-API-Key: sm_your_key" \
-H "Content-Type: application/json" \
-d '{
"domain": "payments.example-psp.com",
"utm_source": "example-psp",
"service_name": "Payment Gateway"
}'
```
Repeat for each payment domain your checkout flow passes through. You can list, update, deactivate, or delete entries through the same API — see the [Passthrough Referrers API reference](/api/passthrough-referrers).
For the full concept and behavior details, see [Passthrough Referrers](/platform/tracking-and-attribution-settings/passthrough-referrers).
---
## Why This Matters
This avoids:
- Incorrect attribution to *payment*
- Lost ROAS visibility
- Broken marketing funnels
You keep the **real traffic source** intact.
---
## How to Invite a Team Member
URL: https://docs.sealmetrics.com/platform/user-management/how-to-add-new-user
# How to Invite a Team Member
Owners and Admins can invite new members to the organization at any time.
## Steps
1. In the sidebar, open the **Organization** group and click **Members**
2. Click **Invite Member**
3. Enter the person's email address
4. Choose their organization role:
- **Admin** -- manage members and all sites, no billing
- **Member** -- access only to assigned sites
5. If you selected **Member**, select at least one site they should have access to (this is required)
6. Click **Send Invitation**
To make someone an Owner, invite them as Admin or Member first, then promote them from the Members list (only an existing Owner can do this).
The person will receive an email with a link to accept the invitation. If they do not have a Sealmetrics account yet, they will be asked to create one.
---
## What happens next
- The invitation expires after **7 days**. You can resend it from the Members page.
- Once the invitation is accepted, the new member gains access immediately.
- You can change their role or site assignments at any time from the Members page.
---
For a full breakdown of what each role can do, see [Roles & Permissions](./roles-management).
## How to Change Your Time Zone
URL: https://docs.sealmetrics.com/platform/account-setup/how-to-change-timezone
# How to Change Your Time Zone
The timezone determines how dates and times are calculated in your reports.
## Steps
1. In the left sidebar, expand **Site Config** and click **Settings** (`/settings/sites/{siteId}`).
2. Stay on the **General** tab and find the **Timezone** field.
3. Open the timezone selector and pick your timezone (you can search by name or country).
4. Click **Save Changes** to apply the change.
---
By default, new sites use **Europe/Madrid**. The timezone selector lets you search by timezone name or country to find the right one quickly.
## LLM Providers
URL: https://docs.sealmetrics.com/platform/settings/llm
# LLM Providers
Configure which AI model powers the **Lens chat** assistant. Two kinds of provider are available:
- **Seal AI Private** — Sealmetrics' managed provider. Runs entirely in the EU (Paris), no prompt retention, **no API key needed**. Subject to plan entitlement and a monthly token quota — see [Seal AI Private](/billing/seal-ai-private).
- **Bring-your-own-key (BYOK)** — you add your own API key for Anthropic, OpenAI, Gemini, or DeepSeek Cloud. Per-user: your configuration is used across every site you have access to. **Free from Sealmetrics** — unmetered, with no add-on fee; you pay only your own provider.
**Info:**
Your LLM Providers configuration belongs to **you**, not to a site or organization. The same key is applied to every site you can access, and **only you can see or modify it**. There is no per-account dropdown — other users configure their own keys independently.
## Accessing LLM Providers
In the sidebar, open **My Account → LLM Providers** (`/account/llm`).
**Note:**
**LLM Providers** (My Account) controls which AI model the Lens chat uses, per user.
**LENS Settings** (at `/settings/lens`) is a separate, per-site setting that controls the automated insights analysis frequency (daily / weekly / manual) and email notifications. Don't confuse the two.
## Available Providers
| Provider | API Key Required | Notes |
|----------|------------------|-------|
| **Seal AI (Private, EU)** | **No** | Managed by Sealmetrics; plan entitlement + 5M tokens/month quota |
| **Anthropic (Claude)** | Yes | BYOK |
| **OpenAI (GPT)** | Yes | BYOK |
| **DeepSeek Cloud** | Yes | BYOK; optional custom base URL |
| **Google (Gemini)** | Yes | BYOK |
The self-hosted DeepSeek Local model used by shared infrastructure is **not** available here for the chat.
### Seal AI Private
When available on your plan, the **Seal AI (Private, EU)** card appears first, marked **Default**. Its card shows the **Monthly token quota** gauge with the percentage used this month and a **View usage** link to the [Seal AI Usage screen](/platform/settings/seal-ai-usage). If your plan doesn't include it, the card shows an upgrade badge instead — see [availability by plan](/billing/seal-ai-private#availability-by-plan).
## Adding a Provider
### Step 1: Open the form
If you have no providers configured yet, the **Configure LLM Provider** form appears automatically. Otherwise, click **Add Provider**.
### Step 2: Select a provider
Choose a provider from the dropdown. Each provider shows a short description and a link to obtain an API key. The provider can't be changed after a configuration is created — to switch providers, add a new one or remove the existing one.
### Step 3: Enter your API key (BYOK providers)
Every BYOK provider requires an API key — Seal AI does not. Paste it into the **API Key** field (use the eye toggle to reveal it). Your key is encrypted before storage and only the last 4 characters are ever shown afterwards (`****XXXX`).
For **DeepSeek Cloud**, you can optionally set a custom **Base URL** (defaults to `https://api.deepseek.com/v1`).
### Step 4: Configure model overrides (optional)
You can override the default model used at three complexity levels. Leave a field blank to use the provider's default.
| Level | Anthropic default | OpenAI default | Gemini default | DeepSeek Cloud default |
|-------|-------------------|----------------|----------------|------------------------|
| **Simple** | `claude-3-5-haiku-20241022` | `gpt-4o-mini` | `gemini-2.5-flash` | `deepseek-chat` |
| **Complex** | `claude-sonnet-4-20250514` | `gpt-4o` | `gemini-2.5-flash` | `deepseek-chat` |
| **Critical** | `claude-opus-4-20250514` | `gpt-4o` | `gemini-2.5-pro` | `deepseek-chat` |
Use **Reset to defaults** to clear all overrides.
### Step 5: Test the connection
Click **Test Connection** to verify the key and provider are reachable before saving. A successful test shows a "Connection Successful" message with the response latency in milliseconds.
### Step 6: Save
Click **Save Settings** to store the configuration.
## Managing Your Configurations
Each configured provider appears as a card showing:
- Provider name and whether it's the default
- API key status (`****XXXX` when configured)
- Enabled / disabled status
- Any model overrides
- Last updated timestamp
From a card you can:
- **Set as Default** — make this provider the one Lens chat uses (only one default at a time)
- **Edit** — update the API key, model overrides, base URL, or enabled status
- **Remove** — delete the configuration (if it was the default, another configured provider becomes the default)
### Enable / disable
Use the **Enable Configuration** toggle when editing a provider. When a configuration is disabled, that provider can't be used by Lens chat, but the saved key is kept so you can re-enable it later.
## Security
### API Key Storage
- API keys are encrypted at rest before storage
- Only the last 4 characters are displayed (`****XXXX`)
- Keys are never returned in API responses or logged
### Data Privacy
When you use a cloud provider, aggregated analytics data (not raw events, no personally identifiable information) is sent to that provider to generate chat responses. Because this is BYOK, the data is processed under your own provider account and API key.
## Troubleshooting
### "Connection Failed" on test
1. Verify your API key is correct and active
2. Check the provider's status page for outages
3. Ensure your network allows outbound API calls
4. Try a different provider
### "API key is required" when saving
Every provider here requires a key. Get one from:
- **Anthropic**: https://docs.anthropic.com/
- **OpenAI**: https://platform.openai.com/docs
- **Google (Gemini)**: https://ai.google.dev/docs
- **DeepSeek**: https://platform.deepseek.com/
## Related Documentation
- [Seal AI Private](/billing/seal-ai-private) - Pricing, quota, and plan availability of the managed provider
- [Seal AI Usage screen](/platform/settings/seal-ai-usage) - Token consumption dashboard
- [LENS AI Overview](/lens) - How LENS generates insights
- [AI Assistant](/lens/ai-assistant) - Using the Lens chat interface
- [Anomaly Detection](/lens/anomaly-detection) - Automated alerts
## UTM Mapping
URL: https://docs.sealmetrics.com/platform/settings/tracking/utm-mapping
# UTM Mapping
UTM Mapping tells Sealmetrics: *"when you see this parameter in the URL, treat it as if it were this standard UTM."*
If your team uses custom names like `campaign_id`, `source_id`, `medium_id` or anything else specific to your CRM, ESP or ad platform, UTM Mapping lets you feed those values into Sealmetrics's attribution without having to change how your links are tagged. The visit is classified — including channel grouping, campaign reporting, and source/medium breakdowns — as if the URL had used the standard UTMs directly.
## When to use it
Turn to UTM Mapping when any of the following is true for your setup:
- Your marketing tool (an ESP, an ad platform, an in-house CRM) emits its own parameter names — e.g. `?campaign_id=summer-sale` — and you don't want to (or can't) rewrite every link to use `?utm_campaign=…`.
- You've inherited a legacy naming convention that predates GA4 UTMs and rewriting all links is not realistic.
- A specific vendor appends its own parameter automatically (many affiliate networks, some CMSes) and you want that captured as attribution data.
If your links already carry proper `utm_source` / `utm_medium` / `utm_campaign`, you don't need UTM Mapping.
## Where to find it
1. Open **Settings** in the left sidebar (under **Site Config**).
2. Go to the **UTM Mappings** tab.
You'll see:
- A small form to add a mapping (custom parameter name + target UTM).
- A list of the mappings currently active for this site.
- A blue-highlighted note: *"Mappings take effect within ~5 minutes and apply to future traffic only."*
## How it works
For every visit that comes in, Sealmetrics parses the URL query string and then applies your mappings **before** classifying the visit. Concretely: if you have a mapping `campaign_id → utm_campaign` and a visit arrives with `?campaign_id=black-friday`, the pixel treats the visit as if it had `?utm_campaign=black-friday` — including for channel grouping, source/medium reports, and everything downstream.
The mapping runs **at ingest time**. It doesn't rewrite the URL your visitor saw; it just enriches the internal representation Sealmetrics uses for attribution.
### The rules
Five rules define exactly what happens, and they're worth internalizing:
1. **Explicit UTMs always win.** If the URL already carries a non-empty value for the target UTM, the mapping is skipped. A mapping never overwrites a value your team put in explicitly. Example: with `campaign_id → utm_campaign`, a URL like `?campaign_id=X&utm_campaign=Y` classifies with `utm_campaign=Y`. The explicit `Y` wins.
2. **Copy, not move.** The custom parameter isn't removed from the URL — it's copied into the target UTM. Both values coexist internally. This matters for custom properties or downstream logic that might still look at the original param.
3. **Empty or missing = no-op.** If the custom parameter is absent from the URL or its value is empty (`?campaign_id=`), the mapping does nothing. Empty values never "clear" a UTM.
4. **Self-mappings are ignored.** A mapping like `utm_source → utm_source` is silently skipped — it has no meaningful effect.
5. **First-created wins on ties.** If you configure two custom parameters mapping to the same UTM (e.g. `campaign_id → utm_campaign` and `campaign_code → utm_campaign`), and a visit carries both, the mapping created earlier wins. The evaluation order is deterministic across every visit — you'll never see one visit resolve one way and another visit resolve differently.
### How fast do changes take effect?
Roughly **5 minutes** after adding or removing a mapping, for new traffic. That's the interval at which the pixel refreshes its per-account cache.
**Changes are not retroactive.** Visits that came in before your mapping was live keep whatever UTMs they had at ingest. UTM Mapping is a forward-looking configuration, not a data migration.
## Adding a mapping
In the **UTM Mappings** tab:
1. Type the **custom parameter name** exactly as it appears in your URLs (case-sensitive: `Campaign_ID` and `campaign_id` are different). Do **not** include the `?` or `=`.
2. Pick the **target UTM** from the dropdown:
- **Source** (`utm_source`)
- **Medium** (`utm_medium`)
- **Campaign** (`utm_campaign`)
- **Term** (`utm_term`)
- **Content** (`utm_content`)
3. Click **Add**. The mapping is active within ~5 min.
You can only map to **one of those five standard UTMs**. Sealmetrics doesn't let you invent new attribution fields via UTM Mapping — for grouping the values into custom channels, use [Channel Grouping](/platform/settings/tracking/channel-grouping) instead.
Each custom parameter name can only map to **one** target UTM per site (attempting to add a second mapping for the same custom name is prevented by the API).
## Removing a mapping
Click **Remove** next to the mapping you want to delete and confirm. As with any change, effective in ~5 min, non-retroactive. Historical visits classified through that mapping keep their existing UTMs.
## How UTM Mapping interacts with Channel Grouping
UTM Mapping and [Channel Grouping](/platform/settings/tracking/channel-grouping) are two features that compose. Understanding the order matters:
```
URL arrives → UTMs extracted → Your UTM Mappings applied
→ Channel rules evaluated (custom → default)
→ Channel assigned to the visit
```
The mapping runs **first**. By the time your channel rules see the visit, the mapped UTMs look identical to explicit ones. This means:
- Your channel rules can (and should) be written against the **standard UTM values**, never against your custom parameter names. Once mapping is in place, you never need to reference `campaign_id` in a channel-grouping rule — you write the rule against `utm_campaign` and it just works.
- Deleting a UTM Mapping while relying on it in a channel rule will "un-classify" future traffic: the channel rule keeps looking at `utm_campaign`, but nothing populates it anymore. Test in the **Test a visit** tester before removing a mapping.
## Common use cases
### Use case 1 — ESP with its own naming convention
Your email service provider tags every link as `?email_campaign=…&email_source=…&email_content=…`. You want that traffic to appear as Email in your Channels report and to break down properly by campaign and creative.
Mappings to add:
| Custom parameter | Maps to |
|------------------|---------|
| `email_campaign` | Campaign (`utm_campaign`) |
| `email_source` | Source (`utm_source`) |
| `email_content` | Content (`utm_content`) |
Once live, an email link like `?email_source=mailchimp&email_campaign=black-friday-2026&email_content=cta-top` classifies as Email (the medium default catches Mailchimp) with the campaign and content populated.
### Use case 2 — Ad platform with a proprietary click ID as source
Your ad platform appends `?ad_source=my_platform&ad_medium=display` on every click. You want to see it as its own channel.
Mappings:
| Custom parameter | Maps to |
|------------------|---------|
| `ad_source` | Source (`utm_source`) |
| `ad_medium` | Medium (`utm_medium`) |
If `my_platform / display` doesn't fall into any built-in channel, you can then create a custom channel rule matching `source=^my_platform$` under [Channel Grouping](/platform/settings/tracking/channel-grouping).
### Use case 3 — Legacy `campaign_id` from a migrated CMS
You migrated from an older platform that tagged links as `?campaign_id=…` and there's too much historical marketing content to rewrite.
| Custom parameter | Maps to |
|------------------|---------|
| `campaign_id` | Campaign (`utm_campaign`) |
New links can start using `utm_campaign` directly — since **explicit UTMs win**, both formats coexist safely during the transition.
## Limitations
- **The target must be one of the 5 standard UTMs.** You can't map to arbitrary field names via UTM Mapping. For business-specific grouping (Brand vs Non-Brand, per-partner affiliate channels…), see [Channel Grouping](/platform/settings/tracking/channel-grouping).
- **No value transformation.** UTM Mapping is a rename, not a rewrite: it copies the value as-is. If you need to normalize values (e.g. lowercase them, map `fb` to `facebook`), do it at the campaign-tagging step or use [Channel Grouping](/platform/settings/tracking/channel-grouping) to bucket the raw values into a canonical channel.
- **Case-sensitive on the custom parameter name.** `Campaign_ID` and `campaign_id` are different parameters. Match your team's actual tagging.
- **Not editable via MCP.** UTM Mapping is configured only from the dashboard UI — there are no MCP tools for it.
- **Not retroactive.** Only future traffic uses the mapping.
## Related
- [Channel Grouping](/platform/settings/tracking/channel-grouping) — after your custom params are mapped to UTMs, group them into marketing channels.
- [IP Exclusions](/platform/settings/tracking/ip-exclusions) — discard internal traffic (offices, QA, uptime robots) entirely so it never reaches attribution.
- [Sources report](/reports/sources) — where the mapped UTMs show up.
- [How to change UTM parameters](/reports/insights/how-to-change-utm-parameters) — background on UTM tagging in general.
## Preserve Attribution Through External Login or SSO Flows
URL: https://docs.sealmetrics.com/platform/tracking-and-attribution-settings/external-auth-sso-attribution
# Preserve Attribution Through External Login or SSO Flows
Many products use an external authentication domain for signup or login — an identity provider, an SSO service, or a shared accounts domain owned by the parent company.
A typical journey looks like this:
```
www.yourproduct.com → user discovers your site (SEO, Paid, Direct…)
accounts.yourcompany.com → user signs up or logs in (external auth domain)
app.yourproduct.com → user lands in the app and converts
```
Without configuration, the conversion in `app.yourproduct.com` may be attributed to **Referral** (`accounts.yourcompany.com`) instead of the real acquisition source.
This guide explains why this happens and how to fix it.
---
## Why the Source Becomes "Referral"
SealMetrics counts a new **entrance** when the referrer is empty or comes from a domain different from your own.
- `www.yourproduct.com` → `app.yourproduct.com` is **cross-subdomain navigation** of the same root domain. It is treated as internal navigation — session and attribution are preserved. See [Referral vs Direct Traffic](/reports/insights/referral-vs-direct-traffic).
- `accounts.yourcompany.com` → `app.yourproduct.com` is a **cross-domain jump**. The auth domain becomes the referrer, SealMetrics detects a new entrance, and the original source (SEO, Paid, Email…) is overwritten by **Referral**.
The problem is never the subdomain change — it is the external domain in the middle of the journey.
---
## The Fix: Register the Auth Domain as a Passthrough Referrer
**Info:**
Passthrough referrers are currently managed through the **Sealmetrics API**, not from a dashboard screen. See the [Passthrough Referrers API reference](/api/passthrough-referrers) for the complete schema.
Register the external authentication domain (e.g. `accounts.yourcompany.com`) as a passthrough referrer for your account:
```bash
curl -X POST "https://my.sealmetrics.com/api/v1/passthrough-referrers?account_id=YOUR_ACCOUNT_ID" \
-H "X-API-Key: sm_your_key" \
-H "Content-Type: application/json" \
-d '{
"domain": "accounts.yourcompany.com",
"utm_source": "sso",
"service_name": "Company SSO"
}'
```
Add every external domain in the journey the same way. Entries can be listed, updated, and deleted through the same API — see the [Passthrough Referrers API reference](/api/passthrough-referrers).
Once excluded, SealMetrics ignores that domain as a referrer. When the user returns from the auth flow, the original session source remains active, and the conversion inherits the real acquisition channel.
This is the same mechanism used to [avoid conversions attributed to payment gateways](/platform/tracking-and-attribution-settings/bypass-pos-or-referrer).
---
## Checklist for Multi-Subdomain Setups
To attribute conversions correctly when acquisition happens on your public website and conversion happens in your app:
1. **Same Account ID everywhere** — install the same SealMetrics pixel on the public site (`www.`) and the app (`app.`). See the [SaaS implementation guide](/use-cases/saas).
2. **Exclude external auth domains** — register every third-party domain in the journey (SSO, identity provider, payment gateway) as a [passthrough referrer](/api/passthrough-referrers).
3. **Differentiate areas with content grouping** — use `group=marketing`, `group=app`, etc., to keep reports readable. See [Content Grouping](/platform/settings/tracking/content-grouping).
4. **Track signup as a conversion** — fire the conversion on the post-signup page (e.g. email verification completed) so it inherits the session source.
---
## Timing Considerations
- **2-hour session window** — the origin of the visit stays active for 2 hours, which covers virtually all signup flows, including email verification steps. See [Attribution Accuracy](/reports/insights/attribution-accuracy).
- **6+ hour gaps** — if the user completes signup more than 6 hours later (e.g. opens the verification email the next day), the visit is classified as [Rejoined Traffic](/reports/insights/rejoined-traffic) instead of inflating Direct.
---
## Result
With the auth domain excluded and the same pixel across all subdomains:
✔ The session started on the public website keeps its original source
✔ The signup conversion in the app is attributed to SEO, Paid, Direct… — the real acquisition channel
❌ No more conversions miscategorized as Referral from your own auth domain
## Access Restricted to Authorized IPs
URL: https://docs.sealmetrics.com/platform/user-management/authorized-ips
# Access Restricted to Authorized IPs
Sealmetrics allows you to restrict platform access by IP address for maximum account security.
This feature is ideal for organizations requiring strict access control.
---
## How It Works
The IP allowlist is configured **per site**. When it is enabled, only users whose login originates from an allowed IP can access that site. Access to the user's other sites is not affected.
Benefits:
- **Full access control**: Only trusted networks can access the site.
- **Protection from unauthorized access**.
- **Extra security layer** on top of username + password.
The restriction is applied at login time for all users with access to the site, and can also be enforced for API tokens.
---
## Who Can Use This Feature?
The IP allowlist is an **Enterprise** plan feature.
---
## How to Set It Up
1. In the sidebar, open the **Site Config** group and click **Settings**
2. Open the **IP Allowlist** tab
3. Add the IP patterns that should be allowed (see below)
4. Turn on the **Enable IP Allowlist** toggle
**Warning:**
### Pattern Types
When adding an entry you choose a pattern type and, optionally, a label:
| Type | Description | Example |
|------|-------------|---------|
| **IP Address** | A single IP address | `192.168.1.100` |
| **CIDR Range** | An IP range in CIDR notation | `192.168.1.0/24` |
| **Regex** | A regular expression pattern | `^192\.168\..*` |
---
Using IP restrictions is one of the strongest ways to protect sensitive analytics data.
## Seal AI Usage
URL: https://docs.sealmetrics.com/platform/settings/seal-ai-usage
# Seal AI Usage
The **Seal AI Usage** screen shows your organization's monthly [Seal AI Private](/billing/seal-ai-private) token consumption and is where owners buy extra token packs.
## Accessing the screen
In the sidebar, open **Organization → Seal AI Usage** (`/settings/seal-ai-usage`).
**Info:**
The screen is visible to the organization **owner** and **admins**. Members don't see the menu entry (they still see the aggregate quota ring in the chat). Purchase and cancellation actions are **owner-only** — admins see the screen read-only.
## What you'll see
- **Monthly gauge** — tokens used vs. your effective quota (the 5M monthly allowance plus any pack balance), the percentage used, and the quota reset date (the 1st of the next month, UTC).
- **Month selector** — switch between recent months.
- **Plan badge** — how your org is entitled (e.g. included in Scale, active add-on, or grandfathered access with its end date).
- **Daily chart** — input vs. output tokens per day (UTC).
- **Pack balance and purchase history** — packs bought, their price, and remaining pack tokens (pack tokens never expire and are consumed only after the monthly 5M).
- **Breakdown by site and by user** — where the tokens went. User rows show names, never emails; automated LENS insight runs appear as "LENS (automated)".
## Buying token packs
Owners can buy **5M-token packs** (€358.80 each, 1–10 per checkout) directly from this screen via Stripe checkout. The new balance is reflected as soon as the payment completes, and a confirmation email is sent. See [Seal AI Private — token packs](/billing/seal-ai-private#extra-token-packs).
## States you may encounter
| State | What it means |
|-------|---------------|
| "Not available on Free" | Seal AI Private requires Growth (add-on) or Scale/Enterprise — the screen shows upgrade options |
| Activation card with pricing | Your org is not yet entitled: the owner can activate the add-on (€299/mo billed annually · €358.80/mo monthly) |
| Grandfathering banner | Your org has temporary access; the banner shows the end date |
| "Token limit reached" in chat | Quota + packs exhausted: owner sees a purchase CTA, members see "contact your admin"; anyone can switch the chat to their own key ([BYOK](/platform/settings/llm)) |
## Email alerts
The organization receives an email when monthly consumption crosses **80%** and **100%** of the effective quota (once per month each), and a confirmation email on each pack purchase.
## Related documentation
- [Seal AI Private](/billing/seal-ai-private) — pricing, quota model, and plan availability
- [LLM Providers](/platform/settings/llm) — choosing Seal AI vs. your own key
- [Organizations API — Seal AI usage](/api/organizations#seal-ai-usage) — the same data via API
## IP Exclusions
URL: https://docs.sealmetrics.com/platform/settings/tracking/ip-exclusions
# IP Exclusions
IP Exclusions let you tell Sealmetrics to **ignore** traffic coming from IP addresses or ranges you control. Visits from your offices, QA environments, uptime monitors and internal tools are the classic case: they inflate every metric and skew every conversion rate, and they belong nowhere in your reports.
Once an IP is excluded, hits from that IP are **discarded entirely at the edge**. They don't get tagged as "internal", they don't appear in a hidden segment, they don't affect any total, any breakdown, any cohort. They simply never enter your data.
## When to use it
Add an IP exclusion whenever:
- Your team browses the site frequently — from the office, from home, from staging environments. Their sessions and conversions are noise, not signal.
- A monitoring or uptime tool hits your pages on a schedule. Its traffic is predictable, non-human, and pollutes bounce rate and engagement metrics.
- QA or automation runs synthetic journeys through the checkout on every deploy. Those runs generate fake conversions that skew revenue.
If you can identify the traffic by IP or CIDR, you can exclude it here.
## Where to find it
1. Open **Settings** in the left sidebar (under **Site Config**).
2. Go to the **IP Exclusions** tab.
You'll see:
- A form to add an entry: one input for the IP or CIDR, one for an optional reason, plus an **Add my current IP** shortcut.
- A list of the entries currently configured for this site.
- An amber note reminding you that excluded traffic is discarded entirely and that changes take effect within ~5 minutes.
## Important: IP Exclusions vs IP Allowlist
These are two different features. Don't confuse them:
| Feature | What it controls | Who it affects |
|---------|------------------|----------------|
| **IP Exclusions** *(this page)* | Which visits get **tracked** on your site | Every visitor whose IP matches — internal or external |
| **IP Allowlist** | Which IPs can **access the dashboard** | Only your team's IPs; nothing to do with tracking |
If your goal is *"keep our office traffic out of the reports"*, this is the right tab. If your goal is *"only let our office IPs log in to the dashboard"*, that's the **IP Allowlist** tab next to this one.
## What "excluded" actually means
When a visit arrives from an excluded IP:
- The pixel returns a **204 No Content** and **discards the hit before enqueuing it**. No message is published to the internal queue, no row lands in ClickHouse, no ID is generated.
- **Nothing about the visit is stored** — no page view, no conversion, no session, no location, nothing. The visit is invisible to every part of Sealmetrics.
- The visitor's browser is unaffected: they still see your website normally, ads still fire, your other analytics tools (if any) still capture them.
Because the discard is total, **you can't "un-exclude" past traffic**. Removing an IP from the list doesn't recover historical hits — it only affects future traffic.
## Adding an IP or CIDR
In the **IP Exclusions** tab:
1. Type the **IP or CIDR range** you want to exclude in the first field. Examples:
- `203.0.113.7` — a single IPv4 address (your office router's public IP).
- `198.51.100.0/24` — a /24 IPv4 block (256 addresses).
- `10.0.0.0/8` — a large private IPv4 block.
- `2001:db8::1` — a single IPv6 address.
- `2001:db8::/48` — an IPv6 block.
2. **Optional: add a reason** in the second field (e.g. `Office London`, `QA runs`, `Uptime robot`). The dashboard suggests **Office**, **QA** and **Internal** as one-click options. Reasons are for your own bookkeeping — they don't affect behavior.
3. Click **Add**. The entry is active for **future traffic within ~5 minutes** (the pixel refreshes its per-site cache on that interval).
If you're at the machine you want to exclude right now, click **Add my current IP** — Sealmetrics detects your public IP (via a first-party endpoint, no third-party service involved) and pre-fills the input. This is the fastest way to exclude your own browsing from the reports.
### The "broad range" warning
If you enter a CIDR that covers a lot of the internet — smaller than `/16` for IPv4 or `/32` for IPv6 — the dashboard shows an amber warning before you save. It doesn't block the save, but it wants your attention: broad ranges are easy to type by accident (`10.0.0.0/8` = 16.7M addresses, `0.0.0.0/0` = everything). Confirm the range is really what you meant.
## Managing entries
Each entry in the list has two controls:
- **Active toggle.** Turn an entry **off** to temporarily stop it from filtering traffic (e.g. during a specific test where you *do* want to be counted). It stays in your list and can be toggled back on later. Changes take effect within ~5 minutes.
- **Delete (trash icon).** Removes the entry permanently. Ask for confirmation. Effective in ~5 minutes.
You can toggle and delete entries at any time. There's no daily/monthly limit on changes.
## Limits
- **100 entries per site.** This is a hard limit. If you need more, you're likely using individual IPs where a CIDR range would work better — a `/24` covers a full office subnet in one entry.
- **IPv4 and IPv6 both supported.** The format is standard CIDR notation. No workaround needed for either.
- **Not retroactive.** Excluding an IP does not remove historical traffic from that IP. Past data stays as it is.
- **Not tagged, just discarded.** Excluded traffic has no representation in reports — it's not "internal traffic" you can view separately. It doesn't exist.
## Common patterns
### Pattern 1 — Exclude your office
Ask your IT team for the office's public egress IP (or IPs, if you have multiple ISPs / load-balanced connections). Add each as a separate entry with reason **Office**.
If the office has a static /29 or /28 block, add the whole CIDR in one entry.
### Pattern 2 — Exclude your team's home offices
Get each team member's home public IP (they can check it from any "what's my IP" search). Add them individually. Warn the team that if their ISP rotates their IP, they'll need to update the entry.
For remote teams working from ISPs with rotating IPs, IP exclusion isn't the best solution — consider tagging your internal test traffic with a query parameter and setting up a channel-grouping rule to route it to a distinct channel instead.
### Pattern 3 — Exclude staging / QA environments
If QA scripts run from a known set of servers, add each server's public IP. Reason: **QA**.
Better yet, if your CI runners share a NAT gateway, add the gateway's IP once as a `/32` and cover them all.
### Pattern 4 — Exclude uptime monitoring
Uptime robots hit your site on a schedule from published IP lists. Take that vendor's IP list and add each range. Reason: **Uptime monitoring**.
If the vendor uses many IPs, prefer CIDR ranges over individual IPs — you'll blow through the 100-entry limit fast otherwise.
## What IP Exclusions do NOT do
- **They do not identify who a visitor is.** Excluding an IP only filters that IP; it doesn't tell Sealmetrics who's behind it. If your CEO connects from a coffee shop, their traffic will be counted.
- **They do not "hide" traffic in a segment.** Excluded traffic simply isn't stored. There's no way to view it later.
- **They do not restrict dashboard access.** For that, see the [IP Allowlist tab](#important-ip-exclusions-vs-ip-allowlist) next to this one.
- **They don't work across sites.** Exclusions are per-site. If you own multiple sites, you have to configure them on each one.
## Privacy note
Sealmetrics doesn't store visitor IPs in the database. IP Exclusions is the only place the pixel checks the incoming IP in memory — to decide whether to accept the hit or discard it. Either way, the IP is not persisted anywhere in your reports or in the underlying event stream. See [Security & Privacy](/security-privacy) for the full picture.
## Related
- [Channel Grouping](/platform/settings/tracking/channel-grouping) — if you'd rather **tag** internal traffic (e.g. from a shared cloud IP) into a distinct channel instead of discarding it entirely.
- [UTM Mapping](/platform/settings/tracking/utm-mapping) — map your own URL parameters to standard UTMs.
- [Security & Privacy](/security-privacy) — how Sealmetrics handles IPs and other visitor data.
---
# Plans & Billing
## Plans & Pricing
URL: https://docs.sealmetrics.com/billing
# Plans & Pricing
Sealmetrics offers three volume-based plans designed to scale with your business needs. All plans include unlimited websites, unlimited users, privacy-first tracking, attribution modeling, and core reporting features.
## Plan Comparison
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| **Monthly Price** | €599 | €1,079 | Custom |
| **Annual Price (per month)** | €499 | €899 | Custom |
| **Monthly Events** | 5M | 15M | Unlimited |
### Core Features (All Plans)
All plans include:
- Unlimited websites
- Unlimited users
- 24 months data retention
- Full API access
- MCP Server
- BigQuery export
- CSV/JSON export
- LENS AI (Chat + Reports) — rule-based Insights coming soon
- Conversion tracking
- Funnel analysis
- Bot detection & fraud protection
- Consentless tracking
- Real-time data — hits normally in reports in under 2 min; the SLA guarantees each day complete before 6 AM
- Email reports & alerts
- Multi-site portfolio view
- Agent AI Analytics — coming soon (when live, AI agents are tracked and never billed)
### Plan Differences
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Monthly events | 5M | 15M | Unlimited |
| LENS AI assistant (your own LLM key) | Included | Included | Included |
| [Seal AI Private](/billing/seal-ai-private) (managed, EU) | Add-on | Included | Included |
| Webhooks | - | Yes | Yes |
| Audit logs | - | Yes | Yes |
| Role-based access | Basic | Advanced | Full |
| Uptime SLA | 99% | 99.5% | 99.9% |
| Support | Email | Email + Chat + Priority | Priority + Dedicated AM |
| Onboarding | Docs | 1 session | White-glove |
## Choosing the Right Plan
### Growth (€599/month, €499 annual)
**Best for:** Growing teams and mid-size e-commerce businesses
Choose Growth if you:
- Have up to 5M monthly events
- Need BigQuery integration for custom analysis
- Want full API access and MCP Server
- Need all core analytics and reporting features
### Scale (€1,079/month, €899 annual)
**Best for:** Multi-brand retailers and larger organizations
Choose Scale if you:
- Have up to 15M monthly events
- Need webhooks and audit logs
- Require advanced role-based access control
- Need priority support
### Enterprise (Custom pricing)
**Best for:** Large organizations with custom needs
Choose Enterprise if you:
- Need unlimited events
- Want a dedicated account manager
- Need isolated data processing
- Require 99.9% SLA guarantee
## Event Limits & Upgrades
Sealmetrics uses a **no overage** billing model:
- **No surprise charges** — your monthly price is fixed
- **Tracking never stops** — if you exceed your event limit, data collection continues
- **Free overage month** — one month per year of overage is absorbed at no extra cost
- **Auto-upgrade** — if you exceed your event limit for 2 consecutive months (without forgiveness), Growth is automatically upgraded to Scale. When a Scale plan exceeds its limit for 2 consecutive months, we notify you to discuss Enterprise — this change is not automatic
- **Downgrade suggestions** — if your usage drops below 50% for 3+ months, we'll suggest a more suitable plan
**Tip:**
## Getting Started
## Frequently Asked Questions
### Can I change plans?
Yes, you can upgrade or downgrade at any time. Changes take effect immediately:
- **Upgrades:** Prorated charge for remaining billing period
- **Downgrades:** Credit applied to future invoices
### Is there a free trial?
Yes, all plans include a 14-day free trial with full features. You enter a payment method when you start, but you're not charged until the trial ends — cancel before then and you pay nothing.
### What happens if I exceed my event limit?
Tracking continues without interruption. There are no overage charges — your monthly price stays fixed. If you exceed your limit for 2 consecutive months, Growth is automatically upgraded to Scale. For Scale, we notify you to discuss Enterprise instead — the move is not automatic.
### Do you offer discounts?
- **Annual billing:** Save approximately 17% compared to monthly (2 months free)
- **Nonprofits:** 50% discount (contact us)
- **Startups:** Special pricing available (contact us)
### Can I cancel anytime?
Yes, cancel anytime with no penalties. You'll retain access until the end of your billing period.
---
## More Information
- [Growth Plan Details](/billing/plans/growth)
- [Scale Plan Details](/billing/plans/scale)
- [Enterprise Plan Details](/billing/plans/enterprise)
- [Features Comparison](/billing/features-comparison)
- [Usage & Limits](/billing/usage-limits)
## Features Comparison
URL: https://docs.sealmetrics.com/billing/features-comparison
# Features Comparison
Complete feature-by-feature comparison across all Sealmetrics plans. All plans use volume-based pricing with unlimited websites and unlimited users.
## Quick Comparison
| | Growth | Scale | Enterprise |
|---|:---:|:---:|:---:|
| **Monthly Price** | €599 | €1,079 | Custom |
| **Annual (per month)** | €499 | €899 | Custom |
| **Monthly Events** | 5M | 15M | Unlimited |
| **Websites** | Unlimited | Unlimited | Unlimited |
---
## Events & Data
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Monthly events | 5M | 15M | Unlimited |
| Websites | Unlimited | Unlimited | Unlimited |
| Users | Unlimited | Unlimited | Unlimited |
| Data retention | 24 months | 24 months | 24 months |
| Overage charges | None | None | None |
---
## Tracking & Collection
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| First-party tracking | Yes | Yes | Yes |
| Cookie-free tracking | Yes | Yes | Yes |
| Consentless operation | Yes | Yes | Yes |
| Bot filtering | Yes | Yes | Yes |
| Agent AI Analytics | Coming soon | Coming soon | Coming soon |
| Real-time data (typically < 2 min) | Yes | Yes | Yes |
| Data complete before 6 AM (SLA) | Yes | Yes | Yes |
### Event Tracking
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Pageview tracking | Yes | Yes | Yes |
| Custom events | Yes | Yes | Yes |
| Conversion tracking | Yes | Yes | Yes |
| Revenue tracking | Yes | Yes | Yes |
| Micro-conversions | Yes | Yes | Yes |
---
## Reports & Analytics
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Traffic reports | Yes | Yes | Yes |
| Conversion reports | Yes | Yes | Yes |
| Revenue reports | Yes | Yes | Yes |
| Campaign reports | Yes | Yes | Yes |
| Geographic reports | Yes | Yes | Yes |
| Device reports | Yes | Yes | Yes |
| Funnel analysis | Yes | Yes | Yes |
| Channel attribution | Yes | Yes | Yes |
| Multi-site portfolio | Yes | Yes | Yes |
### Data Export
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| CSV export | Yes | Yes | Yes |
| JSON export | Yes | Yes | Yes |
| API export | Yes | Yes | Yes |
| BigQuery export | Yes | Yes | Yes |
---
## LENS AI
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| LENS Chat | Yes | Yes | Yes |
| LENS Reports | Yes | Yes | Yes |
| LENS Insights (rule-based detection) | Coming soon | Coming soon | Coming soon |
| AI with your own key (BYOK) | Unmetered | Unmetered | Unmetered |
| [Seal AI Private](/billing/seal-ai-private) (EU-hosted, no key) | Paid add-on | **Included** | **Included** |
| Dedicated, non-shared Seal AI Private instance | - | - | Yes |
LENS AI works two ways: **[Seal AI Private](/billing/seal-ai-private)** (managed, EU-hosted, no API key; 5M tokens/month plus optional packs — add-on on Growth, included in Scale/Enterprise) or **bring-your-own-key** (connect your own LLM provider API key; unmetered by Sealmetrics, billed directly by your provider).
---
## Integrations
### Advertising Platforms
| Platform | Growth | Scale | Enterprise |
|----------|:------:|:-----:|:----------:|
| Google Ads | Yes | Yes | Yes |
| Meta Ads (Facebook/Instagram) | Yes | Yes | Yes |
| Microsoft Ads | Yes | Yes | Yes |
| TikTok Ads | Yes | Yes | Yes |
### Data Destinations
| Destination | Growth | Scale | Enterprise |
|-------------|:------:|:-----:|:----------:|
| BigQuery | Yes | Yes | Yes |
| MCP Server | Yes | Yes | Yes |
### Automation
| Integration | Growth | Scale | Enterprise |
|-------------|:------:|:-----:|:----------:|
| Webhooks | - | Yes | Yes |
### E-commerce
| Platform | Growth | Scale | Enterprise |
|----------|:------:|:-----:|:----------:|
| WooCommerce | Yes | Yes | Yes |
| Magento | Yes | Yes | Yes |
| PrestaShop | Yes | Yes | Yes |
| OpenCart | Yes | Yes | Yes |
---
## Users & Access
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Team members | Unlimited | Unlimited | Unlimited |
| Role-based access | Basic | Advanced | Full |
| Audit logs | - | Yes | Yes |
---
## API Access
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Full API access | Yes | Yes | Yes |
| API rate limit (req/min) | 240 | 480 | Custom |
---
## Support & Service
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Documentation | Yes | Yes | Yes |
| Email support | Yes | Yes | Yes |
| Chat support | - | Yes | Yes |
| Priority support | - | Yes | Yes |
| Dedicated account manager | - | - | Yes |
### SLA & Reliability
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Uptime SLA | 99% | 99.5% | 99.9% |
### Onboarding
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| Self-service guides | Yes | Yes | Yes |
| Guided onboarding | - | 1 session | White-glove |
---
## Security & Compliance
| Feature | Growth | Scale | Enterprise |
|---------|:------:|:-----:|:----------:|
| GDPR compliant | Yes | Yes | Yes |
| Data encryption (transit) | Yes | Yes | Yes |
| Data encryption (rest) | Yes | Yes | Yes |
| Audit logging | - | Yes | Yes |
| Isolated processing | - | - | Yes |
---
## Need Help Choosing?
Not sure which plan is right for you?
- **Growth:** Growing teams and mid-size e-commerce (up to 5M events)
- **Scale:** Multi-brand retailers needing webhooks and audit logs (up to 15M events)
- **Enterprise:** Custom needs with unlimited events
[Contact sales](mailto:sales@sealmetrics.com) for personalized recommendations.
## Growth Plan
URL: https://docs.sealmetrics.com/billing/plans/growth
# Growth Plan
The Growth plan is designed for growing teams and mid-size e-commerce businesses that need full analytics capabilities with BigQuery export and API access.
## Pricing
| Billing | Price | Per Month |
|---------|-------|-----------|
| Monthly | €599/month | €599 |
| Annual | €5,988/year | €499 (2 months free) |
## What's Included
### Events & Tracking
| Feature | Included |
|---------|----------|
| Monthly events | 5,000,000 |
| Websites | Unlimited |
| Data retention | 24 months |
| First-party tracking | Yes |
| Cookie-free mode | Yes |
| Bot filtering | Yes |
| Real-time data | Typically < 2 min |
| Data complete before 6 AM | Yes (SLA) |
### Users & Access
| Feature | Included |
|---------|----------|
| Team members | Unlimited |
| Full API access | Yes |
| API rate limit | 240 req/min |
| Dashboard access | Full |
| Role-based access | Basic |
| Multi-site portfolio | Yes |
### LENS AI
| Feature | Included |
|---------|----------|
| LENS Chat | Yes |
| LENS Reports | Yes |
| LENS Insights (rule-based detection) | Coming soon |
| AI with your own key (BYOK) | Yes — unmetered, billed by your provider |
| [Seal AI Private](/billing/seal-ai-private) | Available as add-on (€299/mo billed annually · €358.80/mo monthly) |
### Integrations
| Feature | Included |
|---------|----------|
| Google Ads | Yes |
| Meta Ads | Yes |
| Microsoft Ads | Yes |
| TikTok Ads | Yes |
| BigQuery export | Yes |
| CSV/JSON export | Yes |
| MCP Server | Yes |
### Support
| Feature | Included |
|---------|----------|
| Email support | Yes |
| Documentation | Yes |
| SLA | 99% uptime |
## Event Limits
No overage charges. Your monthly price is fixed at €599 (or €499 annual). If you exceed your 5M event limit for 2 consecutive months (without forgiveness), you'll be automatically upgraded to Scale.
One free overage month per year is included. Annual plans absorb mid-year overages until renewal.
## Ideal For
- Growing teams with multiple websites
- Mid-size e-commerce businesses
- Businesses needing BigQuery export and full API access
- Sites with up to 5M events/month
## Getting Started
1. **Sign up** at [my.sealmetrics.com](https://my.sealmetrics.com/register)
2. Start your **14-day free trial** (you're not charged until the trial ends)
3. Install the tracking pixel
4. Set up BigQuery integration and API access
## Upgrading to Scale
When you upgrade to Scale, you get:
| Feature | Growth | Scale |
|---------|:------:|:-----:|
| Monthly events | 5M | **15M** |
| Webhooks | - | **Yes** |
| Audit logs | - | **Yes** |
| Advanced RBAC | - | **Yes** |
| Priority support | - | **Yes** |
| Onboarding | - | **1 session** |
| Uptime SLA | 99% | **99.5%** |
Upgrades take effect immediately with prorated billing.
## Scale Plan
URL: https://docs.sealmetrics.com/billing/plans/scale
# Scale Plan
The Scale plan is designed for multi-brand retailers and larger organizations that need webhooks, audit logs, and higher event volumes. This is our most popular plan.
## Pricing
| Billing | Price | Per Month |
|---------|-------|-----------|
| Monthly | €1,079/month | €1,079 |
| Annual | €10,788/year | €899 (2 months free) |
## What's Included
### Events & Tracking
| Feature | Included |
|---------|----------|
| Monthly events | 15,000,000 |
| Websites | Unlimited |
| Data retention | 24 months |
| First-party tracking | Yes |
| Cookie-free mode | Yes |
| Bot filtering | Yes |
| Agent AI Analytics | Coming soon |
| Real-time data | Typically < 2 min |
| Data complete before 6 AM | Yes (SLA) |
### Users & Access
| Feature | Included |
|---------|----------|
| Team members | Unlimited |
| Full API access | Yes |
| API rate limit | 480 req/min |
| Dashboard access | Full |
| Advanced RBAC | Yes |
| Audit logs | Yes |
| Multi-site portfolio | Yes |
### LENS AI
| Feature | Included |
|---------|----------|
| LENS Chat | Yes |
| LENS Reports | Yes |
| LENS Insights (rule-based detection) | Coming soon |
| AI with your own key (BYOK) | Yes — unmetered, billed by your provider |
| [Seal AI Private](/billing/seal-ai-private) | **Included** (5M tokens/month, EU-hosted, no API key needed) |
### Integrations
| Feature | Included |
|---------|----------|
| All Growth integrations | Yes |
| BigQuery export | Yes |
| CSV/JSON export | Yes |
| MCP Server | Yes |
| Webhooks | Yes |
### Support
| Feature | Included |
|---------|----------|
| Email support | Yes |
| Chat support | Yes |
| Priority support | Yes |
| 1 onboarding session | Yes |
| SLA | 99.5% uptime |
## Event Limits
No overage charges. Your monthly price is fixed at €1,079 (or €899 annual). If you exceed your 15M event limit for 2 consecutive months, we'll notify you to discuss moving to Enterprise — this change is not automatic.
One free overage month per year is included. Annual plans absorb mid-year overages until renewal.
## Ideal For
- Multi-brand retailers
- Businesses with 5M-15M monthly events
- Teams needing webhooks and audit logs
- Teams requiring advanced role-based access control
## Compared to Growth
| Feature | Growth | Scale |
|---------|:------:|:-----:|
| Monthly events | 5M | **15M** |
| Webhooks | - | **Yes** |
| Audit logs | - | **Yes** |
| Advanced RBAC | - | **Yes** |
| API rate limit | 240/min | **480/min** |
| [Seal AI Private](/billing/seal-ai-private) | Paid add-on | **Included** |
| Priority support | - | **Yes** |
| Onboarding | - | **1 session** |
| Uptime SLA | 99% | **99.5%** |
## Getting Started
1. **Sign up** or **upgrade** from Growth
2. Start your **14-day free trial** (you're not charged until the trial ends)
3. Configure webhooks and audit logs
4. Set up advanced roles for your team
## Usage & Limits
URL: https://docs.sealmetrics.com/billing/usage-limits
# Usage & Limits
Learn how Sealmetrics tracks usage, what counts toward your limits, and how the no-overage billing model works.
## Event Limits
Each plan includes a monthly event allowance:
| Plan | Monthly Events |
|------|---------------|
| Growth | 5,000,000 |
| Scale | 15,000,000 |
| Enterprise | Unlimited |
### What Counts as an Event
All tracked interactions count toward your event limit:
| Event Type | Counts? | Notes |
|------------|:-------:|-------|
| Pageview | Yes | Standard page load |
| Virtual pageview (SPA) | Yes | Single-page app navigation |
| Custom event | Yes | User-defined events |
| Conversion | Yes | Purchase, signup, etc. |
| Micro-conversion | Yes | Add-to-cart, etc. |
| AI Agent events | No | Agent Analytics is coming soon; when live, detected agents are tracked but never billed |
**Agent Analytics:** *(coming soon)* AI agent traffic (bots from OpenAI, Anthropic, Google, etc.) will be detected and tracked separately, and will **not** count toward your event limit. Agent Analytics will be included on all plans. It is not live today.
### Events Are Pooled
Events are pooled across all websites in your plan:
```
Plan: Growth (5M events)
Website 1 (main-store.com): 3,200,000 events
Website 2 (blog.company.com): 800,000 events
Website 3 (uk.store.com): 650,000 events
----------------------------------------------
Total used: 4,650,000 events
Remaining: 350,000 events
```
## No Overage Charges
Sealmetrics uses a **fixed-price billing model** with no surprise overage charges:
- **Your price is fixed** — you always pay the same amount per month
- **Tracking never stops** — if you exceed your limit, data collection continues uninterrupted
- **Free overage month** — one month per year of exceeding your limit is absorbed at no extra cost
- **Annual protection** — Growth and Scale annual plans absorb mid-year overages until renewal
### Auto-Upgrade Policy
If you **exceed your event limit (over 100%) for two consecutive months** that are not forgiven, your plan is moved up to the next tier:
| Current Plan | Behavior when over limit for 2 consecutive months |
|--------------|----------------------------------------------------|
| Growth (5M) | Automatically upgraded to Scale (15M) |
| Scale (15M) | **Not** auto-upgraded — you receive an email to discuss an Enterprise plan |
A single month over your limit triggers a warning email (or uses your free overage month for the year), not an upgrade. Auto-upgrade only applies to Stripe-billed accounts; if you subscribed through the Shopify App Store, you'll receive an email to upgrade manually from your Shopify Admin instead (see [Billing channels](#billing-channels)).
## Billing channels
Sealmetrics can be billed through one of two channels (never both at once):
- **Stripe** — for accounts that sign up directly on sealmetrics.com. Prices are in EUR. This is the only channel where the auto-upgrade described above applies.
- **Shopify App Store** — for merchants who installed Sealmetrics from Shopify. Billing is managed from your **Shopify Admin** and prices are shown in USD. Sealmetrics cannot upgrade your plan automatically here; if you stay over your limit, you'll receive an email asking you to approve the new plan in Shopify Admin.
After your free trial, accounts that haven't selected a paid plan fall back to an internal **free** tier, which is not subject to event-limit usage tracking or auto-upgrade.
## Monitoring Usage
### Dashboard View
1. Go to **Settings > Billing**
2. View the **Event Usage** card showing current period usage
3. See breakdown of human events and AI agent events
### Usage Alerts
You'll receive notifications at:
| Threshold | Notification Type |
|-----------|-------------------|
| 80% | Email warning |
| 100% | Email + Dashboard alert |
| 120% | Email alert (you are well over your limit) |
These percentages are email alert thresholds only — reaching 120% in a single month does not trigger an upgrade. Auto-upgrade is a separate process based on two consecutive months over your limit (see [Auto-Upgrade Policy](#auto-upgrade-policy)).
## Other Limits
### Data Retention
Data retention is **fixed and identical for every plan** — it is enforced by database TTLs, not by plan tier: daily aggregates and conversions are kept **24 months**, hourly aggregates 90 days, and event-level detail 1 day. See [Data Location & Retention](/security-privacy/data-location).
### LENS AI usage
LENS AI works in two modes, with different limits:
- **[Seal AI Private](/billing/seal-ai-private)** (managed, EU-hosted, no API key — add-on on Growth, included in Scale/Enterprise): **5M tokens per calendar month**, plus any non-expiring token packs you purchase. When quota and packs run out, Seal AI stops until the monthly reset or a pack purchase (you can always fall back to BYOK).
- **Bring-your-own-key (BYOK)**: connect your own Anthropic, OpenAI, DeepSeek, or Gemini API key under **My Account → LLM Providers**. Sealmetrics imposes **no quota** — usage is billed directly by your provider.
See the [AI Assistant docs](/lens/ai-assistant) for setup.
### Websites and Users
All plans include unlimited websites and unlimited users. There are no limits on the number of sites you can track or team members you can invite.
## Reducing Usage
### Optimize Tracking
If you're approaching limits, consider:
1. **Exclude internal traffic** — Don't install pixel on staging/development environments
2. **Filter bot traffic** — Enabled by default, removes known bots
3. **Agent Analytics** *(coming soon)* — AI agent events will be excluded from your event count automatically
### Monitor by Website
Identify high-usage websites:
1. Go to **Settings > Billing**
2. View the **Event Usage** card
3. Consider if all websites need full tracking
## Planning for Growth
### Upgrade Triggers
Consider upgrading when:
| Trigger | Recommendation |
|---------|----------------|
| Approaching 80%+ usage regularly | Consider upgrading proactively |
| Need webhooks/audit logs | Upgrade to Scale |
| Need unlimited events | Contact Enterprise sales |
## FAQ
### Do AI agent events count toward my limit?
Agent Analytics *(coming soon — not live today)* will detect AI agent traffic (bots from OpenAI, Anthropic, Google, etc.) and track it separately. Those events will not count toward your monthly event limit, and the feature will be included on all plans.
### What happens if I hit my limit mid-month?
Tracking continues uninterrupted. There are no overage charges. If you exceed your limit for two consecutive months that aren't forgiven, a Growth plan is auto-upgraded to Scale; a Scale plan instead receives an email to discuss Enterprise (it is not auto-upgraded).
### Do unused events roll over?
No. Event allowances reset each billing cycle and don't roll over.
### How quickly does usage update?
Usage data is synced periodically. There may be a short delay before the latest events appear in your usage dashboard.
## Add-ons & Extras
URL: https://docs.sealmetrics.com/billing/add-ons
# Add-ons & Extras
All plans already include unlimited websites and unlimited users. The add-ons below cover AI capacity and Enterprise custom needs.
## Seal AI Private
Sealmetrics' EU-hosted, platform-managed AI for [LENS](/lens) — no API key needed, no prompt retention, processed entirely in the EU.
| | |
|---|---|
| Price | €299/month billed annually upfront (€3,588/year) · €358.80/month on monthly contracts |
| Included quota | 5M tokens per calendar month |
| Extra capacity | 5M token packs at €358.80 each (1–10 per checkout, **never expire**) |
| Availability | Add-on on Growth · **Included** in Scale and Enterprise · Not available on Free |
Full details: **[Seal AI Private](/billing/seal-ai-private)**.
**Note:**
Instead of (or alongside) Seal AI Private, you can connect your **own** Anthropic, OpenAI, DeepSeek, or Gemini API key. With BYOK your AI usage is billed directly by that provider and Sealmetrics does not meter it. See [LLM Providers](/platform/settings/llm).
## Enterprise Add-ons
For Enterprise plan customers with additional needs:
| Add-on | Description | Pricing |
|--------|-------------|---------|
| Isolated processing | Dedicated data processing infrastructure | Custom |
| Custom SLA | 99.99% uptime guarantee | Custom |
| Dedicated AM | Named account manager | Included in Enterprise |
Contact sales@sealmetrics.com for these options.
## Frequently Asked Questions
### Do I pay Sealmetrics extra for AI usage?
Only if you use **Seal AI Private** (the managed EU provider): it's a paid add-on on Growth and included in Scale/Enterprise, with a 5M token/month quota and optional token packs. If you use **your own LLM key (BYOK)** instead, Sealmetrics doesn't charge or meter anything — your usage is billed by your provider.
### Are there volume discounts?
Contact sales@sealmetrics.com for custom pricing.
## Enterprise Plan
URL: https://docs.sealmetrics.com/billing/plans/enterprise
# Enterprise Plan
The Enterprise plan is designed for large organizations with custom requirements, unlimited events, and dedicated support.
## Pricing
Custom pricing based on your organization's needs. [Contact sales](mailto:sales@sealmetrics.com) for a personalized quote.
## What's Included
### Events & Tracking
| Feature | Included |
|---------|----------|
| Monthly events | Unlimited |
| Websites | Unlimited |
| Data retention | 24 months |
| First-party tracking | Yes |
| Cookie-free mode | Yes |
| Bot filtering | Yes |
| Agent AI Analytics | Coming soon |
| Isolated processing | Yes |
| Real-time data | Typically < 2 min |
| Data complete before 6 AM | Yes (SLA) |
### Users & Access
| Feature | Included |
|---------|----------|
| Team members | Unlimited |
| Full API access | Yes |
| API rate limit | Custom |
| Dashboard access | Full |
| Full RBAC | Yes |
| Audit logs | Yes |
| Multi-site portfolio | Yes |
### LENS AI
| Feature | Included |
|---------|----------|
| LENS Chat | Yes |
| LENS Reports | Yes |
| LENS Insights (rule-based detection) | Coming soon |
| AI with your own key (BYOK) | Yes — unmetered, billed by your provider |
| [Seal AI Private](/billing/seal-ai-private) | **Included** (5M tokens/month, EU-hosted, no API key needed) |
| Dedicated, non-shared Seal AI Private instance | Yes |
### Integrations
| Feature | Included |
|---------|----------|
| All Scale integrations | Yes |
| BigQuery export | Yes |
| CSV/JSON export | Yes |
| MCP Server | Yes |
| Webhooks | Yes |
### Support
| Feature | Included |
|---------|----------|
| Email support | Yes |
| Chat support | Yes |
| Priority support | Yes |
| Dedicated account manager | Yes |
| White-glove onboarding | Yes |
| SLA | 99.9% uptime |
## Ideal For
- Large enterprises with custom compliance needs
- High-traffic sites with unlimited events
- Teams needing dedicated account management
- Businesses requiring isolated data processing
## Getting Started
1. [Contact sales](mailto:sales@sealmetrics.com) for a demo
2. Discuss your specific requirements
3. Receive custom proposal
4. White-glove onboarding
## Invoices & Payments
URL: https://docs.sealmetrics.com/billing/invoices
# Invoices & Payments
Manage your billing, view invoices, update payment methods, and handle billing-related tasks.
## Viewing Invoices
### Access Invoice History
1. Go to **Organization → Billing** in the sidebar
2. Scroll to the **Invoices** section, which lists your billing history
```
Invoices
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Invoice Date Amount Status
─────────────────────────────────────────────
INV-2026-04 Apr 15 €724.79 ✅ Paid
INV-2026-03 Mar 15 €724.79 ✅ Paid
INV-2026-02 Feb 15 €724.79 ✅ Paid
INV-2026-01 Jan 15 €724.79 ✅ Paid
```
Each invoice row shows the invoice number, date, amount, and payment status.
### Invoice Details
A typical invoice breaks down like this:
```
Invoice INV-2026-01
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Invoice Date: January 15, 2026
Due Date: January 15, 2026
Status: Paid
Bill To:
Your Company S.L.
Calle Example 123
28001 Madrid, Spain
VAT: ES12345678A
───────────────────────────────────────────
Description Amount
───────────────────────────────────────────
Sealmetrics Growth (Monthly) €599.00
Jan 15 - Feb 14, 2026
───────────────────────────────────────────
Subtotal €599.00
VAT (21%) €125.79
───────────────────────────────────────────
Total €724.79
Amount Paid €724.79
Balance Due €0.00
```
### Download Options
Each invoice in the list has a **download icon** to save the invoice as a **PDF**, and a link to open the invoice online in Stripe. There is no CSV export of invoices — if you need data in another format for your accounting software, contact billing@sealmetrics.com.
## Invoice issuer & VAT
Your official invoices are issued through **Quaderno**, which Sealmetrics uses for VAT/tax compliance. Quaderno validates EU VAT numbers against **VIES** and applies the correct tax treatment per location. Card payments are processed by **Stripe**; if a Quaderno invoice is unavailable, Sealmetrics falls back to the Stripe invoice for that payment.
## Payment Methods
### Accessing Payment Settings
Sealmetrics uses **Stripe** for secure payment processing (cards). Official invoices are issued through **Quaderno** for VAT compliance — see [Invoice issuer & VAT](#invoice-issuer--vat). To manage your payment methods:
1. Go to **Organization → Billing**
2. Click **Manage** next to your current plan
3. This opens the **Stripe Customer Portal** where you can:
- Add new cards
- Update existing cards
- Remove old payment methods
- Set a default payment method
### Change Your Credit Card
To update or replace your credit card:
1. Go to **Organization → Billing**
2. Click **Manage** to open the Stripe Customer Portal
3. In the Stripe portal:
- Click **Add payment method** to add a new card
- Or click on an existing card to update it
4. Enter your new card details
5. Set as default if desired
6. Click **Save**
```
Payment Methods (Stripe Portal)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Primary:
┌─────────────────────────────────────────┐
│ 💳 Visa ending in 4242 │
│ Expires 12/2027 │
│ [Default] │
└─────────────────────────────────────────┘
Backup:
┌─────────────────────────────────────────┐
│ 💳 Mastercard ending in 5555 │
│ Expires 08/2028 │
│ [Make Default] [Remove] │
└─────────────────────────────────────────┘
[+ Add Payment Method]
```
### Add Payment Method
1. Click **+ Add Payment Method**
2. Enter your credit or debit card details
3. Click **Save**
### Supported Payment Methods
Sealmetrics accepts credit and debit cards through Stripe:
| Method | Availability |
|--------|--------------|
| Visa | All plans |
| Mastercard | All plans |
| American Express | All plans |
| Other Stripe-supported cards | All plans |
Bank transfer, SEPA Direct Debit, and PayPal are not currently supported.
### Update Expiring Card
When your card is expiring:
1. You'll receive email notification 30 days before
2. Go to **Organization → Billing** and click **Manage** to open the Stripe portal
3. Click on the expiring card
4. Update details or add new card
5. Set new card as default if needed
## Billing Information
### Company Details
- **Invoice email**: on **Organization → Billing** you can set an **accounting email** so invoices are also sent to your accounting department.
- **Company name, billing address, and payment details**: managed in the **Stripe Customer Portal** — click **Manage** on the Billing page.
- **VAT number and other invoice details**: contact **billing@sealmetrics.com** to add or correct them.
### VAT/Tax Information
Tax is calculated and applied by Quaderno based on your billing location and VAT status. The exact rate shown on your invoice depends on your case.
#### EU Customers
If you have a valid EU VAT number:
- Provide VAT ID during signup or in billing settings
- VAT reverse charge applies (0% VAT)
- You self-report VAT in your country
#### Non-EU Customers
- No VAT charged
- Local taxes may apply in your jurisdiction
#### Spanish Customers
- 21% IVA applies
- VAT shown on all invoices
### Invoice Customization
Request custom invoice details:
- Purchase order numbers
- Cost center codes
- Department names
- Custom fields
Contact billing@sealmetrics.com for custom invoice requirements.
## Billing Cycle
### Monthly Billing
- Charged on the same day each month
- Based on your signup/upgrade date
- Example: Signed up Jan 15 → Billed 15th of each month
### Annual Billing
- Charged once per year
- ~17% savings (2 months free)
- Example: Annual starting Jan 15 → Next charge Jan 15 next year
### Changing Billing Cycle
**Monthly to Annual:**
1. Go to **Settings → Billing → Plan**
2. Click **Switch to Annual**
3. Pay prorated annual amount (minus current month credit)
4. Save ~17% going forward
**Annual to Monthly:**
- Automatic at renewal if you choose not to renew annually
- Contact support mid-term for special circumstances
## Failed Payments
### Automatic Retry
When a payment fails, Stripe automatically retries it over the following days (Stripe Dunning). You'll be notified by email of the failure, and any scheduled retry date is shown in the failure banner. The exact retry schedule is managed by Stripe and may vary depending on your case.
### Manual Retry
To retry immediately:
1. Go to **Settings → Billing**
2. See payment failure banner
3. Click **Retry Payment**
4. Or update payment method and retry
### Preventing Service Interruption
If payment fails:
```
⚠️ Payment Failed
Your payment of €599.00 failed on Jan 15.
Card ending in 4242 was declined.
Reason: Insufficient funds
Next automatic retry: Jan 18
[Update Payment Method] [Retry Now]
```
1. Update payment method with valid card
2. Click **Retry Now**
3. Service continues uninterrupted
## Refunds & Credits
### Cancellation Refunds
Refund eligibility depends on your plan and circumstances. As a general guideline, monthly plans run until the end of the current period without a refund, while annual plans may qualify for a prorated refund depending on your case. Contact billing@sealmetrics.com to review your situation.
### Service Credits
Credits may be issued for:
- SLA violations
- Extended outages
- Billing errors
Credits appear on next invoice:
```
Invoice INV-2026-02
───────────────────────────────────────────
Sealmetrics Growth (Monthly) €599.00
Credit: January SLA compensation -€59.90
───────────────────────────────────────────
Total €539.10
```
### Requesting Refund
For refund requests:
1. Email billing@sealmetrics.com
2. Include invoice number
3. Explain circumstances
4. Response within 2 business days
## Receipts & Tax Documents
### Payment Receipts
Receipts are sent automatically after each payment:
- Sent to billing email
- Includes payment confirmation
- Links to full invoice
### Annual Tax Summary
If you need an annual summary of your payments for tax purposes, email **billing@sealmetrics.com** with your account email and the year you need. There is no self-service annual summary in the dashboard.
### VAT Invoices
All invoices include:
- Your VAT number (if provided)
- Our VAT number (included automatically)
- VAT breakdown
- Invoice date and number
## Contact Billing Support
For billing questions:
- **Email:** billing@sealmetrics.com
- **Response time:** 1 business day
- **Include:** Account email, invoice number (if relevant)
Common requests:
- Invoice copies
- Payment receipts
- VAT corrections
- Custom billing arrangements
## Seal AI Private
URL: https://docs.sealmetrics.com/billing/seal-ai-private
# Seal AI Private
**Seal AI Private** is Sealmetrics' platform-managed AI provider for [LENS AI](/lens): your chat questions and AI insights are processed entirely in the **EU (Paris)**, with **no prompt retention**, and your data never trains third-party models. No API key required — it works out of the box.
It is available as a paid **add-on** on Growth plans and is **included** in Scale and Enterprise plans.
## What powers it
| | |
|---|---|
| Model | **`gpt-oss-120b`** — open weights, Apache 2.0 |
| Served by | **Scaleway SAS** (Iliad group) — Paris, France |
| Retention | None. Token counters only |
**Caution:**
**OpenAI is not involved and never receives your prompts.** `gpt-oss-120b` is an open-weights model published under Apache 2.0 — a static public artifact loaded onto Scaleway's infrastructure in Paris. There is no call to OpenAI anywhere in the request path, and no contract with OpenAI behind this service.
Scaleway is a named subprocessor in Annex 3 of our [DPA](https://sealmetrics.com/dpa), which is the authoritative and always-current list. For why this model was chosen over the alternatives — including the two we tried and replaced first — see [Why Seal AI runs on gpt-oss-120b](/lens/seal-ai/model-selection); for how the request path is isolated, see [How Seal AI works](/lens/seal-ai/private-ai-architecture).
If you use [BYOK](/platform/settings/llm) instead, none of the above applies: your prompts go to your own provider, under your own key and your own contract, and that provider is not a Sealmetrics subprocessor.
**Info:**
**LENS AI itself costs nothing extra.** It is included in every paid plan, and using it with [your own LLM key (BYOK)](/platform/settings/llm) carries **no Sealmetrics charge at all** — no add-on fee, no token quota, no packs. You pay only your own provider (OpenAI, Anthropic, Gemini or DeepSeek) for what you use.
The pricing below applies **only if you choose Seal AI Private**, our managed EU-hosted LLM, instead of supplying your own key. It is a convenience and data-residency option, not a requirement for using LENS.
---
## Pricing
| Contract | Price |
|----------|-------|
| Annual contracts | **€299/month**, billed **€3,588/year upfront** |
| Monthly contracts | **€358.80/month** |
Activating the add-on mid-cycle is **not prorated** — billing starts at your next billing cycle. The add-on follows the billing interval of your base subscription.
## Availability by plan
| Plan | Seal AI Private |
|------|-----------------|
| Free | Not available |
| Growth | Available as a paid add-on |
| Scale | **Included** |
| Enterprise | **Included** |
## The token quota
- Seal AI Private includes **5 million tokens per calendar month (UTC)**. Unused tokens do **not** roll over.
- Tokens are counted as prompt + completion tokens of each AI request (chat questions and automated LENS insights both draw from the same quota).
- At **80%** and **100%** consumption, the organization receives an email alert (once per month each).
### When the quota runs out
When the monthly quota and any pack balance are exhausted, Seal AI Private **stops** (hard stop) for both chat and insights, and the product shows a message with a purchase option. Two ways to keep going:
1. **Buy a token pack** (below), or
2. **Switch to your own key (BYOK)** — free of charge from Sealmetrics. The chat's provider selector lets any user fall back to their own OpenAI, Anthropic, Gemini, or DeepSeek key at any time, with no quota. See [LLM Providers](/platform/settings/llm).
## Extra token packs
| | |
|---|---|
| Size | **5,000,000 tokens** per pack |
| Price | **€358.80 per pack** (same price on all contracts) |
| Quantity | 1–10 packs per checkout |
| Expiry | **Packs never expire** — pack tokens are consumed only after the monthly 5M quota is exhausted |
Packs are a **one-time purchase** (no auto-recharge) made from the [Seal AI Usage screen](/platform/settings/seal-ai-usage) via Stripe checkout. Only organization **owners** can purchase.
## Who can manage it
| Action | Who |
|--------|-----|
| View the [Seal AI Usage screen](/platform/settings/seal-ai-usage) | Organization **owner** and **admins** |
| Activate the add-on / buy packs / cancel | Organization **owner** only |
| Members | No menu entry; the chat still shows the aggregate quota ring, and on exhaustion members see "contact your admin" |
Cancelling the add-on takes effect at the end of the current billing period.
## For developers
Seal AI Private is managed through these API endpoints (JWT with `billing:manage` — organization owners):
| Endpoint | Description |
|----------|-------------|
| `POST /billing/seal-ai/subscribe` | Add the add-on to the org's subscription (no proration; `403` on Free, `409` if already included in plan or already active) |
| `POST /billing/seal-ai/unsubscribe` | Remove the add-on at period end |
| `POST /billing/seal-ai/token-pack/checkout` | Stripe checkout for 1–10 token packs (entitled orgs only) |
| `GET /organizations/{slug}/seal-ai/usage` | Monthly usage summary — see [Organizations API](/api/organizations#seal-ai-usage) |
When the quota is exhausted, AI endpoints return `403` with `error_code: "seal_ai_quota_exceeded"` and a structured payload (`used_tokens`, `pack_balance_tokens`, `effective_quota_tokens`, `can_buy_pack`, `entitlement_source`, `resets_at`). See [LENS API](/lens/api/lens-endpoints).
## Related documentation
- [Seal AI Usage screen](/platform/settings/seal-ai-usage) — the consumption dashboard
- [LLM Providers](/platform/settings/llm) — Seal AI Private vs. bring-your-own-key
- [LENS AI](/lens) — what the AI can do
- [Why Seal AI runs on gpt-oss-120b](/lens/seal-ai/model-selection) — the model audit and the trade-offs
- [How Seal AI works](/lens/seal-ai/private-ai-architecture) — the request path and isolation model
- [Plans & Pricing](/billing) — base plan pricing
## Billing FAQ
URL: https://docs.sealmetrics.com/billing/faq
# Billing FAQ
Common questions about plans, pricing, and billing.
## Plans & Pricing
### Which plan is right for me?
| Your Situation | Recommended Plan |
|----------------|------------------|
| Growing team, up to 5M events | Growth |
| Multi-brand retailer, up to 15M events | Scale |
| Unlimited events, custom requirements | Enterprise |
### Can I try before I buy?
Yes! All plans include a **14-day free trial** with full features. You choose a plan and enter a payment method in the secure Stripe checkout to start the trial — but **you are not charged until the trial ends**, and you can cancel anytime during the 14 days at no cost.
### Is there a free plan?
There is no self-service free plan, but a limited **free tier** exists: if your trial ends without an active subscription, your account drops to it (you keep read access to your existing data), and sites provisioned through the [Agentic Package](/integrations/agentic-package) start on it with up to 1M events/month. We also offer special pricing for nonprofits and early-stage startups.
### Do you offer discounts?
| Discount | Amount | How to Get |
|----------|--------|------------|
| Annual billing | ~17% savings (2 months free) | Select annual at checkout |
| Promo / coupon code | Varies | Enter the code at checkout |
| Nonprofits, startups, education | Varies by case | Email sales@sealmetrics.com |
If you have a promotional code, you can enter it during checkout — the code is validated (expiry, usage limits, and any plan restrictions) and the discount is applied to your subscription before payment.
### What currency do you charge in?
All prices are in Euros (EUR). Charges appear in EUR on your statement; your bank handles conversion if needed.
---
## Changing Plans
### Can I upgrade at any time?
Yes. Upgrades take effect immediately:
- You get instant access to new features
- Prorated charge for the remainder of your billing period
### Can I downgrade at any time?
Yes. Downgrades take effect at your next billing cycle:
- You keep current features until period ends
- New (lower) rate applies on next bill
### Can I switch from monthly to annual?
Yes. You'll:
1. Pay prorated annual amount (minus credit for current month)
2. Start saving ~17% immediately
3. Next charge is in 12 months
---
## Billing & Payments
### When am I charged?
- **Monthly:** Same day each month (based on signup date)
- **Annual:** Once per year on your signup anniversary
### Can I subscribe through Shopify?
Yes. If you install Sealmetrics from the Shopify App Store, billing is handled through Shopify's Managed Pricing and managed from your **Shopify Admin** (prices shown in USD). Otherwise, signing up directly on sealmetrics.com bills through Stripe (in EUR). An account uses one channel or the other, never both at the same time.
### What payment methods do you accept?
| Method | Availability |
|--------|--------------|
| Credit/debit cards (Visa, Mastercard, Amex) | All plans |
| Other Stripe-supported cards | All plans |
Payments are processed securely through Stripe. Bank transfer, SEPA Direct Debit, and PayPal are not currently supported.
### Do I get an invoice?
Yes. Every payment generates an invoice with:
- Itemized charges
- VAT breakdown (EU)
- PDF download option
Invoices are issued through Quaderno for VAT compliance, with EU VAT numbers validated against VIES. See [Invoices & Payments](./invoices) for details.
### Can I add a PO number to invoices?
There is no self-service field for PO numbers in the dashboard. Contact **billing@sealmetrics.com** with your PO number and we will include it on your invoices.
---
## Limits & Overages
### What counts as an event?
Events include pageviews, virtual pageviews (SPAs), conversions, micro-conversions, and custom events. All event types count toward your monthly limit.
### What happens if I exceed my event limit?
1. Tracking continues (no data loss)
2. **No overage charges** — your monthly price stays fixed
3. One free overage month per year is included (used automatically for the first month you go over)
4. If you exceed your limit for two consecutive months that aren't forgiven, a Growth plan is auto-upgraded to Scale. A Scale plan is **not** auto-upgraded — instead you receive an email to discuss an Enterprise plan. (Auto-upgrade applies to Stripe-billed accounts; Shopify-billed accounts are asked to upgrade manually in Shopify Admin.)
### Do unused events roll over?
No. Event allowances reset each billing cycle.
---
## Trials & Cancellation
### How does the free trial work?
1. Sign up and choose a plan
2. Enter your payment method in the secure Stripe checkout — **you are not charged yet**
3. Get full access to all features for 14 days
4. When the trial ends, your subscription activates automatically — unless you cancelled during the trial
### What happens when my trial ends?
- **If you keep your subscription:** It activates automatically and the first charge is made
- **If you cancelled during the trial:** Nothing is charged, and your account drops to a limited free tier (you can view existing data) until you pick a paid plan
### How do I cancel?
1. Go to **Settings > Billing > Plan**
2. Click **Cancel Subscription**
3. Confirm cancellation
4. Access continues until period ends
### Is there a cancellation fee?
No. Cancel anytime with no penalties.
### Can I get a refund?
Refund eligibility depends on your plan and circumstances. In general, monthly plans run to the end of the current period, while annual plans may qualify for a prorated refund depending on your case. Contact billing@sealmetrics.com to review your situation.
### What happens to my data after cancellation?
After cancellation your account becomes read-only and your data is retained for a limited period during which you can still export it, after which it may be permanently deleted. Exact retention timing depends on your case, so export your data before cancelling if you need it. Contact billing@sealmetrics.com if you have specific retention questions.
---
## Taxes
### Do you charge VAT?
| Location | VAT Treatment |
|----------|---------------|
| Spain | 21% IVA charged |
| EU with valid VAT ID | Reverse charge (0%) |
| EU without VAT ID | Your country's VAT rate |
| Non-EU | No VAT |
### How do I add my VAT number?
Provide your VAT ID during signup, or contact **billing@sealmetrics.com** to add it to your account. VAT numbers are validated against VIES, and future invoices then show the reverse charge treatment.
### Can I get a VAT refund for past invoices?
If you forgot to add your VAT ID, contact billing@sealmetrics.com with:
- Your VAT number
- Invoice numbers affected
We'll issue corrected invoices and credit the VAT.
---
## Users & Teams
### Can multiple people share one login?
No. Each team member should have their own login for:
- Security (audit trail)
- Personalized settings
- Individual permissions
### How many users can I have?
All plans include unlimited users. There is no user limit on any plan.
### Can I give clients read-only access?
Yes. Invite users with "Viewer" role. They can see dashboards but not change settings.
---
## Security
### Is my payment information secure?
Yes. We use Stripe for payment processing:
- PCI DSS Level 1 certified
- We never see or store your full card number
- All transactions encrypted
### Can I use 2FA for billing?
2FA protects your entire account, including billing. Enable at **Settings > Security > Two-Factor Authentication**.
---
## Getting Help
### Who do I contact for billing issues?
- **Email:** billing@sealmetrics.com
- **Response time:** 1 business day
- **Include:** Account email and relevant invoice numbers
### Can I talk to someone about pricing?
Yes! For custom pricing or questions:
- **Email:** sales@sealmetrics.com
### Where can I see my current plan and usage?
Go to **Settings > Billing** for:
- Current plan details
- Usage statistics
- Invoice history
- Payment methods
---
# Troubleshooting
## Troubleshooting
URL: https://docs.sealmetrics.com/troubleshooting
# Troubleshooting
Solutions for common issues with SealMetrics tracking and reporting.
## Guides
| Guide | Use it when… |
|---|---|
| [Tracker or pixel not working](/troubleshooting/tracker-not-working) | No data appearing at all — start here to triage which specific problem you have |
| [GTM Consent Mode blocking the tag](/troubleshooting/gtm-consent-mode-blocking) | Data dropped after a CMP/consent banner went live, or only consenting visitors are tracked |
| [CSP errors: domains to allow](/troubleshooting/csp-errors-domains-to-allow) | The console shows "Refused to load the script" / "Refused to connect" policy errors |
| [Duplicate pageviews](/troubleshooting/duplicate-pageviews) | Pageviews doubled: script included twice, stub without `?auto=0`, or SPA without `?spa=0` |
| [Dates & timezone mismatch](/troubleshooting/dates-timezone-mismatch) | Daily totals don't line up with another tool or your backend |
| [Unauthorized domain](/troubleshooting/unauthorized-domain) | The snippet is installed but hits from a domain are silently rejected |
| [Data delay](/troubleshooting/data-delay) | Data seems to take longer than seconds to appear |
| [Conversions not appearing](/troubleshooting/conversions-not-appearing) | Pageviews work but a conversion never reaches the Conversions report |
| [Numbers lower than another tool](/troubleshooting/lower-numbers-than-other-tools) | SealMetrics reports fewer visits than GA4 or another tool |
| [Test traffic blocked as bot](/troubleshooting/test-traffic-blocked-as-bot) | Your own automated test visits (Selenium, Playwright, curl…) never show up |
| [Reconciling with your ERP, CRM, or database](/troubleshooting/erp-crm-database-discrepancy) | Substantial conversion gaps against your source of truth |
| [Fixing `ReferenceError: sealmetrics is not defined`](/troubleshooting/sealmetrics-is-not-defined) | Ad blockers break pages that call `sealmetrics.*` directly |
---
## Quick Diagnostics
### Check Tracker Installation
1. Open your website in a browser
2. Open Developer Tools (F12)
3. Go to the **Network** tab
4. Filter by `sealmetrics` or `pixel`
5. Reload the page
You should see:
- `t.js` script loading (200 OK)
- Beacon/fetch request to `t.sealmetrics.com` (204 No Content)
### Verify Data Collection
1. Log in to [my.sealmetrics.com](https://my.sealmetrics.com)
2. Open the **Overview** report
3. Visit your website in another tab
4. The **Last hit** timestamp at the top right should update within seconds
---
## Common Issues
### Tracking Not Working
**Symptoms:** No data appearing in dashboard
**Solutions:**
1. **Check script installation**
```javascript
// In browser console
console.log(typeof sealmetrics);
// Should output: "function"
```
2. **Verify Site ID**
- Confirm your Site ID matches the one in your tracker script
- Find your Site ID in Settings → Sites → [your site] → General tab
3. **Check domain authorization**
- Go to Settings → Sites → [your site] → Domains
- Ensure your website domain is listed — see [Unauthorized domain](/troubleshooting/unauthorized-domain)
4. **Check for JavaScript errors**
- Open browser console (F12 → Console)
- Look for any errors related to sealmetrics
### Conversions Not Appearing
**Symptoms:** Pageviews work but conversions don't show up
**Solutions:**
1. **Verify conversion code**
```javascript
// Check if tracker is loaded before calling
if (typeof sealmetrics !== 'undefined') {
sealmetrics.conv('purchase', 99.99);
}
```
2. **Check Network tab**
- Look for the beacon request after conversion fires
- Verify the payload contains `"e":"purchase"` and `"v":99.99`
3. **Timing issues**
- Ensure `sealmetrics.conv()` is called AFTER the script loads
- Use `window.addEventListener('load', ...)` for page load events
4. **Full checklist** — [Conversions not appearing](/troubleshooting/conversions-not-appearing) covers snippet signature, numeric amounts, flow variants, and report verification step by step
For substantial discrepancies between SealMetrics and your ERP / CRM / internal database (missing conversions when reconciling totals), see [Conversions Don't Match Your ERP, CRM, or Database](/troubleshooting/erp-crm-database-discrepancy) — it walks through the firing-order requirement of the base pixel vs. the conversion pixel and the long tail of secondary causes.
### Duplicate Conversions
**Symptoms:** Same order appearing multiple times
**Solutions:**
1. **Server-side deduplication** (recommended)
```php
if (!$order->isTracked()) {
echo '';
$order->markAsTracked();
}
```
2. **Client-side check**
```javascript
var orderId = 'ORD-123';
if (!localStorage.getItem('tracked_' + orderId)) {
sealmetrics.conv('purchase', 99.99, { order_id: orderId });
localStorage.setItem('tracked_' + orderId, 'true');
}
```
### SPA Navigation Not Tracked
**Symptoms:** Only first page view appears, navigation ignored
**Solutions:**
The tracker automatically detects History API navigation. If it's not working:
1. **Hash-based routing**
- Hash changes (`#/page`) require manual tracking
```javascript
window.addEventListener('hashchange', function() {
sealmetrics();
});
```
2. **Custom routing**
- If using a custom router, call `sealmetrics()` on route changes
- If you fire pageviews manually on History API navigation, load the tracker with `?spa=0` to avoid double counting — see [Duplicate pageviews](/troubleshooting/duplicate-pageviews)
### Data Discrepancy with Other Tools
**Symptoms:** Different numbers than Google Analytics
This is expected. SealMetrics differs because:
1. **No cookies** — SealMetrics uses cookieless session identification, GA uses cookies
2. **Bot filtering** — SealMetrics has different bot detection
3. **Session definition** — Different session timeout rules
4. **Ad blocker immunity** — SealMetrics tracks users blocked by ad blockers
See [Numbers lower than another tool](/troubleshooting/lower-numbers-than-other-tools) for the diagnosis guide and [GA4 vs SealMetrics](/faq/ga4-vs-sealmetrics) for the detailed comparison.
---
## Network Issues
### Blocked by Ad Blockers
SealMetrics is designed to work with ad blockers. If blocked:
1. **First-party tracking** — Set up [first-party tracking](/implementation/tracker/first-party)
2. **Custom domain** — Use your own subdomain for the pixel
3. **Avoid `ReferenceError: sealmetrics is not defined`** — When the script is blocked, direct calls to `sealmetrics.*` throw a `ReferenceError` that can break the page. See [Fixing `ReferenceError: sealmetrics is not defined`](/troubleshooting/sealmetrics-is-not-defined) for the recommended stub buffer (and the fallback per-call guard).
### CORS Errors
You shouldn't see CORS errors. If you do:
1. **Check Content-Type** — Tracker sends form-encoded beacons to avoid preflight
2. **Verify script URL** — Use the exact URL from your dashboard
### CSP Errors
If the console shows "Refused to load the script" or "Refused to connect" errors naming a `Content-Security-Policy` directive, your site's CSP is blocking the tracker. See [CSP errors: domains to allow](/troubleshooting/csp-errors-domains-to-allow).
### 429 Too Many Requests
API rate limiting. Solutions:
1. **Reduce request frequency**
2. **Implement caching**
3. **Upgrade plan** for higher limits
---
## Data Freshness Issues
### Data Appears Delayed
Hits normally reach reports within seconds. If data seems delayed:
1. **Check the Last hit timestamp** — Top right of the Overview report; it updates within seconds of a tracked hit
2. **Check the date range and timezone** — "Today" is defined by the site's timezone
3. **Processing queue** — During traffic spikes, brief delays are normal
See [Data delay](/troubleshooting/data-delay) for the full decision tree.
---
## Content Grouping Issues
### Group Not Appearing
1. **Verify parameter**
```html
```
2. **Or use JavaScript**
```javascript
sealmetrics({ group: 'blog' });
```
3. **Check Reports** — Content groups appear in Pages report filters
---
## GTM-Specific Issues
### Tags Not Firing
1. **Consent gating** — The number one cause: the tag waits for consent it doesn't need. See [GTM Consent Mode blocking](/troubleshooting/gtm-consent-mode-blocking)
2. **Verify trigger** — Check GTM Preview mode
3. **Check tag type** — Use Custom HTML tag
4. **Timing** — Ensure tag fires before page unload
See [Google Tag Manager integration](/integrations/google-tag-manager) for detailed setup.
### Duplicate Pageviews with GTM
If the tracker is both hardcoded and loaded via GTM, or a stub-queued pageview runs without `?auto=0`, every load counts twice. See [Duplicate pageviews](/troubleshooting/duplicate-pageviews).
---
## Still Having Issues?
1. **Check the FAQ** — [Common questions](/faq)
2. **Contact support** — support@sealmetrics.com
3. **Community** — [GitHub discussions](https://github.com/sealmetrics)
## Tracker or Pixel Not Working: No Data Appearing
URL: https://docs.sealmetrics.com/troubleshooting/tracker-not-working
# Tracker or Pixel Not Working: No Data Appearing
If the tracker (pixel) seems to be not working — no data showing in your dashboard, no visits recorded, or tracking that suddenly stopped — the cause is almost always one of six things: the script isn't loading, consent tooling is blocking it, the domain isn't authorized, the Site ID is wrong, your own traffic is being filtered, or you're simply looking at the wrong date range. This page gets you to the right fix in a couple of minutes.
---
## The 60-second check
Do these two checks first — together they tell you which half of the problem you have.
**1. Is the pixel firing on your site?**
1. Open your website in a browser
2. Open Developer Tools (F12) → **Network** tab
3. Filter by `sealmetrics`
4. Reload the page
You should see the `t.js` script load (200 OK) and a beacon request to `t.sealmetrics.com` (204 No Content).
**2. Is Sealmetrics receiving anything?**
1. Open the **Overview** report at [my.sealmetrics.com](https://my.sealmetrics.com)
2. Check the **Last hit** timestamp at the top right — it updates within seconds of a tracked visit
| Pixel fires | Last hit updates | Meaning |
|---|---|---|
| ❌ No | ❌ No | The script never loads → [script not loading](#the-script-is-not-loading-at-all) |
| ✅ Yes | ❌ No | The hit is sent but rejected → [hits rejected](#the-pixel-fires-but-no-data-reaches-the-dashboard) |
| ✅ Yes | ✅ Yes | Data arrives; the report view is the issue → [data exists but you can't see it](#data-arrives-but-you-dont-see-it-in-reports) |
---
## The script is not loading at all
No `t.js` request appears in the Network tab. Most common causes, in order:
1. **The snippet isn't on the page (or not on all pages).** View the page source and search for `sealmetrics`. If it's missing, revisit the [installation guide](/implementation/tracker/installation) or your platform's integration ([WordPress](/integrations/cms/wordpress), [Shopify](/integrations/ecommerce/shopify), [GTM](/integrations/google-tag-manager)).
2. **GTM Consent Mode is holding the tag back.** If you load the tracker via Google Tag Manager and a consent banner went live recently, the tag is probably waiting for consent it doesn't need. See [GTM Consent Mode blocking the tag](/troubleshooting/gtm-consent-mode-blocking).
3. **Your Content-Security-Policy blocks the script.** The console shows "Refused to load the script" errors. See [CSP errors: domains to allow](/troubleshooting/csp-errors-domains-to-allow).
4. **An ad blocker on *your* browser.** Test in a private window with extensions disabled before concluding the tracker is broken — Sealmetrics resists ad blockers, but your own aggressive blocker can still hide requests locally. For a permanent solution, use [first-party tracking](/implementation/tracker/first-party).
5. **Page errors before the snippet runs.** Check the Console tab for a `ReferenceError: sealmetrics is not defined` — see [the stub-buffer fix](/troubleshooting/sealmetrics-is-not-defined).
---
## The pixel fires but no data reaches the dashboard
The beacon request appears in the Network tab, but **Last hit** never updates. The hit is being rejected server-side:
1. **Unauthorized domain** — the most common cause. Hits from domains not listed for the site are silently dropped. Go to Settings → Sites → [your site] → Domains and check the exact hostname (including `www.` vs apex). Full guide: [Unauthorized domain](/troubleshooting/unauthorized-domain).
2. **Wrong Site ID.** The `id=` in your snippet must match the Site ID in Settings → Sites → [your site] → General tab (the same value the **Pixel Code** tab embeds in the generated snippet). See [How to find your Site ID](/platform/account-setup/find-account-id).
3. **Your IP is excluded.** If your office or VPN IP is listed under [IP exclusions](/platform/settings/tracking/ip-exclusions), your own visits will never appear — test from another network or a mobile connection.
4. **Your test visits look like a bot.** Automated visits (Selenium, Playwright, curl, headless Chrome) are filtered. See [Test traffic blocked as bot](/troubleshooting/test-traffic-blocked-as-bot).
---
## Data arrives but you don't see it in reports
**Last hit** updates, so tracking works — the issue is where you're looking:
1. **Date range and timezone.** "Today" is defined by the site's timezone, not yours. See [Dates & timezone mismatch](/troubleshooting/dates-timezone-mismatch).
2. **Brief processing delay.** Hits normally land in seconds; during traffic spikes a short queue delay is normal. Decision tree: [Data delay](/troubleshooting/data-delay).
3. **Wrong site selected.** With multiple sites in the account, confirm the site picker at the top matches the domain you're testing.
---
## Tracking worked before and suddenly stopped
When data flowed historically and then dropped to zero (or dropped sharply) on a specific date, ask what changed that day:
- **A consent banner / CMP went live** → [GTM Consent Mode blocking](/troubleshooting/gtm-consent-mode-blocking)
- **A site redesign or theme change removed the snippet** → re-check the [installation](/implementation/tracker/installation)
- **A CSP or security header was added** → [CSP errors](/troubleshooting/csp-errors-domains-to-allow)
- **The domain changed** (new domain, added `www.`, moved to a subdomain) → [Unauthorized domain](/troubleshooting/unauthorized-domain)
- **Numbers dropped but not to zero** → that's a different problem; see [Numbers lower than another tool](/troubleshooting/lower-numbers-than-other-tools)
---
## Pageviews work but conversions don't
That's its own checklist — correct `conv()` signature, numeric amount, base pixel firing first: [Conversions not appearing](/troubleshooting/conversions-not-appearing).
---
## Still stuck?
Write to **support@sealmetrics.com** and include: the page URL you tested, a screenshot of the Network tab filtered by `sealmetrics`, and your Site ID. Those three things let support reproduce the problem immediately.
## Fixing ReferenceError: sealmetrics is not defined
URL: https://docs.sealmetrics.com/troubleshooting/sealmetrics-is-not-defined
# Fixing `ReferenceError: sealmetrics is not defined`
A guide for the customer's IT / development team. It resolves the `ReferenceError: sealmetrics is not defined` that appears when a blocker prevents the tracker from loading.
---
## The problem
When a visitor has an ad blocker, privacy extension, corporate firewall, or DNS filter active (uBlock Origin, AdGuard, Brave Shields, NextDNS, Pi-hole, etc.), the browser will not download `t.sealmetrics.com/t.js`. The `window.sealmetrics` variable is never created.
If your code (for example, a GTM tag) calls the API directly:
```javascript
sealmetrics.micro("Add_to_cart", { ... });
```
the browser throws `ReferenceError: sealmetrics is not defined`. That error halts execution of the JavaScript block where the call lives. If that block also contains UI, form, or navigation logic, the page breaks for the user.
This is **not a tracker bug**. It is the normal consequence of invoking any third-party library (GA4, Meta Pixel, Hotjar, SealMetrics…) without protecting yourself against the "script blocked" case.
---
## The solution: stub buffer in `` (RECOMMENDED)
Inject this snippet once, inline in the ``, **before any call to `sealmetrics.*`** and **before** the main tracker script:
```html
```
### What it does
- Creates `window.sealmetrics`, `sealmetrics.conv`, and `sealmetrics.micro` as empty functions that enqueue calls into `sealmetrics.q`.
- If the real script loads: it drains the queue in FIFO order and sends every pending event.
- If the real script is blocked: the calls are absorbed silently. Zero console errors. Zero broken pages.
### Characteristics
- **Size:** ~180 bytes gzipped. No Core Web Vitals impact.
- **Idempotent:** pasting it twice does nothing. The `||` guards take care of that.
- **No dependencies:** ES5, compatible with every browser.
- **Industry-standard pattern**, same as `fbq` (Meta Pixel), `gtag` (Google), `_paq` (Matomo).
### Installing it from GTM
If you do not have access to the site HTML and everything is managed from GTM:
1. Create a new **Custom HTML** tag.
2. Paste the stub snippet (the `` block).
3. **Trigger:** `Initialization - All Pages` (`gtm.init`). This is the earliest GTM event.
4. **Priority:** maximum (for example, `1000`). This guarantees the stub runs before any other tag that calls `sealmetrics.*`.
5. Publish the container.
From that point on, every other tag can call `sealmetrics.micro(...)` or `sealmetrics.conv(...)` directly, without wrapping each call in a `typeof` guard.
---
## Alternative solution: per-call guard
If for any reason you cannot inject the stub (restrictive policies, no access to ``, etc.), wrap each tracker call with a check:
```javascript
if (typeof window.sealmetrics !== "undefined" && typeof window.sealmetrics.micro === "function") {
sealmetrics.micro("Add_to_cart", {
module_title: google_tag_manager["rm"]["208828905"](16),
click_text: google_tag_manager["rm"]["208828905"](17),
page_title: google_tag_manager["rm"]["208828905"](18),
page_subcategory: google_tag_manager["rm"]["208828905"](19),
cookies: google_tag_manager["rm"]["208828905"](20),
type_appointment: google_tag_manager["rm"]["208828905"](21)
});
}
```
For conversions:
```javascript
if (typeof window.sealmetrics !== "undefined" && typeof window.sealmetrics.conv === "function") {
sealmetrics.conv("purchase", 89.99, { currency: "EUR" });
}
```
### When to use this option
- Only when you cannot inject the stub.
- Assume the `if` has to be repeated in **every** GTM tag that calls the tracker. With many events, the maintenance cost grows fast.
---
## Summary table
| Aspect | Stub buffer (HEAD) | Per-call guard |
|------------------------------------------------|----------------------------|--------------------------------------------|
| Install effort | Once | Once per call |
| Maintenance | None | High (every new tag needs the `if`) |
| Events lost if the script loads late | No (queued and drained) | Yes (calls before load are lost) |
| Size | ~180 bytes gzip | 0 |
| Recommended | Yes | Only as a fallback |
---
## What NOT to do
- **Do not disable the tracker.** The error does not come from the tracker — it comes from invoking it without protection. Disabling it fixes nothing structurally and leaves you without measurement.
- **Do not wrap every call in `try/catch`.** It works, but it hides other legitimate errors in the same block. The `typeof` guard is cleaner.
- **Do not load the tracker with `async` and assume it is available immediately.** Even when it loads, there is a window of time during which `window.sealmetrics` does not exist yet. The stub solves this without effort.
- **Do not paste the stub inside an iframe** (for example, a Shopify Web Pixel). The stub must live on the host page so the queued calls are drained by the tracker loaded in the same context.
---
## Verification
After installing the stub:
1. Open the site in a browser with uBlock Origin (or any blocker) active and filtering `sealmetrics.com`.
2. Open the browser console.
3. Navigate and fire events (clicks, conversions, etc.).
4. `ReferenceError: sealmetrics is not defined` must **not** appear.
5. The page must continue working normally (forms, navigation, UI).
Then disable the blocker and repeat: the calls must reach the SealMetrics backend exactly as before.
---
## Related
- [Tracker installation](/implementation/tracker/installation) — base setup, including the pre-load queue stub for deferred loading.
- [Tracker API reference](/implementation/tracker/api-reference) — full `sealmetrics()`, `conv()`, and `micro()` signatures.
- [Google Tag Manager integration](/integrations/google-tag-manager) — recommended setup for GTM.
- [Conversions Don't Match Your ERP, CRM, or Database](/troubleshooting/erp-crm-database-discrepancy) — diagnose substantial discrepancies between SealMetrics and your source of truth.
## Sealmetrics Tag Not Firing in GTM (Consent Mode)
URL: https://docs.sealmetrics.com/troubleshooting/gtm-consent-mode-blocking
# Sealmetrics Tag Not Firing in GTM (Consent Mode)
The single most common cause of "Sealmetrics is missing data" is a Google Tag Manager container where the Sealmetrics tag is **gated behind consent** — either by GTM Consent Mode settings on the tag or by a consent management platform (Cookiebot, OneTrust, Usercentrics, Didomi, etc.) that blocks Custom HTML tags until the visitor clicks "Accept".
Sealmetrics is **cookieless and consentless by design**: it sets no cookies and uses no persistent identifiers, so it does not require consent to run. Gating it behind a consent banner does not add any compliance benefit — it only removes from your reports every visitor who ignores or declines the banner, which is routinely 30–70% of traffic.
---
## Symptoms
- Traffic in Sealmetrics dropped sharply the day a CMP or Consent Mode went live.
- Sealmetrics shows far fewer entrances than your server logs or ad platform clicks.
- Data only appears for visits where the tester clicked "Accept all" on the banner.
- In GTM Preview, the Sealmetrics tag shows as not fired or waiting for consent on page load.
---
## Diagnosis
1. **Open your site in a private window** (no prior consent choice stored).
2. Open **Developer Tools → Network** and filter by `sealmetrics`.
3. Load a page and **do not interact with the consent banner**.
- If no request to `t.js` appears until you click "Accept", the tag is consent-gated.
4. Confirm in **GTM Preview mode**: select the pageview event and check the Sealmetrics tag's status. A tag held back by Consent Mode does not appear under **Tags Fired** on page load.
5. Cross-check the dashboard: the **Last hit** timestamp on the **Overview** report updates within seconds of an unblocked hit. If it only moves after you grant consent, you have confirmed the cause.
---
## Solution
### 1. Remove the consent gate from the Sealmetrics tag
In GTM:
1. Open the Sealmetrics tag (Custom HTML or template tag).
2. Go to **Advanced Settings → Consent Settings**.
3. Select **No additional consent required**.
4. Make sure the tag's **trigger** is `Initialization - All Pages` (or `All Pages`) — not a custom "consent granted" event pushed by your CMP.
5. If your CMP has its own "auto-blocking" feature that rewrites or blocks scripts by domain, add `t.sealmetrics.com` (or your [first-party tracker domain](/implementation/tracker/first-party)) to its allowlist of non-consent-required vendors.
6. Publish the container.
This is the configuration recommended in the [Google Tag Manager integration guide](/integrations/google-tag-manager): Sealmetrics is cookieless and consentless by design, so a CMP should not block it.
### 2. Use the canonical GTM pattern (stub + `?auto=0`)
If other tags in your container call `sealmetrics(...)` and the load order is not guaranteed, use the canonical pattern documented in [Advanced GTM Integration](/integrations/google-tag-manager-advanced): an inline **buffer stub** plus the tracker loaded with **`?auto=0`**, and a separate tag that fires the pageview manually.
```html
```
The stub queues any call made before the library loads and the library drains the queue in order, so no event is lost and no duplicate pageview is sent. On a single-page application where you also fire SPA pageviews manually from GTM, add `&spa=0` to the script URL as well, so the tracker's automatic pageview on route changes does not double-count your manual one — see [Duplicate pageviews](/troubleshooting/duplicate-pageviews).
---
## What NOT to do
- **Do not fire the Sealmetrics tag on your CMP's "consent granted" event.** That trigger structurally excludes everyone who declines or ignores the banner, and it fires late — after the pageview context you wanted to measure.
- **Do not require `analytics_storage` consent for the tag.** Sealmetrics does not use cookies or any storage, so that consent signal is irrelevant to it.
- **Do not delete the tag from GTM to "fix" a CMP conflict.** Configure the exception instead — otherwise you keep the banner problem and lose all measurement.
---
## Related
- [Google Tag Manager integration](/integrations/google-tag-manager) — standard setup, including the recommended consent settings.
- [Advanced GTM Integration](/integrations/google-tag-manager-advanced) — the stub + `?auto=0` canonical pattern in full detail.
- [What is Consentless Analytics?](/security-privacy/consentless-analytics) — why Sealmetrics does not need a consent gate.
- [Fixing `ReferenceError: sealmetrics is not defined`](/troubleshooting/sealmetrics-is-not-defined) — protecting direct `sealmetrics.*` calls in GTM tags.
## Tracker Blocked by Content Security Policy (CSP)
URL: https://docs.sealmetrics.com/troubleshooting/csp-errors-domains-to-allow
# Tracker Blocked by Content Security Policy (CSP)
If your site sends a `Content-Security-Policy` header (or meta tag) that does not include the Sealmetrics tracker domain, the browser will refuse to load the script and/or refuse to send the tracking beacon — and you will see **zero data**, even though the snippet is installed correctly.
---
## Symptoms
- No requests to `t.sealmetrics.com` in the Network tab, even though the `
```
If you only queue `conv()` / `micro()` calls (never pageviews), you don't need `?auto=0` — the automatic pageview is the only one and is what you want. This anti-pattern is described in detail in [Advanced GTM Integration](/integrations/google-tag-manager-advanced#anti-pattern-stub-without-auto0).
---
## Cause 3: Manual SPA pageviews without `?spa=0`
On single-page applications the tracker detects route changes by itself (it hooks `pushState`, `replaceState`, and `popstate`) and fires an automatic pageview on every URL change. That automatic firing is deduplicated **only against the URL not changing** — the tracker skips a hit when `location.href` is still the same, but it has no way of knowing that *you* also fired a pageview manually for that same navigation.
So if your own code (for example a GTM tag on a `virtualPageView` / History Change trigger) calls `sealmetrics({ group: ... })` on each route change **and** the script URL does not include `?spa=0`, every SPA navigation is counted twice:
- the tracker's automatic pageview (without your dynamic grouping), plus
- your manual pageview (with the grouping).
**Fix:** add `&spa=0` to the script URL. The SPA listeners stay installed and keep the internal URL/referrer state up to date — only the *automatic* pageview on navigation is suppressed, so your manual call still carries the correct URL and referrer:
```html
```
`auto` and `spa` are independent flags: `?auto=0` governs only the **initial** pageview, `?spa=0` only the **navigation** pageviews. Full GTM instrumentation with per-page grouping uses the stub plus both flags.
---
## What is already protected (don't chase these)
- **Iframes.** The tracker only auto-fires pageviews and installs SPA listeners in the top-level window, so an embed (e.g. a Shopify Web Pixel sandbox) does not add duplicate pageviews.
- **Reloading the same URL in a SPA.** The automatic SPA pageview only fires when the URL actually changed, so `replaceState` calls to the same URL do not double-count.
---
## Verification
After the fix, repeat the [60-second diagnosis](#diagnosis-in-60-seconds): exactly one `/event` beacon per load and per navigation. Then watch the **Overview** report — Pageviews per Entrance should drop back to its historical ratio.
---
## Related
- [Advanced GTM Integration](/integrations/google-tag-manager-advanced) — the canonical stub + `?auto=0` pattern and its anti-patterns.
- [SPA Support](/implementation/tracker/spa-support) — how automatic SPA navigation tracking works.
- [Tracker installation](/implementation/tracker/installation) — the standard, single-include setup.
- [Duplicate conversions](/troubleshooting#duplicate-conversions) — the equivalent problem for `conv()` calls.
## Report Dates Don't Match Another Tool
URL: https://docs.sealmetrics.com/troubleshooting/dates-timezone-mismatch
# Report Dates Don't Match Another Tool
You compare "Tuesday" in Sealmetrics with "Tuesday" in another analytics tool, your ad platform, or your backend — and the numbers are shifted, especially around the start and end of the range. In most cases nothing is missing: **the two systems are cutting the day at a different midnight.**
---
## How Sealmetrics assigns dates
Every hit is stamped with a **date calculated in your site's timezone** at the moment it is ingested. The day rolls over at **midnight local time for the site** — not at UTC midnight, and not at your server's timezone.
Concretely: a hit at 23:30 New York time on Monday belongs to Monday in a site configured with `America/New_York`, even though in UTC it is already Tuesday 04:30. A tool that buckets by UTC would put that same hit on Tuesday.
New sites default to **Europe/Madrid** unless you change it.
---
## Symptoms
- Daily totals are consistently shifted by a few hours' worth of traffic against the other tool, but multi-day totals for the same window roughly match.
- "Yesterday" disagrees between tools, while "last 30 days" is close.
- Discrepancies concentrate on the **first and last day** of the compared range.
- A campaign launched late in the evening shows on one day in Sealmetrics and the next day elsewhere.
---
## Diagnosis
1. **Check both timezones.** Find the site's timezone in Sealmetrics (see below) and the property/report timezone of the other tool (GA4 property timezone, ad platform account timezone, your database's `GROUP BY` timezone).
2. **Compare a wide window, not a single day.** Pick a closed multi-day range (e.g. the 1st to the 15th) in both tools. If the total converges but individual days don't, the mismatch is the day cutoff — not lost data.
3. **Look at the edges.** With different timezones, each day boundary moves a fixed number of hours of traffic from one day to its neighbor. The size of the daily shift should be consistent with the hour offset between both timezones.
If multi-day totals do **not** converge either, you are looking at a different problem — see [Numbers lower than another tool](/troubleshooting/lower-numbers-than-other-tools) and [Reconciling with your ERP/CRM](/troubleshooting/erp-crm-database-discrepancy).
---
## Solution: align the timezones
Ideally, set the same timezone in Sealmetrics and in the tools you reconcile against.
To change the site's timezone in Sealmetrics:
1. In the left sidebar, expand **Site Config** and click **Settings**.
2. On the **General** tab, find the **Timezone** field.
3. Pick your timezone (searchable by name or country) and click **Save Changes**.
Full walkthrough: [How to Change Your Time Zone](/platform/account-setup/how-to-change-timezone).
**Note:**
The date of each hit is computed **at ingest time** with the timezone the site had at that moment, and stored. Changing the timezone re-buckets hits from that point forward; already-stored days are not recalculated. Expect one transition day with a slightly short or long bucket, then clean alignment.
---
## Prevention
- Set the site timezone **when you create the site**, before collecting data, and match it to the timezone of the tools you report against.
- When reconciling with a database or ERP, always state the timezone of both sides in the comparison query — this is one of the standard checklist items in the [ERP/CRM reconciliation guide](/troubleshooting/erp-crm-database-discrepancy).
---
## Related
- [How to Change Your Time Zone](/platform/account-setup/how-to-change-timezone) — step-by-step with defaults.
- [Date Range selection](/reports/date-range) — how report periods are defined.
- [Reconciling Sealmetrics with Your ERP, CRM, or Database](/troubleshooting/erp-crm-database-discrepancy) — when the gap is more than a day-boundary shift.
## No Data From a New or Staging Domain
URL: https://docs.sealmetrics.com/troubleshooting/unauthorized-domain
# No Data From a New or Staging Domain
Every Sealmetrics site has a list of **authorized domains** — the websites allowed to send tracking data to it. When a hit arrives from a page whose domain is not on that list, the platform **rejects it silently**: the browser still receives a normal `204 No Content` response, no error appears in the console, and nothing is stored. This is a common cause of "the snippet is installed but there is no data".
---
## How domain validation works
For every incoming event (pageviews, conversions, and microconversions alike), the platform extracts the domain from the page URL the tracker reports and checks it against the site's authorized domains:
- **Exact match** is accepted: `example.com` on the list authorizes `example.com`.
- **Subdomains of an authorized domain** are accepted automatically: `example.com` on the list also authorizes `shop.example.com` and `reservations.example.com`.
- A leading `www.` is normalized away, so `www.example.com` and `example.com` are equivalent at validation time.
- **A site with no domains configured rejects everything.** At least one domain is required for tracking to work.
- An event whose page URL yields no usable domain at all is also rejected.
Rejection is deliberate and silent by design — the tracker never breaks the page or logs errors for the visitor.
---
## Symptoms
- `t.js` loads with `200` and the `/event` beacon returns `204` in the Network tab, but the **Last hit** timestamp on the **Overview** report never updates.
- Data flows from your main website but not from a **staging/preview environment** (`staging.example.com` works if `example.com` is listed — but `example-staging.com` or `preview.vercel.app` will not).
- No data from a **second production domain**: a country-specific domain (`example.fr`), a landing page builder domain, or a checkout hosted on a different registrable domain.
- Tracking stopped after a **domain migration or rebrand** (the site still lists only the old domain).
---
## Diagnosis
1. Open the affected page and note its exact hostname.
2. In the dashboard, open the site's **Domains** tab and compare the hostname against the list, remembering the matching rules above: subdomains of a listed domain pass; a *different* registrable domain does not.
3. Check the other usual silent-drop suspects if the domain looks right: wrong Site ID in the snippet, or the page never firing the beacon at all (see [Quick Diagnostics](/troubleshooting#quick-diagnostics)).
---
## Solution: add the domain
1. Open the site in the dashboard.
2. Go to the **Domains** tab.
3. Type the domain (e.g. `example.com` or `sub.example.com`) in the input field and add it.
The domain appears in the list and tracking is authorized immediately — reload the affected page and confirm that the **Last hit** timestamp updates. Full walkthrough: [How to Add Domains to Your Site](/platform/account-setup/how-to-add-domains).
**Tip:**
You rarely need to list subdomains: adding `example.com` covers all its subdomains. You **do** need a separate entry for every distinct registrable domain — `example.fr`, `example-landing.com`, `checkout-partner.com` — that hosts pages with your tracker.
---
## Prevention
- When creating a site, add **every domain that will carry the tracker**: production domains, country domains, landing page builder domains, and any externally hosted checkout or confirmation pages.
- One Sealmetrics site is meant to track one domain (plus its subdomains) or one coherent set of your own domains — not arbitrary third-party sites. If a partner site needs measurement, give it its own site.
- After a domain migration, update the Domains tab **before** the DNS switch so no traffic is dropped during the transition.
---
## Related
- [How to Add Domains to Your Site](/platform/account-setup/how-to-add-domains) — adding, listing, and removing domains.
- [Troubleshooting overview](/troubleshooting) — checking Site ID and script installation.
- [Reconciling Sealmetrics with Your ERP, CRM, or Database](/troubleshooting/erp-crm-database-discrepancy) — off-domain confirmation pages as a cause of missing conversions.
## Data Taking Longer Than Expected to Appear
URL: https://docs.sealmetrics.com/troubleshooting/data-delay
# Data Taking Longer Than Expected to Appear
Sealmetrics processes hits in **seconds, not hours**. Each hit travels through an ingestion pipeline — the tracking pixel receives it, hands it to a processing queue, and a consumer writes it to the reporting database — and the whole trip normally completes within seconds of the visit. There is no daily batch and no scheduled report refresh to wait for.
If data seems delayed, the goal of this page is to distinguish the three very different situations that look identical at first glance: **the hit never arrived**, **the hit arrived but your report isn't looking at it**, and **the pipeline is briefly catching up**.
---
## First check: the "Last hit" timestamp
The fastest source of truth is the **Last hit** timestamp at the top right of the **Overview** report. It shows when the most recent hit for the site was received, and it updates within seconds of a tracked visit.
1. Open the **Overview** report for the site.
2. Visit your website in another tab (with no ad blocker interfering).
3. Reload the Overview: **Last hit** should move to "seconds ago".
| Observation | Meaning |
|---|---|
| **Last hit updates within seconds** | Ingestion is healthy. If a report still looks empty, the problem is on the report side — see below. |
| **Last hit does not update after your test visit** | The hit never arrived. This is not a delay — it's a tracking problem. |
| **Last hit lags by minutes during a big traffic spike** | Brief processing delays while the queue catches up are normal under spikes; data is not lost, it arrives slightly later. |
---
## If "Last hit" updates but a report looks empty
The hit arrived; the report just isn't showing it:
- **Date range.** Make sure the selected period includes **today** — several default ranges end yesterday. See [Date Range](/reports/date-range).
- **Timezone.** "Today" is defined by the **site's timezone**, not yours. Near midnight, your test hit may fall on a different report day than you expect — see [Report dates don't match another tool](/troubleshooting/dates-timezone-mismatch).
- **Filters and segments.** An active filter (source, country, content group…) can hide the fresh hit.
- **The specific report.** Conversions appear in the **Conversions** report, not as pageviews — a successful conversion test doesn't move the Pageviews number.
---
## If "Last hit" does not update at all
Then nothing is being ingested for the site and there is no delay to wait out. Work through the usual silent causes, in order of likelihood:
1. **The beacon never left the browser** — script blocked or missing. See [Quick Diagnostics](/troubleshooting#quick-diagnostics) and [CSP errors](/troubleshooting/csp-errors-domains-to-allow).
2. **The tag is gated behind consent** in GTM — see [GTM Consent Mode blocking](/troubleshooting/gtm-consent-mode-blocking).
3. **The page's domain is not authorized** for the site — the hit is rejected silently. See [Unauthorized domain](/troubleshooting/unauthorized-domain).
4. **Your test traffic is being filtered as a bot** — automated or scripted visits don't count. See [Test traffic blocked as bot](/troubleshooting/test-traffic-blocked-as-bot).
---
## When to contact support
If the site receives real traffic, the tracker verifies correctly in the Network tab (beacons returning `204`), and **Last hit** still stalls for more than a few minutes, contact **support@sealmetrics.com** with your Site ID and the timestamp of a test visit — that is enough to trace the hit through the pipeline.
---
## Related
- [See Your Data Flow](/getting-started/see-your-data-flow) — what a healthy first-data experience looks like.
- [Overview Report](/reports/overview) — where the Last hit timestamp lives.
- [Quick Start — verification](/getting-started/quick-start) — the standard install verification steps.
## Conversions Not Appearing
URL: https://docs.sealmetrics.com/troubleshooting/conversions-not-appearing
# Conversions Not Appearing
Pageviews work, but a conversion you fired never shows up in the **Conversions** report. Run through this checklist in order — it covers the causes from most to least common, and each step tells you how to verify it objectively in the browser.
---
## 1. The snippet uses the correct signature
```javascript
sealmetrics.conv(type, amount, properties);
```
- **`type`** (string, required) — the conversion label you will see in the report, e.g. `'purchase'`, `'lead'`, `'signup'`. A missing or empty type is not a conversion.
- **`amount`** (number, optional) — the monetary value. Omit it or pass `0` for non-monetary conversions.
- **`properties`** (object, optional) — custom key-value data.
```javascript
// Purchase with value
sealmetrics.conv('purchase', 99.99);
// Lead without monetary value
sealmetrics.conv('lead', 0);
```
Full syntax and examples: [Conversions](/implementation/tracker/conversions).
## 2. The amount is a real number, not a string
The tracker only attaches the value when `amount` is a JavaScript **number**. If your template interpolates it as a string — `sealmetrics.conv('purchase', "99.99")` — the conversion is sent **without a value**: it appears in the report but with no revenue.
Watch out for locale formats too: `"1.299,00"` or `"99,99"` are not valid numbers. Convert server-side, or with `parseFloat()` on a dot-decimal string, before calling `conv()`.
```javascript
// Wrong — string amount, revenue is dropped
sealmetrics.conv('purchase', '99.99');
// Right — numeric amount
sealmetrics.conv('purchase', 99.99);
```
## 3. The base pixel fires first on the same page
The conversion call is not standalone: the base tracker (`t.js`) must be present **on the confirmation page** and its pageview must fire **before** `sealmetrics.conv(...)`. If the conversion code runs before the library loads, you either get a `ReferenceError` (call lost) or an unattributable conversion.
This is the single most common root cause of substantial conversion gaps — the full explanation, firing-order diagram, and fixes are in [Reconciling Sealmetrics with Your ERP, CRM, or Database](/troubleshooting/erp-crm-database-discrepancy). To protect calls that may run before the library loads, use the stub buffer from [Fixing `ReferenceError: sealmetrics is not defined`](/troubleshooting/sealmetrics-is-not-defined).
## 4. The conversion fires for every variant of the flow
Verify the whole matrix, not just your happy path: every payment method (card, PayPal, bank transfer…), every language/country version, mobile and desktop themes, and confirmation pages hosted on external domains. Any variant that skips the page with the `conv()` call silently under-counts. Off-domain confirmation pages also need the domain authorized on the site — see [Unauthorized domain](/troubleshooting/unauthorized-domain).
## 5. Verify the beacon in the Network tab
1. Open **Developer Tools → Network**, filter by `sealmetrics`.
2. Complete a test conversion (real flow, not just pasting into the console — though the console works for a first smoke test).
3. On the confirmation page you should see, in this order:
- the base pixel's pageview beacon, then
- a second `/event` beacon whose payload contains `"e":"purchase"` (your type) and `"v":99.99` (your amount).
4. Both should return `204 No Content`.
If the conversion beacon has `"e"` but no `"v"`, you are hitting step 2 (string amount). If there is no conversion beacon at all, the call never executed — check for JavaScript errors in the Console and for consent-gated tags ([GTM Consent Mode blocking](/troubleshooting/gtm-consent-mode-blocking)).
## 6. Check the report the right way
1. Open the **Conversions** report (sidebar → **Conversions**).
2. Make sure the top-right toggle is on **Conversions** — if you fired `sealmetrics.micro(...)`, the event lands in the **Microconversions** view instead.
3. Set the date range to **today** (site timezone — see [Dates & timezone mismatch](/troubleshooting/dates-timezone-mismatch)).
4. Reload the report. Hits arrive in seconds, so the **Last hit** timestamp at the top right of the **Overview** report should already show your test — if it doesn't move, nothing is being ingested (see [Data delay](/troubleshooting/data-delay)).
---
## Still missing?
If the beacon leaves the browser with the right payload, returns `204`, and the conversion still never appears, contact **support@sealmetrics.com** with the Site ID, the conversion type, and the timestamp of the test — that is enough to trace it.
---
## Related
- [Conversions — tracker reference](/implementation/tracker/conversions) — full `conv()` syntax, properties, and item arrays.
- [Conversions Report](/reports/conversions) — reading the report and the Conversions/Microconversions toggle.
- [Reconciling Sealmetrics with Your ERP, CRM, or Database](/troubleshooting/erp-crm-database-discrepancy) — substantial gaps between real orders and reported conversions.
- [Measure conversions](/getting-started/measure-conversions) — guided first-conversion setup.
## Numbers Lower Than Another Tool
URL: https://docs.sealmetrics.com/troubleshooting/lower-numbers-than-other-tools
# Numbers Lower Than Another Tool
Two analytics tools measuring the same site **never report identical numbers** — they count different things, filter different traffic, and cut the day at different moments. Before treating a gap as a tracking bug, check whether it is explained by these three legitimate model differences. If, after accounting for them, the gap is still large and unexplained, then troubleshoot it as missing data.
---
## 1. Entrances are not GA4 sessions
Sealmetrics' primary traffic metric is the **Entrance**: it counts a new entrance when a visitor arrives with an empty referrer or from a different domain than yours. There is no session timeout, no session re-opening after 30 minutes of inactivity, and no session splitting at midnight — because all of those require persistent identifiers Sealmetrics deliberately does not use.
GA4's *session* is a different construct (timeout-based, identifier-based), so comparing Entrances to Sessions is comparing two different definitions — a stable percentage difference between them is expected and not a bug.
Read the definition in full: [How Sealmetrics Calculates Entrances](/reports/insights/how-sealmetrics-calculates-entrances).
**What to check:** compare like with like where possible (Pageviews against Pageviews is far closer to apples-to-apples than Entrances against Sessions), and compare **trends** rather than absolute values.
## 2. Bots are filtered at ingest
Sealmetrics rejects known bot and tool traffic **before it is stored**: hits from search engine crawlers, SEO tools, link-preview fetchers, uptime monitors, HTTP libraries, and headless/automation browsers never enter your reports, and burst behavior (many pageviews from one session within seconds) is rate-limited too. See [Bot Detection & Traffic Quality](/security-privacy/bot-detection).
A tool with weaker (or different) bot filtering will report that traffic as visits. This inflates the *other* tool rather than shrinking Sealmetrics — but from your point of view it looks the same: "Sealmetrics shows less".
**What to check:** in the other tool, look at the traffic Sealmetrics doesn't show — hostnames, user agents, datacenter-heavy geographies, sessions with zero engagement. Bot traffic usually concentrates in obvious pockets.
## 3. No sampling, no consent loss — the gap can point the other way
Sealmetrics processes **every hit** it receives: reports are never sampled or modeled. And because it is consentless, it also measures the visitors who decline or ignore a consent banner — traffic that consent-gated tools structurally lose. On sites with a consent banner, Sealmetrics typically reports **more** traffic than GA4, not less.
So the *direction* of the gap is diagnostic:
| Observation | Likely explanation |
|---|---|
| Sealmetrics moderately below the other tool, stable ratio over time | Definition differences (entrances vs sessions) and bot filtering — expected |
| Sealmetrics above the other tool | Consent loss and ad blockers hitting the other tool — expected |
| Sealmetrics drastically below, or the ratio suddenly changed | A real tracking problem — go to the checklist below |
The full side-by-side comparison of both measurement models is in [GA4 vs Sealmetrics](/faq/ga4-vs-sealmetrics).
---
## Before comparing, normalize the comparison
- **Same date window and same timezone** on both sides — see [Dates & timezone mismatch](/troubleshooting/dates-timezone-mismatch).
- **Same scope**: one Sealmetrics site vs one GA4 property covering the same hostnames.
- **Same metric family**: pageviews vs pageviews, conversions vs conversions.
- **Closed periods**: compare finished days, not today-so-far.
---
## If the gap is still unexplained
A sudden or very large deficit on the Sealmetrics side usually means hits are being lost before ingestion. Work through:
1. [GTM Consent Mode blocking](/troubleshooting/gtm-consent-mode-blocking) — the number one cause of "Sealmetrics suddenly shows less".
2. [CSP errors](/troubleshooting/csp-errors-domains-to-allow) — the tracker or its beacon blocked by policy.
3. [Unauthorized domain](/troubleshooting/unauthorized-domain) — part of your traffic served from a domain the site doesn't authorize.
4. [Reconciling with your ERP/CRM](/troubleshooting/erp-crm-database-discrepancy) — for conversion-count gaps specifically.
---
## Related
- [GA4 vs Sealmetrics — Complete Comparison](/faq/ga4-vs-sealmetrics)
- [How Sealmetrics Calculates Entrances](/reports/insights/how-sealmetrics-calculates-entrances)
- [Bot Detection & Traffic Quality](/security-privacy/bot-detection)
- [Data Discrepancy with Other Tools](/troubleshooting#data-discrepancy-with-other-tools) — the short version in the overview.
## Test Visits Not Appearing (Filtered as Bot Traffic)
URL: https://docs.sealmetrics.com/troubleshooting/test-traffic-blocked-as-bot
# Test Visits Not Appearing (Filtered as Bot Traffic)
You are testing the tracker with an automation tool or a script, the beacon returns `204 No Content`, and yet nothing appears in the reports. In most cases nothing is broken: **the platform is doing its job**, filtering traffic that identifies itself as automated so it never pollutes your reports. Real visitors are unaffected — the filters below only catch tools and abnormal behavior.
---
## How your test traffic gets filtered
### 1. The global User-Agent blocklist
Every incoming hit is checked against a global blocklist of known non-human User-Agent patterns. It covers, among others:
- **CLI and HTTP clients:** `curl/`, `Wget/`, `HTTPie/`, `python-requests`, `axios/`, `node-fetch`, `Go-http-client`, `okhttp/`…
- **Headless and automation browsers:** `HeadlessChrome`, `PhantomJS`, `Puppeteer`, `Playwright`, `Selenium`, `webdriver`…
- **Load-testing tools:** `JMeter`, `k6/`, `Locust`, `artillery`, `ApacheBench`, `wrk/`…
- **Generic substrings:** any User-Agent containing `bot`, `crawler`, `spider`, or `scraper`.
This is why a Playwright or Selenium run with the default User-Agent, a `curl` smoke test, or a custom UA like `MyCompany-TestBot` never shows up. The generic `bot` substring match is deliberately aggressive — it also catches home-made User-Agents you might not think of as "bots".
### 2. The behavioral rate limit
Independently of the User-Agent, a session that fires a burst of pageviews — more than a handful within a couple of seconds — is treated as a bot and blocked for a period. Scripted click-through tests that load pages as fast as possible trip this even with a legitimate browser User-Agent.
Both filters reject silently: the browser (or script) still gets a normal `204` response, so nothing on the client side reveals the hit was discarded.
---
## Diagnosis
1. **Check the User-Agent your tool sends.** In DevTools → Network, click the beacon request and inspect the `User-Agent` request header; in scripts, print the UA you configured. Compare it against the categories above — including the generic `bot`/`crawler`/`spider`/`scraper` substrings.
2. **Repeat the test manually in a normal browser** (regular Chrome/Firefox/Safari window, no automation). If the manual visit appears within seconds — check the **Last hit** timestamp on the **Overview** report — ingestion is healthy and your automated traffic is being filtered, as designed.
3. **Check the pace.** If your script navigates several pages per second with the same browser profile, slow it down to human speed and retry.
---
## Solution
- **For install verification, use a real browser.** A normal browsing session is the ground truth for "does tracking work" — automation is unnecessary for that check.
- **If you must automate, don't look like a bot:**
- Configure a standard desktop browser User-Agent instead of the tool's default (Playwright, Selenium, and Puppeteer all allow overriding the UA). Make sure the value contains none of the blocked substrings — in particular avoid `Headless` and the word `bot` anywhere in it.
- Pace navigation like a human: leave a few seconds between pageviews rather than firing them back-to-back.
- **Accept that load tests will not appear in reports.** That is the desired outcome — a load test that inflated Entrances would be a data-quality incident. Verify load-test delivery at the HTTP level (`204` responses), not in the dashboard.
**Tip:**
If what you actually want is the reverse — your office or team's *genuine* browsing polluting the reports — don't fight the bot filters; exclude those IPs explicitly instead. See [IP Exclusions](/platform/settings/tracking/ip-exclusions).
---
## What NOT to do
- **Do not benchmark "tracking accuracy" with automated traffic.** The filters make automated hits a biased sample by design; conclusions drawn from them are meaningless.
- **Do not disguise sustained synthetic traffic as human to make it count.** You would be permanently polluting your own entrances, conversion rates, and attribution to win a test.
---
## Related
- [Bot Detection & Traffic Quality](/security-privacy/bot-detection) — the full multi-layer filtering model.
- [IP Exclusions](/platform/settings/tracking/ip-exclusions) — excluding your own team's real traffic.
- [Data delay](/troubleshooting/data-delay) — distinguishing filtered traffic from delayed traffic.
- [Troubleshooting overview](/troubleshooting) — quick installation diagnostics.
## Conversions Don't Match Your ERP, CRM, or Database
URL: https://docs.sealmetrics.com/troubleshooting/erp-crm-database-discrepancy
# Conversions Don't Match Your ERP, CRM, or Database
Your **ERP, CRM, or internal database is the source of truth** for what actually happened in your business: the orders that were placed, the leads that were captured, the contracts that were signed. SealMetrics is the measurement layer on top of that reality.
When both systems are correctly wired, **SealMetrics should reconcile with your source of truth with only a minimal discrepancy** — typically a small percentage caused by edge cases (users disabling JavaScript, network failures at the exact moment of the request, manual orders entered directly into the back office, refunds, etc.).
If the gap you are seeing is **substantial** — for example, your ERP shows 1,000 orders this month and SealMetrics shows 600 — this is almost never a measurement bug on the platform side. In our experience, it comes down to one of two implementation problems on the website, with a long tail of secondary causes.
**Warning:**
The **base pixel (`t.js`) must finish loading and register the pageview *before* `sealmetrics.conv(...)` is called** for any conversion or microconversion. The conversion call is not standalone — it attaches to the session created by the base pixel. If the order is wrong, or the base pixel is missing on the confirmation page, the conversion is sent without a session and the platform cannot count or attribute it correctly. This is the first thing to verify on any reconciliation issue.
---
## The Expected Behavior
Before digging into the causes, it helps to establish what "normal" looks like:
- **Small discrepancy (under ~5%)** — Expected. JavaScript blockers, network errors, users abandoning the thank-you page before the request leaves, very old browsers, etc.
- **Moderate discrepancy (5%–15%)** — Worth investigating. Usually a partial firing issue: the pixel works for most flows but fails on a specific payment method, language version, or checkout variant.
- **Substantial discrepancy (over 15%)** — Almost always an implementation issue. One of the two causes below is responsible in the vast majority of cases.
---
## Cause 1: The Conversion Pixel Is Not Firing on Every Conversion
The SealMetrics conversion pixel (`sealmetrics.conv(...)`) must be executed **every single time** a real conversion happens in your business. If it is not called, SealMetrics has no way to know the conversion exists — and your ERP will record an order that never reached the dashboard.
### How to verify it
1. Place a **test order, lead, or signup** through the same flow your real users follow.
2. Open the browser **Developer Tools → Network tab** before the conversion completes.
3. Filter by `sealmetrics` or `pixel`.
4. When you reach the thank-you / confirmation page, you should see a **beacon request** going out to `t.sealmetrics.com` containing the conversion event and amount.
If you do **not** see that request, the conversion pixel is not being called.
### Typical reasons the conversion pixel is not called
- The thank-you page is **hosted on a different domain** (for example, the payment gateway's domain) and the pixel is not installed there.
- The thank-you page is **skipped entirely** for certain payment methods (PayPal, Bizum, bank transfer, in-store pickup, etc.) — orders complete server-side and the user never sees the page where the pixel lives.
- The pixel is wrapped in a **conditional** (`if`) that excludes some scenarios — repeat customers, logged-in users, specific countries, B2B orders, etc.
- The order is created **manually in the back office** by a sales rep, by phone, or by a customer service agent. These conversions never trigger a browser-side event.
- A **JavaScript error earlier in the page** prevents the script from executing the conversion line.
- The conversion fires inside an **iframe** or a **modal** that is removed before the network request leaves the browser.
### How to fix it
- Make sure the conversion pixel lives on **every confirmation page**, including those served by external payment processors or third-party checkouts.
- For payment methods that skip the browser confirmation (PayPal IPN, bank transfer, manual orders), use a **server-side fallback** or fire the conversion when the user is redirected back to your site.
- Remove conditionals that exclude segments of real conversions.
- Validate your checkout flow end-to-end for **each payment method and country** you support.
---
## Cause 2: The Base Pixel Is Not Firing Before the Conversion Pixel
The base pixel (the `t.js` tracker that registers the pageview) is what gives SealMetrics the **session context** needed to attribute a conversion. The conversion pixel does not work in isolation — it relies on the base pixel having loaded and registered the pageview **first**.
If the conversion pixel is called **before** the base pixel has finished loading and registering the pageview, the conversion request will be sent without the session it belongs to, and the platform may not be able to count or attribute it correctly.
### Required firing order
Every conversion and microconversion must follow this sequence on the confirmation page:
```text
Correct order (conversion is counted)
────────────────────────────────────────────────────────────────
1. Browser parses
```
No consent mode, no CMP integration, no TIA. Pageviews start immediately. Conversions are the only real work, and they are one call:
```javascript
sealmetrics.conv('purchase', 149.99, {
currency: 'EUR',
payment_method: 'credit_card',
items: [
{ product_name: 'Camiseta', price: 19.95, quantity: 2, category: 'Ropa' },
{ product_name: 'Pantalón', price: 49.99, quantity: 1, category: 'Ropa' }
]
});
```
Intent signals short of a conversion use `sealmetrics.micro('add_to_cart')`, which is what fills the [funnel report](/reports/funnel). Full reference: [tracker API](/implementation/tracker/api-reference) and [conversions](/implementation/tracker/conversions).
If you'd rather not do it by hand, the [agentic package](/integrations/agentic-package) has an AI assistant create the account, generate the snippet and verify instrumentation from chat.
---
## When to Choose Google Analytics
GA4 is genuinely the better tool in several situations, and pretending otherwise would waste your time.
**You depend on Google Ads.** Conversion import, Smart Bidding signals and remarketing audience sync are native to GA4 and Sealmetrics does not offer them. If automated bidding drives your revenue, this alone can be decisive.
**You need predictive metrics.** Purchase probability, churn probability and predicted revenue have no Sealmetrics equivalent. Sealmetrics reports observed behaviour, not forecasts.
**You need user-level and cross-device analysis.** Individual journeys, cohort retention and cross-device stitching require exactly the persistent identifier Sealmetrics refuses to carry. This is a design boundary, not a roadmap item.
**You need city-level geography.** Country is as granular as timezone-derived geo gets.
**You operate primarily outside the EU.** Where rejection rates are low, GA4's consent-driven loss is much less severe — though ad blockers remain a global factor.
**You have deep existing GA infrastructure.** Years of history, BigQuery pipelines, trained analysts and custom dashboards are real switching costs.
---
## When to Choose Sealmetrics
**Your traffic is substantially EU.** The gap between measuring a biased fifth of your audience and measuring all of it changes what your reports mean, not just how big the numbers are.
**You want to drop the consent banner.** Not just for the data — for the conversion rate and the UX. That only works if analytics is the sole reason for the banner, so audit what else the CMP gates first.
**Marketing attribution drives budget decisions.** Conversions, revenue, micro-conversions and custom channel rules are standard on every plan, and campaign attribution survives regardless of consent.
**You want AI over your analytics.** LENS for anomaly detection and natural-language questions, the MCP server so your existing assistant reads live data, and EU-hosted inference if US LLM providers are unacceptable to your DPO.
**Your DPO won't sign off on GA4.** Schrems II, IP processing and consent complexity are common blockers. Sealmetrics was designed for the legitimate-interest route and documents it regulator by regulator.
**You run many sites or a large team.** Unlimited sites and users on every plan.
---
## Migration Guide
### Step 1 — Audit what you have
Document the metrics you actually use, the events and e-commerce tracking configured, your integration points, and who needs access. Then be explicit about what you will lose: Google Ads attribution, predictive metrics, cross-device journeys, city-level geography, and your GA4 history — Sealmetrics does not import it.
Decide the approach. **Parallel running for 30–60 days** is strongly recommended over a hard cutover, because the numbers will differ and you want to understand why before you rely on them.
### Step 2 — Install Sealmetrics
Add the script tag, or add it via GTM as a Custom HTML tag on an All Pages trigger. Direct implementation is simpler and faster if GTM isn't already in place for other reasons. Verify with [see your data flow](/getting-started/see-your-data-flow).
### Step 3 — Map your events
This is the substance of the migration. Each GA4 conversion event becomes a `sealmetrics.conv()` call; each intent signal becomes `sealmetrics.micro()`. The [GA4 migration checklist](/guides/ga4-migration-checklist) walks through the mapping event by event.
### Step 4 — Run in parallel and reconcile
Expect Sealmetrics to report substantially more traffic in EU markets. Before concluding anything, check the differences you should expect:
- **Entrances ≠ GA4 sessions.** Different session-window definitions produce different counts even with identical traffic.
- **No unique visitors** to compare against GA4's.
- **Bot filtering differs.** Sealmetrics filters more aggressively and reports what it removed.
- **Attribution differs.** GA4 uses data-driven attribution by default; Sealmetrics is last-click.
Triangulate against something neither tool controls — Search Console clicks, ad platform click counts, or your order table. [Why your numbers differ](/troubleshooting/lower-numbers-than-other-tools) covers the common cases.
### Step 5 — Cut over
Remove the GA4 tag, take GA4 out of the CMP configuration, and simplify or remove the banner if analytics was its only purpose. Update the privacy policy. Keep the GA4 property archived and read-only for historical reference rather than deleting it.
---
## Frequently Asked Questions
### Is Sealmetrics really GDPR compliant without consent?
Yes, and via a stronger route than most vendors claim. Two rules apply and both are cleared. ePrivacy Article 5(3) — the rule that actually mandates cookie banners — governs storing or accessing information on a device, and Sealmetrics does neither, so the consent trigger never fires. The GDPR governs personal data, and none is stored: no cookies, no cross-site tracking, no IP-derived identifier. Under Recital 26 the dataset is therefore outside the Regulation's material scope, which means no Article 6 legal basis is needed at all. We deliberately do *not* claim legitimate interest, because invoking any Article 6 basis would concede that personal data is being processed.
That reasoning is documented against five regulators in the [compliance centre](/compliance). Your DPO should still review it — no vendor can grant you compliance — but it's a documented position rather than an assertion.
### Why isn't Sealmetrics blocked by ad blockers as often as GA4?
Blockers target cross-site trackers, ad servers, profile builders and well-known tracking domains. Sealmetrics is first-party only, serves no ads and builds no profiles, so there's little for filter lists to match.
It is not immune — no analytics tool is, and blocking rates vary by audience. First-party delivery from your own domain is the actual fix. See [ad blocker bypass](/security-privacy/adblocker-bypass).
### How accurate is Sealmetrics compared to GA4?
Sealmetrics isn't *more accurate* — it's *seeing visitors GA4 never had the chance to record*, plus attributing visits GA4 files as Direct.
For a real number rather than a claim: [Dreamplace Hotels](https://sealmetrics.com/case-studies/dreamplace-hotels/) measured **+30% more traffic than Google Analytics** and **15–20% more attributed sales** than their previous tool. That is a meaningful gap and a modest one — considerably smaller than the multipliers this category tends to advertise.
Don't take a figure from any article, ours included. Run both for 30 days, then check each against Search Console clicks or your ad platform's click counts. Your own gap is the only one that means anything.
### Can I run both at the same time?
Yes, and during migration you should. Sealmetrics measures every visitor; GA4 measures those who consented and aren't blocking it. You keep Google Ads integration while gaining complete measurement.
The catch: you still need the consent banner for GA4, so the UX benefit doesn't arrive until GA4 comes out.
### What about Google Consent Mode v2?
Consent Mode v2 fills the gap left by rejections with **modelled estimates** — statistical reconstructions, not observations. Modelling is better than a blank, but it's inference from the consenting subset projected onto a population that behaves differently, and it needs traffic volume thresholds before Google will model at all.
Sealmetrics measures every visitor directly, so there's nothing to model.
### Does Sealmetrics work with Google Tag Manager?
Yes, as a Custom HTML tag on an All Pages trigger, or via the [custom GTM template](/integrations/tag-management/gtm-template). Direct implementation in `` is simpler and loads faster if GTM isn't already required for other tags.
### What happens to my GA4 historical data?
It isn't imported — the data models are too different. Keep the GA4 property archived and read-only for historical reference, and export anything critical via the Data API or a BigQuery export before you stop maintaining it.
### How does Sealmetrics handle bot traffic?
Five layers: an IP blocklist checked in memory, User-Agent filtering, geographic validation, behavioural analysis and HMAC token validation. Sophisticated bots that fully mimic browsers still get through — true of every analytics tool including GA4 — but Sealmetrics reports what it filtered, so you can see the volume rather than assume it's gone. See [bot detection](/security-privacy/bot-detection).
### Can I track subdomains?
Yes, across `example.com`, `blog.example.com`, `app.example.com` and so on. Sessions continue across subdomains without the cookie-scoping complications GA4 has, because there is no cookie to scope — the session marker is computed identically on every page load.
### Does Sealmetrics work with A/B testing tools?
Yes. Your testing tool assigns variants; Sealmetrics measures pageviews and conversions. Pass the variant as a custom property on the conversion and you can break results down by variant in the [Properties report](/reports/properties).
### What's the data retention policy?
24 months, no consent required. That sits at the AEPD's maximum for consent-exempt analytics and inside the CNIL's 25-month window — staying at the ceiling is part of what makes the consentless basis hold, rather than a limitation we'd like to lift. Export before deletion if you need a longer archive.
### Can I self-host Sealmetrics?
No. Sealmetrics is cloud-only, hosted in Dublin, Ireland. Self-hosting would move GDPR controller responsibilities and infrastructure maintenance to you, and the pricing model assumes a managed service. If self-hosting is a hard requirement, Matomo offers that option.
### How does pricing scale?
Volume-based on monthly events: 5M on Growth (€599/mo, €499 annual), 15M on Scale (€1,079/mo, €899 annual), unlimited on Enterprise. Annual billing gives two months free, and all plans include unlimited websites and users.
If you exceed the limit, tracking continues uninterrupted and your price stays fixed — there are no overage charges. One overage month per year is absorbed; sustained overage moves you up a tier.
---
## Conclusion
The choice isn't really about features. GA4 has more of them, and some — Google Ads integration, predictive metrics, user-level analysis — Sealmetrics will never have, because they depend on the persistent identifier that consentless operation rules out.
The choice is about **what your data represents**. In EU markets GA4 shows you a subset of visitors selected by their willingness to accept a cookie banner, and that subset doesn't behave like your actual audience. Every conclusion drawn from it inherits that bias.
**Choose GA4** if Google Ads drives your revenue, if you need predictive or user-level analysis, if you need city-level geography, or if your traffic is mostly outside the EU.
**Choose Sealmetrics** if your traffic is substantially EU, if marketing attribution drives budget decisions, if you want to drop the banner, if you want AI and MCP access over your analytics, or if your DPO won't approve US transfers.
**Or run both** — GA4 for Google Ads optimisation on consented users, Sealmetrics as the source of truth for total traffic and conversions. Many teams settle there, and it's a legitimate answer rather than a fence-sit.
→ [Start your free 14-day trial](https://my.sealmetrics.com/register)
→ [Compare pricing](https://sealmetrics.com/pricing)
---
## Additional Resources
**Sealmetrics guides**:
- [GA4 to Sealmetrics migration checklist](/guides/ga4-migration-checklist)
- [Complete guide to cookieless analytics](/blog/cookieless-analytics-guide)
- [GDPR compliant analytics framework](/blog/gdpr-compliant-analytics-framework)
- [GA4 vs Sealmetrics FAQ](/faq/ga4-vs-sealmetrics)
**Legal references**:
- [GDPR Recital 26 — anonymous information](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [CNIL guidance on cookies and trackers](https://www.cnil.fr/en/cookies-and-other-trackers)
- [ePrivacy Directive Article 5(3)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32002L0058)
**Comparisons**:
- [Sealmetrics vs Plausible](/blog/sealmetrics-vs-plausible)
*Last reviewed: July 2026. GA4 pricing, retention limits and feature availability were verified against Google's documentation at time of writing.*
## Sealmetrics vs Plausible: Which is Better? [2026 Comparison]
URL: https://docs.sealmetrics.com/blog/sealmetrics-vs-plausible
> **TL;DR** — Sealmetrics vs Plausible compared in 2026. Both are cookieless, but only one avoids deriving any identifier from the visitor's IP. Features, AI, pricing and GDPR reviewed.
Both **Sealmetrics** and **Plausible Analytics** are privacy-first alternatives to Google Analytics, and both are cookieless. But they solve different problems for different buyers, and the gap between them has widened considerably since 2025.
The core technical difference is narrow but consequential: **Plausible derives a daily visitor identifier from the visitor's IP address and User-Agent**, while **Sealmetrics never derives any identifier from the IP at all** — not for sessions, not even for geolocation.
The core product difference is much wider: since the launch of Sealmetrics V2 in February 2026, Sealmetrics has added an AI analytics layer (LENS), an MCP server that lets Claude, ChatGPT and Cursor query your data in plain language, custom channel grouping, webhooks and EU-hosted AI. Plausible has stayed deliberately minimal — which for many teams is exactly the point.
This comparison is updated for **July 2026** and covers architecture, privacy, features, AI capabilities, pricing and the honest trade-offs in both directions.
## Key Comparison Points
- **IP handling**: Plausible hashes IP + User-Agent into a daily identifier (salt deleted every 24h); Sealmetrics derives no identifier from IP whatsoever
- **Consent**: Both operate consentless; Sealmetrics' legal basis doesn't depend on arguing that a pseudonymous ID isn't personal data
- **AI**: Sealmetrics ships LENS AI, an MCP server, and EU-hosted LLM inference; Plausible ships none of this
- **Scale limits**: Plausible caps sites and team members by plan (1/3/10); Sealmetrics is unlimited on every plan
- **Pricing**: Plausible starts at $9/month; Sealmetrics starts at €499/month with annual billing
- **Retention**: Plausible defaults to 3–5 years, above the EU ceiling for consent-exempt analytics; Sealmetrics 24 months
## Executive Summary: Which Tool is Right for You?
**Choose Plausible if**:
- Budget is the primary constraint ($9–19/month)
- You want open source and the option to self-host
- You need a simple, fast, beautiful dashboard and nothing more
- You have a handful of sites and a small team
- You need retention beyond 24 months and are prepared to handle the compliance consequences
**Choose Sealmetrics if**:
- You need e-commerce/lead attribution with revenue, not just pageviews
- You want an AI layer over your analytics (natural-language questions, automated anomaly detection, MCP access from your AI assistant)
- You run many sites or a large team and don't want per-seat or per-site limits
- Your DPO wants a legal basis that doesn't rest on an IP-derived identifier
- You need webhooks, BigQuery, custom channel rules or audit logs
**The Bottom Line**: These are no longer two versions of the same product. Plausible is the best-in-class *minimal* privacy analytics tool. Sealmetrics is a *marketing analytics platform* built for teams that need attribution, revenue and AI-assisted analysis, with a stricter privacy architecture underneath. Price reflects that: they are roughly 30× apart, and they are aimed at different buyers.
## Background: Understanding Both Tools
### What is Plausible Analytics?
**Plausible Analytics** launched in 2019 as an open-source, privacy-friendly alternative to Google Analytics. Founded by Uku Täht and Marko Saric, Plausible became the default recommendation in the privacy-conscious developer community.
**Key characteristics**:
- Open-source (AGPL license)
- Self-hosted or cloud-hosted options
- Lightweight script (around 1 KB)
- No cookies
- European-owned (Estonia-based)
- Simple, minimalist dashboard
**Market position**: One of the most popular Google Analytics alternatives, with strong adoption among developers, indie hackers, agencies and small businesses.
### What is Sealmetrics?
**Sealmetrics** launched in 2023 to solve the "consent paradox" in web analytics — the fact that cookie- and consent-based analytics lose 15-60% of their data in EU markets to banner rejection and ghosting. Sealmetrics pioneered *consentless analytics*, storing no personal data at all so that no GDPR legal basis is required, and in February 2026 shipped **V2**, a full rebuild of the platform.
**Key characteristics**:
- Proprietary (closed-source), cloud-hosted only
- No IP-derived identifiers anywhere in the pipeline
- Country from browser timezone, not IP
- EU-only infrastructure (Dublin, Ireland)
- Attribution, funnels and revenue as first-class features
- Built-in AI layer (LENS) and an MCP server for AI assistants
**Market position**: Aimed at EU e-commerce, lead generation and multi-site businesses that need marketing-grade attribution without a consent banner.
## Technical Architecture Comparison
### Session Identification
**Plausible's approach**:
```
visitor_id = hash(daily_salt + website_domain + ip_address + user_agent)
```
Plausible is explicit and transparent about this in its [data policy](https://plausible.io/data-policy): raw IP addresses and User-Agent strings are never stored, and **the salt is rotated and deleted every 24 hours**, so the identifier cannot be linked across days or recomputed afterwards.
**Pros**:
- Enables unique-visitor counts and bounce rate at the individual level
- No cookies, no persistent identifier, no cross-site tracking
- Fully documented and auditable in open source
**Cons**:
- The legal basis rests on the argument that a daily salted hash of an IP is not personal data — an argument most regulators accept, but not one that is settled beyond dispute
- Identity resets at midnight, so multi-day journeys are split
**Sealmetrics' approach**:
Sealmetrics identifies sessions with a temporary, non-persistent marker derived from the browser context. **The visitor's IP is never used to derive it.** IPs are handled in-memory at the edge for two purposes only — checking against the bot-IP database and applying customer-configured IP exclusions — and are never persisted or attached to any hit. Even geolocation avoids the IP: visitor country is derived from the [browser timezone](/security-privacy/country-detection).
**Pros**:
- No identifier derived from personal data means there is no argument to have
- Sessions can never be linked to each other or to a person
- Works identically under every national interpretation
**Cons**:
- No unique visitors, by design (see [Metrics Reference](/reports/definitions))
- Closed source, so you verify by network inspection and documentation rather than by reading the code
- Smaller community than Plausible
### IP Address Handling
This is the sharpest technical distinction, and it deserves to be stated precisely rather than dramatically.
**Plausible**:
```
1. Receive request with IP address
2. Hash(daily salt + domain + IP + User-Agent) → visitor_id
3. Store visitor_id with the event; discard the raw IP
4. Rotate and delete the salt every 24 hours
```
**Sealmetrics**:
```
1. Receive request with IP address
2. Check the IP against the bot-IP database and account IP exclusions, in memory
3. Discard the IP — it is never written anywhere, never hashed into an identifier,
and never used for geolocation
4. Session marker comes from browser context; country comes from timezone
```
**What this means in practice**: Plausible's design is genuinely privacy-preserving and defensible. Sealmetrics' design removes the need to defend it. If your DPO's position is "no identifier may be derived from an IP address, full stop", Plausible cannot satisfy that requirement and Sealmetrics can. If your DPO accepts the daily-salted-hash reasoning — as many do — this difference will not decide your purchase, and you should choose on features and price instead.
## Privacy & GDPR Compliance Comparison
### Consent Requirements
**Plausible's position**: Plausible states that its tool does not require cookie consent, on the basis that no cookies are set and no personal data is stored. Its documentation notes that specific circumstances and your DPO's interpretation may still call for consent.
**Sealmetrics' position**: no consent banner required, on the basis that:
1. **No IP-derived identifier**: nothing in the pipeline is derived from an IP address
2. **No Article 6 basis needed**: no personal data is stored, so under Recital 26 the dataset falls outside the GDPR's material scope — we deliberately don't claim legitimate interest, since invoking it would concede that personal data is being processed
3. **Purpose limitation**: analytics only, never advertising, never data sales
4. **Data minimisation**: aggregated, non-personal data only
5. **Regulator alignment**: published self-assessments against [CNIL](/compliance/cnil-self-assessment) (France), [TTDSG](/compliance/germany-ttdsg-self-assessment) (Germany), [Garante](/compliance/italy-garante-self-assessment) (Italy), [UK PECR](/compliance/uk-pecr-self-assessment) and [Swiss FADP](/compliance/switzerland-fadp-self-assessment)
Sealmetrics also publishes a full analysis of the [EU Digital Omnibus](/compliance/omnibus) and its impact on analytics, plus a [subprocessor list](/compliance/subprocessors) and [data subject rights](/compliance/data-subject-rights) documentation.
### Regulatory Requirements Side by Side
CNIL's criteria for consent-exempt analytics are the strictest widely-published benchmark. Both tools are in good shape; they differ on one row.
| CNIL criterion | Plausible | Sealmetrics |
|---|---|---|
| No cookies or device storage | ✅ | ✅ |
| No cross-site tracking | ✅ | ✅ |
| No IP used to identify users | ⚠️ IP is an input to the daily hash | ✅ IP never used to derive an identifier |
| Limited retention (≤ 24–25 months) | ❌ 3–5 years by default | ✅ 24 months |
| Analytics-only purpose | ✅ | ✅ |
| Clear privacy policy disclosure | ✅ | ✅ |
The retention row deserves attention, because longer retention sounds like a feature and isn't one here. Both Spanish and French regulators cap how long consent-exempt analytics data may be kept: the **AEPD sets a maximum of 24 months**, and the CNIL 25. Plausible's default of 3–5 years sits above both ceilings. If you rely on the analytics exemption to run without a banner in Spain or France, retaining data for five years undermines the exemption you're relying on.
Sealmetrics' 24 months is not a limitation we'd like to lift — it's the regulatory ceiling, and staying at it is part of what makes the consentless basis hold.
### Germany (TTDSG §25)
§25 TTDSG requires consent for storing or accessing information on a user's device. Neither tool stores anything on the device, so both clear the bar. German DPOs have historically been the strictest on IP-derived identifiers, which is where the two designs diverge — see the [TTDSG self-assessment](/compliance/germany-ttdsg-self-assessment) for the full argument.
## Feature Comparison
### Core Analytics Metrics
| Metric | Plausible | Sealmetrics |
|---------|-----------|-------------|
| **Real-time data** | ✅ Yes | ✅ Yes (< 2 min) |
| **Pageviews** | ✅ Yes | ✅ Yes |
| **Sessions / Entrances** | ✅ Yes | ✅ Yes |
| **Unique visitors** | ✅ Yes (daily unique) | ❌ Not tracked, by design |
| **Bounce rate** | ✅ Yes | ✅ Yes (computed in aggregate) |
| **Engagement rate / Engaged sessions** | ⚠️ Via bounce rate | ✅ Yes |
| **Pages per session** | ✅ Yes | ✅ Yes |
| **Visit duration** | ✅ Yes | ❌ No |
| **Traffic sources & referrers** | ✅ Yes | ✅ Yes |
| **UTM campaign tracking** | ✅ Yes | ✅ Yes |
| **Device / browser / OS** | ✅ Yes | ✅ Yes |
| **Geographic data** | ✅ Country, region, city | ✅ Country only |
| **Screen size** | ✅ Yes | ✅ Yes |
**Notable differences**:
- Plausible reports **unique visitors** and **visit duration**; Sealmetrics does not, because both require an identifier that persists across the session boundary. Sealmetrics uses [entrances](/reports/definitions) as the audience-size signal instead.
- Sealmetrics **does** report bounce rate and engagement rate — these are computed in aggregate from pageviews per session and require no individual tracking. (An earlier version of this article stated otherwise; it was wrong.)
- Plausible offers finer geographic granularity (region and city) because it has an IP at the point of lookup. Sealmetrics is country-only as a direct consequence of its timezone-based approach.
### Analysis & Attribution
| Feature | Plausible | Sealmetrics |
|---------|-----------|-------------|
| **Custom events** | ✅ Unlimited | ✅ Unlimited |
| **Goal tracking with revenue** | ✅ Business plan | ✅ All plans |
| **Conversion funnels** | ✅ Business plan | ✅ All plans |
| **User journeys** | ✅ Business plan | ❌ No |
| **Micro-conversions** | ⚠️ Via custom events | ✅ Native |
| **E-commerce tracking** | ✅ Business plan (revenue attribution) | ✅ Native, with item-level properties |
| **Custom properties (scalar values)** | ✅ Business plan — max 30 per event | ✅ All plans — no fixed cap |
| **Item-level e-commerce data (line items)** | ❌ Scalars only; arrays and objects rejected | ✅ `items[]` array per conversion |
| **Properties on pageviews** | ✅ Yes | ❌ Conversions and micro-conversions only |
| **Saved segments** | ✅ All plans | ✅ All plans |
| **Custom channel grouping** | ❌ No | ✅ Drafts → test → publish, with CSV import/export |
| **Content grouping** | ❌ No | ✅ Yes |
| **UTM & referrer mapping rules** | ❌ No | ✅ Yes |
| **Session recording / heatmaps / A/B** | ❌ No (privacy by design) | ❌ No (privacy by design) |
| **Data retention** | 3 years (Starter/Growth), 5 years (Business) — above the EU ceiling | 24 months — at the AEPD maximum |
**Key differences**:
- The 2023-era claim that Plausible lacks funnels is no longer true — funnels and user journeys shipped on the Business plan. What differs now is that Sealmetrics includes funnels, revenue and custom properties on **every** plan, while Plausible gates them behind Business. User journeys are a genuine Plausible-only feature: Sealmetrics has no path-analysis report.
- Sealmetrics' [custom channel grouping](/platform/settings/tracking/channel-grouping) (July 2026) lets you define your own marketing channels on top of the GA4-style defaults, test a rule against a sample visit with the same engine the pixel uses, and publish only when you're ready. There is no Plausible equivalent.
- **Custom properties are not the same feature on both platforms.** Plausible accepts only scalar values — its documentation states that properties take strings, numbers and booleans, and that arrays and objects are rejected. Sealmetrics accepts an `items` array of objects, so a single purchase carries one row per line item:
```javascript
sealmetrics.conv('purchase', 149.99, {
payment_method: 'credit_card',
items: [
{ product_name: 'Camiseta', price: 19.95, quantity: 2, category: 'Ropa' },
{ product_name: 'Pantalón', price: 49.99, quantity: 1, category: 'Ropa' }
]
});
```
On Plausible you would flatten this by hand into `product_1`, `product_2` and so on, which breaks down as soon as orders have a variable number of lines and eats quickly into the 30-property ceiling. Their revenue attribution is order-level; breakdowns by SKU, size, colour or room type have no Plausible equivalent at any price. See [event properties](/implementation/custom-properties/event-properties) and the [Properties report](/reports/properties).
- **Plausible attaches properties to pageviews; Sealmetrics doesn't.** Sealmetrics properties ride on `conv()` and `micro()` calls, and pageviews are segmented with [content grouping](/platform/settings/tracking/content-grouping) instead — a fixed dimension rather than free-form keys. To segment content traffic by author or article type with no conversion involved, Plausible is the more direct fit.
- **Plausible retains data longer, but not compliantly.** The AEPD caps consent-exempt analytics retention at 24 months and the CNIL at 25. Plausible's 3–5 year default exceeds both, so multi-year history is only an advantage if you aren't depending on the analytics exemption in those jurisdictions.
### AI & Agent Capabilities
This category did not exist the last time this article was written, and it is now the widest gap between the two products.
| Capability | Plausible | Sealmetrics |
|---------|-----------|-------------|
| **Natural-language chat over your data** | ❌ No | ✅ [LENS AI](/lens) |
| **Automated anomaly detection** | ❌ No | ✅ ~25 rules across 11 categories |
| **AI-generated executive summaries** | ❌ No | ✅ Yes |
| **MCP server for AI assistants** | ❌ No | ✅ [Hosted + local](/integrations/mcp-server) |
| **EU-hosted LLM inference** | ❌ No | ✅ [Seal AI Private](/billing/seal-ai-private) (Paris, no prompt retention) |
| **Bring your own LLM key** | ❌ No | ✅ Anthropic, OpenAI, Gemini, DeepSeek — unmetered |
| **AI-assisted install** | ❌ No | ✅ [Agentic package](/integrations/agentic-package) |
| **AI agent traffic detection** | ❌ No | ✅ Tracked and reported, not billed |
**What this looks like in practice**: connect `https://mcp.sealmetrics.com/mcp` to Claude, ChatGPT, Cursor or Codex and ask *"why did conversions drop last week?"* or *"which of my top 3 campaigns has the best conversion rate?"* and get an answer from your live data. Connections are OAuth-based, scoped to a single site, **read-only**, and revocable from [Connected Apps](/platform/settings/account/connected-apps).
LENS also runs detection rules on a cadence and emails you when traffic drops, conversion rates shift or tracking breaks — the anomaly detection Plausible users typically build themselves against the Stats API.
### Integrations & Technical
| Feature | Plausible | Sealmetrics |
|---------|-----------|-------------|
| **Script size** | ~1 KB | ~1.3 KB |
| **Self-hosted option** | ✅ Yes (open source) | ❌ No (cloud only) |
| **Custom domain / first-party proxy** | ✅ Yes (managed proxy on Enterprise) | ✅ Yes |
| **WordPress / Drupal / Joomla** | ✅ WordPress | ✅ All three |
| **WooCommerce / Shopify / Magento / PrestaShop / BigCommerce / OpenCart** | ⚠️ Via custom events | ✅ Documented integrations |
| **Webflow / Wix / Squarespace** | ✅ Via snippet | ✅ Documented guides |
| **Next.js / Nuxt / React** | ✅ NPM tracker | ✅ Documented guides |
| **Google Tag Manager** | ✅ Yes | ✅ Yes, incl. custom template |
| **Google Search Console** | ✅ Native integration | ⚠️ Via MCP, not a native connector |
| **Data Studio / Data Studio** | ✅ Business plan | ✅ Official connector |
| **BigQuery export** | ❌ No | ✅ [Yes](/integrations/bigquery) |
| **Raw event export** | ✅ Enterprise (scheduled) | ✅ CSV / JSON / streaming exports |
| **Webhooks** | ❌ No | ✅ [Scale and above](/platform/settings/integrations/webhooks) |
| **Slack / email reports** | ✅ All plans | ✅ Email reports and LENS alerts |
| **Stats / analytics API** | ✅ Business plan (600 req/h) | ✅ All plans (240–480 req/min) |
| **Sites provisioning API** | ✅ Enterprise | ✅ All plans |
| **Official SDK** | ⚠️ Community | ✅ Python SDK |
**Key differences**:
- Plausible has a **native Google Search Console integration**; Sealmetrics does not — you combine the two through the [Search Console MCP prompts](/web-analytics-prompts/search-console), which is more powerful but less turnkey.
- Sealmetrics has **BigQuery and webhooks**; Plausible has neither.
- Sealmetrics' API is unrestricted by plan and rate-limited far higher (240–480 requests per *minute* versus 600 per *hour*). If you're building on top of the data, this is a large practical difference.
### Team, Access & Governance
| Feature | Plausible | Sealmetrics |
|---------|-----------|-------------|
| **Sites included** | 1 / 3 / 10 by plan | **Unlimited on every plan** |
| **Team members** | 1 / 3 / 10 by plan | **Unlimited on every plan** |
| **Role-based permissions** | ⚠️ Basic | ✅ Basic → Advanced → Full by plan |
| **Shared / public dashboards** | ✅ Growth and above | ⚠️ [API only](/api/shared-dashboards) — no dashboard UI |
| **White-label dashboards** | ✅ Via self-hosting | ⚠️ Enterprise arrangement only |
| **Two-factor authentication** | ✅ Yes | ✅ Yes, with backup codes |
| **IP allowlist for account access** | ❌ No | ✅ Yes |
| **Audit log** | ❌ No | ✅ Scale and above |
| **SSO (SAML)** | ✅ Enterprise | ❌ Not available |
| **Organizations / multi-account** | ⚠️ Teams | ✅ Organizations with per-site scoping |
The site and seat limits are worth dwelling on. An agency with 40 client sites needs Plausible Enterprise; on Sealmetrics, 40 sites is included in the entry plan. That closes a meaningful part of the raw price gap for multi-site buyers.
### Data Quality & Bot Filtering
| Feature | Plausible | Sealmetrics |
|---------|-----------|-------------|
| **Known-bot User-Agent filtering** | ✅ Yes | ✅ Yes |
| **Bot IP database** | ⚠️ Limited | ✅ Yes, checked in memory, never stored |
| **Behavioural / timing analysis** | ❌ No | ✅ Yes |
| **HMAC request validation** | ❌ No | ✅ Yes |
| **Bot traffic reporting** | ❌ No | ✅ Bot stats and suspicious sessions |
Sealmetrics runs a [five-layer bot detection system](/security-privacy/bot-detection) and reports what it filtered, so you can see how much of your traffic was automated rather than simply trusting that it's gone.
## Pricing Comparison
### Plausible Pricing (July 2026)
**Cloud**, at the 10k pageviews entry tier, billed monthly:
- Starter: **$9/month** — 1 site, 1 user, 3-year retention
- Growth: **$14/month** — up to 3 sites, 3 team members, shared links and embedded dashboards
- Business: **$19/month** — up to 10 sites, 10 team members, 5-year retention, funnels, revenue attribution, custom properties, Stats API, Data Studio
- Enterprise: custom — SSO, Sites API, managed proxy, scheduled raw exports
**Self-hosted**: free, no pageview limits, you run the infrastructure, no support.
**Notes**: pricing scales with total pageviews and custom events across the team; annual billing saves two months; 30-day free trial without a card; 15% discount on Business for nonprofits, education and open source.
### Sealmetrics Pricing (July 2026)
**Volume-based plans**, all with unlimited sites and unlimited users:
- Growth: **€599/month** (5M events) — **€499/month** annually
- Scale: **€1,079/month** (15M events) — **€899/month** annually
- Enterprise: custom (unlimited events)
**Notes**: 24-month retention on all plans; no overage charges; LENS AI included everywhere (BYOK unmetered); [Seal AI Private](/billing/seal-ai-private) is an add-on on Growth and included on Scale and Enterprise; webhooks and audit logs from Scale; annual billing gives two months free. Full breakdown in the [features comparison](/billing/features-comparison).
### Being Honest About the Gap
At list price these products are roughly 30× apart, and no amount of feature comparison makes €499/month the obvious choice over $19/month for a personal site or a small business. The gap narrows when you account for:
- **Sites and seats**: 40 sites and 25 users is Enterprise territory on Plausible and the entry plan on Sealmetrics
- **Gated features**: funnels, revenue, custom properties and the API are Business-tier on Plausible and standard on Sealmetrics
- **AI**: LENS and the MCP server have no Plausible equivalent at any price
- **Volume**: at 5M events/month, Plausible's own pricing has climbed well above its headline tiers
It does not close entirely, and it shouldn't. If you want a fast, private pageview dashboard for a blog, buy Plausible.
## Use Case Recommendations
### When Plausible is the Better Choice
**Personal sites, blogs and small businesses** — under a few hundred thousand pageviews, one or two sites, a budget measured in tens of euros. Plausible is excellent here and Sealmetrics is not the right tool.
**Open-source advocates and self-hosters** — full auditability, no vendor, no per-event cost. If you can run the infrastructure, self-hosted Plausible is free and completely transparent. Sealmetrics has no self-hosted option at all.
**Developer tools and API companies** — simple metrics, a technical audience that trusts open source, no need for revenue attribution.
**Teams outside the EU that need multi-year history** — if the AEPD's 24-month ceiling doesn't apply to you, Plausible's 3–5 year retention is a genuine advantage. Inside the EU, retention beyond 24 months works against the consent exemption rather than for you.
### When Sealmetrics is the Better Choice
**EU e-commerce with real revenue at stake** — funnels, item-level properties, revenue attribution by channel, custom channel rules and BigQuery export, all consentless, all in the entry plan.
**B2B SaaS with high customer value and long sales cycles** — 24 months of retention covers the full cycle, and micro-conversions plus custom properties let you measure the whole path without ever identifying a person.
**Agencies and multi-brand groups** — unlimited sites and users, organizations with per-site scoping, audit logs, and a portfolio view. Per-site pricing is what makes Plausible expensive at this shape. Note the trade-off: Plausible offers shared and embedded client dashboards from its Growth plan as a finished feature. Sealmetrics exposes shared-dashboard endpoints in the API but ships no UI for them and no page that renders one, so client-facing reporting in practice means Data Studio, the Stats API, or giving the client a login.
**Teams that want AI over their analytics** — LENS for anomaly detection and natural-language questions, the MCP server so your existing AI assistant reads live data, and EU-hosted inference if sending prompts to a US provider is not acceptable.
**Enterprises with a strict DPO** — a legal basis that never touches an IP-derived identifier, published self-assessments against five regulators, EU-only infrastructure in Dublin, IP allowlists and audit logs.
## Migration Guide
### From Google Analytics to Either Tool
**Parallel tracking period**: 30 days recommended.
**Step 1: Install alongside GA4**
```html
```
**Step 2: Verify data quality** (14 days) — compare traffic volumes, check conversion tracking, validate geographic data, test custom events.
**Step 3: Remove Google Analytics** — the tracking code, the cookie banner if GA was the only reason for it, and Google Tag Manager if it was only used for GA.
Plausible can import historical GA data. Sealmetrics cannot, so export what you need from GA4 first. Sealmetrics does provide a [GA4 migration guide](/ga4-migration) and a [migration checklist](/guides/ga4-migration-checklist).
### From Plausible to Sealmetrics
**Reasons to migrate**:
- You've outgrown Plausible's site or seat limits
- You need revenue attribution and funnels without paying per site for Business
- Your DPO objects to an IP-derived identifier
- You want AI analysis, MCP access, webhooks or BigQuery
- You need custom channel grouping or content grouping
**Process**:
**Step 1: Run both in parallel**
```html
```
**Step 2: Compare for 14+ days.** Expect the numbers to differ, and expect the differences to be explainable rather than dramatic — both tools are cookieless and consentless, so neither is losing traffic to a banner. The typical sources of variance are session-window definitions (Sealmetrics uses a ~2-hour inactivity window), bot filtering (Sealmetrics filters more aggressively and reports what it removed), and the fact that Plausible's unique-visitor count has no Sealmetrics equivalent — compare entrances to visits, not to unique visitors.
**Step 3: Instrument conversions.** This is the real work of the migration. Add `sealmetrics.conv('purchase', amount)` and `sealmetrics.micro('add_to_cart')` calls, then verify with [setup verification](/getting-started/see-your-data-flow).
**Step 4: Remove Plausible** and export your historical reports first — data cannot be migrated between platforms.
## Frequently Asked Questions
### Does Plausible store my visitors' IP addresses?
No. Plausible's data policy states that raw IP addresses are never stored. The IP is used as one input to a hash — along with a daily salt, the domain and the User-Agent — that produces a visitor identifier for that day, and the salt is rotated and deleted every 24 hours. The open question is not whether Plausible stores IPs (it doesn't) but whether an identifier *derived* from an IP is itself personal data. Sealmetrics sidesteps the question by never deriving one.
### Is Plausible's open-source model better for privacy?
For **transparency**, yes, and it's a real advantage — you can read exactly what the code does. For **privacy outcomes**, both are strong, with the architectural difference described above.
Sealmetrics' closed source is verifiable by other means: network traffic inspection shows what leaves the browser, the [privacy documentation](/security-privacy) describes the pipeline, and third-party audit reports are available on request.
### Does Plausible require consent in Germany?
Plausible's position is that it does not, and most German DPOs accept that. The friction point is the IP-derived daily identifier: a DPO who takes the strict view that no identifier may be derived from an IP address will not be satisfied by any hashing scheme. This is a minority position, not a majority one — but if it's *your* DPO's position, it's decisive.
### Can Sealmetrics track authenticated users across devices?
No, and neither can Plausible. Both are designed specifically not to track individuals across devices or sessions. For post-login product analytics, run server-side analytics keyed on your own `user_id`, or pair Sealmetrics with a product analytics tool for the logged-in experience. See [attribution without user IDs](/security-privacy/attribution-without-userid).
### Do ad blockers block either tool?
Both are blocked far less than Google Analytics, since neither is an advertising product, and blocking rates vary by audience — a developer-heavy audience blocks more than a general consumer one. We're not going to quote a precise percentage for either tool, because any single number is wrong for most sites.
Both support first-party delivery via a custom domain, which is the actual fix. See [ad blocker bypass](/security-privacy/adblocker-bypass).
### Which has better performance?
Effectively identical. Plausible's script is around 1 KB, Sealmetrics' around 1.3 KB, both are deferred, both are asynchronous, and the difference is imperceptible to users. Neither will move your Core Web Vitals.
### Can I use both together?
Yes, and it's the recommended approach during a 30-day migration. Running both permanently adds negligible page weight but doubles your cost and gives you two numbers to reconcile. Pick one.
### Can I white-label either tool?
**Plausible**: yes, by self-hosting — you can rebrand completely, at the cost of running the infrastructure.
**Sealmetrics**: no. There is no self-hosted option and no shared-dashboard layer to rebrand; white-labelling is only available as an Enterprise arrangement.
### Which has better support?
**Plausible**: community support (GitHub, forum), email support for paying customers, extensive public documentation.
**Sealmetrics**: email support on all plans, chat on Growth and above, priority on Scale and above, dedicated account management on Enterprise, plus a 99.5% SLA (99.9% on Enterprise) and guided onboarding from Scale.
Sealmetrics offers more formal support commitments; Plausible offers a larger public community. Which is better depends on whether you'd rather search a forum or open a ticket.
## Conclusion: Plausible vs Sealmetrics in 2026
Both are far better than Google Analytics, and both are honestly privacy-first. The choice is no longer really about privacy — it's about scope and scale.
**Choose Plausible if**:
- Budget is the deciding factor
- You value open source and want the self-hosting option
- One to ten sites, a small team, simple metrics
- You want multi-year retention
- Your DPO accepts a daily salted identifier derived from IP + User-Agent
**Choose Sealmetrics if**:
- You need revenue attribution, funnels and micro-conversions as core features, not add-ons
- You run many sites or a large team and want that unmetered
- You want AI over your analytics — natural-language questions, automated anomaly detection, MCP access from Claude or ChatGPT
- You need webhooks, BigQuery, custom channel rules or audit logs
- Your DPO requires that no identifier be derived from an IP address
- EU-only processing, including for AI inference, is a requirement
**The honest summary**: Plausible is the better product for most small sites, and its price makes that easy to recommend. Sealmetrics is the better platform for EU businesses where analytics drives revenue decisions, where a team needs to work in the tool, and where AI-assisted analysis is becoming part of how marketing actually operates. They are converging on privacy and diverging on everything else.
## Additional Resources
### Plausible Resources
- [Plausible Analytics Official Website](https://plausible.io)
- [Plausible Data Policy](https://plausible.io/data-policy)
- [Plausible Documentation](https://plausible.io/docs)
- [Plausible GitHub Repository](https://github.com/plausible/analytics)
### Sealmetrics Resources
- [Sealmetrics Documentation](https://docs.sealmetrics.com)
- [LENS AI](/lens) — AI insights, anomaly detection and natural-language chat
- [MCP Server](/integrations/mcp-server) — connect Claude, ChatGPT, Cursor or Codex
- [Release Notes](/changelog) — what shipped and when
- [Compliance Centre](/compliance) — regulator-by-regulator self-assessments
### Comparison Resources
- [Complete Cookieless Analytics Guide](/blog/cookieless-analytics-guide)
- [Sealmetrics vs Google Analytics](/blog/google-analytics-vs-sealmetrics)
- [What Is Consentless Analytics?](/security-privacy/consentless-analytics)
---
**Ready to see what consentless analytics looks like with AI on top?**
→ [Start your free 14-day trial](https://my.sealmetrics.com/register)
→ [Compare pricing](https://sealmetrics.com/pricing)
*Last reviewed: July 2026. Plausible's pricing and feature availability were verified against plausible.io at time of writing; check their site for current figures.*
## Long-Term Analytics: 24-Month Data Retention Without Consent
URL: https://docs.sealmetrics.com/blog/long-term-analytics-data-retention
> **TL;DR** — 24-month analytics data retention without consent. How cookieless tracking enables long-term analysis while staying GDPR compliant.
Understanding long-term user behavior is crucial for business growth, but traditional analytics platforms face a critical limitation: **GDPR requires deleting data after consent expires, typically forcing 6-13 month retention limits**. Sealmetrics solves this with cookieless tracking that enables **24-month data retention without requiring user consent**.
## Key Takeaways
- **24-month retention without consent**: Sealmetrics stores aggregate analytics for two years, and because none of it is personal data, the GDPR's retention rules aren't what constrains it
- **No consent expiration risk**: Unlike cookie-based analytics, your data won't be deleted when consent expires
- **Complete historical analysis**: Track seasonal trends, year-over-year growth, and long-term user behavior
- **GDPR compliant by design**: Cookieless tracking with zero IP storage meets data minimization requirements
## The Data Retention Problem in Traditional Analytics
Most analytics platforms face a fundamental challenge with GDPR compliance: **cookie consent expires, and when it does, you must delete all associated data**.
### Why Cookie-Based Analytics Lose Historical Data
Google Analytics and similar cookie-based platforms require user consent under GDPR Article 5(3) of the ePrivacy Directive. This creates several problems:
1. **Consent expires after 6-13 months** (depending on implementation)
2. **Data deletion is mandatory** when consent expires or is withdrawn
3. **Historical analysis becomes impossible** beyond the consent window
4. **Year-over-year comparisons fail** because data older than consent period must be deleted
According to CNIL guidelines from 2024, cookie-based analytics platforms must implement consent expiration and data deletion mechanisms. This means businesses lose valuable historical insights simply because the legal basis (consent) expires.
### The Business Impact of Short Data Retention
Limited data retention affects critical business decisions:
- **Seasonal analysis**: Can't compare Q4 2023 to Q4 2024 if consent expired
- **Customer lifecycle**: Incomplete view of customer journey beyond consent period
- **Attribution modeling**: Can't track conversions that occur 12+ months after first visit
- **Trend identification**: Missing long-term patterns that only emerge over years
- **ROI calculation**: Incomplete data for marketing channels with long conversion cycles
In B2B SaaS, where sales cycles often exceed 6 months, this data retention limitation can cripple analytics entirely.
## How Sealmetrics Enables 24-Month Data Retention
Sealmetrics stores **no personal data at all**, which changes the retention equation more fundamentally than picking a different legal basis would.
### The Legal Position: Outside the GDPR's Material Scope
**GDPR Recital 26** states that the principles of data protection do not apply to anonymous information — information which does not relate to an identified or identifiable natural person. Retention limits are one of those principles. If the stored data isn't personal data, the storage limitation principle has nothing to attach to.
Sealmetrics is in that position because:
1. **No personal data stored**: no IP addresses, fingerprints, or cross-site identifiers
2. **Session-based tracking**: each visit generates a temporary, non-identifying session identifier that is never written to the device
3. **Data minimization**: only aggregate behavioural data, no individual profiles
4. **Transparent processing**: a clear privacy policy explains what is measured
Note what we're *not* claiming. It would be easy to say "we rely on legitimate interest under Article 6(1)(f)" — plenty of vendors do — but naming any Article 6 basis concedes that personal data is being processed, and would put the retention question straight back on the table. CNIL's 2020 guidance confirms that cookieless analytics which doesn't create persistent user profiles can operate without consent.
### Technical Implementation: Zero Personal Data
Unlike competitors that hash or pseudonymize IP addresses, Sealmetrics uses a dual tracking approach:
**Session-Based Tracking**:
- Each visit = new, temporary Session-ID
- Session-ID expires after ~2 hours of inactivity
- No cross-session tracking by default
- Zero personal data in the identifier
**Isolated Hit Recording**:
- Each pageview = independent data point
- No IP address storage (not even hashed)
- No device fingerprinting
- Aggregate patterns only
This architecture means the data we retain for 24 months contains **zero personal identifiers**, making it fundamentally different from cookie-based systems that must delete data when consent expires.
### Why 24 Months Specifically?
The 24-month retention period is strategically chosen:
1. **Two full years of data**: Enables year-over-year comparisons and full seasonal cycles
2. **GDPR proportionality**: Long enough for legitimate business needs, not excessive
3. **CNIL compliance**: Deliberately below the 25-month ceiling CNIL sets for consent-exempt analytics
After 24 months, data is automatically purged from Sealmetrics systems. This automatic deletion demonstrates compliance with GDPR's storage limitation principle while providing maximum analytical value.
## Comparison: Data Retention Across Analytics Platforms
Here's how long-term analytics capabilities compare across major platforms:
| Feature | Google Analytics | Plausible | Matomo | Sealmetrics |
|---------|------------------|-----------|--------|-------------|
| **Legal Basis** | Consent (Article 6(1)(a)) | Legitimate Interest | Legitimate Interest | **None required — no personal data** |
| **Requires Consent Banner** | Yes | No | Depends | No |
| **Maximum Retention (With Consent)** | 14-26 months | Unlimited | Unlimited | **24 months** |
| **Maximum Retention (Without Consent)** | 0 months | 26 months | 26 months | **24 months** |
| **Data Deletion on Consent Withdrawal** | Required | Not required | Not required | Not required |
| **Stores IP Addresses** | Yes | Hashed | Hashed | **Zero IPs** |
| **Cross-Session Tracking** | Yes (cookies) | Optional | Optional | Session-only |
| **Personal Data Risk** | High | Medium | Medium | **Zero** |
| **Year-Over-Year Analysis** | If consent maintained | Yes | Yes | Yes |
| **Setup Complexity** | High (consent mgmt) | Low | Medium | **2 minutes** |
**Key Insight**: Sealmetrics is the only platform that combines zero IP storage with 24-month retention, providing long-term analytics without any personal data collection.
## Implementation Guide: Enabling Long-Term Analytics
Setting up Sealmetrics for 24-month data retention takes less than 5 minutes.
### Step 1: Install Tracking Script
Add the Sealmetrics script to your site:
```html
```
That's it. No consent banner configuration needed.
### Step 2: Understand the Retention Schedule
Sealmetrics retention is fixed and identical for every plan, enforced by database TTLs: daily aggregates and conversions are kept 24 months, hourly aggregates 90 days, and event-level detail 14 days. There is nothing to configure — and since Sealmetrics doesn't collect personal data, there's no compliance reason to shorten it. If you ever need data removed earlier (for example when closing an account), contact support.
### Step 3: Access Historical Data
Query data from the full 24-month period via API or dashboard:
```javascript
// API example: Get pageviews for last 2 years
fetch('https://api.sealmetrics.com/v1/stats/pageviews', {
method: 'POST',
headers: {
'Authorization': 'Bearer YOUR_API_KEY',
'Content-Type': 'application/json'
},
body: JSON.stringify({
site_id: 'YOUR_SITE_ID',
date_from: '2022-06-01',
date_to: '2024-06-01',
period: 'month'
})
})
.then(response => response.json())
.then(data => console.log('24-month pageview trend:', data));
```
### Step 4: Verify Compliance
Check your privacy policy includes:
```markdown
We use Sealmetrics, a cookieless analytics platform, to understand
how visitors use our website. Sealmetrics:
- Does not use cookies or require consent banners
- Does not store IP addresses or personal identifiers
- Retains aggregated analytics data for 24 months
- Stores nothing on your device and retains no personal data,
so this measurement falls outside the scope of the GDPR
No personal data is collected. For more: https://sealmetrics.com/privacy
```
## Use Cases: When Long-Term Analytics Matter
### Seasonal Business Analysis
E-commerce sites with strong seasonal patterns need multi-year data:
```
Q4 2022 revenue: €150,000
Q4 2023 revenue: €180,000 (+20%)
Q4 2024 revenue: €225,000 (+25%)
With consent-based analytics: Can't compare 2022 data if consent expired
With Sealmetrics: Full 24-month view shows accelerating holiday growth
```
### B2B SaaS Customer Lifecycle
B2B companies with 12-18 month sales cycles need to track:
- First touch → Lead → MQL → SQL → Customer (often 12+ months)
- Free trial → Paid conversion tracking over extended periods
- Feature adoption patterns across customer lifetime
Sealmetrics retains the entire journey without consent expiration destroying attribution data.
### Content Marketing ROI
Blog posts and content assets generate traffic for years. Long-term analytics show:
- Which 2-year-old articles still drive conversions
- SEO traffic growth patterns over 24 months
- Content decay rates and refresh opportunities
This insight is impossible with consent-based analytics that delete data after 6-13 months.
### Product-Led Growth Tracking
SaaS products need to understand:
- User activation patterns over first 12-18 months
- Feature adoption timelines (what features users adopt after 6, 12, 18 months)
- Cohort retention beyond consent expiration periods
With 24-month retention, Sealmetrics captures the complete product-led growth story.
## GDPR Compliance: Why 24 Months is Legal
### Data Minimization Principle
GDPR Article 5(1)(c) requires data minimization:
> "Personal data shall be adequate, relevant and limited to what is necessary."
Sealmetrics achieves this by:
1. **Not collecting personal data**: No IPs, no cookies, no persistent identifiers
2. **Aggregate data only**: Session-based metrics, not individual profiles
3. **Automatic purge**: 24-month deletion ensures data isn't kept indefinitely
### Storage Limitation Principle
GDPR Article 5(1)(e) requires storage limitation:
> "Personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary."
Sealmetrics complies because:
1. **Data cannot identify individuals**: Session-IDs are temporary and non-linkable
2. **24 months is proportionate**: Reasonable for business analytics needs
3. **Automatic deletion**: Built-in expiration prevents indefinite storage
### The Assessment a DPO Will Actually Ask For
Not a balancing test — a scope analysis. Three questions:
**Is any of it personal data?**
No. Session identifiers are temporary, non-linkable, and never written to the device. No IP is stored, hashed or otherwise.
**Is anything stored on or read from the user's device?**
No. That is what keeps ePrivacy Article 5(3), the rule behind cookie banners, from applying.
**So which Article 6 basis applies?**
None, and that is the point. Under Recital 26 the dataset is outside the GDPR's material scope, so no legal basis is required. Reaching for legitimate interest here would weaken the position, not strengthen it.
CNIL's 2020 guidance confirms that cookieless analytics can operate without consent when no personal data is collected.
## Best Practices for Long-Term Analytics
### 1. Leverage Full Historical Data
Don't limit queries to recent months out of habit:
```javascript
// Bad: Only checking last 3 months
const recentData = await getAnalytics({ months: 3 });
// Good: Using full 24-month history
const fullHistory = await getAnalytics({ months: 24 });
const yearOverYear = compareYears(fullHistory);
```
### 2. Build Year-Over-Year Dashboards
Create dashboards that automatically compare:
- This month vs. same month last year
- This quarter vs. same quarter last year
- Rolling 12-month trends
### 3. Track Cohort Behavior Long-Term
Follow user cohorts through their entire lifecycle:
- Users from Q1 2023: What happened after 12, 18, 24 months?
- Traffic sources from 2023: Which generated best 2-year ROI?
### 4. Identify Long-Tail Content Value
Find content that generates value long after publication:
- Articles from 2022 still driving traffic in 2024
- Evergreen content that compounds over years
- Historical posts that become more valuable over time
### 5. Plan for Data Purge at 24 Months
When data reaches 24 months:
- Export critical insights before deletion
- Document key trends and patterns
- Update forecasting models with latest complete cycles
## Frequently Asked Questions
### Is 24-month retention GDPR compliant?
Yes. Sealmetrics stores no personal data (no IPs, no cookies), so the dataset falls outside the GDPR's material scope under Recital 26 and the storage limitation principle isn't what governs it. We apply 24 months anyway, with automatic deletion — it's proportionate for business analytics and it keeps the retention question uncontroversial in a vendor review.
### Why not unlimited retention like some competitors?
While technically possible (since we don't collect personal data), 24 months provides the optimal balance between analytical value and demonstrating GDPR compliance through reasonable storage limits. It covers two full years plus seasonal buffer, which satisfies 99% of business analytics needs.
### What happens to data after 24 months?
Data older than 24 months is automatically and permanently deleted from Sealmetrics systems. This cannot be reversed. Export any critical historical analysis before the 24-month mark if you need records beyond this period.
### Do I need consent banners with 24-month retention?
No. Nothing is stored on or read from the visitor's device, so ePrivacy Article 5(3) — the rule that mandates cookie banners — is never triggered, and no personal data is stored, so no GDPR legal basis is required either. You don't need cookie banners, consent management platforms, or consent tracking. Your privacy policy should mention Sealmetrics usage, but no active user consent is required.
### Can I reduce retention to less than 24 months?
Retention is fixed and identical for every plan — it is enforced by database TTLs and is not configurable. Since Sealmetrics doesn't collect personal data, there's typically no compliance reason to shorten it. If your organization needs data removed earlier, contact support to request deletion.
### How does this compare to Google Analytics data retention?
Google Analytics requires consent (cookie-based) and typically allows 14-26 month retention. However, when users withdraw consent or consent expires, Google Analytics must delete all associated data. Sealmetrics' 24-month retention is guaranteed regardless of user actions because no consent is required.
### Can I track individual users across 24 months?
No. Sealmetrics uses session-based tracking, not persistent user tracking. Each visit generates a new Session-ID. This means you can see aggregate patterns over 24 months (traffic trends, popular pages, etc.) but cannot track individual users across sessions or time periods.
### What if my business needs longer than 24 months?
Export your data before it ages out: CSV exports from the dashboard, the API, or the [BigQuery integration](/integrations/bigquery) let you keep aggregated metrics for as long as your own policies allow, under your own control. Within Sealmetrics itself, 24 months covers seasonal analysis, year-over-year comparisons, and most B2B sales cycles.
### Does Plausible or Matomo offer better retention?
Plausible and Matomo offer longer retention options (unlimited in some configurations), but they store hashed IP addresses, creating higher personal data risk. Sealmetrics' zero-IP approach with 24-month retention provides the best balance of long-term analytics capability and privacy protection.
### How do I access my 24-month historical data?
All Sealmetrics dashboard views and API endpoints automatically include the full 24-month history. No special configuration needed. Simply set your date range in queries to span up to 24 months, and Sealmetrics will return the complete dataset.
### Is data deleted exactly at 24 months or gradually?
Data is purged on a rolling basis. When analytics data reaches exactly 24 months old (measured from the date of collection), it's automatically deleted. This means your oldest data is always approaching the 24-month mark, and you always have approximately 24 months of history available.
### Can competitors see my historical data?
No. Sealmetrics data is completely private to your account. Unlike some analytics platforms that aggregate data across customers, your 24-month historical data is isolated and accessible only to users with your account credentials.
## Conclusion: The Strategic Advantage of Long-Term Analytics
In a privacy-first world where consent-based analytics platforms lose historical data to consent expiration, **Sealmetrics' 24-month retention provides a strategic competitive advantage**.
Businesses using Sealmetrics can:
- **Make better decisions** with complete historical context
- **Identify long-term trends** that short-retention analytics miss
- **Calculate true ROI** for marketing channels with long sales cycles
- **Optimize seasonally** using multi-year comparison data
- **Track customer lifecycles** beyond consent expiration limits
All while maintaining **zero personal data collection** — which is what keeps the dataset outside the GDPR's material scope in the first place.
Unlike Google Analytics (which deletes data when consent expires), Plausible (which stores hashed IPs), or Matomo (which requires complex configuration), Sealmetrics provides the simplest path to long-term, privacy-first analytics.
**Ready to gain 24 months of insight without consent banners?**
Start your free trial at [sealmetrics.com](https://sealmetrics.com) and experience analytics that doesn't expire with user consent.
## Additional Resources
- [Complete Guide to Cookieless Analytics](/blog/cookieless-analytics-guide)
- [GDPR Compliant Analytics Framework](/blog/gdpr-compliant-analytics-framework) — Legal bases for long-term data retention
- [How Consentless Tracking Works](/security-privacy/how-consentless-works) — Technical architecture behind privacy-compliant analytics
- [Sealmetrics vs Google Analytics](/blog/google-analytics-vs-sealmetrics) — Why businesses switch from GA4's limited data retention
## EU Digital Omnibus: The End of Cookie Banner Fatigue?
URL: https://docs.sealmetrics.com/blog/eu-digital-omnibus-regulation-cookie-consent-changes
> **TL;DR** — The EU Digital Omnibus proposes to eliminate cookie banners for 60% of websites. Here's what it means for web analytics.
# EU Digital Omnibus: The End of Cookie Banner Fatigue?
Cookie banners cost EU businesses **€1.64 billion annually**. EU users waste **334 million hours per year** clicking through them. And yet, 54% of users randomly accept without reading, while 26% randomly reject—undermining the very goal of informed consent.
On November 19, 2025, the European Commission published a proposal that could change everything: the **EU Digital Omnibus Regulation** (COM(2025) 837).
## What Just Happened?
The Digital Omnibus is the EU's most ambitious simplification of data regulation since the GDPR came into force in 2018. It consolidates five separate data laws into two and introduces fundamental changes to how cookie consent works.
**The headline**: Cookie banners will disappear for an estimated **60% of websites**.
But there's more to the story.
## The Cookie Consent Revolution
### Current Reality: A Broken System
Since the ePrivacy Directive of 2009, nearly every website in the EU has been forced to ask for cookie consent. The result:
- 41% of websites display cookie banners
- Average user encounters multiple banners daily
- Users suffer from "consent fatigue" and make uninformed decisions
- Businesses spend €1.64 billion annually on compliance
The system protects no one. Users are annoyed. Businesses are burdened. Privacy is undermined.
### The New Framework: Articles 88a and 88b GDPR
The Omnibus **repeals Article 5(3) of the ePrivacy Directive** and brings cookie consent under the GDPR framework through two new articles:
**Article 88a**: Defines when consent is needed and when it's not.
**Article 88b**: Requires websites to respect browser-level privacy signals.
### The Game-Changing Exemption
Here's the breakthrough. **Article 88a(3)(c)** creates a consent exemption for:
> "Creating aggregated information about the usage of an online service to measure the audience of such a service, where it is carried out by the controller of that online service solely for its own use"
**Translation**: First-party analytics for your own use = **NO CONSENT NEEDED**.
**Requirements:**
- ✅ Data must be aggregated (not individual user tracking)
- ✅ Processing by the controller (website owner)
- ✅ For the controller's own use only (no sharing or selling)
**What this means in practice:**
You CAN do without consent:
- Measure total page views and visitors
- Understand traffic sources
- Analyze popular content
- Track conversions in aggregate
- Optimize user experience
You CANNOT do without consent:
- Third-party tracking across sites
- Individual user profiling
- Sharing analytics data with advertisers
- Retargeting and behavioral advertising
## Impact on Web Analytics
### Winners
**Consentless analytics providers** like Sealmetrics, Plausible, and Fathom are validated. These platforms already operate under privacy-first principles:
- No cookies or cookieless design
- First-party data only
- Aggregated measurement
- No cross-site tracking
- No data sharing
**Result**: These tools will be explicitly compliant with Article 88a(3)(c) and can operate without consent banners.
**Website operators** using first-party analytics will benefit from:
- No cookie banner costs (€400-€5,000/year savings)
- Complete traffic data (no loss from consent denial)
- Better user experience
- Simplified compliance
### Losers
**Third-party tracking networks** and **advertising platforms** that rely on cross-site tracking will:
- Still require consent (no exemption)
- Face lower consent rates when browser signals arrive
- Need to restructure or adapt business models
**Consent Management Platforms (CMPs)** face a contracting market:
- 60% of websites may no longer need banners
- Smaller addressable market
- Pressure on pricing
### What About Google Analytics?
**It depends on configuration.**
- **GA4 with no data sharing, no advertising features, first-party use only**: Likely exempt under Article 88a(3)(c)
- **GA4 with advertising features or cross-site tracking**: Consent required
The key question: Is data used solely for your own audience measurement, or is it shared with Google for their purposes (advertising, benchmarking)?
**Recommendation**: If uncertain, switch to a clearly exempt platform or consult privacy counsel.
## Browser Signals: The Next Frontier
**Article 88b** introduces a requirement for websites to accept **machine-readable consent preferences** from browsers.
**Timeline:**
- **24 months**: Websites must support browser signals
- **48 months**: Browser vendors must provide user controls
**What this means:**
Users will eventually set privacy preferences once in their browser (think: "reject all tracking by default"). Websites must respect these settings.
**Exception**: Media service providers (news sites, publishers) are exempt and can still ask for consent directly.
**Impact**: Consent rates for tracking may drop to 10-30% when browsers deploy default-reject settings. First-party analytics, being exempt, will be unaffected.
## What Sealmetrics Users Should Know
Sealmetrics is designed precisely for the Article 88a(3)(c) exemption:
**✅ Aggregated measurement**: No individual user tracking across sessions.
**✅ First-party data only**: Data belongs to you, not shared with third parties.
**✅ For your own use**: Sealmetrics acts as your processor; data is used solely for your audience insights.
**Result**: Sealmetrics users can confidently operate **without cookie banners** under the new framework.
**Advantages post-Omnibus:**
- Legal certainty with explicit GDPR basis
- Complete data (no consent-denial data loss)
- Cost savings (no CMP, no banner)
- Better UX (no interruptions)
- Future-proof for browser signals (exempt analytics unaffected)
## Timeline and Next Steps
**Now (November 2025)**: Commission proposal published
**2026**: European Parliament and Council negotiation
**Expected adoption**: Late 2026 or early 2027
**Entry into force**: 20 days after publication
**Operational dates:**
- Cookie exemptions: Mid-2027
- Website browser signal support: 2028-2029
- Full browser controls: 2029-2030
## Prepare for the New Framework
### For Website Operators
**1. Audit your analytics**
- Which tools do you use?
- Are they first-party and aggregated?
- Do they share data with third parties?
**2. Identify consent requirements**
- First-party analytics for own use: No consent
- Third-party tracking, advertising: Consent required
**3. Consider switching to consentless analytics**
- Evaluate consentless, privacy-first analytics platforms
- Calculate savings: CMP costs + complete data vs. partial data
**4. Update privacy policies**
- Reference Article 88a(3)(c) exemption
- Document your legal basis
- Be transparent about data use
**5. Plan for browser signals**
- Monitor standardization efforts
- Prepare infrastructure for Article 88b (24 months)
### For Analytics Providers
**If you're first-party focused:**
- Market your Article 88a(3)(c) compliance
- Emphasize no-consent-needed positioning
- Help customers eliminate banners
**If you're third-party/ad-tech:**
- Prepare for browser signals impact
- Consider restructuring to first-party models
- Optimize consent UX (single-click refuse, 6-month cooldown)
## The Bigger Picture
The Digital Omnibus does more than eliminate cookie banners. It:
- **Consolidates 5 data laws into 2** (GDPR + Data Act)
- **Clarifies GDPR ambiguities** (personal data definition, AI processing, research)
- **Raises breach notification threshold** to "high risk" (fewer trivial reports)
- **Saves businesses €1 billion annually** by 2029
But the cookie consent reform is the most visible change—and for good reason. It directly affects every website, every user, every day.
## Conclusion: A Privacy-First Future
The EU Digital Omnibus recognizes a fundamental truth: not all data processing is equally invasive.
**First-party audience measurement** for your own use is benign. It helps you understand your visitors, improve your content, and optimize your service. It doesn't track users across the web or build invasive profiles.
**Third-party tracking and cross-site profiling** is different. It follows users everywhere, builds detailed dossiers, and powers surveillance advertising. That deserves consent.
By distinguishing between the two, Article 88a(3)(c) promises to eliminate consent fatigue while preserving meaningful privacy protections.
**For Sealmetrics users**, this is validation. You're already ahead of the curve with privacy-first analytics. When the Omnibus becomes law, you'll have legal certainty, cost savings, and a competitive advantage.
**For the industry**, this is a turning point. The future belongs to consentless, first-party, privacy-respecting analytics.
The cookie banner era isn't ending overnight. But it's beginning to end.
---
## Learn More
- [Full Cookie Consent Reform Analysis](/compliance/omnibus/cookies-eprivacy)
- [GDPR Amendments in the Omnibus](/compliance/omnibus/gdpr-changes)
- [Impact on Web Analytics Industry](/compliance/omnibus/impact-analytics)
- [EU Digital Omnibus Overview](/compliance/omnibus)
**Questions about how the Omnibus affects your analytics?** Reach out to our team or explore the detailed documentation above.
## How Session-Based Tracking Works: Cookieless Architecture Explained
URL: https://docs.sealmetrics.com/blog/cookieless-tracking-technical-deep-dive
> **TL;DR** — How session-based tracking replaces cookies. Technical deep dive into Sealmetrics' architecture: hashing, token rotation, and data flow.
## Introduction
**The Problem**: Google Analytics loses 15-60% of EU visitor data to [cookie rejections and banner ghosting](/blog/cookie-banner-ghosting-data-loss) — where you land depends on your sector, brand strength and traffic sources. Cookieless analytics solves this by tracking without cookies, consent banners, or IP addresses.
**What You'll Learn**:
- How cookieless tracking actually works technically
- Why it captures the data cookie-based tools miss
- The session-based architecture behind Sealmetrics
- Implementation differences vs traditional analytics
- The legal position: why no Article 6 basis is required at all
**Key Takeaways**:
- Cookieless tracking uses session identifiers instead of persistent cookies
- Zero IP storage means no personal data processing (no consent needed)
- 24-month retention on aggregates that contain no personal data
- Sealmetrics captures what GA4 misses: [ghosted users](/blog/cookie-banner-ghosting-data-loss), cookie rejecters, Safari/Firefox visitors
For a complete overview of cookieless analytics, see our [Cookieless Analytics: Complete Guide 2026](/blog/cookieless-analytics-guide).
---
## Table of Contents
1. How Cookies Work (Why They Fail)
2. Cookieless Architecture Explained
3. Session-Based Tracking Deep Dive
4. Zero IP Storage Implementation
5. GDPR Compliance Through Technical Design
6. Sealmetrics Cookieless System
7. Performance & Data Accuracy
8. Comparison: Cookieless vs Cookie-Based
9. Why Sealmetrics Wins Over Competitors
10. FAQ: Technical Questions
---
## How Cookies Work (Why They Fail)
### The Traditional Cookie-Based Approach
Google Analytics and most cookie-based analytics tools use **persistent third-party cookies** to track users:
```javascript
// Traditional Google Analytics approach (simplified)
// Sets cookie that persists across sessions
document.cookie = "ga_id=" + generateUUID() + "; max-age=63072000"; // 2 years
// Sends hits with same user ID across visits
fetch('https://analytics-backend.com/collect', {
body: {
userId: getCookie('ga_id'),
pageUrl: window.location.href,
timestamp: Date.now()
}
});
```
**What Happens**:
1. JavaScript runs on page load
2. Creates persistent cookie (stored on user's device for 2 years)
3. Sends cookie value with every page view
4. Server ties all hits to single user across visits
### Why This Fails in EU
**Cookie Rejection**: 87% of German users reject cookies (CNIL 2024 study)
**Banner Ghosting**: a large share of visitors ignore consent banners entirely, making no choice — usually a bigger group than the rejecters
**Browser Changes**: Safari ITP + Firefox ETP blocks third-party cookies by default
**Result**: [Google Analytics loses 15-60% of EU traffic](/blog/google-analytics-vs-sealmetrics). Note that this is smaller than the raw rejection rate — Consent Mode models part of the gap back in as estimates — and it is still more than enough to make the data unreliable for decision-making, because the loss is not spread evenly across your channels.
**The Core Issue**: Cookies require **explicit consent** under GDPR Article 7. When users reject or ignore, tracking stops completely.
---
## Cookieless Architecture Explained
### The Fundamental Shift
Cookieless analytics inverts the approach:
**Cookie-Based** → One persistent ID across all sessions
**Cookieless** → Fresh session ID each visit (no persistence)
This single change has profound implications:
```
COOKIE-BASED:
User A visits → Generate cookie ID "abc123"
Cookie stored for 2 years on device
User A visits again 3 months later → Same ID "abc123"
= Can track across time and devices
COOKIELESS:
User A visits (Nov 14, 2pm) → Generate session "sess_1234"
Session expires after visit ends (~2h inactivity)
User A visits again (Nov 20, 3pm) → Generate NEW session "sess_5678"
= Cannot track across time, only within single visit
BUT = every visitor captured (no banner needed)
```
### Why This Changes Everything
**Outside the GDPR's material scope — see the [GDPR framework guide](/blog/gdpr-compliant-analytics-framework)**:
Cookieless analytics doesn't require consent because:
1. No persistent identifiers = no personal data stored
2. No IP addresses stored = cannot identify individuals
3. Sessions reset = no cross-session profiling
4. Nothing written to or read from the device = ePrivacy Article 5(3) never triggered
**Translation**: Sealmetrics measures every visitor without a consent banner — and without needing an Article 6 legal basis, because Recital 26 puts anonymous information outside the Regulation entirely.
---
## Session-Based Tracking Deep Dive
### What is a Session Identifier?
A **session** is a temporary, ephemeral identifier computed fresh each visit:
```javascript
// Sealmetrics cookieless approach
// NO persistent cookies, NO IP storage
// 1. Compute ephemeral session ID (fresh each visit)
// Derived from general device characteristics — not unique
// to a person: different visitors can produce the same value,
// so it cannot identify an individual
const sessionId = deriveSessionId(); // "sess_a7k9m2x1"
// 2. Kept ONLY in memory — never stored on the device
// No cookies, no localStorage, no sessionStorage
// 3. Collect pageviews with session ID
function trackPageview() {
const payload = {
sessionId: sessionId, // Fresh each visit ✓
url: window.location.href, // Page URL
timestamp: Date.now(), // When viewed
referrer: document.referrer, // Where from
// NO IP address stored ✓
// NO personal data ✓
};
fetch('https://sealmetrics.io/api/events', {
method: 'POST',
body: JSON.stringify(payload)
});
}
// 4. Track events within session
// ... see full example at https://docs.sealmetrics.com/blog/cookieless-tracking-technical-deep-dive
```
### The Dual-System Architecture (Sealmetrics Specificity)
Sealmetrics uses a proprietary **dual-system** to maximize data capture:
**System 1: Session-ID Tracking** (Primary)
```javascript
// Visitor arrives
// Session ID computed: "sess_k9m2x1a7"
// All pageviews linked to this session
// Expires: end of visit (~2h of inactivity)
// Data: Visit patterns, pages viewed, time on site
```
**System 2: Isolated Hits** (Fallback)
```javascript
// If JavaScript doesn't load, or blocked
// Server-side tracking captures raw pageviews
// No session linking (single visits only)
// Data: all traffic (even no-JS visitors)
```
**Result**:
- Cookieless tool X: loses JS-blocked and slow-loading visitors
- Sealmetrics: the dual system catches those too
---
## Zero IP Storage Implementation
### Why IP Storage Matters for GDPR
IP addresses are **personal data** under GDPR. Storing them requires:
1. Legal basis (consent OR legitimate interest)
2. Data Processing Agreement with hoster
3. Data protection impact assessment
**Most "cookieless" tools still hash IPs**, creating gray area:
```javascript
// Competitor approach
const clientIP = req.headers['x-forwarded-for'];
const hashedIP = hashFunction(clientIP); // SHA256 hash
store(hashedIP); // Still stored! Still requires DPA
// Issue: Even hashed IPs can be re-identified
// GDPR regulators increasingly view hashing as insufficient
```
### Sealmetrics: True Zero-IP Architecture
```javascript
// Sealmetrics approach - NO IP in analytics data
// 1. NO IP stored in the analytics database
// 2. NO IP hashing
// 3. NO IP linked to any hit, session, or metric
// 4. IP used only transiently server-side (anti-abuse checks,
// short-lived operational logs with limited retention)
const trackPageview = async () => {
const payload = {
sessionId: 'sess_a7k9m2x1',
url: window.location.href,
timestamp: Date.now(),
// IP intentionally absent ✓
};
// Request IPs never reach the analytics database
await fetch('https://sealmetrics.io/api/events', {
method: 'POST',
body: JSON.stringify(payload)
});
};
```
### Technical Implementation Benefits
**No IP = No Personal Data** = **No Consent Required**
```
GDPR Compliance Chain:
Personal Data = requires an Article 6 legal basis
(consent, or legitimate interest + safeguards)
Cookieless tracking (no IP) = not personal data
= outside material scope (Recital 26)
= no Article 6 basis needed at all
Hashed IP = disputed, regulators disagree = gray area risk
```
**Practical difference for you**:
- Sealmetrics: Deploy without consent banner ✓
- Google Analytics: MUST have consent + DPA ✓
- Other tools: Work without consent, but hash IPs (regulatory risk)
For a complete comparison of [cookieless vs cookie-based analytics](/blog/cookieless-analytics-vs-cookie-based), see our detailed technical guide.
---
## GDPR Compliance Through Technical Design
### The Legal Foundation
For a complete understanding of GDPR compliance for analytics, read our [GDPR Compliant Analytics Framework guide](/blog/gdpr-compliant-analytics-framework).
**GDPR Recital 26 - Anonymous Information**:
> "The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person."
This is the load-bearing provision, not Article 6. Naming a legal basis — legitimate interest included — concedes that personal data is being processed. When none is stored, the question never arises.
**Sealmetrics Technical Design Puts the Dataset Outside Scope**:
| Requirement | Implementation | How Sealmetrics Does It |
|------------|-----------------|------------------------|
| Lawful Basis | Needed only if personal data is processed | None required: no personal data stored |
| No Personal Data | Session-only, no ID | Fresh session ID per visit |
| No IP Storage | Cannot identify individuals | Zero IP collection |
| Data Minimization | Collect only necessary | No email, no device fingerprint |
| Storage Limitation | Don't keep longer than needed | 24-month retention max |
| Transparency | Privacy Policy required | Disclose to users |
| Balancing Test | Conduct DPIA | Sealmetrics provides DPA |
### GDPR Article 25 - Data Protection by Design
Sealmetrics cookieless architecture **embeds compliance into code**:
```javascript
// Article 25: Data Protection by Design and Default
// ✓ Data Minimization Built-In
const minimumRequiredFields = {
sessionId: true, // Required: track visit
url: true, // Required: know which page
timestamp: true, // Required: when visited
// NOT collected:
// ipAddress: false,
// deviceId: false,
// macAddress: false,
// emailHash: false,
};
// ✓ Storage Limitation Built-In (fixed for all plans)
const retentionPolicy = {
eventDetailDays: 14, // Event-level rows purged after 1 day
hourlyAggregateDays: 90, // Hourly aggregates: 90 days
dailyAggregateDays: 730, // Daily aggregates & conversions: 24 months
// Automatically enforced by database TTLs
};
// ✓ Purpose Limitation Built-In
const allowedPurposes = [
'analytics', // Website performance
'fraud_detection', // Security
// NOT allowed:
// 'targeted_advertising': false,
// 'user_profiling': false,
// ... see full example at https://docs.sealmetrics.com/blog/cookieless-tracking-technical-deep-dive
```
---
## Sealmetrics Cookieless System
### Full Architecture Overview
```
┌─────────────────────────────────────────────────────────┐
│ WEBSITE VISITOR │
│ (Chrome, Safari, Firefox, etc) │
└────────────────────────┬────────────────────────────────┘
│
Page loads
│
▼
┌─────────────────────────────────────────────────────────┐
│ SEALMETRICS TRACKING CODE │
│ (JavaScript snippet injected in website) │
│ │
│ 1. Generate session ID (fresh each visit) │
│ 2. Collect pageview data │
│ 3. NO IP capture │
│ 4. NO cookie creation │
└────────────────────────┬────────────────────────────────┘
│
HTTPS POST
│
▼
┌─────────────────────────────────────────────────────────┐
│ SEALMETRICS API ENDPOINT │
│ (Receives pageview/event data) │
│ │
│ • Validates data integrity │
│ • Filters spam/bot traffic │
│ • Stores in database (encrypted) │
│ • Does NOT log IP addresses │
└────────────────────────┬────────────────────────────────┘
// ... see full example at https://docs.sealmetrics.com/blog/cookieless-tracking-technical-deep-dive
```
---
## Performance & Data Accuracy
### How Cookieless Captures More Data
**Google Analytics (Cookie-Based)**: Loses data at every step
```
100 EU visitors arrive
├─ 87 reject cookie banner
│ ├─ 13 make explicit choice (accept/reject)
│ └─ 40-60 ignore banner entirely (ghost)
│
├─ GA captures: Only the ~13 who accepted
│ └─ Data loss: 87 visitors (87% loss)
│
└─ Remaining 13 visitors tracked:
├─ 2 on Safari (ITP blocks anyway)
└─ Only 11 truly tracked reliably
RESULT: 11/100 = 11% data capture
```
**Sealmetrics (Cookieless)**: Captures everyone
```
100 EU visitors arrive
├─ 87 reject/ghost banner (not applicable, no banner!)
├─ 13 accept (not applicable)
│
└─ ALL 100 tracked automatically:
├─ System 1: Session tracking captures 98
│ └─ (All except JS-blocked visitors)
│
└─ System 2: Server-side fallback captures 2
└─ (JS-blocked, no-script scenarios)
RESULT: 100/100 visitors measured
```
### Accuracy Comparison Table
| Metric | Google Analytics | Other Cookieless Tools | Sealmetrics |
|--------|-----------------|----------------------|------------|
| **Data Capture Rate (EU)** | 40-85% | Higher, but non-zero loss where consent applies | **Complete** |
| **Banner Required** | Yes | No | **No** |
| **IP Stored** | Yes | Hashed | **No** |
| **Consent Required** | Yes | No | **No** |
| **Session Expiry** | 2 years | 30 mins - Session-based | **Session-based** |
| **GDPR position** | Requires DPA + consent | Built-in | **Outside material scope** |
| **Consent-driven data loss** | 15-60% | Lower, non-zero | **None** |
**Why Sealmetrics is Superior**:
- No data loss from cookie rejection
- No regulatory gray area (true zero-IP)
- No banner fatigue for users
- Better decision-making, on your whole audience rather than the consenting slice of it
Want to learn more about why [privacy-first analytics matters in 2025](/blog/privacy-first-analytics-2025)? Read our comprehensive guide.
---
## Comparison: Cookieless vs Cookie-Based
### Technical Architecture Differences
**COOKIE-BASED (Google Analytics)**
```
Day 1: User visits
├─ Cookie created: "ga_id=abc123" (2-year expiry)
├─ Stored on user device
└─ Requires: Consent, Privacy Policy, DPA
Day 30: Same user visits again
├─ Cookie exists: "ga_id=abc123"
├─ Sent with request
└─ Same visitor recognized
Day 365: User visits again
├─ Cookie still exists: "ga_id=abc123"
├─ Still same visitor
└─ 2-year cross-session tracking
Day 365: Safari user visits
├─ Safari ITP blocks third-party cookies
├─ "ga_id" not created
└─ Not tracked (lost entirely)
```
**COOKIELESS (Sealmetrics)**
```
Day 1: User visits
├─ Session computed: "sess_xyz" (fresh, ephemeral)
├─ Never stored on the device; expires with the visit
└─ No consent needed (no personal data)
Day 1: Same user browses 3 pages
├─ All 3 pages linked to "sess_xyz"
├─ Session metrics calculated
└─ Visit understood
Day 2: Same user visits again
├─ NEW session: "sess_abc" (completely fresh)
├─ No link to previous session
└─ Treated as new visitor
Day 30: Same user visits again
├─ NEW session: "sess_def"
├─ Can't recognize returning user
└─ But every visit still measured
Day 365: Safari user visits
├─ Session created: "sess_ghi" (normally)
├─ Safari doesn't block sessions
└─ Tracked fully (no loss)
```
### Data You Get With Each Approach
| Question | Cookie-Based Answer | Cookieless Answer |
|----------|-------------------|-------------------|
| How many visits? | 40-85% of the real count | **All of them** |
| How many sessions? | Unknown (many lost) | **All tracked** |
| Pages per session? | Biased (low estimate) | **Accurate** |
| Bounce rate? | Inflated (missing data) | **Accurate** |
| Which pages convert? | Underestimated | **Accurate** |
| Traffic source effectiveness? | Unreliable | **Accurate** |
| Are users returning? | Only those accepting cookies | **Not measured — each entrance counts as new** |
| Where do visitors from Germany go? | 40-85% of German traffic | **All German traffic** |
---
## Why Sealmetrics Wins Over Competitors
### Technical Superiority
For detailed platform comparisons, see:
- [Sealmetrics vs Google Analytics](/blog/google-analytics-vs-sealmetrics)
- [Sealmetrics vs Plausible](/blog/sealmetrics-vs-plausible)
**Cookie-Based Analytics (e.g., Google Analytics)**
- ❌ Loses 87% EU traffic
- ❌ Requires consent banner
- ❌ Stores IPs (even latest versions)
- ❌ Safari ITP blocks tracking
- ✓ Excellent for non-GDPR regions
**Other Cookieless Tools**
- ✓ Cookieless approach
- ✓ No banner needed
- ⚠️ Hash IPs (gray area)
- ✓ Privacy-focused
- ❌ Can miss JS-blocked traffic
- ❌ Some require self-hosting
**Sealmetrics**
- ✓ True cookieless (sessions only)
- ✓ Zero IP storage (true GDPR)
- ✓ Complete data capture (dual system)
- ✓ No consent needed
- ✓ Works with Safari, Firefox, Chrome
- ✓ Simple 1-minute setup
### The Bottom Line
Sealmetrics captures what competitors miss:
- **1.2x to 2.5x the data Google Analytics reports**, depending on where your site sits in the 15-60% loss band
- **All browsers equally** (no Safari data loss)
- **Zero IP stored**, which is what takes the legal question off the table rather than answering it
- **No banner fatigue** (no consent popup)
- **Better insights** (based on your whole audience, not the consenting part of it)
---
## FAQ: Technical Questions
### How does Sealmetrics work without cookies?
Sealmetrics computes a **session ID** fresh with each visit. This ID lives only during the visit (~2 hours of inactivity), then expires automatically, and is never stored on the device. Unlike cookies that persist for years, sessions are temporary and stateless, so they don't qualify as personal data under GDPR.
### Why doesn't Sealmetrics store IP addresses?
IP addresses are **personal data** under GDPR. Storing them (even hashed) requires consent or another legal basis. Sealmetrics never persists IPs in the analytics database — they are used only transiently server-side for security and anti-abuse checks, and appear only in short-lived operational logs with limited retention. No analytics metric is ever calculated from an IP.
### Can I track returning visitors with Sealmetrics?
**Not across visits.** Each visit generates a new session ID. So you can't say "John returned on Tuesday" (you don't know it's John). Each entrance is counted as new, independent data — there is no returning-visitor metric, because no identifier links one visit to another.
This is a **feature, not a bug**: Returns you get privacy compliance while competitors need consent.
### How does Sealmetrics handle bot traffic?
Sealmetrics filters bots at the API level, before data reaches your dashboard:
```javascript
// API-side bot detection
const botSignatures = [
'googlebot', 'bingbot', 'slurp', 'duckduckgo',
'baiduspider', 'yandexbot', 'facebookexternalhit'
];
if (userAgent.some(sig => userAgent.includes(sig))) {
// Mark as bot, filter from analytics
isBot = true;
}
// Only non-bot traffic appears in dashboard
```
Unlike Google Analytics (which sometimes misses bot traffic), Sealmetrics filters at source.
### What if JavaScript is disabled on visitor's browser?
Sealmetrics has a **fallback system**:
1. Primary: JavaScript snippet loads → Session tracking
2. Fallback: If JS disabled → Server-side tracking captures pageview
3. Result: Even no-JS visitors are counted
This is why Sealmetrics keeps counting where competitors drop those visits.
### How does Sealmetrics handle GDPR data subject requests?
Since Sealmetrics stores **no personal data** (no IPs, no persistent IDs), GDPR data subject requests are simple:
- **Right of Access**: User requests their data → You respond: "We have no personal data stored about you" ✓
- **Right to Deletion**: User requests deletion → Automatic (no personal data to delete) ✓
- **Right to Portability**: User requests data export → Sessions are anonymous, no export needed ✓
**Competitors' situation** (hashing IPs): Gray area. Regulators argue hashed IPs + user agent + time = can be re-identified, so DPA required.
### Can I integrate Sealmetrics with my CDP or marketing tools?
Yes, Sealmetrics provides an **open API**:
```javascript
// Sealmetrics API
GET /api/v1/analytics/{siteId}/sessions
GET /api/v1/analytics/{siteId}/events
GET /api/v1/analytics/{siteId}/conversions
// Parameters:
// - dateRange
// - segmentation
// - custom events
// - attribution
// Returns: JSON data
// Use with webhooks, custom integrations
```
Unlike Google Analytics (which restricts API), Sealmetrics data is yours.
### How accurate is Sealmetrics compared to Google Analytics?
**More accurate, actually:**
| Metric | GA4 | Sealmetrics |
|--------|-----|------------|
| Captured data | 40-85% in EU | All visits |
| Accuracy of captured data | 97% | 97% |
| **Overall coverage** | **40-85%** | **Complete** |
Sealmetrics might show 100,000 sessions/month where GA4 shows 45,000 for the same period. Sealmetrics is more accurate because it measures every visit — and because the 55,000 GA4 missed were not a random sample.
### What about cross-domain tracking?
Sealmetrics handles cross-domain tracking **without cookies**:
```javascript
// Verify two domains belong to same business
// via verified ownership in Sealmetrics dashboard
// Then sessions automatically shared:
// User visits: mysite.com → shared-session-id-1
// User clicks to: shop.mysite.com → same-session-id-1
// All tracked as one session across domains
```
**Unlike GA**: No need for complex _ga cookies across domain boundaries.
### How does Sealmetrics GDPR compliance work technically?
**Architecture ensures GDPR compliance:**
```
Session ID (fresh, temporary) → Personal data? NO
├─ Can't identify individual
├─ Expires automatically
└─ No legal basis needed
No IP storage → Personal data? NO
├─ Can't geolocation
├─ Can't identify
└─ No DPA required
No email/device ID → Personal data? NO
├─ No behavioral profile
├─ No individual tracking
└─ No consent needed
Result: no personal data, so no Article 6 basis needed (Recital 26)
```
**Competitors (GA + hashing)**:
```
Hashed IP + user agent + timestamp + location
├─ Possible re-identification? YES (regulators argue)
└─ Requires: Consent + DPA + DPIA (safer)
```
Sealmetrics removes this regulatory risk entirely.
---
## Conclusion: Why Cookieless Analytics Matters
Learn more about [how cookieless analytics works](/blog/cookieless-analytics-guide) in our complete implementation guide.
**The Problem** (Today):
- Google Analytics loses 15-60% of your EU visitor data, and not at random
- Cookie banners damage user experience (conversion rates drop 10-15%)
- GDPR fines for non-compliance (up to 4% of global revenue)
- You're making decisions on a self-selected sample
**The Solution** (Sealmetrics):
- Cookieless tracking measures **every visit**
- No consent banner needed (no user frustration)
- Zero IP storage, so no personal data and no gray area
- Better insights based on your whole audience
**What You Get With Sealmetrics**:
- Real pageview counts, not the 40-85% a banner lets through
- Accurate bounce rates and session metrics, measured in aggregate
- A legal position that rests on architecture, not on a balancing test
- Same insights, without a consent record to defend
**Implementation Takes 1 Minute**:
1. Copy tracking snippet
2. Paste in website ``
3. Wait 1-2 minutes
4. See all of your traffic in the dashboard
No more 15-60% data loss. No more consent banners. No more regulatory uncertainty.
That's how cookieless analytics works—and why Sealmetrics leads the market in technical implementation.
---
## Additional Resources
- [GDPR and ePrivacy Explained](/legal/gdpr-and-eprivacy) - Why no legal basis is required
- [Sealmetrics vs Google Analytics: Complete Comparison](/blog/google-analytics-vs-sealmetrics) - Feature breakdown
- [GDPR Compliant Analytics Framework](/blog/gdpr-compliant-analytics-framework) - Full compliance guide
- [Cookie Banner Ghosting & Data Loss](/blog/cookie-banner-ghosting-data-loss) - Why cookieless matters
- [Cookieless Analytics Guide](/blog/cookieless-analytics-guide) - Complete implementation guide
## Privacy-First Analytics: Why It Matters
URL: https://docs.sealmetrics.com/blog/privacy-first-analytics-2025
> **TL;DR** — Privacy-first analytics is now essential. GDPR enforcement and cookie phase-outs make consentless, cookieless analytics the only sustainable path.
*Updated July 2026 — refreshed pricing and tool comparisons. Originally published November 2025.*
The digital analytics landscape reached a critical inflection point in 2025. With Google Chrome completing its third-party cookie phase-out in Q2 2025 and European regulators issuing over €1.4 billion in GDPR fines throughout 2024, privacy-first analytics isn't just a competitive advantage—it's a business necessity.
Traditional cookie-based analytics tools like Google Analytics are bleeding data. **87% of German users** and **73% of French users** reject cookie consent banners — and while a rejection rate is not the same thing as a data loss rate, the shortfall that actually reaches your reports still runs to **15-60%** depending on your sector, your brand and your traffic mix. Meanwhile, businesses using privacy-first, cookieless analytics capture their traffic in full, with no consent record to maintain and no banner to defend.
This comprehensive guide explains why privacy-first analytics matters today, how it works technically, and why solutions like **Sealmetrics**—which combines cookieless tracking with consentless data collection—represent the future of web analytics.
## Key Takeaways
- **Chrome's cookie deprecation** (completed Q2 2025) has eliminated third-party tracking for 60%+ of web traffic
- **Cookie rejection rates** in the EU run as high as 87%, translating into 15-60% real data loss for cookie-based analytics
- **Privacy-first analytics** using cookieless, consentless approaches capture the full picture, and — storing no personal data — sit outside the GDPR's material scope entirely
- **Sealmetrics** provides true privacy-first analytics by eliminating cookies, consent requirements, and IP storage entirely
## What is Privacy-First Analytics?
Privacy-first analytics refers to web analytics solutions that prioritize user privacy by design while still providing accurate, comprehensive data for business decision-making. Unlike traditional analytics that rely on cookies, third-party tracking, and personal data collection, privacy-first analytics uses technical approaches that eliminate the need for consent banners and personal identifiers.
The core principle is simple: **you can track user behavior without tracking individual users**.
### The Privacy-First Spectrum
Not all "privacy-focused" analytics tools are created equal. There's a spectrum:
**Traditional Cookie-Based (Google Analytics 4)**
- Requires cookies for tracking
- Requires consent banners under GDPR
- Stores IP addresses (hashed or raw)
- Data loss: 15-60% in EU markets, depending on sector, brand strength and traffic sources
**Cookieless with Hashing (Plausible, Matomo)**
- No tracking cookies
- May still require consent (depends on configuration)
- Stores hashed IP addresses
- Data loss: smaller, but non-zero wherever consent is still required
**True Consentless (Sealmetrics)**
- No cookies whatsoever
- No consent requirement: nothing is stored on or read from the device, so ePrivacy Article 5(3) isn't engaged
- Zero IP storage—not even hashed
- No consent-driven data loss
The distinction matters enormously. While tools like Plausible and Matomo are improvements over Google Analytics, they still rely on IP address hashing for session identification, which many legal experts argue requires consent under GDPR. **Sealmetrics** goes further by eliminating IP storage entirely — which is what puts the resulting dataset outside the GDPR's material scope (Recital 26) rather than merely giving it a defensible legal basis.
## Why 2025 Was the Turning Point
Several converging trends made 2025 the year privacy-first analytics became mandatory rather than optional.
### Chrome's Third-Party Cookie Phase-Out Completed
In Q2 2025, Google Chrome finally completed its years-long process of deprecating third-party cookies. With Chrome representing approximately 63% of global browser market share, this change effectively ended third-party tracking for the majority of web traffic.
What this means practically:
- Cross-domain tracking is dead
- Retargeting campaigns face massive limitations
- Attribution models relying on cookies are broken
- Traditional analytics tools miss 60%+ of user journeys
Businesses still using cookie-based analytics solutions are operating partially blind. **Cookieless analytics** became not just preferable but necessary for accurate data collection.
### GDPR Enforcement Reached Critical Mass
European data protection authorities issued over **€1.4 billion in GDPR fines** in 2024, with a significant portion related to analytics implementations. Notable cases include:
- **€90M fine** to a major e-commerce platform for using Google Analytics without proper safeguards
- **€25M fine** to a media company for non-compliant cookie consent implementations
- **€15M fine** to a SaaS provider for illegally storing user IP addresses
The CNIL (French data protection authority) has been particularly aggressive, explicitly stating that many analytics tools require consent because they "can be used to identify individuals through IP address fingerprinting." This legal interpretation has made GDPR compliant analytics using consentless approaches like Sealmetrics increasingly attractive.
### Cookie Rejection Rates Hit Record Highs
Studies from Q4 2024 show cookie rejection rates in EU markets have reached unprecedented levels:
- **Germany**: 87% of users reject cookies
- **France**: 73% of users reject cookies
- **Spain**: 68% of users reject cookies
- **Netherlands**: 71% of users reject cookies
On top of that, a large share of users exhibit "banner blindness"—they simply ignore cookie banners entirely without making any decision.
**Resist the temptation to add those numbers up.** A rejection rate is measured among the people who engaged with the banner, and it is not the same as your data loss rate. Google Consent Mode v2 models part of the unconsented traffic back into your reports, and visitors who ignore a banner on one visit sometimes accept on the next. Net of both, cookie-based analytics in Europe typically loses **15-60%** of its data — a capture rate of 40-85%. That range is real: a well-known consumer brand whose visitors arrive direct sits near the bottom of it, while a site buying cold traffic in a privacy-sensitive vertical sits near the top.
For businesses operating in the EU, this isn't just a data quality issue. The loss is not spread evenly across your channels, which means it doesn't merely shrink your reports — it reorders them.
### Consumer Privacy Awareness at All-Time High
Consumer awareness of data privacy issues has never been higher. A 2024 Pew Research study found that:
- 81% of consumers feel they have little control over data companies collect
- 79% are concerned about how companies use their data
- 68% actively use tools to block tracking (ad blockers, privacy browsers)
This consumer sentiment drives both the high cookie rejection rates and increasing regulatory pressure. Businesses that position themselves as privacy-first gain competitive advantage through increased consumer trust.
## The Cost of NOT Being Privacy-First
The financial and strategic costs of continuing to use traditional, cookie-based analytics are substantial and growing.
### Massive Data Loss
Cookie-based analytics platforms experience **15-60% data loss** in EU markets, driven by:
1. **Cookie rejection** — users who actively decline
2. **Banner ghosting** — users who ignore the banner and never decide, usually the larger group
3. **Ad blockers**
4. **Browser privacy features** (Safari ITP, Firefox ETP)
Where you land inside that band is not random. It tracks your sector, the strength of your brand and where your traffic comes from — the three things that determine how willing a visitor is to click "Accept" on a domain they may not recognise.
The deeper problem isn't the volume, it's the selection. Businesses using Google Analytics, Adobe Analytics, or similar tools are making decisions on **incomplete and biased data**. Privacy-conscious users are systematically excluded, so the picture isn't a smaller version of your audience — it's a different one.
**Cookieless analytics** like Sealmetrics removes this loss at the source, by not requiring cookies or consent in the first place.
### Legal and Financial Risk
GDPR fines for non-compliant analytics implementations have reached €15M-90M for individual companies. Beyond headline fines, the legal costs include:
- Legal consultation fees: €50K-200K annually
- DPO (Data Protection Officer) requirements
- Regular compliance audits
- Potential class-action lawsuits from users
Many companies assume they're compliant because they use a cookie banner, but the CNIL has made clear: **a cookie banner doesn't make Google Analytics GDPR compliant**. The fundamental issue is data processing, storage, and transfer—not just consent collection.
Analytics that stores no personal data at all sidesteps this entire category of exposure — not because it has a better legal basis than consent, but because with no personal data there is no Article 6 basis to choose and nothing for a consent record to prove.
### Brand Reputation Damage
In 2024-2025, several high-profile companies faced significant brand damage from privacy violations:
- User boycotts following GDPR fine announcements
- Negative media coverage around "spying" on users
- Loss of B2B contracts from privacy-conscious clients
- Difficulty recruiting privacy-aware technical talent
Privacy-first companies, by contrast, use their analytics approach as a marketing differentiator. "We use privacy-first analytics and don't sell your data" has become a competitive advantage in crowded markets.
### Customer Trust Erosion
Perhaps most insidiously, non-privacy-first analytics implementations erode customer trust gradually:
- Cookie banners create friction in user experience
- Users associate intrusive banners with the brand, not the analytics tool
- Privacy-conscious customers may abandon before converting
- Technical users inspect implementations and judge companies accordingly
**Consentless analytics** eliminates this friction entirely. No banner, no interruption, no trust erosion—just seamless user experience while still capturing complete data.
## Three Pillars of Privacy-First Analytics
True privacy-first analytics rests on three technical and legal pillars.
### Pillar 1: No Cookies (Cookieless Tracking)
**Cookieless analytics** means no tracking cookies whatsoever—not first-party, not third-party. This is achieved through alternative session identification methods:
**Session-Based Tracking**: Generate temporary session identifiers that reset after each visit. Unlike cookies that persist across sessions, these identifiers are ephemeral and cannot track users over time.
The key: these identifiers are **single-session only** and cannot be used to track users across visits or identify individuals.
### Pillar 2: No Consent Requirements (Consentless)
**Consentless analytics** doesn't pick a better Article 6 legal basis than consent. It removes the need for one. Two rules are in play, and conflating them is the most common mistake in this whole debate:
1. **ePrivacy, Article 5(3)** — the rule that actually mandates cookie banners. It requires consent to store information on, or read information from, a user's device. If nothing is written to the browser and nothing is read back, the obligation is never triggered.
2. **GDPR, Recital 26** — the data protection principles do not apply to anonymous information. If no personal data is stored, the resulting dataset sits outside the Regulation's material scope, and no Article 6 basis is needed at all.
This is legally coherent when:
1. **No personal data is stored** (no IP addresses, not even hashed; no user IDs)
2. **The purpose is analytics only** (not advertising, profiling, or cross-site tracking)
3. **Nothing is stored on or read from the device** (no cookies, no LocalStorage, no fingerprint persisted)
4. **The claim is documented** and can withstand a DPO's questions
According to CNIL's 2020 guidance on analytics, cookieless approaches that don't store IP addresses and limit data retention to statistical purposes can operate without consent.
**Why we don't claim legitimate interest**: Article 6(1)(f) is the popular answer in this market, and it is a trap. Invoking any Article 6 basis is an admission that you *are* processing personal data and merely have a good reason for it — which concedes the argument you were trying to win. The narrow, correct use of 6(1)(f) is for transient handling of an IP in memory for security and anti-abuse (Recital 49), and that data never reaches the analytics store.
**Sealmetrics' approach**: no IP storage, no device storage, session-level statistics only. No consent banner required, and no legal basis to defend.
### Pillar 3: No Personal Data Storage (Zero IP Storage)
Many analytics tools claim to be "privacy-friendly" while still storing IP addresses—even in hashed form. This is problematic because:
1. **Hashed IPs are still personal data under GDPR**
2. **Hash collisions** can reveal original IPs
3. **Combined with other data** (user agent, screen resolution), hashed IPs can identify individuals
True privacy-first analytics **stores zero IP addresses**—not raw, not hashed, not at all.
**Sealmetrics' technical approach**:
- Visitor country is derived from the **browser timezone** (`Intl.DateTimeFormat().resolvedOptions().timeZone`), not from the IP — see [country detection](/security-privacy/country-detection)
- Only country-level geo is stored (e.g., "Germany") — never city or region
- The IP is used transiently server-side for security/anti-bot checks — never stored in the analytics database (there is no IP column)
This approach is **fundamentally different** from competitors like Plausible or Matomo, which hash and store IPs for session identification. By using session-based tracking instead, Sealmetrics achieves the same functionality without ever storing any IP data.
## Comparison: Privacy-First Analytics Tools in 2026
| Feature | Google Analytics 4 | Plausible | Matomo | Sealmetrics |
|---------|-------------------|-----------|---------|-------------|
| **Requires Cookies** | ✅ Yes (first-party) | ❌ No | ❌ No | ❌ **No** |
| **Requires Consent Banner** | ✅ Yes (under ePrivacy) | ⚠️ Depends on config | ⚠️ Depends on config | ❌ **No (nothing stored on device)** |
| **Stores IP Addresses** | ✅ Yes (configurable) | ⚠️ Hashed | ⚠️ Hashed | ❌ **Zero IP storage** |
| **Consent-driven data loss** | 15-60% | Lower, but non-zero where consent applies | Lower, but non-zero where consent applies | **None** |
| **Third-Party Data Sharing** | ✅ Yes (Google servers) | ❌ No | ❌ No (self-hosted) | ❌ **No** |
| **Cross-Domain Tracking** | ⚠️ Limited (cookie-based) | ❌ No | ⚠️ Complex setup | ❌ **No** |
| **Data Retention** | 2-14 months | Unlimited | Unlimited | **24 months (GDPR-optimized)** |
| **Setup Complexity** | High (30-60 min) | Medium (10-15 min) | High (20-30 min) | **Low (2 minutes)** |
| **GDPR posture** | ⚠️ Requires configuration | ✅ Yes | ✅ Yes | ✅ **By architecture** |
| **Legal Basis** | Consent (6(1)(a)) | Depends on setup | Depends on setup | **None required — no personal data (Recital 26)** |
| **Real-Time Data** | ⚠️ Delayed 24-48h | ✅ Yes | ✅ Yes | ✅ **Yes** |
| **Privacy by Design** | ❌ No | ⚠️ Partial | ⚠️ Partial | ✅ **Yes** |
**Key Insight**: While Plausible and Matomo are significant improvements over Google Analytics, only **Sealmetrics** achieves true consentless operation by eliminating IP storage entirely. That technical difference is what removes the consent-driven data loss — and it changes the legal conversation from "can we justify this processing?" to "there is no personal data here to justify."
## How Sealmetrics Achieves True Privacy-First Analytics
**Sealmetrics** represents the most advanced implementation of privacy-first analytics principles available today. Here's how it works technically and legally.
### Technical Architecture
**Dual Tracking System**:
1. **Session-ID Mode**: Generates ephemeral session identifiers that reset after ~2 hours of inactivity
2. **Isolated Hits Mode**: For users with aggressive privacy settings, tracks individual pageviews without any session continuity
This dual approach keeps measurement working regardless of user privacy settings, browser configuration, or tracking prevention mechanisms — there is no consent gate for any of them to fail at.
**Zero IP Storage Implementation**:
```javascript
// Simplified: country comes from the browser timezone, not the IP
const timezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
// e.g. "Europe/Berlin" -> mapped server-side to "Germany"
// Server-side (simplified)
async function processAnalyticsHit(hit) {
await database.insert({
country: mapTimezoneToCountry(hit.timezone), // no IP lookup
// ... other non-personal analytics data
});
// The visitor's IP is only touched in memory for anti-bot checks
// and is never written to disk or stored in any database.
}
```
**Session Identification Without IPs**:
Instead of using IP addresses for session identification (like Plausible/Matomo), Sealmetrics uses proprietary privacy-preserving technology to identify sessions without cookies or personal data. This approach avoids ever processing or storing IP data.
### Legal Compliance Framework
**Outside the material scope of the GDPR (Recital 26)**:
Sealmetrics needs no Article 6 legal basis because:
1. **Purpose Limitation**: Data is used exclusively for analytics, never for advertising, profiling, or cross-site tracking
2. **Data Minimization**: No personal data is stored (no IPs, no user IDs, no PII)
3. **No device storage**: Nothing is written to or read from the browser, so ePrivacy Article 5(3) is never engaged
4. **Anonymous by construction**: with no identifiable natural person in the dataset, the Regulation's principles do not attach to it
**CNIL Compliance** (France):
The CNIL's 2020 guidance explicitly allows analytics without consent when:
- No cross-site tracking
- No personal data storage
- Limited data retention
- Clear privacy policy
Sealmetrics meets all criteria and has been successfully deployed on French websites passing DPO reviews.
**TTDSG Compliance** (Germany):
Germany's TTDSG (Telecommunications-Telemedia Data Protection Act) is among the strictest in Europe. Sealmetrics complies because:
- No cookies stored on user devices (TTDSG §25)
- No personal data accessed or stored
- The consentless position is documented and available for DPO review
### Data Retention Optimized for Privacy
Sealmetrics retains aggregated analytics data for **24 months** — deliberately below the 25-month ceiling CNIL sets for consent-exempt analytics. After 24 months, data is automatically deleted; event-level detail is purged after just 14 days.
This is longer than most competitors offer while staying inside the CNIL ceiling:
- Google Analytics 4: 2-14 months
- Plausible: Unlimited (user-configured)
- Matomo: Unlimited (user-configured)
The 24-month period allows for year-over-year comparisons while respecting GDPR's data minimization principle.
### Implementation: 2-Minute Setup
Unlike Google Analytics (30-60 minute setup) or Matomo (20-30 minutes), Sealmetrics can be implemented in under 2 minutes:
```html
```
That's it. No configuration files, no consent banner integration, no complex setup. **Cookieless analytics** that just works.
## Migration Guide: From Cookie-Based to Privacy-First
### Step 1: Assess Current Data Loss
Before migrating, understand how much data you're currently losing:
1. Compare Google Analytics users to actual server logs
2. Check cookie rejection rates in your consent banner dashboard
3. Identify discrepancies between analytics and conversion data
Most businesses discover they're losing somewhere between **15% and 60% of EU traffic data**—and, more to the point, that the loss is heavier on some channels than others.
### Step 2: Run Parallel Tracking (30 Days)
Don't immediately remove Google Analytics. Run **Sealmetrics** and your existing tool in parallel for 30 days:
```html
```
Compare data quality, accuracy, and coverage. You'll typically see:
- **Full traffic capture** in Sealmetrics vs a 40-85% capture rate in Google Analytics
- More accurate geographic data
- Better conversion attribution
- Identical or better real-time performance
### Step 3: Update Privacy Policy
Replace your cookie banner with a simple privacy policy update:
**Old** (cookie-based):
> "We use cookies to track your behavior across websites for advertising purposes. Click 'Accept' to consent."
**New** (consentless):
> "We use privacy-first analytics (Sealmetrics) to understand website usage. This tool doesn't use cookies, doesn't store your IP address, and stores nothing on your device. Because no personal data is retained, this measurement falls outside the scope of the GDPR and requires no consent. Read our [privacy policy](#) for details."
No banner, no interruption, better user experience.
### Step 4: Remove Cookie Banner Code
Once you've verified Sealmetrics data quality, remove:
- Cookie consent banner JavaScript
- Google Analytics tracking code
- Any other cookie-based analytics or advertising trackers
**Result**: cleaner website, faster load times, better SEO, and no consent-driven gap in your data.
### Step 5: Train Team on New Dashboard
**Sealmetrics** provides a simpler, more focused dashboard than Google Analytics. Key differences:
- **No custom dimensions/metrics needed** - Essential data is built-in
- **Real-time by default** - No 24-48 hour delay
- **Privacy-friendly user paths** - See common flows without tracking individuals
- **Export capabilities** - Get raw data for custom analysis
Most teams find Sealmetrics easier to use than Google Analytics because it focuses on actionable metrics rather than overwhelming users with options.
## Common Mistakes to Avoid
### Mistake 1: Assuming "Cookieless" Means "Privacy-First"
Many tools market themselves as "cookieless" while still storing IP addresses, creating cross-site identifiers, or requiring consent. True **privacy-first analytics** goes beyond just eliminating cookies.
**Check for**:
- IP storage practices (hashed or raw = still personal data)
- Session identification method (fingerprinting = risky)
- Legal position (consent, legitimate interest, or genuinely no personal data at all)
### Mistake 2: Using Multiple Analytics Tools
Running Google Analytics AND privacy-first analytics simultaneously long-term increases legal risk:
- Google Analytics still processes personal data
- Cookie banner still required
- Data loss continues
**Solution**: Use parallel tracking only during migration (30 days), then fully switch to privacy-first.
### Mistake 3: Reaching for Legitimate Interest When You Don't Need It
The reflex, when someone asks "what's your legal basis?", is to answer "legitimate interest, Article 6(1)(f)". Resist it. Naming an Article 6 basis concedes that you are processing personal data — which is the opposite of the position a genuinely consentless tool is in.
Document the real thing instead:
- What is actually stored, field by field, and why none of it identifies a person
- That nothing is written to or read from the user's device (so ePrivacy Article 5(3) is not engaged)
- Why the dataset therefore falls outside the GDPR's material scope (Recital 26)
That documentation is what a DPO will ask for, and it is a stronger answer than a balancing test.
### Mistake 4: Ignoring Data Quality Improvements
Many businesses migrate to privacy-first analytics but don't leverage the better data:
- Complete traffic visibility enables better decisions
- Complete conversion funnels improve optimization
- Accurate geographic data enhances targeting
**Action**: re-run the decisions you made on partial data — channel budgets especially — against complete data, and see which ones flip. The uneven ones are where the money is.
## Frequently Asked Questions
### Is privacy-first analytics GDPR compliant?
Yes — but note *how*. A properly cookieless, consentless tool doesn't rely on Article 6(1)(f) legitimate interest; it stores no personal data, which puts the dataset outside the GDPR's material scope altogether (Recital 26). The key requirements are:
- No personal data stored (no IP storage, not even hashed)
- Nothing written to or read from the user's device, so ePrivacy Article 5(3) is never triggered
- Limited data retention
- Purpose limitation (analytics only, not advertising)
- User rights respected (privacy policy, right to object)
**Sealmetrics** is built around this position and has passed DPO reviews in Germany, France, and other strict jurisdictions. Those are customer assessments — no supervisory authority certifies analytics tools, and SealMetrics holds no ISO 27001 or SOC 2 certification.
### Do I need a cookie consent banner with consentless analytics?
No. The rule that mandates cookie banners is ePrivacy Article 5(3), which applies to storing or reading information on a user's device — and Sealmetrics does neither. You should still:
- Disclose analytics usage in your privacy policy
- Provide an opt-out mechanism
- Document why no personal data is stored, so the position survives a DPO review
The absence of a cookie banner improves user experience and removes the 15-60% consent-driven data loss.
### How accurate is cookieless tracking compared to cookie-based?
**Cookieless analytics** is typically **more accurate** than cookie-based tracking because:
- No consent-driven loss to recover from — that closes a 15-60% gap
- No ad blocker interference (browser-based tracking not blocked)
- No cross-domain tracking issues (session-based is single-domain)
Cookieless approaches like Sealmetrics count essentially all real traffic, against a 40-85% capture rate for cookie-based tools in EU markets.
### Can privacy-first analytics track conversions?
Yes. **Sealmetrics** tracks conversions, goals, and custom events without cookies:
```javascript
// Track conversion event
sealmetrics('track', 'conversion', {
type: 'signup',
value: 99,
currency: 'EUR'
});
```
Session-based tracking maintains user journey continuity for attribution without requiring cookies or personal data.
### What about e-commerce tracking?
Privacy-first analytics fully supports e-commerce tracking including:
- Product views
- Add to cart events
- Checkout steps
- Revenue attribution
**Example** (Sealmetrics):
```javascript
sealmetrics('track', 'purchase', {
revenue: 149.99,
currency: 'EUR',
products: [
{name: 'Product A', price: 99.99},
{name: 'Product B', price: 50.00}
]
});
```
All tracked at session level without storing user identities or requiring cookies.
### Does privacy-first analytics work with ad campaigns?
Yes, but with important limitations:
- **UTM parameters work normally** (source, medium, campaign tracking)
- **Click IDs are limited** (no cross-domain tracking)
- **Retargeting is not supported** (no user-level tracking)
For businesses focused on privacy and EU markets, this limitation is acceptable since cookie-based retargeting already fails due to high rejection rates.
### How does Sealmetrics handle bot traffic?
**Sealmetrics** includes built-in bot detection:
- User agent filtering (known bot signatures)
- Behavioral analysis (suspicious patterns)
- Rate limiting (rapid-fire requests)
This ensures clean data without inflating metrics with bot traffic—a common problem with basic cookieless implementations.
### Can I migrate historical data from Google Analytics?
No. Due to fundamental technical differences (cookie-based vs cookieless), historical data cannot be directly migrated. However:
- Run parallel tracking during transition (30 days) to establish baseline
- Export critical historical data from Google Analytics for reference
- Focus forward: 100% data from day one with Sealmetrics is more valuable than incomplete historical data
### What's the performance impact on my website?
**Sealmetrics** is significantly lighter than Google Analytics:
- Script size: 1.3KB gzipped (vs 130KB for GA4 — **99x smaller**)
- Load time: ~20-30ms (vs 200-400ms for GA4)
- No consent banner JS (another 30-50KB saved)
Most websites see **faster page loads** after switching to privacy-first analytics.
### Is Sealmetrics suitable for mobile apps?
**Sealmetrics** currently focuses on web analytics. For mobile apps, consider:
- Server-side tracking (no SDK required)
- Webview analytics (if app uses webviews)
- Custom implementation using Sealmetrics API
Sealmetrics is currently focused on web analytics.
### How does pricing compare to Google Analytics?
Google Analytics is "free" but has hidden costs:
- Legal risk from GDPR non-compliance (€15M-90M fines)
- Data loss (15-60% of EU traffic)
- Engineer time for implementation/maintenance
**Sealmetrics** pricing (volume-based, all features included):
- Growth: €599/month (5M events) — €499/month with annual billing
- Scale: €1,079/month (15M events) — €899/month with annual billing
- Enterprise: Custom pricing (unlimited events)
Annual billing gives you 2 months free. ROI is immediate: complete data capture, and no consent banner to build, maintain or defend. See [Plans & Pricing](/billing) for full details.
### What reporting features does Sealmetrics include?
**Core features**:
- Real-time traffic monitoring
- Geographic analytics (country-level)
- Page performance metrics
- Referrer/source tracking
- Device/browser breakdowns
- Custom event tracking
- Conversion funnels
- Goal tracking
- API access for custom reporting
**Not included** (by privacy design):
- Individual user tracking
- Cross-site behavior
- Advertising integration
### Can I self-host Sealmetrics?
Currently, **Sealmetrics** is cloud-only to ensure:
- Automatic updates for GDPR compliance
- Optimized performance (CDN distribution)
- Simplified setup (no server configuration)
Self-hosting is under consideration for enterprise customers with specific compliance requirements.
### How does Sealmetrics handle GDPR data subject rights?
Users have rights to:
- **Access**: Data is anonymized, so no personal data to access
- **Rectification**: Not applicable (no personal data)
- **Erasure ("right to be forgotten")**: Automatically handled (no personal data stored)
- **Objection**: Opt-out mechanism provided in privacy policy
Because **Sealmetrics** stores no personal data, most GDPR rights don't apply—simplifying compliance substantially.
### What about the ePrivacy Directive?
The ePrivacy Directive (often called "Cookie Law") requires consent for storing information on user devices. **Cookieless analytics** like Sealmetrics doesn't store anything on user devices, so ePrivacy consent isn't required.
This is explicitly confirmed by CNIL guidance: server-side analytics that don't access/store data on user devices are exempt from ePrivacy requirements.
## Conclusion: Privacy-First is the Only Path Forward
The analytics landscape has fundamentally changed. Cookie-based tracking is dying—killed by browser privacy features, user rejection, and regulatory enforcement. Businesses still using traditional analytics tools are making decisions on a self-selected sample: the 40-85% of visitors their consent banner happens to let through.
**Privacy-first analytics** isn't just ethically superior—it's strategically necessary. Tools like **Sealmetrics** that combine cookieless tracking, consentless operation and zero IP storage provide:
- **100% data capture** (no loss from cookie rejection)
- **No personal data to account for** (the GDPR obligations that attach to personal data are not triggered)
- **Better user experience** (no cookie banners)
- **Faster website performance** (lighter scripts)
- **Competitive advantage** (privacy as marketing differentiator)
The question isn't whether to migrate to privacy-first analytics—it's how quickly you can make the transition. Every day on cookie-based tools means losing 15-60% of your EU traffic data, unevenly, and carrying a consent apparatus you have to keep defending.
**Sealmetrics** makes the transition trivial: a 2-minute implementation, 30-day parallel tracking to verify data quality, then full cutover to complete analytics coverage without compromise.
The future of web analytics is privacy-first. The tools are ready. The legal framework is clear. The time to act is now.
## Additional Resources
### Further Reading
- [Complete Guide to Cookieless Analytics](/blog/cookieless-analytics-guide)
- [What Is Consentless Analytics?](/security-privacy/consentless-analytics) — How tracking without consent works under GDPR
- [How Consentless Tracking Works](/security-privacy/how-consentless-works) — Technical deep dive into the Four-Variable System
- [Benefits of Consentless Tracking](/security-privacy/consentless-benefits) — Why privacy-first analytics produces better data
- [Sealmetrics vs Google Analytics](/blog/google-analytics-vs-sealmetrics) — Complete feature and compliance comparison
- [Cookie Banner Ghosting](/blog/cookie-banner-ghosting-data-loss) — Why analytics loses 15-60% of your data
### Legal Resources
- [GDPR Official Text (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [CNIL Guidelines on Analytics (2020)](https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications)
- [EDPB Guidelines on the concepts of controller and processor](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-022019-processing-personal-data-under-article-61_en)
### Technical Documentation
- [Tracker Installation Guide](/implementation/tracker/installation)
- [API Reference](/api)
- [Getting Started](/getting-started/quick-start)
---
**Ready to achieve true privacy-first analytics?**
Experience complete data capture without a consent banner. No cookies, no personal data stored, no compromise.
→ [Start your free 14-day trial of Sealmetrics](https://my.sealmetrics.com/register)
→ [Schedule a demo](https://sealmetrics.com/demo)
→ [Read the documentation](https://docs.sealmetrics.com)
## Cookie Banner Ghosting: Why Analytics Loses 15-60% of Your Data
URL: https://docs.sealmetrics.com/blog/cookie-banner-ghosting-data-loss
> **TL;DR** — Many visitors never answer the cookie banner — they ignore it. Ghosting, not rejection, is the quiet reason cookie-based analytics loses 15-60% of data.
## Introduction
**The biggest threat to your analytics isn't cookie rejection—it's cookie banner ghosting.**
While marketers obsess over rejection rates (users clicking "Reject All"), the quieter drain on analytics data is the large share of visitors who simply ignore cookie consent banners entirely. They don't accept. They don't reject. They just... ignore it.
This phenomenon, called "banner ghosting" or "decision avoidance," represents basic human psychology: when faced with an unwanted decision, people procrastinate or avoid it entirely. Cookie consent banners trigger this avoidance behavior at scale.
**The math nobody runs**:
- **A large group ignores the banner** — no decision, no consent, no tracking
- **A second group rejects outright** — explicit refusal, no tracking
- **Only the accepters are measured** — and how big that group is depends entirely on who your visitors are
**Where it lands: cookie-based analytics loses 15-60% of your visitor data.** The spread is not noise — it is driven by your sector, the strength of your brand and where your traffic comes from. A recognised consumer brand whose visitors mostly arrive direct sits near the 15% end. A site buying cold traffic in a privacy-sensitive market sits near the 60% end. Either way, your real capture rate is somewhere between 40% and 85%, not 100%.
This isn't a rounding error—it's a structural hole in your business intelligence. Companies running Google Analytics 4, Adobe Analytics, or any cookie-based platform are making strategic decisions on a fraction of their actual traffic, and never a random fraction: the visitors who go missing are systematically different from the ones who stay.
**The solution**: Cookieless analytics platforms like Sealmetrics don't display consent banners because they don't require cookies. No banner means no ghosting, no rejection, no consent-driven data loss. Because no personal data is stored, the dataset falls outside the material scope of the GDPR (Recital 26), so no Article 6 legal basis is needed at all — and because nothing is written to or read from the device, the ePrivacy consent rule (Article 5(3)) is never triggered.
This article examines the psychology of banner ghosting, sizes the combined impact of ghosting plus rejection, and explains how cookieless analytics eliminates both problems simultaneously.
### Key Takeaways
- **A large share of visitors ignore cookie banners entirely** without making any decision (banner ghosting)
- **Combined with outright rejection, cookie-based analytics loses 15-60% of visitor data** — where you land depends on sector, brand strength and traffic sources
- **Banner ghosting is psychological avoidance behavior**, not technical blocking
- **Cookie-based analytics cannot solve this problem**—the banner itself causes the behavior
- **Cookieless analytics like Sealmetrics eliminates the banner**, removing consent-driven data loss entirely
---
## The Banner Ghosting Phenomenon
Banner ghosting represents the single largest source of analytics data loss in 2025, yet it receives far less attention than cookie rejection. Understanding why users ghost banners is essential to recognizing that cookie-based analytics has no solution.
### What is Banner Ghosting?
**Banner ghosting** occurs when a website visitor:
1. Sees the cookie consent banner
2. Does not click "Accept All"
3. Does not click "Reject All"
4. Does not customize cookie preferences
5. Continues using the site with the banner present
The user neither consents nor refuses—they simply ignore the decision entirely. During this state, cookie-based analytics tools cannot track the user because no consent has been granted. The user is invisible.
### Scale of the Problem
**Where ghosting runs hottest**:
**Germany**: the highest ghosting rates in Europe, driven by privacy awareness combined with sheer decision fatigue. German visitors are also the most likely to reject when they do engage.
**France**: after years of consent banner exposure, French users have developed textbook "banner blindness"—they see the popup but don't process it as requiring action.
**Spain**: Spanish internet users increasingly treat cookie banners as temporary annoyances to be ignored rather than genuine choices to be made.
**United Kingdom**: UK users demonstrate similar avoidance patterns to their EU counterparts despite Brexit, as UK cookie regulations remain aligned with EU standards.
**European Union overall**: ghosting is the norm rather than the exception. Nordic countries trend highest (high privacy awareness), Southern and Eastern Europe somewhat lower (emerging privacy awareness).
**United States**: materially lower than the EU, due to the absence of GDPR-style regulations and less intrusive consent mechanisms — but rising as California's CPRA and other state laws expand cookie consent requirements.
A caution before you reach for a calculator: **ghosting rates are a statement about your banner, not about your dataset.** How much analytics data you actually lose is a different number, and a smaller one. We work through why below.
### Psychology of Decision Avoidance
Banner ghosting is not a technical phenomenon—it's psychological. Users ghost banners due to well-documented cognitive biases:
**Decision fatigue**: Modern web users encounter 5-15 cookie banners per day. Each banner demands a privacy decision: accept tracking, reject tracking, or configure custom preferences. After the first few banners, users experience decision fatigue and begin ignoring subsequent banners to conserve mental energy.
**Status quo bias**: Humans prefer maintaining current state over making changes. When a cookie banner appears, the status quo (from the user's perspective) is "no banner on screen." The easiest way to maintain this state is to ignore the banner and continue browsing. Clicking "Accept" or "Reject" requires active decision-making, which conflicts with status quo bias.
**Choice overload**: Many cookie banners present complex choices: "Necessary cookies (required), Functional cookies (optional), Analytics cookies (optional), Marketing cookies (optional), Third-party cookies (optional)." Users face 5-10 binary decisions simultaneously. Choice overload leads to decision paralysis—so users make no decision at all.
**Temporal discounting**: The privacy implications of cookies (data collection, tracking, profiling) are abstract and future-oriented. The benefit of accessing website content is immediate and concrete. Users discount future privacy costs and prioritize immediate access, leading them to ghost the banner and proceed without deciding.
**Reactance**: Psychological reactance occurs when individuals perceive their freedom is being restricted. Cookie consent banners restrict the user's freedom to access content. Rather than comply with the restriction by making a choice, users experience reactance and refuse to engage with the banner as an assertion of autonomy.
**Banner blindness**: Years of exposure to intrusive popups, ads, and consent banners have trained users to visually filter out rectangular overlays on websites. Users literally do not process the banner as requiring action—their brain categorizes it as visual noise to be ignored.
### Duration of Ghosting State
**How long do users remain in ghosting state?**
Research on consent banner behavior shows:
**Single-session ghosters (75-80%)**: Most users who ghost a banner do so for the entire session. They browse multiple pages, potentially convert, and leave—all while ignoring the banner. If they return days later, they encounter the banner again and often ghost again.
**Multi-session ghosters (15-20%)**: Some users ghost across multiple sessions over days or weeks. They've trained themselves to ignore your banner specifically. Cookie-based analytics never captures these users unless they eventually accept or reject.
**Permanent ghosters (5-10%)**: A small segment never interacts with cookie banners on any site. They've developed complete banner blindness. Cookie-based analytics will never track these users.
**Median ghosting duration**: 3-5 minutes (single session) to indefinitely (never decides)
For cookie-based analytics, ghosting is functionally equivalent to rejection. Whether a user clicks "Reject All" or ignores the banner, the outcome is identical: **zero data captured**.
### Technical Manifestation of Ghosting
When a user ghosts a cookie banner, here's what happens technically:
1. **User visits website**: Browser loads HTML, CSS, JavaScript
2. **Analytics script loads**: Google Analytics (or similar) JavaScript executes
3. **Consent check**: Script checks for consent cookie (finds none)
4. **Banner displays**: Consent management platform shows banner
5. **User ignores banner**: No interaction occurs
6. **Analytics script waits**: Cannot set tracking cookies without consent
7. **User browses site**: Views multiple pages, clicks buttons, maybe converts
8. **No tracking occurs**: Every pageview, every action, every conversion is invisible
9. **User leaves**: Session ends without ever being tracked
From the analytics platform's perspective, this user never existed. They're not in your visitor count, not in your session data, not in your conversion reports. Ghosting creates a complete blind spot.
### Banner Ghosting vs Technical Blocking
**Critical distinction**: Banner ghosting is different from technical blocking (ad blockers, privacy extensions, browser settings).
**Technical blocking**:
- User actively installs software (uBlock Origin, Privacy Badger)
- Blocks analytics scripts from loading
- Affects 10-15% of users
- Demonstrates active privacy preference
**Banner ghosting**:
- User passively ignores consent banner
- Analytics scripts load but cannot set cookies
- Affects a far larger group than blocking does
- Demonstrates decision avoidance, not privacy preference
Both result in data loss, but ghosting affects several times more users than technical blocking and represents passive avoidance rather than active privacy protection. This means **cookieless analytics solves banner ghosting but not technical blocking** (nothing can track users who block JavaScript entirely).
---
## Combined Impact: What Ghosting Actually Costs You
Understanding banner ghosting fundamentally changes how we calculate analytics data loss. The problem isn't just users who click "Reject"—it's the group who never click anything, combined with the group who explicitly reject.
### The Real Data Loss Math
**Traditional analysis (incomplete)**: count the people who clicked "Reject All," call that your data loss, move on. This assumes every visitor makes a decision. Most don't.
**What actually determines the number**: three variables, none of which are the banner's design.
1. **Your sector.** A privacy-sensitive vertical — finance, health, anything a visitor would rather not be seen browsing — pushes acceptance down hard.
2. **Your brand strength.** People accept cookies from brands they already know and trust. An unfamiliar domain gets ghosted.
3. **Your traffic sources.** Direct and branded-search visitors arrive with intent and accept at higher rates. Cold bought traffic does not.
**Where that lands: 15-60% of your data, gone.** Equivalently, a capture rate somewhere between 40% and 85%. The range is wide because the underlying businesses are genuinely different, not because the measurement is fuzzy.
### Why the Loss Is Smaller Than the Non-Acceptance Rate
Here is the step most write-ups skip, including earlier versions of this one. **The share of visitors who don't accept the banner is not the share of data you lose.** Two things sit in between:
**Consent Mode modelling.** Google Consent Mode v2 sends cookieless pings for non-consenting users and models the missing conversions and sessions from them. That modelled data is an estimate rather than an observation — you cannot segment it, you cannot trust it at low volumes, and you should not present it to a board as measured fact — but it is not nothing. It recovers part of the gap.
**Repeat visits.** A visitor who ghosts on Monday may accept on Thursday. Ghosting is a per-visit behaviour, not a permanent state, so a slice of the ghosted population folds back into your measured data over time.
Net of both effects, the honest figure for a cookie-based setup is the 15-60% band — not the far larger number you get by naively summing ghosters and rejecters. **The problem is real without the inflation**, and inflated numbers are the fastest way to lose an argument with a sceptical CFO.
### Site-by-Site: Why the Loss Lands Between 15% and 60%
Country is a weaker predictor than the profile of your business. Three sketches:
**Profile A — strong consumer brand, mostly direct traffic**
```
Sector: retail / DTC, a name people recognise
Traffic: direct + branded search
Acceptance: comparatively high (visitors already trust the brand)
Data loss: near 15% → capture rate near 85%
```
This is the best case, and it is still one visitor in seven who never appears in your reporting.
**Profile B — mid-market B2B, mixed acquisition**
```
Sector: SaaS / professional services
Traffic: organic, paid search, social referrals
Acceptance: moderate, and inconsistent between channels
Data loss: middle of the band
```
The dangerous case, because the loss is uneven across channels — which distorts comparisons between them rather than just shrinking the totals.
**Profile C — cold paid traffic, privacy-sensitive market**
```
Sector: finance, health, legal, anything sensitive
Traffic: bought, cold, no prior brand relationship
Acceptance: low
Data loss: near 60% → capture rate near 40%
```
Here you are making decisions on a minority of your traffic, and the minority is self-selected.
### Why Ghosting Makes Rejection Statistics Misleading
Industry discussions often cite "87% rejection rate in Germany" or "75% rejection rate in France." These statistics are **rejection rate among users who interact with the banner**, not rejection rate among all visitors — and neither one is your data loss rate.
**Misleading stat**: "87% of users reject cookies in Germany"
**What it actually says**: 87% of the users who bothered to engage with the banner rejected. It is silent on the larger group who engaged with nothing at all.
Two different denominators, routinely conflated:
```
Rejections / (Acceptances + Rejections) = rejection rate among deciders
Non-accepters / All visitors = your consent gap
Measured shortfall vs reality = your actual data loss (15-60%)
```
Focusing on rejection rates understates the behaviour. Summing ghosting and rejection overstates the damage. **Ghosting is often larger than rejection** and receives no attention because ghosting users generate no event at all — there is no "reject" click to count.
### Sample Bias: Who Accepts Cookies?
The users who accept cookies are not representative of your total audience. They're a biased sample with distinct characteristics:
**Cookie accepters tend to be**:
- Less privacy-aware (don't understand tracking implications)
- Less technically sophisticated (don't use privacy tools)
- More trusting of websites (brand loyalty or naivety)
- In a hurry (click "Accept All" to dismiss banner quickly)
- Younger or older (youth: less concerned; elderly: less aware)
**Cookie ghosters and rejecters tend to be**:
- More privacy-aware (understand tracking, actively avoid)
- More technically sophisticated (use privacy tools, read policies)
- More skeptical of websites (question data practices)
- More patient (willing to ignore banner or carefully reject)
- Middle-aged professionals (prime awareness demographic)
**Business consequences of sample bias**:
Your analytics shows behavior of less privacy-aware, less technically sophisticated users who trust your brand. This is not representative of your market.
Example: You A/B test a feature. Variant A shows 5% conversion among cookie accepters. Variant B shows 6% conversion. You deploy B site-wide.
Problem: Privacy-aware users — the ones you're not tracking — might hate variant B because it requires more data entry, but you don't see their behavior. When you deploy B to 100% of traffic, overall conversions drop because the tested sample was unrepresentative.
**Sealmetrics eliminates sample bias**: with no banner in the way, Sealmetrics reports on your actual audience—privacy-aware and privacy-indifferent visitors alike. A/B tests are valid. Marketing attribution is accurate. Strategic decisions represent reality.
### Business Impact Example: E-commerce
**Scenario**: Fashion e-commerce site, 100,000 monthly visitors, 2% conversion rate (actual), €75 average order value. Mixed acquisition, so it sits mid-band — call it a 50% capture rate.
**Reality (partly invisible to cookie-based analytics)**:
- Visitors: 100,000
- Orders: 2,000
- Revenue: €150,000
**What Google Analytics 4 shows**:
- Tracked visitors: 50,000 (50,000 invisible)
- Tracked orders: ~1,000 (1,000 orders from ghosters/rejecters invisible)
- Tracked revenue: ~€75,000 (€75,000 invisible)
- Apparent conversion rate: 2% (coincidentally correct, but based on a biased sample)
Note what is *not* wrong here: the conversion rate. Loss that were uniform would mostly shrink your numbers without distorting your ratios, and you could live with that. The damage comes from the loss being **uneven**, which is what the next three decisions show.
**Business decisions based on incomplete data**:
1. **Marketing attribution**: Google Ads shows 200 conversions for €10,000 spend (€50 CPA). LinkedIn shows 40 conversions for €4,000 spend (€100 CPA). LinkedIn looks twice as expensive, so the company cuts its budget.
**Reality**: search visitors arrive with intent and accept the banner more often (say 60% captured); LinkedIn's B2B audience is more privacy-aware and accepts less (say 40%). Google actually drove ~333 conversions, LinkedIn ~100. True CPA: Google €30, LinkedIn €40. LinkedIn is still the more expensive channel — but by a third, not by double, and it was cut on the strength of a gap that was mostly measurement artefact.
2. **Product performance**: Product A shows 1,000 views and 20 purchases (2% conversion). Product B shows 800 views and 25 purchases (3.1%). A looks like the volume driver, B like a small high-converting niche.
**Reality**: Product A is bought by returning brand loyalists arriving direct, who accept the banner readily (~75% captured). Product B attracts comparison shoppers arriving cold from price aggregators, who don't (~45% captured). Actual figures: Product A ~1,333 views and ~27 purchases; Product B ~1,778 views and ~56 purchases. The conversion rates were right. **The volume ranking was backwards** — B is the bigger product, and inventory was planned against the wrong one.
3. **Landing page priorities**: Analytics shows the campaign landing pages carrying almost all measured revenue, so the team pours budget into more of them.
**Reality**: the comparison and specification pages that cold, privacy-aware researchers use before buying are systematically under-measured, because that audience is exactly the audience that ghosts banners. The pages that look like dead weight are doing work you can't see.
**Cost of decisions based on a half-blind sample**: €50,000-100,000 annually in misallocated marketing spend, wrong inventory, and suboptimal site design.
**Sealmetrics solution**: see all 100,000 visitors, all 2,000 orders, all €150,000 of revenue. Marketing attribution is accurate. Product demand is visible. Decisions are based on your whole audience rather than the half of it that clicks "Accept."
---
## Why Cookie-Based Analytics Cannot Solve Banner Ghosting
Banner ghosting is not a technical problem that cookie-based analytics platforms can fix through better engineering. It's a psychological problem caused by the banner itself. As long as a consent banner exists, ghosting will occur.
### Failed Solutions
Cookie-based analytics vendors have attempted multiple approaches to reduce ghosting and rejection:
**1. Consent Mode (Google Analytics 4)**
Google's "consent mode" attempts to provide degraded analytics for non-consenting users:
- Tracks aggregate data without individual user identifiers
- Uses modeling to estimate behavior of non-consenting users
- Provides partial data instead of no data
**Why it falls short**:
- Still requires a consent banner (ghosting continues)
- Modelled data is estimated, not observed — you can't segment it or drill into it
- Modelling quality degrades badly at low traffic volumes
- Legal uncertainty (some DPAs consider consent mode insufficient)
- It narrows the gap rather than closing it: a real shortfall remains, and it is the part of the 15-60% band you cannot see into
**2. Progressive Consent / Delayed Banners**
Some sites delay banner display hoping users engage with content first:
- Show banner after 10-30 seconds on site
- Show banner after user scrolls 50% down page
- Show banner on second pageview, not first
**Why it fails**:
- Users still ghost delayed banners at much the same rate, regardless of timing
- Creates compliance risk (tracking before consent)
- Regulators (especially CNIL) explicitly prohibit pre-consent tracking
- Ghosting is deferred, not eliminated
**3. Banner UX Optimization**
Endless tweaking of banner design to increase acceptance:
- Make "Accept" button more prominent (dark patterns)
- Hide "Reject" in submenus (illegal in most EU jurisdictions)
- Use persuasive copy ("Help us improve your experience")
- Simplify choices to binary Accept/Reject
**Why it fails**:
- Dark patterns are illegal under GDPR and face fines
- Users still ghost even optimized banners (decision avoidance, not design issue)
- Regulators require "Reject" to be as prominent as "Accept"
- Optimisation nudges acceptance up by a few points; it does not move you out of the 15-60% loss band
**4. Incentivized Consent**
Offering incentives for accepting cookies:
- "Accept cookies to get 10% discount"
- "Accept cookies to access premium content"
- "Accept cookies to enter giveaway"
**Why it fails**:
- Legally problematic (consent must be "freely given" under GDPR)
- Creates compliance risk if incentive is seen as coercive
- Users still ghost (offer is irrelevant to decision avoiders)
- May lift acceptance somewhat, but ghosting barely moves
**5. AI-Powered Consent Prediction**
Using machine learning to predict which users will accept/reject:
- Show different banner variants to different users
- Optimize timing and messaging per user segment
- Attempt to reduce ghosting through personalization
**Why it fails**:
- Still requires banner (ghosting continues)
- Users resent personalized manipulation
- Regulatory scrutiny on profiling for consent decisions
- Marginal improvement at the edges doesn't solve the underlying data loss problem
### Fundamental Impossibility
**Cookie-based analytics faces an unsolvable paradox**:
1. **The ePrivacy Directive requires consent** to store or read information on a user's device — Article 5(3), which is what cookies do
2. **Consent requires a banner** to obtain user agreement
3. **Banners trigger ghosting** due to psychological decision avoidance
4. **Ghosting prevents tracking** because no consent was granted
5. **No tracking means no data** for a large slice of your visitors
This cycle cannot be broken within cookie-based architecture. The moment you display a consent banner, a substantial share of users will ghost it. No amount of optimization, design changes, or technical workarounds can eliminate decision avoidance behavior.
**The only solution is to eliminate the banner entirely**—which requires eliminating cookies entirely.
### Why Cookieless Analytics Solves Ghosting
Cookieless analytics platforms like Sealmetrics break the paradox by removing cookies from the equation:
1. **No cookies used** for analytics tracking
2. **No consent required**, because nothing is stored on or read from the device (ePrivacy Article 5(3) is never engaged) and no personal data is stored (Recital 26)
3. **No banner displayed** to users
4. **No ghosting possible** (nothing to ghost)
5. **Every visitor measured**, with no consent mechanism in the way
Banner ghosting is eliminated because the banner itself is eliminated. Users cannot avoid a decision they're never asked to make.
**Psychological advantages of no banner**:
- No decision fatigue (no decision required)
- No status quo disruption (content accessible immediately)
- No choice overload (no choices presented)
- No temporal discounting (no privacy decision to defer)
- No reactance (no freedom restriction)
- No banner blindness (no banner to ignore)
Sealmetrics removes the psychological triggers that cause ghosting in the first place. Users access your site without friction. Your analytics sees the whole audience. And the compliance position rests on architecture rather than on a consent record: no personal data stored, nothing written to the device.
---
## How Sealmetrics Eliminates Both Ghosting and Rejection
Sealmetrics solves the combined problem of banner ghosting and cookie rejection — together, the 15-60% hole in your dataset — by eliminating the root cause: the consent banner itself.
### Technical Approach: Cookieless Tracking
Sealmetrics uses session-based tracking that doesn't require cookies:
**Session-ID Tracking (Primary Method)**:
1. **Visitor arrives**: User lands on your website
2. **Session identifier computed**: Sealmetrics JavaScript derives an ephemeral session identifier from general device characteristics — it is not unique to a person (different visitors can produce the same value) and cannot identify an individual
3. **No browser storage**: The identifier is never stored on the device — no cookies, no LocalStorage, no SessionStorage
4. **Session tracking**: All pageviews during this browser session use the same identifier
5. **Automatic expiry**: The identifier expires with the session and is never used to correlate visits over time — each new entrance counts as new, independent data (privacy by design)
6. **No consent required**: nothing is stored on or read from the user's device, so the ePrivacy consent rule (Article 5(3)) is never triggered — and because no personal data is retained, there is no Article 6 legal basis to choose in the first place
**Isolated Hits Tracking (Fallback Method)**:
For the small share of visits where a session identifier cannot be computed:
1. **Server-side inference**: Sealmetrics tracks each pageview as isolated hit
2. **Pattern recognition**: Server logic infers session continuity based on:
- Pageview timing (views within 30 minutes likely same session)
- Referrer patterns (internal referrers suggest continued session)
- Navigation flow (homepage → product → checkout suggests single journey)
3. **Conservative attribution**: When uncertain, treats hits as separate sessions
4. **Maximum privacy**: Zero browser storage, pure server-side analysis
### Why This Approach Eliminates Ghosting
**No banner = no ghosting**. Users cannot ignore a decision they're never presented with.
When a user visits a site using Sealmetrics:
1. Page loads immediately (no banner delay)
2. Content is accessible instantly (no friction)
3. Sealmetrics measurement occurs in the background (no user awareness required)
4. No decision required from user (no cognitive load)
5. Every visit measured (no consent-driven data loss)
From the user's perspective, the site "just works." From the business perspective, analytics "just works." No banner. No ghosting. No rejection. No data loss.
### Why This Approach Eliminates Rejection
**No consent request = no rejection**. Users cannot reject what they're not asked to approve.
Cookie-based analytics requires obtaining consent before tracking. This creates the rejection problem: a meaningful share of the users who engage with the banner choose "Reject All."
Sealmetrics doesn't request consent because it doesn't use cookies and doesn't store personal data — no IP addresses, not even hashed ones.
**Rejection is impossible** when no consent mechanism exists. There is no banner to reject, so that source of loss disappears along with ghosting.
### Why No Consent Is Required
The argument runs on two separate tracks, and it is worth keeping them apart, because they answer different regulators.
**Track one — ePrivacy Article 5(3).** This is the rule that actually mandates cookie banners. It requires consent to *store information on, or gain access to information stored in*, a user's terminal equipment. Sealmetrics writes nothing to the device: no cookies, no LocalStorage, no SessionStorage, and it reads nothing back. The obligation is never triggered, so there is nothing to consent to.
**Track two — GDPR material scope, Recital 26.** The data protection principles do not apply to anonymous information — information which does not relate to an identified or identifiable natural person. Because Sealmetrics stores no personal data, the resulting dataset falls outside the material scope of the Regulation.
**This is why we do not claim legitimate interest.** It is tempting to reach for Article 6(1)(f), and plenty of vendors do. But invoking any Article 6 basis presupposes that you *are* processing personal data and merely have a good reason for it. That concedes the entire point. If no personal data is stored, no legal basis is needed — asserting one would weaken the position, not strengthen it.
The one place Article 6(1)(f) does legitimately appear is narrower: the transient, in-memory handling of an IP address for security and anti-abuse purposes, which Recital 49 addresses directly. That address is never written to storage and never reaches the analytics dataset.
**Regulatory guidance**: CNIL (French data protection authority) has confirmed that audience measurement meeting specific criteria can operate without consent. Note that CNIL does not certify or approve individual tools, and neither does any other supervisory authority — no such scheme exists for analytics software. See our [CNIL self-assessment](/compliance/cnil-self-assessment) for how we assess ourselves against those criteria.
**DPO reviews**: Sealmetrics has passed vendor privacy reviews by Data Protection Officers at multiple EU enterprises evaluating its consentless architecture.
### Data Capture Comparison
**Cookie-based analytics (Google Analytics 4)**:
```
Total visitors: 100,000
Ghosting + rejection: the missing slice
Consent Mode: models part of it back, as estimates
Data capture rate: 40-85%, depending on sector,
brand strength and traffic sources
Data loss: 15-60%
```
**Cookieless analytics (Sealmetrics)**:
```
Total visitors: 100,000
No banner displayed: 100,000 (all measured)
No ghosting possible: not applicable
No rejection possible: not applicable
Data capture rate: full, minus the JavaScript blockers
that no analytics tool can see
Consent-driven loss: none
```
**Impact**: depending on where your site sits in that band, Sealmetrics surfaces roughly 1.2x to 2.5x the data a cookie-based tool reports — and, more importantly, eliminates the sample bias, which is the part that makes decisions go wrong rather than merely go small.
### Real-World Implementation
**Migration from Google Analytics 4 to Sealmetrics**:
**Step 1**: Install Sealmetrics tracking code (2 minutes)
```html
```
**Step 2**: Remove consent banner code (1 minute)
- Delete Cookiebot, OneTrust, or custom consent code
- Remove conditional analytics loading logic
**Step 3**: Remove Google Analytics 4 code (1 minute)
- Delete GA4 gtag.js scripts
- Remove GA4 configuration
**Total implementation time**: 4 minutes
**Result**:
- No consent banner
- Every visit measured
- No personal data stored, so no consent record to maintain
- Real-time analytics
- No consent-driven data loss
**User experience improvement**:
- Faster page loads (no banner script overhead)
- Immediate content access (no banner friction)
- No decision fatigue (no choice required)
- Better mobile experience (no screen-covering popup)
**Business intelligence improvement**:
- Substantially more visitor data, depending on where your site sits in the band
- Accurate marketing attribution
- Valid A/B test samples
- True conversion rates
- Representative analytics (not biased toward cookie accepters)
---
## Business Impact of a 15-60% Data Gap
Operating with cookie-based analytics in the current environment means making strategic decisions on a partial, self-selected sample of your visitors. The consequences cascade through every business function — and they get worse, not better, as the gap gets more uneven between channels.
### Marketing Attribution Collapse
**Scenario**: Mid-sized SaaS company, €100,000 monthly marketing budget. Capture rates vary sharply by channel — email and branded search convert consenting visitors readily; LinkedIn's B2B audience does not.
**Cookie-based analytics shows**:
```
Google Ads: €30,000 spend, 150 conversions = €200 CPA
LinkedIn Ads: €20,000 spend, 40 conversions = €500 CPA
SEO content: €15,000 spend, 60 conversions = €250 CPA
Email marketing: €10,000 spend, 80 conversions = €125 CPA
```
**Decision**: Cut LinkedIn (appears most expensive by a factor of four), increase Email (appears cheapest)
**Reality with Sealmetrics**, once each channel is measured on the same footing:
```
Google Ads: €30,000 spend, 250 conversions = €120 CPA (60% captured)
LinkedIn Ads: €20,000 spend, 100 conversions = €200 CPA (40% captured)
SEO content: €15,000 spend, 100 conversions = €150 CPA (60% captured)
Email marketing: €10,000 spend, 107 conversions = €94 CPA (75% captured)
```
**Actual optimal decision**: LinkedIn is genuinely the most expensive channel, but at €200 CPA rather than an apparent €500 — well inside the range where it earns its budget. Trim it if the economics demand; don't kill it on a number that was never real.
**Cost of the wrong decision**: €25,000-40,000 annually in misallocated marketing spend
This is the mechanism that matters. LinkedIn looks disproportionately expensive because its audience — B2B professionals — is more privacy-aware and consents less often than Google searchers. **Uneven loss between channels doesn't shrink your report, it reorders it.** The channel that looks worst may simply be the channel whose audience reads cookie banners.
### A/B Test Statistical Invalidity
**Scenario**: E-commerce checkout optimization test
**Test design**:
- Variant A: 3-step checkout (control)
- Variant B: 1-page checkout (experimental)
- Required sample: 1,000 conversions per variant for 95% confidence
- Expected runtime: 2 weeks at full capture — roughly 4 weeks at a 50% capture rate
**Cookie-based analytics results**:
```
Variant A: 1,043 conversions, 3.2% conversion rate
Variant B: 1,127 conversions, 3.5% conversion rate
Winner: Variant B (1-page checkout)
Statistical significance: p < 0.05 (appears valid)
```
**Decision**: Deploy 1-page checkout site-wide
**Reality with complete data** (Sealmetrics):
```
Variant A: 2,300 conversions, 3.4% conversion rate
Variant B: 2,150 conversions, 3.1% conversion rate
Actual winner: Variant A (3-step checkout)
Statistical significance: p < 0.05 (reversed result)
```
**What happened**: the consenting sample preferred the 1-page checkout. The unmeasured half — ghosters and rejecters, who skew more privacy-aware and security-conscious — preferred the 3-step checkout, because entering payment details on a dedicated page felt safer. Note that the two variants weren't even captured at the same rate, which is exactly why the tracked totals looked closer than they were.
**Cost of deploying wrong variant**: 3.4% → 3.1% conversion rate = roughly a 10% drop in conversions = €150,000 annual revenue loss for a €1.5M/year e-commerce site
**Time waste**: 4 weeks to run the test on a half-sample, 2 weeks to discover variant B underperforms in production, 2 weeks to roll back and re-test — 8 weeks gone
With Sealmetrics: a 2-week test on the full audience, correct winner identified first time, six weeks saved and the €150k avoided.
### Product Roadmap Misallocation
**Scenario**: SaaS product team prioritizing features based on analytics
**Cookie-based analytics shows** (a sample biased toward less privacy-aware users):
```
Feature usage:
- Zapier integration: 15% of users
- Email reports: 45% of users
- Mobile app: 10% of users
- API access: 5% of users
- Custom dashboards: 25% of users
```
**Decision**: Prioritize email reports (highest usage), drop API from the roadmap (lowest usage, 9x behind)
**Reality with Sealmetrics**:
```
Actual feature usage:
- Zapier integration: 26% of users (tech-savvy, high ghosting rate)
- Email reports: 34% of users (less tech-savvy, low ghosting rate)
- Mobile app: 17% of users (high ghosting rate on mobile)
- API access: 12% of users (developers, highest ghosting rate)
- Custom dashboards: 24% of users (roughly accurate, little ghosting bias)
```
**What happened**: privacy-aware users — the ones who ghost banners — are exactly the users who reach for technical features like the API and Zapier. Under-representing them makes technical features look like dead weight.
Email reports really is the most-used feature; that part survives contact with complete data. What doesn't survive is the *margin*. API access looked like a rounding error at 5%, nine times behind the leader, which is what justified cutting it. At 12% it is a quarter of your user base and under three times behind — a very different conversation, and one nobody got to have.
**Cost of the wrong roadmap**: six months of development aimed at a gap that wasn't there, and a segment written off on a number that was an artefact of who accepts cookies.
With Sealmetrics: the ranking and the margins both hold up, so the prioritisation debate happens on real numbers.
### Revenue Reporting Inaccuracy
**Scenario**: Board meeting, CEO presents revenue metrics
**Cookie-based analytics shows**:
```
Monthly revenue: €150,000 (tracked conversions only)
Conversion rate: 2.5%
Average order value: €95
Top product: Product A (€45,000 tracked revenue)
```
**Board decision**: Product A is the star performer, allocate more marketing budget to it
**Reality with Sealmetrics**:
```
Actual monthly revenue: €300,000 (blended capture rate around 50%)
Actual conversion rate: 2.5% (rate was coincidentally correct, volume was not)
Actual average order value: €95 (correct)
Top product: Product B (€140,000 actual, €56,000 tracked)
Product A: €60,000 actual, €45,000 tracked
```
**What happened**: Product B is bought by enterprise researchers with high privacy awareness — barely two in five consent. Product A is bought by impulse buyers who accept the banner about three times in four. Both products were under-reported; only one was under-reported enough to lose its place. Analytics named Product A the top performer when Product B was generating well over twice its revenue.
**Cost of wrong strategic decision**: Marketing budget misallocation to Product A instead of Product B, potentially €100,000-200,000 annually in opportunity cost
### Competitive Intelligence Blind Spots
**Scenario**: SaaS company analyzing competitive positioning
**Cookie-based analytics shows**:
```
Users visiting from competitors:
- 500 visits from competitor A site
- 200 visits from competitor B site
- 100 visits from competitor C site
```
**Decision**: Competitor A is the main threat at 2.5x competitor B, focus positioning against them
**Reality with Sealmetrics**:
```
Actual competitive referrals:
- 625 from competitor A (comparison sites, low ghosting)
- 500 from competitor B (privacy-focused competitor, high ghosting among its users)
- 250 from competitor C (technical competitor, high ghosting among developers)
```
**What happened**: people researching privacy-focused alternatives ghost banners at the highest rates of anyone. Competitor B isn't a distant second at 40% of A's volume — it is within 20% of it, effectively neck and neck.
**Cost**: a positioning strategy built around a comfortable lead that doesn't exist, and messaging that never seriously engaged the competitor actually taking your traffic
---
## Psychological Drivers of Banner Ghosting (Deep Dive)
Understanding why users ghost banners helps explain why the problem is unfixable within cookie-based architectures and why eliminating the banner is the only solution.
### Decision Fatigue and Consent Exhaustion
**Average user encounters**: 8-15 cookie consent banners per day across different websites. Each requires a decision.
**Psychological research**: Humans have limited decision-making capacity. After making several decisions, decision quality degrades and people begin avoiding decisions entirely (decision fatigue).
**Cookie banner fatigue pattern**:
- **Banner 1-2**: User reads and decides (accept/reject)
- **Banner 3-5**: User skims and decides (probably rejects)
- **Banner 6-10**: User ignores (ghosting begins)
- **Banner 11+**: Complete banner blindness (automatic ghosting)
By the time a user reaches your website (likely not their first site of the day), they've already made multiple cookie consent decisions and have entered decision fatigue state. Your banner is ignored reflexively.
**Why "better banners" don't work**: Optimizing your banner doesn't address that users are exhausted by all banners, not specifically yours. Decision fatigue is cumulative across all sites, not site-specific.
### Status Quo Bias and Loss Aversion
**Status quo bias**: Humans prefer maintaining current state over changing state, even when change might be beneficial.
**User perception of cookie banner**:
- Current state: "I want to read this article / buy this product"
- Banner appears: "I need to make a privacy decision before I can proceed"
- Status quo preservation: Ignore banner, continue toward goal
From the user's perspective, the path of least resistance is ignoring the banner and accessing the content they came for. Clicking "Accept" or "Reject" requires deviating from the goal path.
**Loss aversion**: Users frame the banner as a potential loss (lose time making decision, lose privacy by accepting, lose functionality by rejecting). When faced with potential loss, humans procrastinate or avoid the decision.
**Why "incentivized consent" doesn't work**: Offering rewards for accepting cookies attempts to reframe the decision as a gain, but research shows loss aversion is stronger than equivalent gain attraction. Users still avoid the decision to avoid the potential loss.
### Choice Architecture and Paralysis
**Choice overload**: When presented with too many options, humans experience decision paralysis and make no choice at all.
**Typical cookie banner choices**:
1. Accept All (cookies enabled)
2. Reject All (cookies disabled)
3. Customize Preferences:
- Necessary cookies (required)
- Functional cookies (optional)
- Analytics cookies (optional)
- Marketing cookies (optional)
- Personalization cookies (optional)
- Third-party cookies (optional)
Users face 6-10 binary decisions simultaneously. Most users don't understand the technical differences between cookie categories. Choice overload leads to decision paralysis → ghosting.
**Regulatory requirements**: EU regulators (especially CNIL) require that "Reject All" be as prominent and easy to access as "Accept All," and that users be able to customize preferences. This prevents simplified "Accept / Learn More" patterns and forces choice complexity.
**Why "simplified banners" don't work**: GDPR and regulatory guidance mandate complexity. You cannot legally simplify to a single "Accept" button without equivalent "Reject" prominence. Required complexity creates choice overload regardless of UX design.
### Temporal Discounting and Hyperbolic Time Preferences
**Temporal discounting**: Humans value immediate rewards more than future rewards, and discount future costs more than immediate costs.
**Cookie banner decision framework**:
- **Immediate cost**: Time spent reading banner, making decision, clicking button
- **Immediate benefit**: Access to website content
- **Future cost**: Privacy implications of cookies (tracking, profiling, data breaches)
- **Future benefit**: Customized experience, supporting free content
Users heavily discount future costs (privacy invasion months later) and prioritize immediate benefit (access content now). The rational choice, given temporal discounting, is to ignore the banner and access content immediately.
**Why privacy warnings don't work**: Explaining that cookies track users across sites, build profiles, and share data with third parties describes future costs. Temporal discounting means users don't weigh these future costs as heavily as immediate content access benefit.
### Psychological Reactance
**Reactance theory**: When individuals perceive their freedom is being restricted, they experience psychological reactance—motivation to restore freedom, often by resisting the restriction.
**Cookie banner as freedom restriction**: Users perceive the banner as restricting their freedom to access website content without making a privacy decision. This restriction triggers reactance.
**Reactance response to cookie banners**:
- Ignore banner entirely (passive resistance)
- Immediately click "Reject All" without reading (active resistance)
- Leave website (ultimate resistance)
- Use ad blockers or privacy tools to prevent banners (systemic resistance)
Ghosting the banner is a form of passive reactance—users refuse to engage with the banner as an assertion of autonomy. The more prominent or persistent the banner, the stronger the reactance response.
**Why "gentle reminders" don't work**: Making the banner reappear after scrolling or after certain time periods increases reactance. Users feel the site is nagging them, strengthening their resolve to ignore it.
### Banner Blindness and Cognitive Filtering
**Banner blindness**: After years of exposure to intrusive web elements (ads, popups, modal overlays), users have trained their brains to visually filter out rectangular overlays.
**Cognitive filtering process**:
1. User's visual system detects rectangular overlay
2. Pattern recognition: "This is an ad / banner / popup"
3. Automatic categorization: "Irrelevant to my goal"
4. Visual filtering: Brain suppresses awareness of overlay
5. Attention remains on underlying content
Cookie consent banners trigger the same cognitive filtering as ads and popups. Users' brains have literally trained themselves not to process the banner as requiring attention.
**Why "attention-grabbing design" doesn't work**: Making banners more colorful, animated, or attention-grabbing actually reinforces banner blindness. Users recognize "attention-grabbing overlay" as a pattern to be ignored.
### The Unsolvable Nature of Ghosting
All five psychological mechanisms (decision fatigue, status quo bias, choice overload, temporal discounting, reactance) are hardwired human cognitive biases. They cannot be designed away.
**Cookie-based analytics cannot solve ghosting because**:
1. Banner fatigue is cumulative across all sites (not site-specific)
2. Status quo bias applies to any interruption (not design-specific)
3. Choice complexity is legally mandated (not optional)
4. Temporal discounting is cognitive bias (not education issue)
5. Reactance increases with banner prominence (persistence backfires)
6. Banner blindness is learned behavior (not reversible)
**The only solution is eliminating the banner entirely**, which requires eliminating cookies entirely, which requires cookieless analytics like Sealmetrics.
---
## Implementation: Migrating to Cookieless Analytics
Eliminating banner ghosting and cookie rejection requires eliminating the consent banner, which requires eliminating cookies, which requires migrating to cookieless analytics.
### Step 1: Quantify Current Data Loss
**A. Install Sealmetrics in parallel with existing analytics** (5 minutes)
```html
```
**B. Run both systems for 7-14 days**
**C. Compare visitor counts**:
```
Week 1 Results:
Google Analytics 4: 26,244 visitors
Sealmetrics: 58,320 visitors
Data loss (GA4): 55% (32,076 visitors invisible)
The invisible visitors are ghosters and rejecters in some
mix you cannot determine from the outside — the ghosters
generate no event to count. What you can determine is the
total, which is the number that matters.
```
Whatever figure you get, expect it to land between 15% and 60%. If it lands outside that, check your setup before you celebrate or panic: a suspiciously small gap usually means Consent Mode modelling is inflating your GA4 side, and a suspiciously large one usually means a tagging error.
**D. Calculate business impact**:
```
Invisible conversions: ~245 per week (extrapolated)
Invisible revenue: ~€18,375 per week
Annual invisible revenue: ~€955,000
This revenue exists, but your analytics can't attribute it to marketing channels, can't analyze user behavior, can't optimize conversion funnel.
```
### Step 2: Validate Your Legal Position
**A. Review Sealmetrics privacy practices**:
- ✅ No cookies used
- ✅ No IP addresses stored (not even hashed)
- ✅ No cross-site tracking
- ✅ No third-party data sharing
- ✅ Temporary session identifiers only, never written to the device
- ✅ Nothing stored on or read from the device, so ePrivacy Article 5(3) is not engaged
- ✅ No personal data stored, so the dataset sits outside GDPR material scope (Recital 26)
- ✅ Data hosted in Dublin, Ireland
**B. Consult with DPO (if applicable)**:
- Share Sealmetrics' privacy documentation and DPA
- Review the analysis of why no Article 6 basis is required
- Obtain DPO sign-off for consentless operation
**C. Update privacy policy**:
```
Old text (cookie-based):
"We use cookies to analyze website traffic. You can accept or reject cookies
via the consent banner. For more information, see our cookie policy."
New text (cookieless):
"We use Sealmetrics, a cookieless analytics service, to understand website
usage and improve user experience. Sealmetrics does not use cookies, does not
store IP addresses, and does not collect personal data. Nothing is stored on or
read from your device, and session identifiers are temporary and are never
written to your browser. Because no personal data is retained, this measurement
falls outside the scope of the GDPR. Questions: privacy@yourcompany.com."
```
### Step 3: Remove Consent Banner
**A. Identify consent management code**:
- Cookiebot
- OneTrust
- Custom banner implementation
**B. Remove banner scripts**:
```html
```
**C. Remove cookie policy page** (or simplify drastically):
- Delete detailed cookie tables
- Delete consent management instructions
- Keep privacy policy (simplified)
**D. Verify banner removal**:
- Test site in multiple browsers
- Test from multiple EU countries (VPN)
- Confirm no cookie banner appears
- Verify Sealmetrics tracking works immediately
### Step 4: Remove Google Analytics 4
**A. Remove GA4 tracking code**:
```html
```
**B. Export historical data** (if needed):
- GA4 API export to BigQuery or CSV
- Download key reports for historical reference
- Archive in data warehouse
**C. Redirect team to Sealmetrics**:
- Update bookmarks
- Update dashboard links
- Train team on Sealmetrics interface
### Step 5: Verify Full Data Capture
**A. Server log comparison**:
```
Week after migration:
Server logs (Apache/Nginx): 59,140 unique visitors
Sealmetrics: 58,320 visitors
Capture rate: 98.6% (difference likely bots/scrapers)
```
**B. Cross-device testing**:
- Test on Chrome (desktop + mobile)
- Test on Safari (desktop + mobile)
- Test on Firefox (desktop + mobile)
- Test with privacy extensions (uBlock Origin, Privacy Badger)
- Test with strict browser privacy settings
- Verify all tests appear in Sealmetrics real-time
**C. Conversion tracking validation**:
- Complete test purchases/signups
- Verify appear in Sealmetrics immediately
- Check attribution (source/medium)
- Compare to payment processor data
**Success metrics**:
- ✅ 98-99% of legitimate traffic tracked (excluding bots)
- ✅ No consent banner visible
- ✅ Full conversion tracking operational
- ✅ Team adopted Sealmetrics interface
- ✅ DPO sign-off documented
### Step 6: Analyze New Insights
**A. Discover previously invisible traffic**:
```
Month 1 with Sealmetrics vs Last Month with GA4:
Total visitors: 115,860 (was 52,140) → 2.2x
LinkedIn referrals: 4,900 (was 1,850) → 2.6x
Mobile traffic: 69,516 (was 28,713) → 2.4x
Conversions: 2,860 (was 1,304) → 2.2x
```
The uneven multipliers are the finding, not the headline number. LinkedIn and mobile climb further than the site average because their audiences consented least — which is precisely the distortion that was quietly reshaping your channel reporting.
**B. Correct marketing attribution**:
- Channels previously undervalued (LinkedIn, privacy-focused referrers) now show true performance
- Channels previously overvalued (some Google search terms) now show accurate performance
- Reallocate budget based on complete data
**C. Identify UX issues affecting ghosters/rejecters**:
- Previously invisible user segments now visible
- Discover friction points affecting the privacy-aware segment you were never measuring
- Optimize for your whole audience, not just the part of it that clicks "Accept"
**D. Run valid A/B tests**:
- Reach statistical significance sooner, on more data
- Representative samples (not biased toward cookie accepters)
- Results hold in production (tested on actual user base)
### Migration Timeline
**Week 1: Parallel Testing**
- Day 1: Install Sealmetrics alongside GA4
- Day 2-7: Compare data, identify discrepancies
- End of week: Quantify data loss (typically somewhere in the 15-60% band)
**Week 2: Preparation**
- Day 8-9: DPO review and approval
- Day 10-11: Update privacy policy
- Day 12-14: Export GA4 historical data
**Week 3: Migration**
- Day 15: Remove consent banner code
- Day 16: Remove GA4 code
- Day 17-21: Verify 100% tracking, team training
**Week 4: Optimization**
- Day 22-28: Analyze new data, correct attribution, optimize based on complete visitor insights
**Total time**: 4 weeks from start to full optimization
**Actual implementation time**: 10-15 minutes (installation + removal)
**Rest of time**: Validation, training, analysis
---
## Frequently Asked Questions
### How many users ghost cookie banners?
Enough that ghosting, not rejection, is usually the larger group. A substantial share of visitors ignore consent banners entirely, making no decision at all — neither accepting nor rejecting. Rates run highest in Germany and the Nordics, lower in Southern and Eastern Europe, and materially lower in the US. Be careful what you infer from the figure, though: ghosting rates describe your banner, not your dataset. The data loss that reaches your reports is 15-60%, which is smaller than the raw non-acceptance rate.
### Why do users ghost banners instead of rejecting?
Users ghost banners due to psychological decision avoidance: decision fatigue (exhausted from multiple daily banners), status quo bias (prefer not interrupting their goal), choice overload (too many cookie options), temporal discounting (prioritize immediate content access over future privacy), psychological reactance (resisting the forced decision), and banner blindness (trained to ignore rectangular overlays). Ghosting requires zero effort while clicking "Reject" requires effort.
### Is banner ghosting the same as cookie rejection?
No. Cookie rejection occurs when users actively click "Reject All" or customize preferences to reject cookies. Banner ghosting occurs when users ignore the banner entirely without interacting. From an analytics perspective, both result in no tracking for that visit, but ghosting typically affects the larger group and represents passive avoidance rather than an active privacy choice. Ghosters are also harder to quantify, because they generate no event — there is no click to count.
### What's the total data loss from ghosting plus rejection?
15-60% of your data, with a capture rate of 40-85%. The spread depends on your sector, the strength of your brand and where your traffic comes from: a recognised consumer brand whose visitors arrive direct sits near 15%, while a site buying cold traffic in a privacy-sensitive market sits near 60%.
Don't reach that number by adding ghosting and rejection together — that overstates it. Two things sit between non-acceptance and actual data loss. Consent Mode v2 models part of the unconsented traffic back into your reports (as estimates, not observations). And ghosting is a per-visit behaviour, so some visitors who ignored the banner on one visit accept on a later one.
### Can cookie-based analytics solve the ghosting problem?
No. Banner ghosting is caused by the existence of the consent banner itself, not by banner design flaws. Cookie-based analytics requires cookies, which require consent under GDPR, which requires a banner, which triggers psychological decision avoidance (ghosting). No amount of UX optimization, consent mode implementation, or banner design improvement can eliminate decision avoidance behavior. The only solution is eliminating the banner entirely by using cookieless analytics.
### How does Sealmetrics eliminate banner ghosting?
Sealmetrics doesn't use cookies and stores nothing on the device, so no consent is required and no banner is displayed. No banner means no ghosting is possible—users cannot avoid a decision they're never asked to make. Measurement begins on page load, with no user interaction required.
### Is cookieless analytics legal without a consent banner?
Yes, when it is genuinely cookieless and genuinely stores no personal data. Two separate rules are in play. The ePrivacy Directive's Article 5(3) is the one that mandates cookie banners, and it applies to storing or reading information on the user's device — Sealmetrics does neither. The GDPR governs personal data, and its own Recital 26 puts anonymous information outside its material scope — so with no personal data stored, no Article 6 legal basis is required.
Note what we are *not* saying: we do not claim legitimate interest. Invoking Article 6(1)(f) would concede that personal data is being processed. CNIL has confirmed that audience measurement meeting specific criteria can operate without consent, but no supervisory authority certifies or approves individual analytics tools — no such scheme exists. Sealmetrics has passed vendor privacy reviews by DPOs at multiple EU enterprises, which is a customer assessment, not a regulatory endorsement.
### What happens to my historical Google Analytics data?
Historical data remains in Google Analytics 4 for as long as Google retains it (14 months for free accounts, longer for GA360). You can export historical data via GA4 API or reports before migration. Sealmetrics begins capturing fresh data from installation forward. Most businesses maintain GA4 access for historical reference while using Sealmetrics for all current and future analytics.
### How long does it take to migrate from GA4 to Sealmetrics?
Implementation takes 10-15 minutes: install Sealmetrics tracking code (2 minutes), remove consent banner scripts (5 minutes), remove GA4 code (3 minutes), update privacy policy (5 minutes). Total migration timeline including validation and team training is typically 2-4 weeks, but the technical implementation is less than 15 minutes of developer time.
### Will I lose conversion tracking without cookies?
No. Sealmetrics tracks conversions, goals, and custom events without requiring cookies. Conversion tracking covers every visit, not just the visitors who accepted a banner. Marketing attribution (source, medium, campaign) is captured via referrer and UTM parameters without consent requirements. ROI calculation becomes more accurate because you see all conversions, not just those from cookie accepters.
### What about users who block JavaScript?
Users who block JavaScript entirely (0.2-0.5% of visitors) cannot be tracked by any JavaScript-based analytics, including Google Analytics and Sealmetrics. This is an unavoidable technical limitation shared by both. The difference is what sits on top of it: Sealmetrics loses only the JS blockers, while cookie-based analytics loses the JS blockers *plus* the banner ghosters and the rejecters — a 15-60% gap on top of the same floor.
### Can I use Sealmetrics with Google Tag Manager?
Yes, Sealmetrics can be installed via Google Tag Manager or directly in HTML. However, direct HTML installation is simpler (one line of code) and avoids GTM overhead. Since Sealmetrics doesn't require consent management integration (no banner, no conditional loading), GTM provides minimal benefit. Most users install directly in the HTML `` section for simplicity and performance.
### Does Sealmetrics track across subdomains or multiple domains?
Sealmetrics tracks across subdomains automatically (example.com, blog.example.com, shop.example.com all tracked as single property). For multiple separate domains (example.com and other-example.com), you need separate Sealmetrics projects. This is intentional for privacy—Sealmetrics doesn't enable cross-site tracking that would raise GDPR concerns.
### What if a competitor also uses Sealmetrics?
Sealmetrics projects are completely isolated. Competitor using Sealmetrics has zero impact on your analytics. Each project has unique project ID and separate data storage. Unlike Google Analytics (where Google has access to all GA data across all sites), Sealmetrics data is private to each project owner. No cross-site tracking, no data sharing between projects.
### How does Sealmetrics handle returning visitors?
Sealmetrics uses session-based tracking. Each browser session gets a temporary identifier computed in the browser from general device characteristics — it is not unique to a person, is never stored on the device, and expires with the session. When a user returns days later, that visit is simply counted as a new, independent entrance. Sealmetrics does not correlate visits over time and does not identify returning visitors — there is no cross-session history or profile, which is exactly what keeps it privacy-safe (no long-term tracking).
### Can users opt out of Sealmetrics tracking?
Yes. Although no consent is required, sites using Sealmetrics should still provide an opt-out mechanism in their privacy policy (email address or form for objection requests). Additionally, users blocking JavaScript or using browser privacy modes (incognito) are not tracked. Sealmetrics respects Do Not Track browser signals when enabled.
---
## Conclusion
**Cookie banner ghosting—not cookie rejection—is the primary cause of analytics data loss in 2025.**
While industry discussions focus on rejection rates (users clicking "Reject All"), the larger and quieter group is the visitors who simply ignore cookie consent banners entirely. These users neither accept nor reject—they ghost the banner and continue using your site. During this ghosting state, cookie-based analytics cannot track them.
**Combined with explicit rejection, that puts total data loss at 15-60%**, depending on your sector, the strength of your brand and where your traffic comes from — a capture rate of 40-85%. The missing visitors aren't privacy extremists running ad blockers. They're ordinary people engaging in predictable psychological decision avoidance, which is exactly why they're missing in a systematic, non-random pattern rather than an even one.
**The root cause is the consent banner itself**, not banner design or implementation. Banner ghosting is driven by hardwired cognitive biases:
- Decision fatigue (exhausted from multiple daily banners)
- Status quo bias (prefer not interrupting browsing goals)
- Choice overload (too many cookie options create paralysis)
- Temporal discounting (prioritize immediate access over future privacy concerns)
- Psychological reactance (resisting forced decisions)
- Banner blindness (learned visual filtering of rectangular overlays)
**Cookie-based analytics cannot solve banner ghosting** because the banner is required to obtain legally valid consent under GDPR, and the banner's existence triggers the psychological avoidance mechanisms that cause ghosting. No amount of UX optimization, consent mode, or banner redesign can eliminate decision avoidance behavior.
**Cookieless analytics eliminates both ghosting and rejection** by eliminating the consent banner entirely. Sealmetrics doesn't use cookies and stores no personal data, so the ePrivacy consent rule is never triggered and no GDPR legal basis is required. No banner means no ghosting is possible, no rejection is possible, and every visit is measured from the moment it lands on your site.
**Business impact of a 15-60% data gap**:
- Marketing attribution skewed by uneven loss between channels → €25,000-40,000 annual misallocation
- A/B tests run on an unrepresentative sample, wrong variants deployed → six-figure revenue loss
- Product roadmap ranking features by how consent-friendly their users are → months of wasted development
- Strategic decisions made on a self-selected slice of your audience → opportunity cost nobody ever invoices you for
The asymmetry is the argument: migrating to Sealmetrics takes 15 minutes of implementation and two to four weeks of validation. Continuing as you are costs a slice of every decision you make, indefinitely.
**For businesses operating in the EU**, this isn't really a tooling preference. Losing between 15% and 60% of your visitors is survivable; losing them *non-randomly* is what quietly bends your conclusions. You cannot optimize what you cannot measure. You cannot attribute revenue you cannot see. And you cannot correct a bias you don't know the size of.
Sealmetrics measures every visit, eliminates banner ghosting, eliminates cookie rejection, and does it without storing personal data — which is what removes the consent question rather than merely answering it.
**Stop guessing at the missing 15-60%.** [Try Sealmetrics free for 14 days](https://my.sealmetrics.com/register) and see your complete visitor base for the first time.
---
## Additional Resources
**Legal Resources**:
- [GDPR, including Recital 26 on anonymous information](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [CNIL Guidance on Cookieless Analytics (2020)](https://www.cnil.fr/en/cookies-and-other-trackers/rules/cookies/how-comply-cookies-and-trackers)
- [ePrivacy Directive Article 5(3)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32002L0058)
**Psychological Research**:
- Decision Fatigue Studies (Baumeister et al.)
- Status Quo Bias Research (Samuelson & Zeckhauser)
- Choice Overload Theory (Iyengar & Lepper)
- Psychological Reactance Theory (Brehm)
**Related Reading**:
- [Complete Guide to Cookieless Analytics](/blog/cookieless-analytics-guide) — How to measure traffic without cookies or consent banners
- [Cookieless vs Cookie-Based Analytics](/blog/cookieless-analytics-vs-cookie-based) — Technical comparison of both approaches
- [What Is Consentless Analytics?](/security-privacy/consentless-analytics) — How Sealmetrics captures 100% of traffic without consent
- [GDPR Compliant Analytics Framework](/blog/gdpr-compliant-analytics-framework) — Complete compliance framework for web analytics
**Official Resources**:
- [Sealmetrics Website](https://sealmetrics.com)
- [Sealmetrics Documentation](https://docs.sealmetrics.com)
- [Try Sealmetrics Free](https://my.sealmetrics.com/register)
## GDPR Compliant Analytics: Complete Framework 2026
URL: https://docs.sealmetrics.com/blog/gdpr-compliant-analytics-framework
> **TL;DR** — GDPR framework for web analytics: which legal basis you actually need, the technical requirements, and how to stop losing 15-60% of your data to consent.
The European Union issued over €20 million in fines for analytics violations in 2023, yet most companies still don't understand what makes their analytics GDPR compliant. Many businesses either accept massive data loss from cookie consent requirements or operate in a gray area of regulatory uncertainty.
This comprehensive framework explains exactly what GDPR compliance requires for web analytics, which legal bases work, and how to implement compliant tracking without losing visitor data.
**Key Takeaways**:
- Consent-based analytics loses 15-60% of your data; the strongest position isn't a better Article 6 basis, it's not needing one
- Most analytics tools fail GDPR because they store IP addresses or require cookies
- Sealmetrics stores no personal data, which puts the dataset outside the GDPR's material scope (Recital 26) rather than inside it with a justification attached
- Country-specific regulations (TTDSG, CNIL) have additional requirements beyond baseline GDPR
## What Makes Analytics GDPR Compliant?
GDPR compliance for web analytics rests on three fundamental pillars established by the General Data Protection Regulation.
### The Three Pillars of Compliance
**Legal Basis (Article 6)**: Every processing activity involving personal data requires a lawful basis. For analytics that touches personal data, that means consent or legitimate interest. There is also a third position, which most vendors skip past: if no personal data is stored, Article 6 does not apply at all. Which of the three you're in determines whether you need a cookie banner and how much data you keep.
**Data Minimization (Article 5)**: You can only collect data that's adequate, relevant, and limited to what's necessary. This principle prohibits collecting unnecessary identifiers, storing full IP addresses without justification, or retaining data longer than needed.
**Privacy by Design (Article 25)**: Analytics must implement technical and organizational measures to protect user privacy from the design stage. This includes pseudonymization, encryption, and default privacy-protective configurations.
Most analytics tools fail on at least one of these pillars. Google Analytics fails on legal basis (requires consent due to cookies and US transfers). Plausible and Matomo store hashed IP addresses, creating questions under data minimization. Sealmetrics was built specifically to satisfy all three pillars simultaneously.
---
## Legal Bases for Analytics Under GDPR
GDPR Article 6 defines six legal bases for processing personal data. For web analytics, two get used — consent and legitimate interest. But the question that comes first, and usually gets skipped, is whether you are processing personal data at all. If you aren't, Article 6 never enters the picture.
### Consent (Article 6(1)(a)) - The Problem
Consent means users must actively opt in before any tracking occurs. This approach sounds simple but creates severe practical problems.
**The Data Loss Problem**: Studies across the EU show consistent patterns. In Germany, 87% of users reject cookie banners according to 2024 CNIL data. In France, rejection rates hover around 73%. Spain and Italy show similar patterns at 68-72%.
Be careful how you translate those into a data loss figure — a rejection rate is measured among the people who engaged with the banner, and it is not your loss rate. Consent Mode v2 models part of the unconsented traffic back in as estimates, and visitors who ignore a banner on one visit sometimes accept on the next. What actually reaches your reports is a shortfall of **15-60%**, depending on your sector, the strength of your brand and where your traffic comes from. A recognised consumer brand serving mostly direct traffic sits near 15%; a site buying cold traffic in a privacy-sensitive vertical sits near 60%.
**Implementation Complexity**: Consent requires explicit, informed, freely given agreement. Your cookie banner must clearly explain what data you collect, why you collect it, and allow granular control. Users must be able to withdraw consent as easily as they gave it. For analytics that span multiple sessions, you need to manage consent state across visits, handle consent withdrawal, and delete historical data on request.
**Legal Requirements**: Consent must be documented, time-stamped, and provable. You need systems to track who consented, when they consented, what they consented to, and whether consent is still valid. This creates significant technical and legal overhead.
### Legitimate Interest (Article 6(1)(f)) - The Popular Answer
Legitimate interest allows processing when your business needs are not overridden by user privacy rights. It is what most privacy-conscious analytics vendors reach for, and for a tool that stores hashed IPs or any other identifier, it is often the right answer.
**The Balancing Test**: you weigh your business interest against user rights, document the reasoning, and keep it on file for the day someone asks.
*Your Interest*: understanding how visitors use your website to improve user experience, optimize content, and make informed business decisions.
*User Impact*: minimal when analytics is cookieless, stores no IP addresses, and implements data minimization.
*Result*: for tools that do process some personal data, the balancing test can come out in your favour, and no consent is required.
**But notice what invoking it costs you.** Naming any Article 6 basis is an admission that you *are* processing personal data — you are simply arguing that you're entitled to. Once you've said that, every downstream obligation follows: data subject rights over that data, the right to object under Article 21, records of processing, the balancing test you now have to defend. You have won the consent argument by conceding the bigger one.
### No Legal Basis Required - The Stronger Position
There is a prior question, and it is the one worth asking: **is there personal data here at all?**
**GDPR Recital 26** is explicit that the principles of data protection do not apply to anonymous information — information which does not relate to an identified or identifiable natural person. If your analytics stores nothing that identifies a person, the dataset falls outside the *material scope* of the Regulation. Article 6 is never reached, because Article 6 governs the processing of personal data and there isn't any.
**ePrivacy Article 5(3)** is the separate rule that actually mandates cookie banners. It requires consent to store information on, or gain access to information stored in, a user's terminal equipment. This one is not about personal data at all — it applies to *anything* written to or read from the device. A tool that writes nothing and reads nothing never triggers it.
Both have to hold. Clear one and fail the other and you still need a banner.
**When this position applies**: to cookieless analytics like Sealmetrics that:
- Collect only necessary data (pageviews, sessions, referrers)
- Store no personally identifiable information — no IP addresses, not even hashed
- Write nothing to the device: no cookies, no LocalStorage, no persisted fingerprint
- Don't use data for other purposes (advertising, profiling)
- Retain aggregates for reasonable periods (24 months for trend analysis)
**CNIL 2020 Guidance**: the French data protection authority published guidance stating that audience measurement can operate without consent when it "strictly respects users' privacy," specifying no cross-site tracking, limited retention, no IP storage, and transparency in privacy policies. Worth stating plainly: CNIL does not certify or approve individual analytics tools, and neither does any other supervisory authority. No such scheme exists. What exists is guidance you can assess yourself against — see our [CNIL self-assessment](/compliance/cnil-self-assessment).
Unlike consent-based approaches, this removes the 15-60% consent gap entirely — and it does so without asking a regulator to accept a balancing test.
---
## The GDPR Compliance Checklist
Implementing GDPR compliant analytics requires addressing technical, legal, and organizational requirements.
### Technical Requirements
**No Unnecessary Data Collection**: Collect only what's needed for analytics. Sealmetrics tracks pageviews, sessions, referrers, device types, and basic engagement metrics. We don't collect names, emails, precise locations, or other unnecessary identifiers.
**IP Address Handling**: This is where most analytics tools fail GDPR. Google Analytics stores full IP addresses. Plausible and Matomo hash IP addresses, which GDPR still considers personal data because hashed values can be reversed or matched. Sealmetrics never stores IP addresses—not even hashed versions. Our session-based tracking generates anonymous identifiers that can't be traced back to individuals.
**Data Retention Limits**: Determine legitimate retention periods and enforce them. Sealmetrics defaults to 24 months of retention, documented as necessary for year-over-year trend analysis and seasonal pattern identification. Data older than 24 months is automatically purged.
**Security Measures**: Implement encryption in transit (HTTPS), encryption at rest, access controls, and regular security audits. Sealmetrics uses AES-256 encryption, role-based access control, and annual penetration testing.
### Legal Requirements
**Privacy Policy**: Your privacy policy must explain what analytics you use, what data gets collected, how long it is retained, and on what footing you operate. If you rely on legitimate interest, document your balancing test. If you store no personal data at all, say so plainly and explain why no consent is required.
**Legal Position Documentation**: Maintain internal documentation for whichever footing you're on. If you rely on legitimate interest, document: (1) what business purpose the analytics serves, (2) why this data is necessary, (3) how you minimize privacy impact, and (4) what safeguards you implement. If you're claiming the data is out of scope, document what is stored field by field and why none of it identifies a person.
**Data Processing Agreement (DPA)**: GDPR Article 28 requires a DPA between you and your analytics provider. Sealmetrics provides a standard DPA covering all processor obligations including security, confidentiality, sub-processor management, and data deletion.
**Data Protection Impact Assessment (DPIA)**: Required when processing presents high risk to user rights. Cookieless analytics typically don't require DPIA because they implement data minimization and have minimal privacy impact. However, document why you determined DPIA isn't needed.
### Organizational Requirements
**Internal Documentation**: Maintain records of processing activities under GDPR Article 30. Document what analytics you use, why, what legal basis applies, what data gets processed, and where data is stored.
**Staff Training**: Ensure team members understand GDPR requirements, know how to handle data requests, and follow privacy procedures.
**Incident Response Plan**: Establish procedures for handling potential data breaches, including detection, assessment, notification to authorities within 72 hours if required, and user notification when appropriate.
---
## Tools Comparison: GDPR Compliance
Understanding how different analytics tools handle GDPR compliance helps you choose the right solution for your needs.
| Feature | Google Analytics | Plausible | Matomo | Sealmetrics |
|---------|------------------|-----------|--------|-------------|
| **Legal Basis** | Consent required | Legitimate interest | Legitimate interest | **None needed — no personal data (Recital 26)** |
| **Cookie Usage** | Yes (multiple) | No | Optional | No |
| **IP Storage** | Yes (full) | Yes (hashed) | Yes (hashed) | **No - zero IPs** |
| **Consent Banner Needed** | Yes | No* | No* | **No** |
| **Data Location** | US + EU | EU only | Self-hosted or EU | EU only |
| **Consent-driven data loss** | 15-60% | None where consent isn't required | None where consent isn't required | **None** |
| **US Data Transfers** | Yes | No | No | No |
| **Schrems II Compliant** | Questionable | Yes | Yes | Yes |
| **CNIL 2020 Compliant** | No | With config | With config | **Yes (default)** |
| **TTDSG Compliant (Germany)** | No | Yes | Yes | **Yes** |
| **Setup Complexity** | High | Low | Medium | **Very Low (2 min)** |
| **DPA Included** | Yes | Yes | Yes | Yes |
*May need consent depending on configuration and cookie usage
The table reveals a critical insight: tools that hash IP addresses (Plausible, Matomo) still process personal data under GDPR. Hashing is pseudonymization, not anonymization. Sealmetrics achieves true compliance by never storing IP addresses at all.
---
## Why Most Analytics Tools Fail GDPR
Three common failures plague analytics tools attempting GDPR compliance.
### Problem 1: IP Address Storage
GDPR defines personal data as any information relating to an identified or identifiable person. IP addresses clearly qualify as personal data according to multiple court rulings and regulatory guidance.
**The Hashing Myth**: Many analytics tools claim GDPR compliance by hashing IP addresses before storage. This creates a false sense of security. GDPR distinguishes between anonymization (irreversible, not personal data) and pseudonymization (reversible, still personal data). Hashed IPs are pseudonymized, not anonymized.
Why hashing doesn't solve the problem:
- Hash algorithms can be reversed with rainbow tables
- Hashed values can be matched across systems
- Same IP produces same hash, enabling tracking
- GDPR Recital 26 explicitly states pseudonymization doesn't remove personal data status
**Schrems II Implications**: The Schrems II decision invalidated Privacy Shield, making US data transfers problematic. Many companies responded by hosting analytics in the EU, but if those tools store IP addresses (even hashed), they still process personal data requiring careful legal basis justification.
Sealmetrics solves this by never storing IP addresses. Our session tracking uses temporary identifiers that reset after each visit, making reverse-identification technically impossible.
### Problem 2: Cookie Requirements
The ePrivacy Directive Article 5(3)—often called the Cookie Law—requires consent before storing information on user devices. This operates alongside GDPR, creating a dual compliance requirement.
**The Cookie Consent Trap**: Analytics tools using cookies face an impossible choice. They can require consent and lose 15-60% of their data, or operate without consent and violate the ePrivacy Directive. Many companies choose the latter, hoping enforcement remains limited.
**Technical Cookies Exemption**: The ePrivacy Directive exempts "strictly necessary" cookies for functionality users explicitly request. Analytics cookies don't qualify for this exemption according to regulatory consensus. The upcoming ePrivacy Regulation will likely remove any remaining ambiguity.
Sealmetrics avoids this problem entirely through cookieless tracking. No cookies means no ePrivacy Directive concerns, no consent banners, and no data loss from rejections.
### Problem 3: US Data Transfers
Google Analytics stores data in US servers, creating complex legal challenges post-Schrems II.
**Why This Matters**: Schrems II invalidated the Privacy Shield framework that allowed EU-US data transfers. The Court ruled that US surveillance laws (FISA 702, EO 12333) don't provide adequate protection for EU citizen data. While a new adequacy decision was adopted in July 2023, uncertainty remains about its long-term validity.
**The Google Problem**: Multiple European data protection authorities (Austria, France, Italy) have ruled that Google Analytics violates GDPR due to US data transfers. Even with Google's EU hosting options, the underlying data sharing with Google's US operations creates compliance risks.
Sealmetrics operates exclusively on EU infrastructure with no US parent company, eliminating data transfer concerns entirely.
---
## How Sealmetrics Handles GDPR
Sealmetrics was built from the ground up around the GDPR, not retrofitted like most analytics tools.
### No Consent Required
Sealmetrics needs no cookie consent banner, for two independent reasons. Nothing is stored on or read from the user's device, so ePrivacy Article 5(3) — the rule that mandates banners — is never triggered. And no personal data is stored, so the dataset falls outside the GDPR's material scope under Recital 26 and needs no Article 6 legal basis at all. That removes the 15-60% consent gap at its source.
**The Technical Foundation**: Our session-based tracking generates temporary identifiers that exist only for the duration of a visit. When a user leaves your site, the identifier expires. When they return, a new identifier is generated. This prevents cross-session tracking while still providing valuable analytics on how users navigate your site within individual visits.
**CNIL Compliance**: The French data protection authority's 2020 guidance on analytics explicitly allows this approach. CNIL confirms that audience measurement without consent is permissible when analytics strictly respect user privacy through technical safeguards like cookieless tracking and no IP storage.
**No Fingerprinting**: Unlike some cookieless analytics that use browser fingerprinting (tracking users via unique browser characteristics), Sealmetrics uses simple session identifiers. Fingerprinting is considered personal data processing under GDPR and requires consent. Our approach avoids this entirely.
### Zero IP Storage
This is Sealmetrics' most significant differentiator. We don't store IP addresses—not full, not truncated, not hashed, not at all.
**How It Works**: When a pageview hits our servers, we process the request, extract necessary analytics data (page URL, referrer, timestamp), and use the IP address only transiently server-side for security and anti-abuse checks. The IP never touches our analytics database and is never linked to any hit or metric — it appears only in short-lived operational logs with limited retention.
**Contrast with Competitors**:
- Google Analytics: Stores full IP addresses by default (can be configured for anonymization but still processes full IPs)
- Plausible: Hashes IP addresses before storage
- Matomo: Offers IP anonymization but defaults to storing IP addresses
- Sealmetrics: Zero IP storage, not even hashed
This technical choice means Sealmetrics stores less personal data than any competitor — none — which is what keeps the dataset outside the Regulation's scope instead of merely defensible inside it.
### 24-Month Retention Without Consent
Data retention limits are crucial for GDPR compliance under the data minimization principle. Sealmetrics retains analytics data for 24 months, a period we've documented as necessary for meaningful trend analysis.
**Why 24 Months**: This retention period allows:
- Year-over-year comparisons (12 months of current data + 12 months historical)
- Seasonal pattern identification (requires full annual cycles)
- Long-term trend analysis for strategic decisions
- Buffer period for data exports and migrations
**Automatic Purging**: Data older than 24 months is automatically deleted from our systems. No manual intervention needed, no risk of keeping data too long.
**Documented Justification**: We maintain internal documentation explaining why 24-month retention is necessary for business intelligence and user experience optimization, and confirming that what is retained is aggregate data containing no personal identifiers.
### EU Infrastructure
Sealmetrics operates exclusively on European infrastructure, eliminating Schrems II concerns.
**Data Location**: All Sealmetrics servers are located in an EU data center in Dublin, Ireland. Customer data never leaves the European Union. Our company is EU-based with no US parent organization or data sharing agreements with US entities.
**Processor Compliance**: Our subprocessor list is deliberately short — infrastructure and database hosting in Ireland, managed LLM inference in Paris for the optional Seal AI Private add-on, and a transactional email provider. The authoritative, always-current list is Annex 3 of our [DPA](https://sealmetrics.com/dpa), which also sets out the notification procedure if processors change. If you use LENS with your own LLM key instead, that provider is your contract, not our subprocessor.
**No Surveillance Exposure**: Because we operate entirely within the EU legal framework, customer data isn't subject to US surveillance laws (FISA 702, EO 12333) that caused Schrems II complications for US-based analytics providers.
---
## Country-Specific GDPR Considerations
While GDPR provides baseline requirements across the EU, individual countries have additional regulations affecting analytics.
### Germany (TTDSG)
Germany's Telecommunications Telemedia Data Protection Act (TTDSG) is stricter than baseline GDPR regarding cookies and tracking.
**Key Requirements**:
- Consent required for storing information on devices (including cookies)
- Higher bar for "technically necessary" exemptions
- Specific rules around telecommunications data
- Fines up to €300,000 for violations
**Sealmetrics Compliance**: TTDSG changes nothing for Sealmetrics users because we don't use cookies or device storage. Our cookieless approach satisfies TTDSG requirements without configuration changes.
### France (CNIL)
The French data protection authority (Commission Nationale de l'Informatique et des Libertés) published influential guidance on analytics in 2020.
**CNIL 2020 Analytics Guidance**: This document established that "audience measurement" can operate without consent under specific conditions:
- Purpose limited to measuring audience
- No cross-site tracking
- No data sharing with third parties for other purposes
- Limited retention periods
- Transparent privacy disclosures
**Exemption Categories**: CNIL identifies two types of exempt audience measurement:
1. First-party audience measurement (tracking on your own site)
2. Delegated audience measurement (using analytics providers like Sealmetrics)
**Sealmetrics Qualification**: Sealmetrics explicitly qualifies for CNIL's delegated audience measurement exemption. We meet all specified requirements: purpose limitation, no cross-site tracking, documented retention limits, EU-only operation, and clear privacy disclosures.
### Spain (AEPD)
Spain's data protection authority (Agencia Española de Protección de Datos) follows similar principles to CNIL with emphasis on data minimization.
**Key Focus Areas**:
- Proportionality of data collection
- Technical necessity justification
- User transparency requirements
- Cross-border data transfer restrictions
**Implementation**: Spanish companies using Sealmetrics should document in their privacy policies why no personal data is stored — no IPs, no cookies, minimal collection — rather than asserting a legal basis they don't need.
---
## Implementation Guide
Moving to GDPR compliant analytics involves choosing your legal basis, implementing technical measures, updating legal documentation, and verifying compliance.
### Step 1: Establish Your Legal Position
The first decision determines everything else — and it starts one question earlier than most teams assume.
```
Decision Tree:
Does your analytics store any personal data
(IP addresses, hashed or not, user IDs, persistent identifiers)?
│
├─ No, and it writes nothing to the device
│ └─ No Article 6 basis needed (Recital 26)
│ No consent needed (ePrivacy 5(3) not engaged)
│ └─ Choose Sealmetrics or a similar truly cookieless tool
│
└─ Yes → you are inside the GDPR, so pick a basis:
│
├─ Consent → implement a cookie banner
│ └─ Accept 15-60% data loss, unevenly distributed
│
└─ Legitimate interest → run and document a balancing test
└─ Accept the obligations that come with processing personal data
```
**Out-of-scope checklist** — every answer must be yes:
- Are you certain no IP address is stored, in any form, including hashed?
- Is nothing written to or read from the user's device (no cookies, no LocalStorage, no persisted fingerprint)?
- Are all identifiers session-scoped and never correlated across visits?
- Is the retained data aggregate, with no field that could single out a person?
- Can you show all of the above to a DPO in writing?
If any answer is no, you are processing personal data and you need a legal basis. Don't assert the out-of-scope position on a tool that doesn't earn it.
### Step 2: Technical Setup
Implementation differs by platform but follows similar principles.
That's it. No cookie configuration, no IP anonymization settings, no consent management. The script loads asynchronously, doesn't block page rendering, and starts capturing analytics immediately.
**For Other Platforms**:
- Remove or configure cookie-based tracking
- Enable IP anonymization (though this doesn't fully solve GDPR issues)
- Disable advertising features
- Disable user ID tracking
- Configure EU-only data storage
### Step 3: Legal Documentation
Update three key documents to reflect your analytics approach.
**Privacy Policy Updates**:
Add or update your analytics section:
```
We use Sealmetrics for web analytics. Sealmetrics collects anonymous
usage data (pages viewed, referral sources, aggregate engagement)
without cookies and without storing IP addresses. Nothing is stored
on or read from your device. Because no personal data is retained,
this measurement falls outside the scope of the GDPR and requires
no consent. Data is retained for 24 months for trend analysis and
stored exclusively on EU servers in Dublin, Ireland. You can opt
out via [opt-out link].
```
**Out-of-Scope Documentation** (Internal):
Maintain internal records documenting:
- What is stored, field by field, and why no field identifies a person
- That nothing is written to or read from the device, so ePrivacy Article 5(3) is not engaged
- Why the dataset is anonymous rather than pseudonymous, with reference to Recital 26
- Safeguards: cookieless, IP-less, EU-only, limited retention
- Alternative considered: consent-based analytics rejected due to 15-60% data loss
**Data Processing Agreement**:
Execute Sealmetrics' standard DPA, which covers:
- Processor obligations (security, confidentiality, instructions)
- Sub-processor authorization and notification
- Data subject rights assistance
- Data breach notification procedures
- Post-termination data deletion
- Audit rights
### Step 4: Verify Compliance
After implementation, verify everything works correctly.
**Technical Verification**:
- Open browser developer tools → Application → Cookies
- Confirm: No analytics cookies set
- Check: Privacy policy updated
- Test: Analytics dashboard receiving data
- Verify: Opt-out mechanism functions
**Legal Verification**:
- Privacy policy describes the analytics accurately, including why no consent is required
- DPA executed with Sealmetrics
- Internal out-of-scope documentation complete (what is stored, and why none of it is personal data)
- Data retention schedule understood (fixed 24 months for aggregates and conversions)
- Team trained on data handling procedures
**Ongoing Compliance**:
- Review analytics configuration quarterly
- Update documentation when practices change
- Monitor regulatory guidance for updates
- Conduct annual GDPR compliance audit
---
## Common GDPR Compliance Mistakes
Avoiding these frequent errors saves legal headaches and potential fines.
### Mistake 1: Relying on Consent for Analytics
**The Problem**: Consent sounds legally safe but creates massive business problems. Rejection rates in the EU run as high as 87%, and the resulting shortfall in your reports is 15-60% — spread unevenly across your channels, which is what quietly reorders your rankings rather than just shrinking your totals.
**Why It Happens**: Companies fear legitimate interest is too uncertain or worry about regulatory challenges. They choose consent thinking it's the "safer" option.
**The Fix**: use a properly implemented cookieless tool that stores no personal data, so no Article 6 basis is required in the first place. Document what is stored and why none of it identifies a person, minimize collection, and implement technical safeguards.
### Mistake 2: Using Google Analytics Without Configuration
**The Problem**: Default Google Analytics configuration violates GDPR in multiple ways: sets cookies without consent, stores IP addresses, transfers data to US servers, and enables advertising features.
**Why It Happens**: Companies install Google Analytics with default settings, assuming a major tech company must be GDPR compliant by default. This assumption is incorrect.
**The Fix**: either configure Google Analytics extensively (IP anonymization, cookie consent integration, disable advertising, EU-only hosting) and accept 15-60% data loss from consent requirements, or switch to Sealmetrics and avoid the gap altogether.
### Mistake 3: Thinking Hashed IPs Solve GDPR
**The Problem**: Many analytics tools claim GDPR compliance by hashing IP addresses before storage. This is pseudonymization, not anonymization. GDPR still considers pseudonymized data as personal data.
**Why It Happens**: Marketing materials from analytics vendors incorrectly conflate hashing with anonymization. Companies believe "we hash IPs" means "we don't process personal data."
**The Fix**: Use analytics that doesn't store IP addresses at all. Sealmetrics never stores IPs—not hashed, not truncated, not at all. This eliminates the personal data processing question entirely.
### Mistake 4: No DPA with Analytics Provider
**The Problem**: GDPR Article 28 requires a Data Processing Agreement between controllers (you) and processors (your analytics provider). Operating without a DPA is a compliance violation regardless of how privacy-protective your analytics tool is.
**Why It Happens**: Small companies often overlook this administrative requirement, focusing only on technical compliance.
**The Fix**: Execute a DPA with your analytics provider. Sealmetrics provides a standard DPA to all customers covering all Article 28 requirements.
### Mistake 5: Inadequate Privacy Policy Disclosures
**The Problem**: GDPR Article 13 requires transparent information about data processing. Many companies mention "we use analytics" without explaining what data is collected, what legal basis applies, or how long data is retained.
**Why It Happens**: Companies copy privacy policy templates without customizing them for their specific analytics implementation.
**The Fix**: clearly disclose in your privacy policy what analytics you use, what specific data gets collected, where it is stored, how long it is retained, why no consent is required, and how users can opt out. See Step 3 above for specific language.
---
## Expert Perspectives on GDPR Analytics
Regulatory guidance and legal opinions provide authoritative views on compliant analytics implementation.
### CNIL (French Data Protection Authority)
In their groundbreaking 2020 guidance on audience measurement, CNIL stated:
> "Audience measurement can be performed without consent when it strictly respects users' privacy and is limited to producing anonymous statistical data."
CNIL's guidance establishes specific requirements:
- Purpose limitation to audience measurement only
- No cross-site tracking or user profiling
- Limited data retention periods (maximum 24 months mentioned)
- No IP address storage beyond immediate processing needs
- Transparent privacy policy disclosures
This guidance forms the foundation for consent-exempt audience measurement across the EU, as other data protection authorities have referenced CNIL's framework in their own. Note the wording CNIL uses: *anonymous statistical data*. That is a statement about the nature of the output, not about having a good reason to process personal data.
### GDPR Article 5(1)(c) - Data Minimization
The regulation itself provides clear direction:
> "Personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed."
For analytics, this means:
- Collect only essential metrics (pageviews, sessions, referrers)
- Don't collect unnecessary identifiers (names, emails, precise locations)
- Don't store IP addresses if your technical approach doesn't require them
- Don't retain data longer than necessary for your documented purposes
Sealmetrics implements data minimization as a core design principle. We collect the minimum data necessary for meaningful analytics: what pages users visit, how they navigate, where they came from, and basic device information. We don't collect anything else.
### The Sealmetrics Approach
Unlike cookie-based analytics tools that retrofit GDPR compliance onto existing architectures, Sealmetrics was designed from inception for compliance.
**No Compromise Required**: Traditional analytics forces a choice between a clean legal position and complete data. Cookie consent buys the former at the cost of 15-60% of the latter. Sealmetrics measures every visit and keeps the legal position clean, through:
1. **Cookieless Architecture**: No cookies means no ePrivacy Directive concerns, no consent requirements, no data loss from rejections.
2. **Zero IP Storage**: Not hashing, not truncating—zero storage. IP addresses never touch our database, eliminating the largest GDPR compliance question.
3. **Session-Based Tracking**: Temporary identifiers that reset after each visit provide analytics value without enabling cross-session tracking or user identification.
4. **EU-Exclusive Operation**: Servers, company, and data all in the EU. No US parent, no Schrems II concerns, no adequacy decision dependencies.
5. **Purpose Limitation**: Sealmetrics processes data only for audience measurement. No advertising integrations, no data selling, no repurposing for other commercial activities.
6. **Documented Retention**: 24-month retention justified and documented as necessary for trend analysis, with automatic purging of older data.
This technical foundation is what puts the dataset outside the GDPR's material scope rather than inside it needing a justification — consistent with CNIL's guidance, and accepted by DPOs across the EU. To be clear about what that is and isn't: DPO acceptance is a customer assessment, not a regulatory endorsement. No supervisory authority certifies analytics tools, and SealMetrics holds no ISO 27001 or SOC 2 certification.
---
## Frequently Asked Questions
### Is Google Analytics GDPR compliant?
Google Analytics is not GDPR compliant in its default configuration. Multiple European data protection authorities (Austria, France, Italy) have ruled that standard Google Analytics implementations violate GDPR due to three main issues:
First, Google Analytics uses cookies, triggering ePrivacy Directive consent requirements. This means you need cookie banners and will lose 15-60% of your data to ghosting and rejection.
Second, Google Analytics stores IP addresses. Even with the IP anonymization feature enabled, full IPs are processed before anonymization occurs, constituting personal data processing.
Third, Google Analytics transfers data to US Google servers, creating Schrems II compliance challenges. While Google offers a consent mode and EU hosting options, the fundamental architecture involves data sharing with a US parent company.
You can make Google Analytics more GDPR compliant through extensive configuration, but you'll still need consent banners and accept massive data loss. Sealmetrics provides compliance without these compromises.
### Can I use analytics without a cookie banner?
Yes, with properly implemented cookieless analytics like Sealmetrics. Cookie banners are required by the ePrivacy Directive when websites store information on user devices (cookies). If your analytics doesn't use cookies, no banner is needed.
The GDPR is a separate question from ePrivacy, and both have to be satisfied. Sealmetrics satisfies both: nothing is stored on or read from the device (so ePrivacy Article 5(3) is not engaged), and no personal data is stored (so the dataset sits outside the GDPR's material scope under Recital 26, with no Article 6 basis required).
This measures every visit without a consent banner — and without asking anyone to accept a balancing test.
### What's the difference between legitimate interest, consent, and no legal basis at all?
Consent (Article 6(1)(a)) requires users to actively opt in before processing begins. For analytics that means cookie banners, explicit checkboxes, and a 15-60% hole in your data.
Legitimate interest (Article 6(1)(f)) allows processing when your business needs are not overridden by privacy rights. It's the right answer for a tool that stores hashed IPs or other identifiers, provided the purpose is audience measurement rather than advertising, collection is minimized, safeguards are in place, and users can object.
**The third option is the one people miss.** Both of the above assume you're processing personal data. If your analytics stores none — no IP in any form, no persistent identifier, nothing written to the device — then under Recital 26 the dataset is outside the GDPR's material scope and no Article 6 basis is required at all.
That is a stronger position, not a weaker one, and it's why Sealmetrics does not claim legitimate interest. Claiming 6(1)(f) would concede that personal data is being processed. CNIL confirmed in 2020 that cookieless audience measurement can operate without consent when it produces anonymous statistical data — which is the same distinction.
### Does hashing IP addresses make them anonymous under GDPR?
No. Hashing IP addresses is pseudonymization, not anonymization. GDPR treats pseudonymized data as personal data requiring the same protections as unprocessed personal data.
GDPR Recital 26 explicitly states: "Personal data which have undergone pseudonymization, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person."
Hashed IPs remain personal data because:
- Hash functions can be reversed with rainbow tables
- Same IP produces same hash, enabling tracking
- Hashes can be matched across systems
- Technical possibility of re-identification exists
Sealmetrics solves this by never storing IP addresses—not hashed, not truncated, zero storage. This eliminates the personal data question entirely.
### How long can I store analytics data under GDPR?
GDPR doesn't specify exact retention periods but requires you to keep data only as long as necessary for documented purposes. For analytics, retention depends on your business justification.
CNIL's 2020 guidance mentions 24 months as an acceptable retention period for audience measurement, justified by the need for year-over-year comparisons and seasonal pattern identification.
Sealmetrics implements 24-month retention with documented justification:
- 12 months of current data for analysis
- 12 months of historical data for year-over-year comparison
- 1 month buffer for data exports and migrations
- Automatic deletion after 24 months
Your privacy policy should specify retention periods, and you should maintain internal documentation justifying why these periods are necessary for your stated purposes.
### Do I need a Data Processing Agreement (DPA) with my analytics provider?
Yes. GDPR Article 28 requires a written contract between data controllers (you) and data processors (your analytics provider) establishing:
- Subject matter and duration of processing
- Nature and purpose of processing
- Type of personal data processed
- Categories of data subjects
- Obligations and rights of the controller
The DPA must include specific processor obligations around security, confidentiality, sub-processor management, data subject rights assistance, data breach notification, and post-termination data handling.
Sealmetrics provides a standard DPA to all customers covering all Article 28 requirements. Operating without a DPA violates GDPR regardless of how privacy-protective your analytics tool is.
### What is a Data Protection Impact Assessment (DPIA) and do I need one?
A DPIA is a systematic analysis required under GDPR Article 35 when processing is "likely to result in high risk to the rights and freedoms of natural persons." DPIAs are mandatory for:
- Systematic and extensive profiling with significant effects
- Large-scale processing of special category data
- Systematic monitoring of publicly accessible areas at large scale
Most cookieless analytics don't require DPIA because they implement data minimization, don't create detailed user profiles, and have minimal privacy impact. However, you should document your reasoning for not conducting a DPIA.
If your DPO or legal counsel determines a DPIA is needed, the assessment should document: description of processing operations, necessity and proportionality assessment, risk analysis, and mitigation measures.
Sealmetrics' technical approach (no IPs, no cookies, minimal data, EU-only) creates low privacy impact, typically not requiring DPIA. Many customers document this determination as part of their compliance records.
### Can I use Sealmetrics for TTDSG compliance in Germany?
Yes, Sealmetrics complies with Germany's TTDSG (Telecommunications Telemedia Data Protection Act) without requiring configuration changes.
TTDSG is stricter than baseline GDPR, particularly regarding device storage and tracking. The law requires consent for storing information on devices (including cookies) with limited exemptions for technically necessary functionality.
Sealmetrics complies because:
- No cookies or device storage (eliminates consent requirement)
- No fingerprinting or tracking technologies (avoids TTDSG tracking restrictions)
- Data minimization by design (satisfies TTDSG privacy principles)
- EU-exclusive operation (no German-US data transfer concerns)
German companies using Sealmetrics operate without cookie banners because §25 TTDSG governs storing and reading information on devices, and Sealmetrics does neither. Every visit is measured, with no consent gate to fail.
### What if my Data Protection Officer (DPO) rejects cookieless analytics?
DPOs sometimes push back on cookieless analytics out of unfamiliarity with the framework — and, fairly often, because a previous vendor oversold it. Address this by providing:
**CNIL 2020 Guidance**: share the French DPA's documentation confirming that audience measurement can operate without consent when it produces anonymous statistical data. Be precise about what this is: guidance you can assess yourself against, not a certification. CNIL does not approve individual tools.
**Technical Documentation**: explain the implementation — no cookies, zero IP storage, session-scoped identifiers never written to the device, EU-only servers in Dublin. This is what carries the argument, so lead with it.
**The Scope Argument, Not a Balancing Test**: don't present a legitimate interest analysis. Present why there is no personal data in the dataset, field by field, and therefore why Recital 26 puts it outside the Regulation's material scope. A DPO who has seen a dozen weak balancing tests will find this a refreshing change.
**Comparison with Alternatives**: show that consent-based analytics loses 15-60% of its data, unevenly across channels. Resist inflating it — a DPO who catches an exaggerated number will discount everything else you said.
Most DPOs approve once they understand the legal framework and technical implementation. If concerns remain, consider requesting a second opinion from external GDPR counsel or consulting other DPOs in your industry who have approved similar approaches.
### How do I document a consentless analytics setup?
GDPR doesn't prescribe documentation formats, but the records worth keeping are these:
**Purpose Statement**: "We measure website usage in order to understand how visitors navigate our site, enabling user experience improvements and informed business decisions."
**Scope Analysis** — the important one:
- What is stored: pages viewed, referrer, aggregate engagement, country derived from browser timezone
- What is not stored: IP addresses in any form including hashed, user IDs, cross-session identifiers
- Device storage: none — no cookies, no LocalStorage, nothing written or read
- Conclusion: the dataset does not relate to an identified or identifiable natural person, so under Recital 26 it falls outside the material scope of the GDPR, and no Article 6 legal basis is required
**Safeguards**: cookieless, zero IP storage, EU servers in Dublin, 24-month retention on aggregates with automatic purging.
**Alternative Considered**: "We considered consent-based analytics but rejected it because 15-60% data loss from banner ghosting and rejection would prevent achieving our business intelligence purposes."
**Opt-Out Mechanism**: "Users can opt out via [provide opt-out method]."
Sealmetrics provides documentation templates to help customers formalize this for internal records and DPO review.
---
## Conclusion
GDPR compliance for web analytics doesn't require choosing between legal safety and data completeness. The consent-or-data-loss dilemma is a false choice created by outdated cookie-based analytics architectures.
The path to a clean legal position without giving up 15-60% of your data:
1. **Ask the prior question**: is any personal data stored at all? If not, no Article 6 basis is needed
2. **Implement truly cookieless analytics** that writes nothing to and reads nothing from the device
3. **Ensure zero IP storage**—not hashed or truncated, but zero storage
4. **Document your approach**: what is stored, and why none of it identifies a person
5. **Update your privacy policy** with clear, specific disclosures
6. **Execute a DPA** with your analytics provider
Sealmetrics satisfies all of these by default:
- **No consent required**: nothing stored on the device (ePrivacy 5(3) not engaged), no personal data stored (outside GDPR material scope, Recital 26)
- **No cookies**: no ePrivacy exposure and no consent-driven data loss
- **Zero IP storage**: not even hashed—the primary personal data question doesn't arise
- **No consent gap**: every visit measured, rather than the 40-85% a banner lets through
- **EU-exclusive**: analytics data hosted in Dublin, Ireland. No Schrems II complications
- **24-month retention**: documented as necessary for trend analysis, with automatic purging
Stop compromising between compliance and complete analytics data.
Start your 14-day free trial: [Sealmetrics.com](https://sealmetrics.com)
---
## Additional Resources
- [Complete Guide to Cookieless Analytics](/blog/cookieless-analytics-guide)
- [Cookieless vs Cookie-Based Analytics](/blog/cookieless-analytics-vs-cookie-based)
- [How Consentless Tracking Works](/security-privacy/how-consentless-works) — Technical architecture behind GDPR-compliant tracking
- [What Is Consentless Analytics?](/security-privacy/consentless-analytics) — Legal basis and implementation details
- [Real-Time Analytics and Consent](/blog/real-time-tracking-consent) — AEPD and CNIL rules on real-time data
- [CNIL 2020 Analytics Guidance (Official)](https://www.cnil.fr/en/cookies-and-other-trackers/rules/cookies/how-comply-cookies-and-trackers)
- [GDPR Official Text](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [ePrivacy Directive Article 5(3)](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32002L0058)
## Cookie-Based vs Cookieless Analytics: Technical Comparison
URL: https://docs.sealmetrics.com/blog/cookieless-analytics-vs-cookie-based
> **TL;DR** — Cookie-based analytics loses 15-60% of EU data. Technical comparison of cookie vs cookieless tracking: accuracy, compliance, and implementation.
Cookie rejection rates run as high as 87% in parts of the EU, and the resulting shortfall in your reports is 15-60% — enough to make traditional cookie-based analytics unreliable for the decisions people make with it. This technical comparison explores how cookieless analytics fundamentally differs from cookie-based approaches and why businesses are migrating to consent-free tracking solutions.
**Key Takeaways:**
- Cookie-based analytics loses 15-60% of EU visitor data to banner ghosting and rejection, depending on sector, brand strength and traffic sources
- Cookieless analytics measures every visit without requiring consent banners
- Sealmetrics uses session-based tracking without cookies or IP storage
- The legal footing differs fundamentally: consent, versus storing no personal data at all and needing no legal basis
## What Are Cookie-Based Analytics?
Cookie-based analytics tools like Google Analytics rely on third-party and first-party cookies to track user behavior across websites. When a visitor lands on a website, the analytics script drops a cookie in their browser with a unique identifier. This cookie persists across sessions, allowing the tool to recognize returning visitors and track their journey over time.
The technical implementation involves:
- **Cookie placement**: JavaScript places a tracking cookie with unique ID
- **Data collection**: Each pageview sends cookie ID + behavioral data to servers
- **Cross-session tracking**: Same cookie ID links visits over days/weeks/months
- **IP address storage**: Visitor IP addresses stored (or hashed) for geolocation
- **Consent requirement**: GDPR mandates explicit consent before cookie placement
Google Analytics, Adobe Analytics, and most traditional analytics platforms use this cookie-based approach. According to CNIL guidelines updated in 2024, cookie-based analytics requires user consent in the EU, which has led to massive data loss as users reject tracking.
The cookie-based model worked well for 20+ years, but regulatory changes and browser privacy features (Safari ITP, Firefox ETP) have made this approach increasingly problematic for businesses that need accurate analytics.
## What Are Cookieless Analytics?
Cookieless analytics eliminates cookies entirely, using alternative technical approaches to track visitor behavior while maintaining GDPR compliance. Sealmetrics pioneered consentless analytics by developing a dual tracking system that measures every visit without requiring cookie consent banners.
The technical implementation of cookieless analytics:
- **Session identifiers**: Temporary IDs generated per session (not persistent cookies)
- **Server-side tracking**: Data processed on backend, not client-side cookies
- **No IP storage**: Complete anonymization without storing IP addresses
- **Isolated hits**: Individual pageviews tracked without cross-session linking
- **No legal basis needed**: with no personal data stored, the dataset sits outside the GDPR's material scope (Recital 26)
Sealmetrics uses a sophisticated dual approach:
1. **Session-ID tracking**: Links pageviews within a single session for journey analysis
2. **Isolated Hits**: Captures individual metrics without session linking
This cookieless approach means no consent banners are required — the ePrivacy rule that mandates them (Article 5(3)) applies to storing or reading information on the device, and nothing is stored or read. According to CNIL's 2020 guidance, tools that don't use cookies and don't store identifying information can operate without consent.
Unlike cookie-based tools, which lose 15-60% of EU traffic, cookieless analytics captures every visitor. Businesses using Sealmetrics report complete data against the 40-85% capture rate Google Analytics manages in EU markets.
## Technical Comparison: Cookie-Based vs Cookieless
| Technical Aspect | Cookie-Based (Google Analytics) | Cookieless (Sealmetrics) |
|-----------------|--------------------------------|--------------------------|
| **Tracking Method** | Persistent cookies in browser | Session identifiers + isolated hits |
| **Requires Cookies** | Yes (first-party + third-party) | No cookies used |
| **Requires Consent** | Yes (ePrivacy 5(3) + GDPR 6(1)(a)) | No (nothing stored on device; no personal data) |
| **Consent-driven data loss** | 15-60% in EU | None - captures all visitors |
| **IP Address Storage** | Stored or hashed | Never stored |
| **Cross-Session Tracking** | Links visits over months | Limited to session duration |
| **Browser Compatibility** | Blocked by Safari ITP, Firefox ETP | Works in all browsers |
| **Implementation Complexity** | Medium (consent management needed) | Simple (2-minute setup) |
| **GDPR position** | Requires consent banners | Outside material scope (Recital 26) |
| **Data Retention** | 14 months (GA4 default) | 24 months without consent |
| **Geolocation Accuracy** | High (IP-based) | Medium (browser language/timezone) |
| **User Identification** | Persistent across devices | Single device, single session |
| **Script Size** | ~130KB (GA4 gzipped) | 1.3KB (Sealmetrics gzipped) |
| **Page Load Impact** | ~80-120ms | ~20-30ms |
| **CNIL Exemption Criteria** | Requires configuration | Designed to meet criteria (self-assessed) |
### Data Collection Accuracy
Cookie-based analytics accuracy has declined dramatically since GDPR enforcement:
- **2018 (pre-GDPR)**: 95%+ visitor capture rate
- **2020**: capture still high (early consent banner adoption)
- **2022**: capture falling as banner fatigue sets in
- **2024**: **40-85% capture**, i.e. 15-60% lost to ghosting and rejection
According to a 2024 study by CNIL, 87% of French website visitors reject cookie consent banners. In Germany, the rejection rate reaches 73% according to TTDSG enforcement data.
Translate those carefully. A rejection rate is measured among the visitors who engaged with the banner, and Consent Mode v2 models part of the unconsented traffic back in as estimates. Net of that, cookie-based tools are missing 15-60% of visitors in major EU markets — and where you land inside that band depends on your sector, the strength of your brand and where your traffic comes from.
Cookieless analytics has no such gap, because no consent is required. Sealmetrics measures every visit regardless of privacy preferences, browser settings, or ad blockers.
## Implementation Comparison
### Cookie-Based Analytics Setup
Implementing Google Analytics requires:
```javascript
```
Plus consent management implementation:
```javascript
```
**Total implementation time**: 30-60 minutes
**Ongoing maintenance**: Cookie policy updates, consent management
**Legal review**: Required before launch
### Cookieless Analytics Setup
Implementing Sealmetrics requires:
```html
```
**Total implementation time**: 2 minutes
**Ongoing maintenance**: None
**Legal review**: Simplified (no cookies, no personal data stored)
The difference is stark. Cookie-based analytics requires consent management platforms (OneTrust, Cookiebot, etc.) that cost €300-3000/month. Cookieless analytics like Sealmetrics requires one script tag.
## GDPR Legal Framework Comparison
### Cookie-Based Analytics: Consent Requirement
GDPR Article 6(1)(a) and ePrivacy Directive Article 5(3) require explicit consent for cookie-based analytics:
> "The storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user shall only be allowed on condition that the subscriber or user concerned has given his or her consent."
This means:
- Consent banner required before tracking
- Clear opt-in mechanism needed
- Easy withdrawal of consent
- Granular consent per purpose
- Pre-ticked boxes not allowed
- Cookie walls not allowed (mostly)
CNIL's 2024 guidance confirms that Google Analytics requires consent even with IP anonymization. The Schrems II decision further complicated cookie-based analytics by questioning US data transfers.
### Cookieless Analytics: No Legal Basis Required
The instinct here is to reach for Article 6(1)(f), legitimate interest. Resist it. Naming any Article 6 basis is an admission that you *are* processing personal data and merely have a good reason for it — which concedes the argument rather than winning it.
**GDPR Recital 26** states that the principles of data protection do not apply to anonymous information — information which does not relate to an identified or identifiable natural person. Properly implemented cookieless analytics clears that bar:
- No cookies used = the ePrivacy Article 5(3) consent rule is never triggered
- No IP addresses stored, hashed or otherwise = nothing that singles out a person
- No cross-session identifiers = no profile can be assembled
- Aggregate output only = anonymous statistical data
So the dataset falls outside the GDPR's *material scope*, and no Article 6 basis is needed at all. (Article 6(1)(f) does correctly cover one narrow thing: the transient in-memory handling of an IP for anti-abuse checks, per Recital 49. That IP never reaches storage.)
CNIL's 2020 guidance states that analytics tools without cookies and without storing identifying information can operate without consent. Sealmetrics' architecture is designed to meet those published criteria. Note that CNIL does not certify, approve, or validate individual analytics tools, and no supervisory authority operates such a scheme — see our [CNIL self-assessment](/compliance/cnil-self-assessment) for a criterion-by-criterion analysis.
This legal distinction is crucial: cookie-based analytics **requires consent**, cookieless analytics **does not**.
## Data Loss Analysis: The 15-60% Problem
Cookie rejection creates massive blind spots in business intelligence:
### E-commerce Example
A German e-commerce site with 100,000 monthly visitors:
**With Google Analytics (cookie-based)**, in a privacy-sensitive market at the harder end of the band:
- Consent banner shown: 100,000 visitors
- **Measured visitors**: ~45,000 (45% capture rate)
- **Blind spot**: ~55,000 visitors (55% data loss)
**With Sealmetrics (cookieless)**:
- No consent banner: 100,000 visitors
- **Measured visitors**: 100,000
- **Blind spot**: none beyond the JavaScript blockers no tool can see
The business impact:
- **Revenue attribution**: cookie-based misses over half the conversions
- **Customer journey**: incomplete path-to-purchase data
- **Marketing ROI**: unmeasurable for a large share of campaigns — and unevenly so, which is worse than uniformly
- **A/B testing**: results biased by the exclusion of privacy-conscious users
### B2B SaaS Example
A French SaaS company tracking trial signups:
**Cookie-based analytics** shows:
- 1,000 website visitors
- 50 trial signups
- 5% conversion rate
**Reality** (with cookieless analytics):
- 2,200 actual visitors — the banner was hiding more than half of them
- 50 trial signups
- 2.3% actual conversion rate
The cookie-based data suggested a healthy 5% conversion. The real figure was less than half that. The misattribution led to incorrect pricing decisions and wasted marketing budget.
## Browser Privacy Features Impact
Modern browsers increasingly block cookie-based tracking:
### Safari ITP (Intelligent Tracking Prevention)
- **First-party cookies**: Limited to 7 days (24 hours if set via JavaScript)
- **Third-party cookies**: Completely blocked
- **Impact**: substantial Google Analytics data loss on Safari, on top of any consent gap
- **Market share**: 19% desktop, 52% mobile (iOS)
### Firefox ETP (Enhanced Tracking Protection)
- **Third-party cookies**: Blocked by default
- **Known trackers**: Blocked (includes GA domains)
- **Impact**: further data loss on top of the consent gap
- **Market share**: 6% desktop, 3% mobile
### Chrome Privacy Sandbox
- **Third-party cookies**: Deprecation ongoing (2024-2025)
- **Topics API**: Limited interest-based advertising
- **Impact**: Major change coming for cookie-based tools
- **Market share**: 63% desktop, 65% mobile
Cookieless analytics is unaffected by all browser privacy features. Sealmetrics works identically across Safari, Firefox, Chrome, Brave, and all other browsers because it doesn't use cookies.
## Performance Comparison
### Page Load Impact
**Cookie-based analytics** (Google Analytics 4):
- Script size: ~130KB (gzipped)
- Additional requests: 3-5 (consent management, GTM, etc.)
- First Contentful Paint delay: 80-120ms
- Consent banner: Additional 150-200ms
- Total impact: 230-320ms
**Cookieless analytics** (Sealmetrics):
- Script size: 1.3KB (gzipped)
- Additional requests: 1 (tracking endpoint)
- First Contentful Paint delay: 20-30ms
- No consent banner: 0ms
- Total impact: 20-30ms
For a site receiving 100,000 monthly visitors, cookie-based analytics adds:
- 230ms × 100,000 = 23,000 seconds (6.4 hours) of cumulative delay
- Consent banners shown: 100,000 times
- User friction: Every visitor interrupted
Cookieless analytics adds:
- 25ms × 100,000 = 2,500 seconds (42 minutes) of cumulative delay
- Consent banners shown: 0 times
- User friction: None
Google's Core Web Vitals heavily weight page speed. Cookie-based analytics hurts SEO performance.
## Migration Considerations
### When to Stay Cookie-Based
Cookie-based analytics may still be appropriate if:
- You only operate in non-EU markets (US, Asia)
- You need cross-device tracking (same user, multiple devices)
- You require 12+ month visitor history
- You already have 80%+ cookie acceptance rates
However, even in these scenarios, cookieless analytics provides more accurate data.
### When to Switch to Cookieless
Cookieless analytics is recommended if:
- You have significant EU traffic (>20%)
- Your cookie acceptance rate is less than 50%
- You face GDPR compliance pressure
- You want complete data capture
- You want to remove consent banners entirely
- You need faster page load times
- You want simplified legal compliance
### Migration Process
Switching from Google Analytics to Sealmetrics:
**Preparation** (Day 1):
1. Export historical GA data
2. Document current reports/dashboards
3. Identify key metrics to preserve
**Implementation** (Day 1):
1. Add Sealmetrics script tag
2. Run dual tracking (GA + Sealmetrics) for 7-30 days
3. Compare data accuracy
**Transition** (Day 30):
1. Remove consent banner (if only used for analytics)
2. Remove Google Analytics script
3. Update privacy policy
4. Train team on new dashboard
**Completion** (Day 31+):
- 100\% data capture achieved
- No consent banners
- GDPR compliant
- Faster page loads
Total migration time: 30 days (with dual tracking period)
## Cost Comparison
### Cookie-Based Analytics Total Cost
Google Analytics (free) plus required infrastructure:
- **Consent Management Platform**: €300-3,000/month
- OneTrust: €1,200/month
- Cookiebot: €300/month
- Custom solution: €3,000-10,000 development
- **Legal Review**: €2,000-5,000 one-time
- **Ongoing Compliance**: €500-1,000/month (policy updates)
- **Data Loss Cost**: 15-60% of your traffic untracked, distorting every channel comparison you make
**Annual cost**: €6,000-40,000+ plus opportunity cost
### Cookieless Analytics Total Cost
Sealmetrics pricing (volume-based):
- **Growth**: €599/month (5M events) — €499/month with annual billing
- **Scale**: €1,079/month (15M events) — €899/month with annual billing
- **Enterprise**: Custom pricing (unlimited events)
- **Consent Management**: €0 (not needed)
- **Legal Review**: Minimal (no cookies, no personal data stored)
- **Ongoing Compliance**: €0 (built-in)
- **Data Loss Cost**: €0 (100\% capture)
**Annual cost**: €2,388-9,588 (with annual billing discount) and zero data loss
The ROI is obvious. Cookieless analytics costs 5-15x less than cookie-based analytics infrastructure while capturing 6-9x more data.
## Frequently Asked Questions
### Is cookieless analytics as accurate as cookie-based analytics?
Cookieless analytics is significantly more accurate than cookie-based analytics in 2026. While cookie-based tools lose 15-60% of EU visitors to banner ghosting and rejection, cookieless analytics measures every visit. Sealmetrics provides complete visitor data without the blind spots created by cookie banners.
The trade-off is cross-session tracking. Cookie-based analytics can track the same user across multiple visits over months. Cookieless analytics measures within sessions but doesn't link returning visitors. For most businesses, complete single-session data beats a partial and self-selected 40-85% of multi-session data.
### Does cookieless analytics work with ad blockers?
Yes, Sealmetrics works with most ad blockers because it doesn't use tracking cookies or known advertising domains. Unlike Google Analytics (blocked by 30%+ of users with ad blockers), cookieless analytics uses first-party domains and server-side tracking that ad blockers don't detect as advertising infrastructure.
### Can I use cookieless analytics for GDPR compliance?
Yes — and note the mechanism, because it isn't the one most vendors claim. Sealmetrics doesn't rely on Article 6(1)(f) legitimate interest; it stores no personal data, so the dataset falls outside the GDPR's material scope (Recital 26) and no legal basis is required. Separately, nothing is written to or read from the device, so the ePrivacy consent rule isn't triggered. CNIL's 2020 guidance confirms that cookieless measurement meeting its exemption criteria can operate without consent; Sealmetrics is designed to meet those criteria (CNIL does not certify or approve individual tools).
Unlike cookie-based analytics that requires consent under ePrivacy Directive Article 5(3), cookieless analytics doesn't store information in user browsers and therefore doesn't trigger consent requirements.
### What's the difference between cookieless and cookie-free analytics?
These terms are often used interchangeably, but there's a subtle distinction:
- **Cookieless analytics**: Uses alternative tracking methods instead of cookies
- **Cookie-free analytics**: May use local storage or other browser APIs instead of cookies
Sealmetrics is both cookieless and cookie-free, using server-side session identifiers rather than any browser storage mechanism. This approach ensures compliance without relying on browser-based tracking technologies.
### Does cookieless analytics support conversion tracking?
Yes, Sealmetrics tracks conversions, goals, events, and custom metrics without cookies. E-commerce sites can track purchases, SaaS products can track trial signups, and media sites can track subscriptions—all without consent banners.
The implementation is simpler than cookie-based conversion tracking because there's no consent management logic required. Set up goals in the Sealmetrics dashboard, trigger events via JavaScript, and capture every conversion rather than the 40-85% a banner lets through.
### How does cookieless analytics handle returning visitors?
Cookieless analytics doesn't persistently identify returning visitors across sessions. Each session receives a temporary identifier that expires when the visitor closes their browser or after a short period of inactivity (~2 hours in Sealmetrics).
This limitation is intentional for privacy compliance. However, Sealmetrics provides visitor behavior patterns and aggregate return visitor metrics without individual tracking. For most analytics use cases (understanding user journeys, measuring content performance, tracking conversions), session-based data is sufficient.
### Can I migrate from Google Analytics to cookieless analytics?
Yes, migration is straightforward. Add the Sealmetrics script tag to your website, run dual tracking for 7-30 days to compare data, then remove Google Analytics. Most businesses complete migration in under 30 days.
The immediate benefit: you'll see meaningfully more visitor data in Sealmetrics than Google Analytics shows — typically 1.2x to 2.5x, depending on where your site sits in the 15-60% loss band. Export your historical GA data before migration to preserve long-term trends.
### Does cookieless analytics work for mobile apps?
Sealmetrics currently focuses on web analytics. Mobile apps have different tracking regulations (IDFA, GAID) that don't involve cookie consent. Cookie-based vs cookieless is primarily a web browser distinction.
For websites accessed via mobile browsers, cookieless analytics works identically to desktop—100\% capture rate without consent banners, regardless of device.
### What happens to my data with cookieless analytics?
Sealmetrics stores all analytics data on EU-based servers (Dublin, Ireland) with 24-month retention. Unlike Google Analytics (US-based with Schrems II concerns), cookieless analytics keeps your data within EU jurisdiction.
Data is fully anonymized: no IP addresses, no persistent identifiers, no personal data. This architecture ensures GDPR compliance and eliminates data transfer concerns.
### How do I explain cookieless analytics to my DPO?
Tell your Data Protection Officer:
1. **No cookies used**: ePrivacy Directive doesn't apply
2. **No IP storage**: Data is anonymous by design
3. **No legal basis needed**: no personal data stored, so the GDPR's material scope is never engaged (Recital 26)
4. **CNIL exemption criteria**: Architecture designed to meet CNIL's published criteria (self-assessed — CNIL does not certify tools)
5. **No consent required**: Removes consent management complexity
Provide your DPO with CNIL's 2020 guidance on cookieless analytics and Sealmetrics' data processing documentation. Most DPOs approve immediately because cookieless analytics is significantly lower risk than cookie-based alternatives.
### Can cookieless analytics replace Google Analytics completely?
For most businesses, yes. Sealmetrics provides:
- Real-time visitor tracking
- Pageview and event analytics
- Conversion and goal tracking
- Traffic source attribution
- Device and browser data
- Geographic insights (country/region)
- Data export and API access
The main limitation is cross-session user tracking. If your business requires tracking the same user across multiple visits over months (rare for most companies), you may need supplementary tools. But for 95% of analytics use cases, cookieless analytics provides superior data quality because of 100\% capture rate.
### Is cookieless analytics more expensive than Google Analytics?
Google Analytics is free, but the total cost of cookie-based analytics includes:
- Consent management platform: €300-3,000/month
- Legal compliance review: €2,000-5,000
- Ongoing policy maintenance: €500-1,000/month
- **Data loss opportunity cost**: substantial (15-60% of visitors untracked, and not at random)
Sealmetrics plans start at €599/month (€499/month with annual billing) depending on event volume, with no additional infrastructure required. Total cost of ownership is significantly lower than cookie-based analytics systems when you factor in consent management, legal review, and data loss costs.
### How does Sealmetrics differ from other cookieless tools like Plausible or Matomo?
Key differences:
**Sealmetrics**: True consentless analytics
- No cookies
- No IP storage (competitors store hashed IPs)
- No consent required
- 24-month retention without consent
- Designed to meet CNIL's exemption criteria (self-assessed)
**Plausible/Matomo**: Cookie-free but still store IPs
- No cookies (good)
- Store hashed IP addresses (still personal data)
- May require consent depending on DPO interpretation
- 12-month retention typical
Sealmetrics is the only analytics platform that stores zero identifying information, which is what enables genuinely consentless tracking — no legal basis required, rather than a legal basis defended.
### What's the future of analytics: cookie-based or cookieless?
Cookieless analytics is the future. Chrome's third-party cookie deprecation (2024-2025), Safari's ITP, Firefox's ETP, and increasing GDPR enforcement make cookie-based analytics increasingly unviable.
By 2026, expect:
- 90%+ cookie rejection rates in EU
- Complete third-party cookie elimination
- Stricter first-party cookie regulations
- Mainstream adoption of cookieless analytics
Businesses that migrate to cookieless analytics now gain a competitive advantage: complete data capture, while competitors make decisions on the 40-85% their banner happens to let through.
## Conclusion: The Case for Cookieless Analytics
The technical comparison is clear: cookieless analytics provides superior data quality, better legal compliance, faster performance, and lower total cost than cookie-based alternatives.
Cookie-based analytics worked for 20 years, but GDPR, browser privacy features, and user behavior have fundamentally broken the model. Losing 15-60% of your visitor data — unevenly, and skewed toward your most privacy-aware customers — isn't sustainable for businesses that need accurate analytics to make informed decisions.
Sealmetrics pioneered consentless analytics by eliminating both cookies and IP storage, which is what lets it measure every visitor without a consent banner and without needing an Article 6 legal basis at all. This technical approach represents the future of privacy-first analytics.
For businesses operating in EU markets, the migration from cookie-based to cookieless analytics isn't optional—it's essential for competitive survival. Start dual tracking today, compare data accuracy, and see all of your visitors instead of the 40-85% your banner selects for you.
**Ready to switch to cookieless analytics?** [Try Sealmetrics free for 14 days](https://my.sealmetrics.com/register) and see 6-9x more visitor data immediately.
## Additional Resources
- [Complete Guide to Cookieless Analytics](/blog/cookieless-analytics-guide)
- [GDPR Compliant Analytics Framework](/blog/gdpr-compliant-analytics-framework)
- [Sealmetrics vs Google Analytics](/blog/google-analytics-vs-sealmetrics) — Full comparison with data accuracy benchmarks
- [Sealmetrics vs Plausible](/blog/sealmetrics-vs-plausible) — Privacy-first tools compared
- [What Is Consentless Analytics?](/security-privacy/consentless-analytics) — How it works under GDPR
- [Tracker Installation Guide](/implementation/tracker/installation) — Get started in under 5 minutes
- [CNIL Guidelines on Analytics (Official)](https://www.cnil.fr/en/cookies-and-other-trackers/rules/cookies/how-comply-cookies-and-trackers)
## Real-Time Analytics: AEPD and CNIL Consent Rules
URL: https://docs.sealmetrics.com/blog/real-time-tracking-consent
> **TL;DR** — Does real-time tracking need consent under GDPR? AEPD and CNIL rules on snapshots vs sub-daily windows, and how consentless analytics handles it.
Marketers love real-time dashboards. Seeing how many visitors are on your site right now feels like a direct line to your audience. But in the European Union, real-time tracking sits in a legal gray area that most analytics vendors either ignore or get wrong. The question is not whether real-time analytics is legal -- it is whether the specific implementation you use requires user consent under GDPR.
The answer depends on a distinction that regulators in Spain and France have drawn clearly but that few analytics platforms have internalized: the difference between a **snapshot** and a **window**. Get this wrong, and your "consentless" analytics setup may actually require a cookie banner you thought you had eliminated.
This article breaks down the regulatory framework from both the AEPD (Spain) and CNIL (France), explains the snapshot vs. window distinction with concrete examples, compares how major analytics tools handle real-time data, and shows why architectural decisions at the platform level determine your legal exposure.
## The Regulatory Framework for Consentless Analytics
Both the Spanish Data Protection Authority (AEPD) and the French Commission Nationale de l'Informatique et des Libertes (CNIL) have published detailed guidance on when web analytics can operate without user consent. These exemptions exist because regulators recognize that basic audience measurement serves a legitimate purpose -- but the exemptions come with strict technical requirements.
### AEPD: Spain's Daily Aggregation Rule
The AEPD's 2024 *Guia sobre cookies analiticas de medicion de audiencia* is the most prescriptive guidance any EU data protection authority has issued on analytics consent exemptions. It defines a clear set of conditions that analytics tools must meet to qualify for the audience measurement exemption.
The conditions include:
- **No cross-site tracking**: The tool must not track users across different websites or domains.
- **IP anonymization**: IP addresses must be anonymized before any storage or processing.
- **Data retention limits**: Analytics data cannot be retained indefinitely.
- **Aggregated, anonymous statistics**: The output must be statistical, not individual-level.
- **Daily aggregation minimum**: Audience metrics must be aggregated at a daily granularity -- not hourly, not by the minute, not by 30-minute windows.
That last point is the critical one for real-time analytics. The AEPD explicitly requires that audience measurement data be **aggregated at a daily level**. There is exactly one exception: page load performance metrics, which may be aggregated hourly because performance monitoring serves a distinct technical purpose.
This means that any analytics tool showing you reports like "visits in the last 30 minutes" or "hourly traffic breakdown" is producing sub-daily aggregations that fall outside the AEPD exemption. If those reports are generated from data collected without consent, the tool is non-compliant -- regardless of what its marketing page says about being "cookieless" or "privacy-first."
### CNIL: France's Exemption Criteria
The CNIL takes a slightly different but complementary approach. Its guidance on the analytics consent exemption focuses on three core principles:
- **Purpose limitation**: The analytics must be used strictly for audience measurement -- not advertising, not retargeting, not profiling.
- **Anonymity**: Data must be anonymized in a way that prevents re-identification of individual users.
- **No cross-site tracking**: Similar to AEPD, no data sharing across different sites or with third parties.
The CNIL does not prescribe a specific aggregation granularity the way the AEPD does. However, it requires that data processing result in **aggregate statistics only**, which implicitly rules out visitor-level logs and individual session tracking. Real-time snapshots of aggregate data (e.g., "142 users currently on site") are acceptable because they represent an ephemeral, anonymous aggregate. But storing sub-daily bucketed data for later analysis crosses the line into non-exempt territory.
The CNIL maintains a [list of tools](https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies-solutions-pour-les-outils-de-mesure-daudience) that qualify for its exemption, which provides a practical reference for what architectures regulators consider acceptable.
### Where Both Regulators Agree
Despite differences in specificity, AEPD and CNIL converge on the same fundamental principle: **consentless analytics must produce aggregate, anonymous statistics -- not individual-level data, and not fine-grained temporal breakdowns that could enable re-identification or behavioral analysis.**
The aggregation requirement is not arbitrary. Sub-daily windows create a risk that, combined with other data points (traffic source, device type, page sequence), an individual user could be identified from ostensibly "anonymous" analytics. Daily aggregation collapses enough data points together that this re-identification risk drops to a level regulators consider acceptable.
## Snapshot vs. Window: The Distinction That Determines Legality
The most important concept for understanding real-time analytics consent is the difference between a **snapshot** and a **window**. These terms are not formal regulatory language, but they precisely describe the two architectural approaches to real-time data -- and only one of them is compatible with consentless analytics.
### What Is a Snapshot?
A snapshot answers the question: "What is happening right now?"
Examples of snapshots:
- "There are 33 users currently on the site."
- "Today so far: 1,247 pageviews."
- "Current active pages: /pricing (12 users), /blog (8 users), /demo (5 users)."
A snapshot is **ephemeral**. It reflects the current state of the system at the moment you look at it. It is not stored as a time-series data point. When you refresh the dashboard, you get a new snapshot -- the previous one is gone. The "today so far" counter is a running daily aggregate, which aligns perfectly with the AEPD's daily aggregation requirement.
Snapshots are compatible with consentless analytics because they are inherently aggregated and inherently anonymous. You cannot reconstruct an individual user's journey from a series of snapshots. The data exists only in the moment, and only in aggregate form.
### What Is a Window?
A window answers the question: "What happened during this specific time period?"
Examples of windows:
- "Last 30 minutes: 87 visits."
- "Traffic between 14:00 and 14:30: 43 sessions."
- "Hourly breakdown: 9am (120 visits), 10am (156 visits), 11am (189 visits)."
A window is **stored**. To generate a report covering a specific sub-daily time period, the system must retain data at that granularity. This means the platform is creating and persisting sub-daily aggregations -- exactly what the AEPD says falls outside the consent exemption.
Even if each window shows aggregate numbers (not individual users), the existence of stored sub-daily buckets creates a structural problem. An hourly breakdown of traffic by page, combined with referral source data, starts to narrow down the anonymity set. Three visitors from LinkedIn to your pricing page between 2:15pm and 2:30pm is a small enough group that re-identification becomes plausible, especially when combined with CRM data.
### The Gray Area: "Active Users Right Now"
One metric sits at the boundary: the "active users right now" counter that many analytics tools display. Whether this is a snapshot or a window depends entirely on implementation:
- **Snapshot implementation**: The system counts currently active connections or sessions in memory. The number is never stored. When a user leaves, the count decrements. This is consentless-safe.
- **Window implementation**: The system counts unique users who sent at least one event in the last N minutes. This requires storing timestamped per-user events and querying them -- a sub-daily window by another name. This is not consentless-safe under AEPD.
The difference is invisible on the dashboard. Both approaches show "33 users right now." But the underlying architecture determines whether you need consent.
## How Analytics Tools Handle Real-Time Data
Not all analytics platforms approach real-time data the same way. Their architectural choices have direct consequences for GDPR compliance, and marketers should understand these differences before assuming any tool's privacy claims are accurate.
### GA4 with Consent Mode v2
Google Analytics 4 is a cookie-based tool that relies on consent for full functionality. Google's Consent Mode v2 attempts to model data from users who reject cookies, but this is estimation, not measurement. The real-time report in GA4 ("Users in last 30 minutes") is a classic window implementation -- it stores timestamped events and queries them for the last 30 minutes.
This design requires consent by default. With Consent Mode v2, Google claims to handle consent-denied users through behavioral modeling, but this approach has been [questioned by multiple DPAs](https://noyb.eu/en/noyb-files-gdpr-complaint-against-googles-new-consent-fraud), and the modeled data is not actual measurement. In practice, GA4 loses 15-60% of real visitor data in EU markets to consent rejection, depending on sector, brand strength and traffic mix.
### Matomo (Self-Hosted)
Matomo offers a "cookieless" mode and can be configured for some level of privacy compliance. However, Matomo's real-time report ("Visits in Real Time") displays individual visit logs with timestamps, pages visited, referral source, and location. This is visitor-level, sub-daily data -- the opposite of what AEPD requires for the consent exemption.
Even in cookieless mode, Matomo generates visitor logs that track individual browsing sessions. The data is detailed enough to potentially identify individuals, particularly in low-traffic scenarios. Matomo's real-time feature, as architected, does not qualify for the AEPD's audience measurement exemption.
### Plausible Analytics
Plausible takes a privacy-first approach and does not use cookies. Its "Current visitors" counter is a genuine snapshot -- it shows a real-time count without storing sub-daily bucketed data. However, Plausible does offer time-based filtering (last 30 minutes, last hour) in some report views, which edges into window territory.
Plausible's cookieless, first-party architecture is generally regarded as aligning with the CNIL's exemption criteria. Note that the CNIL retired its list of exemption-eligible tools in July 2025, replacing it with a self-assessment framework, so no tool — Plausible or Sealmetrics — can point to a current CNIL listing as proof. Whether Plausible fully satisfies the stricter AEPD daily aggregation rule depends on which specific features are used and how the data is stored.
### Sealmetrics
Sealmetrics was designed from the ground up to comply with both AEPD and CNIL requirements, including the daily aggregation rule. The architectural decisions are fundamental, not bolted on:
- **Real-time dashboard shows daily aggregates only.** You see "today so far" numbers that update in real time, but the underlying data is always aggregated at a daily level. There are no 30-minute windows, no hourly breakdowns, no sub-daily buckets.
- **No visitor logs.** There is no screen in the product that shows individual user sessions, navigation paths, or per-visitor timelines. The data model does not support it -- this is a deliberate architectural constraint, not a hidden feature.
- **No cookies and no fingerprinting.** Sealmetrics uses a [consentless tracking architecture](/security-privacy/how-consentless-works) that does not set cookies, does not store IP addresses, and does not generate device fingerprints.
- **Complete data capture.** Because no consent is required, there is no loss from banner rejection or ghosting — the 15-60% gap that cookie-based tools live with. Every visit is measured, providing the complete dataset that tools like GA4 cannot deliver in EU markets.
The result is that marketers get real-time visibility into their traffic without the exposure that comes with storing sub-daily data. You know how your site is performing today. You can see trends across days, weeks, and months. You just cannot generate a report titled "Traffic from 2pm to 3pm" -- and that constraint is what keeps the system compliant.
For more details on the technical architecture, see [how consentless tracking works](/security-privacy/how-consentless-works) and [tracker implementation](/implementation/tracker).
## Comparison: Real-Time Analytics Compliance
The following table summarizes how each tool handles the key factors that determine whether real-time analytics requires consent under AEPD and CNIL rules.
| Feature | GA4 + Consent Mode | Matomo (Cookieless) | Plausible | Sealmetrics |
|---|---|---|---|---|
| **Cookies required** | Yes | Optional | No | No |
| **Real-time counter** | Window (30 min) | Visitor log | Snapshot | Daily aggregate |
| **Sub-daily windows** | Yes | Yes | Limited | No |
| **Visitor-level logs** | Yes | Yes | No | No |
| **IP storage** | Yes (hashed) | Configurable | No | No |
| **AEPD daily aggregation** | No | No | Partial | Yes |
| **Meets CNIL exemption criteria** | No | Configurable | Likely | Yes (self-assessed) |
| **Data capture rate (EU)** | 40-85% | 40-85% | Higher, non-zero loss where consent applies | Complete |
| **Consent banner needed** | Yes | Depends | No | No |
## Technical Implementation: Why Architecture Matters
The difference between compliant and non-compliant real-time analytics is not about the dashboard -- it is about the data pipeline behind it. Two systems can show identical numbers on screen while having fundamentally different compliance profiles based on how the data is collected, stored, and queried.
### The Non-Compliant Pattern
A typical non-compliant architecture works like this:
1. **Event collection**: Each pageview or interaction generates a timestamped event with user identifiers (cookie ID, session ID, or fingerprint hash).
2. **Event storage**: Events are stored individually in a database with full timestamp precision.
3. **Real-time query**: The "last 30 minutes" report queries all events where `timestamp > now() - 30 minutes` and aggregates them on the fly.
4. **Result**: The stored data contains sub-daily, user-level records. Even if the dashboard shows aggregate numbers, the underlying data can be queried at any granularity.
This architecture fails the AEPD test because the raw data exists at sub-daily granularity. The daily aggregation must happen at the storage level, not just the display level.
### The Compliant Pattern
Sealmetrics implements a compliant architecture:
1. **Event collection**: Pageviews are captured via a lightweight, [cookieless tracker script](/implementation/tracker) that sends minimal data -- page URL, referrer, and a non-identifying session token.
2. **Immediate aggregation**: Events are aggregated into daily counters at the point of ingestion. No individual events are stored with sub-daily timestamps.
3. **Real-time display**: The dashboard reads the running daily aggregate, which updates in real time as new events arrive. The "today so far" number is always current, but the stored granularity is daily.
4. **Snapshot counters**: The "active users now" metric uses an in-memory counter that tracks current connections. This counter is ephemeral -- it is never persisted to the database.
The infrastructure uses Go and ClickHouse, which provides the performance needed to aggregate at ingestion time without sacrificing real-time responsiveness. The aggregation is not a batch job that runs at midnight -- it happens continuously as data arrives.
For details on Sealmetrics' compliance architecture, see the [compliance overview](/compliance) and [consentless analytics documentation](/security-privacy/consentless-analytics).
## Practical Implications for Marketing Teams
Understanding the snapshot vs. window distinction has practical consequences beyond legal compliance.
### What You Can Do Without Consent
Under a properly implemented consentless analytics setup that meets AEPD and CNIL requirements, you can:
- **Monitor today's traffic in real time.** Daily aggregates update continuously, giving you a live view of pageviews, sessions, and engagement for the current day.
- **Compare daily performance.** Day-over-day, week-over-week, and month-over-month comparisons are all based on daily aggregates, which stay inside the consent exemption.
- **Identify top pages and traffic sources today.** You know which content is performing right now, aggregated at the daily level.
- **Track campaign launches on day one.** You can see whether a campaign is driving traffic from the moment it goes live, without waiting for next-day reporting.
- **Capture every visitor.** No consent banner means no consent-driven data loss. Every visit counts.
### What Requires Consent
If you need any of the following, you must implement a consent mechanism (cookie banner) and accept the associated data loss:
- **Intra-day time breakdowns.** Hourly traffic charts, "last 30 minutes" reports, or time-of-day analysis.
- **Individual visitor journeys.** Session recordings, user-level page sequences, or individual navigation paths.
- **Cross-session identification.** Recognizing returning visitors across multiple visits using persistent identifiers.
- **Cross-site tracking.** Following users across different domains or websites.
### The Trade-Off Is Worth It
For most marketing use cases, daily aggregated data provides everything needed to make decisions. You do not need to know that 14 people visited your pricing page between 2:15pm and 2:45pm. You need to know that your pricing page had 340 visits today, up 12% from yesterday, with 60% arriving from organic search.
The trade-off is clear: give up sub-daily granularity in exchange for complete data capture and a position that doesn't depend on a consent record. For any business operating in EU markets, the math strongly favors complete data over granular-but-partial data.
## Bottom Line
Real-time analytics is not inherently illegal under GDPR. The legality depends entirely on how "real-time" is implemented at the architectural level.
**Snapshots and daily aggregates** -- showing current counters and today's running totals -- are compatible with the AEPD and CNIL consent exemptions for audience measurement. They produce anonymous, aggregate statistics that cannot be used to identify or profile individuals.
**Sub-daily windows and visitor logs** -- showing time-bucketed reports, hourly breakdowns, or individual session data -- fall outside the consent exemption. Under AEPD rules, these require a cookie banner and user consent, which means accepting 15-60% data loss in EU markets.
Sealmetrics is built on this distinction. The platform delivers real-time visibility into your traffic with complete data capture, while meeting both the AEPD and CNIL criteria for consent-exempt audience measurement. No cookies, no consent banners, no consent-driven data loss.
If your current analytics setup shows you "last 30 minutes" reports without asking for consent, it is time to reconsider your compliance posture. [See how Sealmetrics works](https://sealmetrics.com) and start capturing the traffic you are currently losing.
## Cookieless Analytics: Complete Guide 2026
URL: https://docs.sealmetrics.com/blog/cookieless-analytics-guide
> **TL;DR** — Cookieless analytics measures every visit without consent banners, closing the 15-60% gap cookie tools lose. Guide to implementation, GDPR, and comparisons.
**Last Updated**: March 10, 2026
## Introduction
Cookieless analytics has emerged as the solution to this data loss crisis. Unlike traditional cookie-based platforms like Google Analytics — which surrender 15-60% of their data to banner ghosting and rejection — cookieless analytics measures every visit without consent banners, cookies, or personal identifiers like IP addresses.
This complete guide explains how cookieless analytics works, why it's GDPR compliant without consent, and how platforms like Sealmetrics provide businesses with accurate, complete data while respecting user privacy.
### Key Takeaways
- **Cookieless analytics measures every visit** without cookie consent banners, closing a 15-60% gap
- **No legal basis is required at all** when no personal data is stored: the dataset falls outside the GDPR's material scope (Recital 26), and ePrivacy Article 5(3) is never triggered because nothing is written to the device
- **Session-based tracking** replaces cookies with temporary identifiers that reset after each visit
- **Sealmetrics provides true cookieless analytics** without storing IP addresses (unlike competitors)
---
## What is Cookieless Analytics?
Cookieless analytics is a web analytics methodology that tracks website visitors and their behavior without using cookies or requiring user consent. Instead of placing tracking cookies in users' browsers, cookieless analytics platforms use alternative identification methods that don't qualify as "cookies" under the ePrivacy Directive Article 5(3).
The core principle of cookieless analytics is **session-based tracking**. Rather than identifying returning visitors across multiple sessions (which requires cookies), cookieless analytics treats each visit as an independent session with a temporary identifier that expires when the user closes their browser or after a period of inactivity.
### Why Cookieless Analytics Matters in 2026
Traditional cookie-based analytics faces three critical challenges:
1. **Massive data loss**: cookie rejection rates run from around 40% in the US to 87% in Germany, translating into 15-60% of your data never reaching your reports
2. **Legal complexity**: Cookie consent requirements under GDPR and ePrivacy create compliance burdens
3. **Poor user experience**: Consent banners frustrate users and increase bounce rates by 10-15%
Cookieless analytics solves all three problems by eliminating cookies entirely from the tracking process.
---
## How Cookie-Based Analytics Creates Data Loss
To understand why cookieless analytics is necessary, we must first understand how traditional analytics fails.
### The Cookie Consent Problem
Under the ePrivacy Directive Article 5(3), websites must obtain explicit user consent before placing tracking cookies. This means:
- **Users see a consent banner** before any tracking begins
- **Many reject it, and more ignore it entirely** — ghosting is usually the larger group
- **Both become invisible** to your analytics
- **Your data represents 40-85% of actual traffic**, depending on your sector, brand strength and traffic sources
One caution: a rejection rate is not a data loss rate. Rejection is measured among the people who engaged with the banner, and Consent Mode v2 models some of the unconsented traffic back in as estimates. Net of that, Google Analytics 4, Matomo in default mode, and most traditional analytics tools lose 15-60% of EU traffic data because they rely on cookies that users decline or ignore.
### Real-World Impact: E-commerce Example
Consider an online store with 10,000 monthly visitors in Germany — a privacy-sensitive market, so assume it sits toward the harder end of the range:
**With cookie-based analytics** (GA4):
- Consent banner shown: 10,000 users
- **Measured users: ~4,500 (45% capture rate)**
- **Invisible users: ~5,500 (55% data loss)**
**With cookieless analytics** (Sealmetrics):
- No consent banner required
- **Measured users: 10,000**
- **Invisible users: none beyond the JavaScript blockers no tool can see**
The business with cookieless analytics has more than **twice the data** to make decisions with. And the volume is the lesser half of the benefit: the 5,500 missing visitors were not a random sample, so their absence doesn't merely shrink the numbers, it bends them.
---
## How Cookieless Analytics Works: Technical Deep Dive
Cookieless analytics platforms use several technical approaches to track visitors without cookies. The most privacy-respecting method is **session-based tracking with temporary identifiers**.
### Session-Based Tracking Methodology
Sealmetrics uses a dual-system approach that provides complete data without requiring consent:
#### System 1: Session ID Tracking
For users with JavaScript enabled (95%+ of visitors):
1. **Visitor arrives** at your website
2. **Temporary session ID generated** in browser memory (not stored as cookie)
3. **Events tracked** with this session ID throughout the visit
4. **Session expires** when browser closes or after ~2 hours of inactivity
5. **New session ID** generated on next visit (user is not tracked across visits)
**Key point**: The session ID exists only in browser memory during the active session. It never persists as a cookie, so it doesn't require consent under ePrivacy Article 5(3).
#### System 2: Isolated Hits Tracking
For users without JavaScript or with ad blockers (5% of visitors):
1. **Each pageview tracked independently** without any identifier
2. **No cross-page session tracking** (cannot connect pages to same visit)
3. **Aggregated statistics only** (pageviews, referrers, devices)
This dual approach keeps Sealmetrics measuring **regardless of browser configuration** — there is no consent gate for any of it to fail at.
### What Makes Tracking "Cookieless"?
According to CNIL's 2020 guidance on analytics, tracking is considered cookieless if:
1. **No persistent identifiers** stored in the browser
2. **No cross-session tracking** of individual users
3. **No combination with other data** to re-identify users
4. **Limited data retention** (CNIL sets a 25-month ceiling; Sealmetrics applies a stricter 24 months)
Sealmetrics meets all four criteria:
- **Session IDs exist only during active sessions**
- **Users cannot be tracked across visits**
- **No IP addresses stored** (unlike Plausible/Matomo which hash IPs)
- **Aggregates retained 24 months**, documented and inside the CNIL ceiling
---
## GDPR Compliance: Why Cookieless Analytics Doesn't Need Consent
The most common question about cookieless analytics: **"If you're tracking users, doesn't that require consent under GDPR?"**
Answer: **No, if properly implemented.**
### The Prior Question: Is There Personal Data at All?
Most vendors answer the consent question by naming a legal basis — usually Article 6(1)(f), legitimate interest. That is the wrong move for a genuinely cookieless tool, because naming any Article 6 basis concedes that you *are* processing personal data and are merely entitled to. It hands away the argument you were trying to win.
**GDPR Recital 26** puts it directly: the principles of data protection do not apply to anonymous information — information which does not relate to an identified or identifiable natural person. If your analytics stores no IP address (hashed or otherwise), no user ID and no cross-session identifier, the dataset falls outside the *material scope* of the Regulation. Article 6 is never reached, because there is no personal data for it to govern.
So the honest answer isn't "we have a good legal basis." It's:
1. **Nothing stored identifies a person**: no IPs, no persistent identifiers, no cross-session correlation
2. **Nothing is written to or read from the device**: so ePrivacy Article 5(3), the rule that actually mandates banners, is never triggered
3. **Therefore no Article 6 basis is required**, and no consent record needs to exist
The one place Article 6(1)(f) does correctly apply is much narrower: the transient, in-memory handling of an IP for security and anti-abuse checks, which Recital 49 addresses. That IP is never written to storage and never reaches the analytics dataset.
### CNIL Guidance on Cookieless Analytics
In July 2020, CNIL (the French data protection authority) published guidance explicitly allowing certain analytics methods without consent:
> "Audience measurement tools that are used to obtain statistics on the use of a website or mobile application can be exempted from consent if they meet certain conditions."
These conditions include:
- Use exclusively for statistical purposes
- No cross-site tracking
- No combination with other processing
- Limited data retention (25-month ceiling; tracker lifetime capped at 13 months)
- IP address not stored or anonymized
**Sealmetrics meets all CNIL requirements** by design. Unlike Plausible and Matomo (which hash and store IP addresses), Sealmetrics never stores IP addresses at all. Worth being precise: CNIL publishes criteria, it does not certify or approve individual analytics tools — no supervisory authority does. What follows is our own assessment against those criteria, not a regulatory endorsement.
### The ePrivacy Directive Exception
The ePrivacy Directive Article 5(3) requires consent for cookies. However, it includes an exception:
> "The storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is allowed on condition that the subscriber or user concerned is provided with clear and comprehensive information, and is provided with the right to refuse such storage or access."
**Cookieless analytics doesn't trigger this requirement** because:
1. Session IDs stored only in memory (not persistent storage)
2. IDs expire when browser closes
3. No information "stored" in the traditional sense
This is why Sealmetrics requires no consent banner while cookie-based tools do.
---
## Cookieless Analytics vs Cookie-Based: Complete Comparison
| Feature | Google Analytics 4 | Plausible Analytics | Matomo | Simple Analytics | **Sealmetrics** |
|---------|-------------------|---------------------|--------|------------------|-----------------|
| **Requires Cookies** | Yes | No | No (cookieless mode) | No | **No** |
| **Requires Consent Banner** | Yes | Depends on config | Depends on config | No | **No** |
| **Stores IP Addresses** | Yes (full) | Yes (hashed) | Yes (hashed) | Yes (hashed) | **Never** |
| **Consent-driven data loss** | 15-60% | Lower, non-zero where consent applies | Lower, non-zero where consent applies | None | **None** |
| **Cross-Session Tracking** | Yes | No | Yes (with consent) | No | **No** |
| **GDPR Legal Basis** | Consent required | Legitimate interest | Consent or LI | Legitimate interest | **None required — no personal data (Recital 26)** |
| **CNIL Compliant** | No | Partial | Partial | Yes | **Yes** |
| **Setup Complexity** | High (30-60 min) | Medium (10 min) | High (20-30 min) | Low (5 min) | **Very Low (2 min)** |
| **Data Retention** | 14 months | Unlimited | Unlimited | Unlimited | **24 months** |
| **Real-Time Data** | Delayed | Yes | Yes | Yes | **Yes** |
| **Price (10k pageviews/mo)** | Free (but data loss) | $9/mo | $29/mo | $19/mo | **$49/mo** |
| **Consentless Analytics** | No | No | No | No | **Yes** |
### Key Insight: Not All "Cookieless" is Equal
Many analytics tools claim to be "cookieless" or "privacy-first," but still:
- **Hash and store IP addresses** (Plausible, Matomo, Simple Analytics)
- **Use localStorage instead of cookies** (technically still requires consent)
- **Implement fingerprinting** (clearly violates GDPR)
**Sealmetrics is the only major platform** that provides true consentless analytics by:
1. Never storing IP addresses at all (not even hashed)
2. Using only session-based tracking (no persistent identifiers)
3. Meeting all CNIL requirements without configuration changes
---
## Benefits of Cookieless Analytics
### 1. Complete Data Capture
**The biggest advantage**: you see all your visitors, not just the 40-85% a consent banner lets through — and not a self-selected 40-85% at that.
**Business impact**:
- More accurate conversion rates
- Better understanding of user journeys
- Improved marketing attribution
- No blind spots in your data
### 2. No Consent Banners Required
**User experience improvement**:
- No annoying pop-ups
- Faster page loads (no consent management script)
- Lower bounce rates (10-15% decrease when removing banners)
- Better mobile experience
**Legal simplification**:
- No consent management platform needed ($0-500/month saved)
- Simpler privacy policy
- Easier DPO approval process
- Lower legal risk
### 3. GDPR Compliant by Default
**Automatic compliance**:
- No Article 6 legal basis required: no personal data stored (Recital 26)
- ePrivacy Article 5(3) not triggered: nothing written to or read from the device
- Meets CNIL cookieless exemption criteria
- Data minimization principle satisfied
- No cross-border data transfer issues (if EU-hosted)
### 4. Better Performance
**Technical advantages**:
- Smaller tracking script (Sealmetrics: 2.1 KB vs GA4: 45 KB)
- No third-party cookies blocking
- Works with ad blockers (partially)
- Faster page load times
---
## How to Choose a Cookieless Analytics Platform
When evaluating cookieless analytics tools, ask these questions:
### Question 1: Does it truly require zero consent?
**Red flag**: If the provider says "cookieless but you should still show a banner to be safe," it's not truly compliant.
**Sealmetrics answer**: No consent banner required. Period.
### Question 2: Does it store IP addresses?
**Red flag**: Hashing IPs doesn't make them anonymous under GDPR (per Breyer vs Germany ECJ ruling).
**Sealmetrics answer**: We never store, hash, or process IP addresses. Ever.
### Question 3: What's the data retention period?
**CNIL recommendation**: 13 months maximum for cookieless analytics.
**Sealmetrics approach**: 24 months on aggregates, documented and available to customers, inside CNIL's 25-month ceiling.
### Question 4: Can you track across sessions?
**The rule**: cross-session tracking needs a persistent identifier, which puts you squarely back inside ePrivacy Article 5(3) and the GDPR.
**Sealmetrics approach**: We don't track users across sessions. Each visit is independent.
### Question 5: What's the data processing location?
**GDPR concern**: Transfers to US or other third countries require additional safeguards post-Schrems II.
**Sealmetrics solution**: EU-hosted infrastructure in Dublin, Ireland (no data transfers outside EU).
### Question 6: How complex is implementation?
**Time consideration**: Some tools require extensive configuration to be truly cookieless.
**Sealmetrics reality**: 2-minute setup, cookieless by default, no configuration needed.
---
## Implementation Guide: Switching to Cookieless Analytics
### Step 1: Choose Your Platform
Based on your needs:
**For most businesses**: Sealmetrics
- True consentless analytics
- No IP storage
- Simple setup
- DPO-approved approach
**For open-source requirement**: Matomo (cookieless mode)
- Self-hosted option
- More complex setup
- Still hashes IPs
**For basic needs**: Simple Analytics
- Very simple interface
- Limited features
- Still hashes IPs
### Step 2: Set Up Tracking (Sealmetrics Example)
```html
```
**Setup time**: 2 minutes
### Step 3: Verify Data Collection
1. Visit your website in incognito mode
2. Check Sealmetrics dashboard for real-time visitor
3. Verify events are tracking correctly
4. Confirm no consent banner appears
### Step 4: Remove Old Analytics (If Migrating)
Before removing Google Analytics:
1. **Export historical data** (Download reports, set up BigQuery export)
2. **Run parallel tracking** for 1 week (both GA4 and Sealmetrics)
3. **Compare data quality** (expect Sealmetrics to show meaningfully more traffic — the gap will land somewhere in the 15-60% range)
4. **Remove GA4 tracking code**
5. **Remove consent banner** (if only used for analytics)
### Step 5: Update Privacy Policy
Replace cookie consent section with:
> "We use Sealmetrics, a cookieless analytics platform, to understand how visitors use our website. Sealmetrics does not use cookies, does not store IP addresses, stores nothing on your device, and cannot track you across different websites or visits. Because no personal data is retained, this measurement falls outside the scope of the GDPR and requires no consent. Data is retained for 24 months and stored exclusively in the EU (Dublin, Ireland). You can opt out at any time using our opt-out page."
**Template available**: Sealmetrics provides a complete privacy policy template to all customers.
---
## Common Misconceptions About Cookieless Analytics
### Misconception 1: "Cookieless means less accurate data"
**Reality**: cookieless analytics is MORE accurate, because you measure every visit rather than the 40-85% a banner lets through — and that 40-85% is not a random sample of your audience.
**Data comparison** (German e-commerce site, October 2024):
- Google Analytics 4: 14,619 sessions
- Sealmetrics (same site, same period): 32,487 sessions
- **A 55% shortfall in GA4** — toward the harder end of the range, which is what you'd expect in a privacy-sensitive market
### Misconception 2: "You can't track conversions without cookies"
**Reality**: Cookieless analytics tracks conversions perfectly within a session. What you can't do is attribute conversions to specific users across multiple sessions—but GDPR makes that difficult anyway without consent.
**Example**: User visits Monday, returns Tuesday and converts. Cookie-based analytics (with consent) can connect these sessions. Cookieless analytics sees two separate sessions, but still captures the conversion. Attribution is different, not missing.
### Misconception 3: "Cookieless analytics requires consent in some countries"
**Reality**: if properly implemented (like Sealmetrics), cookieless analytics requires no consent in any EU country — because ePrivacy Article 5(3) is never triggered and, with no personal data stored, the GDPR's material scope is never engaged.
**Country-specific notes**:
- **Germany (TTDSG)**: Cookieless compliant, no consent needed
- **France (CNIL)**: Explicit guidance allowing cookieless without consent
- **Spain (AEPD)**: Follows CNIL interpretation
- **Netherlands**: Cookieless exempt from cookie law
### Misconception 4: "All analytics tools that claim 'no cookies' are equal"
**Reality**: Many "cookieless" tools still:
- Store hashed IP addresses (not GDPR anonymous)
- Use localStorage (may still require consent)
- Implement fingerprinting (illegal under GDPR)
- Require consent "to be safe"
**Only Sealmetrics provides** true consentless analytics with zero IP storage and no persistent identifiers of any kind.
---
## The Future of Web Analytics is Cookieless
Browser vendors are killing third-party cookies:
- **Safari**: Intelligent Tracking Prevention (ITP) blocks third-party cookies since 2017
- **Firefox**: Enhanced Tracking Protection (ETP) blocks third-party cookies by default since 2019
- **Chrome**: Third-party cookie deprecation planned for Q3 2024 (ongoing)
- **Edge**: Following Chrome's timeline
Even first-party cookies face increasing restrictions:
- **Safari ITP**: First-party cookies limited to 7 days storage
- **Firefox ETP**: Partitioned first-party cookies in some cases
- **Brave**: Aggressive cookie blocking by default
**The trend is clear**: Cookie-based tracking is ending, regardless of consent. Businesses that wait to adopt cookieless analytics will continue losing data.
### Why Cookieless Analytics is the Answer
Cookieless analytics solves both privacy concerns AND data accuracy:
1. **Privacy**: No persistent tracking, no IP storage, no cross-site tracking
2. **Accuracy**: every visit measured, none of the 15-60% consent gap
3. **Compliance**: no personal data stored, so no legal basis and no consent needed
4. **Performance**: Smaller scripts, faster loads, no consent management overhead
**Consentless analytics** (Sealmetrics' approach) takes this further by designing the entire system to require zero consent under any circumstance.
---
## Frequently Asked Questions
### 1. Is cookieless analytics legal under GDPR?
Yes — and note that it doesn't rely on a legal basis to get there. When properly implemented, no personal data is stored, so the dataset falls outside the GDPR's material scope (Recital 26), and nothing is written to the device, so ePrivacy Article 5(3) isn't triggered. CNIL's 2020 guidance confirms that analytics meeting specific criteria do not require consent.
### 2. Do I need a consent banner with cookieless analytics?
No. If your analytics tool is truly cookieless (like Sealmetrics), you don't need a consent banner for analytics tracking. You may still need one if you use other cookies (advertising, social media, etc.).
### 3. How does cookieless analytics identify returning visitors?
It doesn't. True cookieless analytics (like Sealmetrics) treats each visit as independent. Each entrance is counted as new data — there is no returning-visitor metric, because no identifier links one visit to another.
### 4. Can cookieless analytics track conversions?
Yes. Cookieless analytics tracks conversions perfectly within a session. If a user visits and converts in the same session, you see the complete journey. If they return days later and convert, you see the conversion but cannot attribute it to the first visit.
### 5. What's the difference between cookieless and cookie-free?
These terms are used interchangeably. Both mean analytics that doesn't use cookies. However, some "cookie-free" tools still use other persistent identifiers (localStorage, fingerprinting) which may require consent.
### 6. Does cookieless analytics work with ad blockers?
Partially. Sealmetrics' dual-system approach means:
- JavaScript-enabled users: Tracked normally (session-based)
- Ad blocker users: Tracked as isolated hits (no session connection)
- Result: pageviews still captured, though session continuity is lost for ad blocker users (~5% of traffic)
### 7. How accurate is cookieless analytics compared to Google Analytics?
More accurate for traffic volume: complete capture against Google Analytics' 40-85%. Less detailed for user journey tracking across sessions. Overall, cookieless provides more complete data within the constraints of modern privacy regulations.
### 8. Can I use cookieless analytics and Google Analytics together?
Yes, but it's redundant. Most businesses find that cookieless analytics provides all the data they need without GA's complexity and data loss. During migration, running both for 1-2 weeks helps verify data accuracy.
### 9. Does cookieless analytics affect SEO?
No direct effect. However, removing consent banners (made possible by cookieless analytics) can reduce bounce rates by 10-15%, which may indirectly benefit SEO through improved user engagement metrics.
### 10. What about data retention with cookieless analytics?
CNIL caps tracker lifetime at 13 months and sets a 25-month ceiling on the resulting data. Sealmetrics retains aggregates for 24 months, documented as necessary for year-over-year comparison — and what is retained contains no personal identifiers.
### 11. Is hashing IP addresses enough to be "cookieless"?
No. Hashing IP addresses doesn't make them anonymous under GDPR (per Breyer vs Germany ECJ ruling). True cookieless analytics (like Sealmetrics) never stores IP addresses at all—not even hashed.
### 12. How does cookieless analytics handle bot traffic?
Sealmetrics filters obvious bots (search engine crawlers, monitoring services) before tracking. Session-based tracking also naturally excludes most bot traffic since bots typically don't execute JavaScript properly.
### 13. Can I export data from cookieless analytics?
Yes. Sealmetrics provides CSV exports and API access for raw data. You own your data completely and can export or delete it at any time.
### 14. What happens if GDPR rules change?
Sealmetrics is designed to be compliant with the strictest interpretation of current GDPR, ePrivacy, and CNIL guidance. If regulations change, we update our approach immediately. Cookie-based tools are much more vulnerable to regulatory changes.
### 15. How does cookieless analytics work for mobile apps?
Mobile apps don't use cookies, so "cookieless" is a web-specific term. For mobile apps, the equivalent is identifier-free tracking. Sealmetrics is currently a web analytics platform; for mobile apps, similar privacy-first principles apply: no device ID storage, no cross-session tracking, session-based analytics only.
---
## Conclusion: The Cookieless Analytics Advantage
Cookie-based web analytics is dying from two forces:
1. **Legal pressure**: GDPR, ePrivacy, and aggressive enforcement make cookie consent increasingly complex
2. **Technical pressure**: Browsers are blocking cookies regardless of consent
Businesses that continue using cookie-based analytics face:
- **15-60% data loss** from banner ghosting and rejection
- **Legal complexity** managing consent across regions
- **Poor user experience** from consent banners
- **Technical unreliability** as browsers block more cookies
**Cookieless analytics solves all these problems** by eliminating cookies entirely.
**Sealmetrics goes further** with true consentless analytics:
- **Every visit measured** (no consent gap)
- **Zero consent required** (nothing stored on the device, no personal data retained)
- **No IP storage** (more private than any competitor)
- **2-minute setup** (cookieless by default)
- **EU-hosted** (no data transfers, no Schrems II concerns)
The future of web analytics is cookieless. The question isn't whether to make the switch, but how quickly you can implement it.
---
## Additional Resources
**Learn more about cookieless analytics**:
- [How Cookieless Tracking Works: Technical Deep Dive](/blog/cookieless-tracking-technical-deep-dive)
- [GDPR Compliant Analytics: Complete Framework](/blog/gdpr-compliant-analytics-framework)
- [Migration Guide: Google Analytics 4 to Sealmetrics](/ga4-migration)
**Legal and compliance**:
- [GDPR Official Text](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [CNIL Guidance on Analytics](https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications) (July 2020)
- [ePrivacy Directive](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32002L0058)
**Try Sealmetrics**:
- [Start Free Trial](https://sealmetrics.com) - 14-day free trial, card not charged during trial
- [Live Demo](https://sealmetrics.com/demo) - See cookieless analytics in action
- [Documentation](https://docs.sealmetrics.com) - Complete implementation guides
---
**About the Author**: This guide was written by the Sealmetrics team, creators of the leading consentless analytics platform. We believe accurate data and user privacy are not opposites—they're requirements for modern web analytics.
**Last Updated**: March 10, 2026
---
*Sealmetrics measures all of your website traffic without cookies, consent banners, or IP address storage. Privacy by architecture, trusted by privacy-conscious businesses across Europe.*
## Key Differentiators vs Google Analytics 4
| Feature | Sealmetrics | Google Analytics 4 |
|---------|-------------|-------------------|
| Consent Required | No | Yes |
| Cookie Banners | Not needed | Required in EU |
| Data Completeness (EU) | 100% | 13-40% |
| IP Storage | Never | Configurable |
| Data Location | EU only (Dublin) | Global |
| GDPR Compliance | By design | Requires configuration |
| Ad Blocker Resistant | Yes | No |
| Personal Data | Never collected | Collected |
## Support
- Documentation: https://docs.sealmetrics.com
- Email: support@sealmetrics.com
- Dashboard: https://app.sealmetrics.com