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 | Minimal and pseudonymised — a session identifier that rotates daily and is unrecoverable after rotation; no persistent identifiers | In practice cannot be matched to a person (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 nothing on the device and no data that identifies anyone, and no persistent identifiers:
- No IP addresses stored (used ephemerally in memory for anti-bot protection, never persisted)
- No cookies or terminal storage
- No user IDs, persistent device IDs, or stored fingerprints
- No cross-session identifiers — the session identifier is a hash computed in the browser that is never stored as sent: the server re-keys it with a daily salt destroyed on rotation, and the resulting daily pseudonym is purged after 1 day, so it cannot recognize a returning visitor
- Country derived from the browser timezone, not from the IP
- User agent used in flight only; just the derived browser/OS/device categories are kept, in aggregates, never joined to any identity
The session identifier is a pseudonym (personal data under GDPR) only while the day's salt exists; after the daily rotation it cannot be reconstructed, not even by Sealmetrics. A visitor has no way to supply it, and nothing else in the data points to them, so in practice 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 practical 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 once the day has passed: the only per-visitor value, a daily session pseudonym, is purged after 1 day and its salt is destroyed, so nothing stored can be matched to a device or person.
This is not a workaround to avoid answering DSARs. It is the direct consequence of collecting only minimal, pseudonymised data that becomes unrecoverable daily: data minimization taken to its logical conclusion.
What this means in practice for your DPO
When a visitor rights request mentions your website analytics:
- You can respond substantively — explain that your analytics tool (Sealmetrics) stores nothing on the visitor's device, no IP and no persistent identifier, and that its session identifier rotates daily and cannot be reconstructed, so in practice no stored record can be attributed to the requester (GDPR Art. 11).
- 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.
- Document the reasoning — reference your records of processing (ROPA) entry for Sealmetrics, which should describe the tool as processing pseudonymised data under legitimate interest (Art. 6(1)(f)), per-hit data kept 1 day, with aggregated reports. This page and What We Track vs What We Don't can be attached as supporting documentation.
- 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.
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, 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. 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 | In practice no record can be matched to them — the identifier is unrecoverable after the daily rotation (GDPR Art. 11) |
| Visitor asks for erasure of their analytics data | Same — no record can be located; per-hit data is purged after 1 day anyway |
| Visitor objects to processing | The right applies (legitimate interest), but past records cannot be matched; honour it going forward by not loading the tracker for them — visitors can also 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 |
Primary sources
- GDPR Art. 11 — no obligation to acquire extra data just to identify a data subject — eur-lex
- GDPR Art. 12 — facilitating rights requests and the one-month response timeline — eur-lex
- GDPR Arts. 15–22 — the individual rights this page maps against analytics data — eur-lex
- GDPR Recital 26 — pseudonymised data is personal data; anonymous information falls outside the Regulation — eur-lex
Related documentation
- What We Track vs What We Don't — the full inventory of what is (and is not) collected
- Subprocessors — who touches what data, and where
- Data Location & Retention — storage location and deletion schedules
- Why Sealmetrics Can Measure Without Consent — the consent-free model behind this analysis
- CNIL Self-Assessment — configuration rules that keep PII out of the system