GDPR-Compliant Web Analytics: What the Rules Actually Require

> This article is general information for engineers and product teams, not legal advice. Requirements vary by jurisdiction and by how you deploy. Confirm your specific situation with qualified counsel.

Two separate rules, often conflated

Most confusion about "GDPR-compliant analytics" comes from treating one question as two, or two as one.

The ePrivacy rule (the "cookie rule") governs storing or accessing information on a user's device. It is triggered by the storage itself, regardless of whether the stored data is personal. Consent is generally required unless the storage is strictly necessary for a service the user requested.

The GDPR governs processing personal data. It is triggered by the data being about an identifiable person, wherever it is stored.

You can be subject to one, both, or neither. A tool that stores nothing on the device but records IP addresses server-side escapes the first and is squarely inside the second.

The "no cookies means no banner" claim

This is the most common overstatement in the privacy-analytics market, and it is worth being precise about.

The ePrivacy rule covers storing or accessing information on terminal equipment. Several data protection authorities have taken the position that this covers localStorage and similar mechanisms, not only HTTP cookies. So "we use localStorage instead of cookies" is not automatically a consent exemption.

What genuinely reduces the question is storing nothing on the device at all — deriving a visitor identifier server-side from a rotating salt, with nothing written to the browser. Some regulators have published guidance describing conditions under which certain audience-measurement analytics may be exempt from consent; those conditions are specific and vary by country.

The honest position: not storing on the device and not retaining identifiers puts you in a much better place, and whether a banner is required is still a question for your counsel and your jurisdiction.

Lawful basis under GDPR

If you process personal data, you need a lawful basis. For analytics the realistic options are:

• Consent — explicit, informed, freely given, as easy to withdraw as to give. Required if you are doing anything resembling profiling or cross-site tracking.
• Legitimate interests — available for genuinely limited, privacy-protective measurement, and requires a documented Legitimate Interests Assessment balancing your interest against the user's rights. It is not a checkbox; it is a document you write and keep.

If you have designed the data out — no IPs, no cross-site linkage, no device storage, coarse geography — you may not be processing personal data at all, which is the strongest position available. That is a design outcome, not a policy one.

Data minimisation in practice

Article 5 requires data be adequate, relevant and limited to what is necessary. Translated into schema decisions:

Every row of that table is a design decision you make once. Retroactive minimisation means deleting data you should never have collected.

Storage limitation

Personal data must not be kept longer than necessary, and "necessary" must be a period you can justify. Implement it as an enforced job, not a policy document:

DELETE FROM events WHERE timestamp < now() - INTERVAL '14 months';

Aggregate into rollups first so trend history survives without retaining event-level rows. And apply the same window to backups and logs — a 14-month retention policy is void if you hold three years of nightly dumps, or if your reverse proxy is quietly logging IPs to disk.

International transfers

Chapter V restricts sending personal data outside the EEA without an adequate safeguard. Using a US-based analytics SaaS has been the subject of several national DPA decisions concerning EU-US transfers, and the legal framework here has changed more than once.

Self-hosting removes the question entirely. If the data never leaves a server you control in a region you chose, there is no transfer to assess, no processor agreement to negotiate, and no dependency on the current state of an adequacy decision. This is one of the strongest practical arguments for self-hosted analytics, and it is structural rather than contractual.

Data subject rights

Even with minimal data, be able to answer:

• Access / portability — what do you hold about this person? With rotating pseudonymous IDs the honest answer is often "we cannot identify you in our data," which is a valid response under Article 11 if genuinely true.
• Erasure — you must be able to delete. If you cannot link data to a person, you cannot delete selectively, and you should say so plainly rather than implying a capability you lack.
• Objection — honour DNT and GPC signals, server-side as well as client-side.

Do not claim you can service a right that your architecture makes impossible. Explain the architecture instead.

Records and documentation

Keep, and actually maintain:

• A record of processing activities (Article 30) covering analytics.
• A Legitimate Interests Assessment, if that is your basis.
• A privacy policy that names the tool, the data, the retention period, and the basis.
• A DPA with any processor. Self-hosting means there is no processor for this data — one fewer agreement to maintain.

Frequently asked questions

Does removing cookies make me GDPR compliant?

No. Two separate rules are being conflated: the ePrivacy storage rule governs cookies and triggers consent banners, while GDPR governs personal data regardless of how it is stored. Dropping cookies resolves the first, not the second.

Is an IP address personal data under GDPR?

Yes — European case law has repeatedly held that IP addresses are personal data because they can identify a person when combined with other information. This is why not storing them at all is the cleanest position.

What lawful basis applies to analytics?

Legitimate interest is usually the appropriate basis for privacy-preserving, aggregate analytics, provided you document a balancing test. Consent is required once tracking becomes cross-site or identifies individuals.

Does self-hosting solve international transfer problems?

It solves them if you host inside your own jurisdiction, because there is no transfer. Self-hosting on a US-owned cloud region is a more nuanced question than it first appears.

What about data subject access and deletion requests?

You still owe them, but properly pseudonymous analytics often cannot link a request to any row — and being unable to identify someone is a legitimate response under Article 11, provided you can explain the design.

A practical checklist

• [ ] Nothing written to the visitor's device, or a documented basis for what is
• [ ] No IP addresses stored anywhere, including proxy and application logs
• [ ] User agent parsed and discarded
• [ ] Query strings stripped; referrer reduced to host
• [ ] Country-level geography only
• [ ] Visitor IDs pseudonymous with a rotating, unpersisted salt
• [ ] Retention window enforced by a monitored scheduled job
• [ ] Backups and logs on the same retention window
• [ ] Data stays in a region you chose (self-hosting)
• [ ] DNT and GPC honoured client-side and server-side
• [ ] Privacy policy accurate about what is actually collected
• [ ] LIA or consent flow documented

InsightsTrack is built to satisfy the technical rows of this list by construction: self-hosted, no IP storage, no cookies, rotating-salt IDs, country-level geo, configurable retention, and DNT/GPC honoured in both the script and the API. The documentation rows are still yours to complete. For the technical detail, see privacy-first database design and cookieless analytics explained.