Is legitimate interest enough for product analytics? Check what your tool stores on the device first.

Open your product in a browser, press F12, and look at the Application tab. If your analytics tool has written anything into Cookies, Local Storage or Session Storage, it did that before your visitor clicked anything, and your privacy policy probably names legitimate interest as the basis for analytics. Those two facts do not sit together. The rule that governs writing to the device does not offer legitimate interest at all, so when someone asks you to show the basis for that write, whether a regulator or the enterprise buyer whose security questionnaire asks what runs before consent, there is nothing to show.

I start with the browser because most teams answer the second of two questions without noticing the first. You open the GDPR's list of lawful bases, weigh consent against legitimate interest, pick legitimate interest because a banner would hurt conversion, and ship. Two rules apply to what you just built, in order, and the first does not put legitimate interest on the menu.

Which rule applies before you reach the GDPR's lawful bases?

Article 5(3) of the ePrivacy Directive. In plain terms, you may store information on a visitor's laptop or phone, or read information already there, only with their consent or under one of two narrow exemptions 1. The Directive calls the laptop or phone terminal equipment, and the exemptions are storage or access for the sole purpose of carrying out the transmission of a communication, or where it is "strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service" 1.

Read the second one slowly. The service has to be one the user explicitly requested. A session cookie that keeps somebody logged in passes, because they asked to log in. Analytics is hard to fit, because nobody opens your pricing page in order to be counted: the analytics is something you wanted, and the exemption is written about what the user asked for. That is the mainstream reading rather than a settled one: the European Data Protection Board (EDPB), where the EU's national privacy regulators agree common positions, deliberately leaves exemptions to be judged case by case against each country's own implementing law and its own regulator's guidance 1. France has published a route through, and I come to it below.

What Article 5(3) does not offer at all is a choice of lawful basis. It names consent and those two exemptions, and legitimate interest is not among them. The GDPR's list of lawful bases, which is Article 6, belongs to a question you have not reached yet.

Does "cookieless" analytics escape Article 5(3)?

Not automatically. The rule is written about "information", and in 2024 the EDPB published guidelines on how much wider that is than a cookie 1.

On what counts as information, the EDPB is blunt. Information "includes both non-personal data and personal data, regardless of how this data was stored and by whom", and the EU's top court has held that the protection "applies to any information stored in such terminal equipment, regardless of whether or not it is personal data" 1. So an anonymous visitor ID is inside the rule. Whether it counts as personal data changes which other rules apply on top, not whether this one does.

Three consequences you can check against your own stack:

• An identifier is in scope without any cookie. Where client-side code instructs the browser to send an identifier, the EDPB treats that as a gaining of access, and Article 5(3) applies 1.
• Local storage counts as storage. The ePrivacy Directive places no upper or lower limit on how long information must persist on a storage medium to count as stored, nor on how much of it there is 1.
• Even IP-only tracking can be in scope. Some tools identify visitors from the IP address alone. What matters is that the tool is doing something extra with the address rather than simply answering the request, and the EDPB says that "unless the entity can ensure that the IP address does not originate from the terminal equipment of a user or subscriber, it has to take all the steps pursuant to the Article 5(3) ePD" 1.

This is where vendor copy and the legal test pull apart. Plausible's data policy states that it uses no cookies, browser cache or local storage, and that you therefore do not need cookie banners for analytics; its visitor identifier is a daily hash of IP address and User-Agent. PostHog's GDPR guidance runs the other way, telling you plainly that if you use it with cookies for logged-out visitors you should also use a cookie banner. Plausible is making two different kinds of claim. "No cookies, browser cache or local storage" describes a mechanism, and it is accurate. "You do not need cookie banners" is a legal conclusion, and the IP-only bullet above puts it in tension: a daily hash of IP address and User-Agent is IP-derived identification. That does not make the conclusion wrong, because Article 5(3) applying does not automatically mean consent has to be collected and an exemption may still cover it 1. It makes it a conclusion to defend on your own deployment rather than inherit from a vendor page. If Plausible is your tool, defend it against the seven CNIL conditions below. The mechanism carries some of them on its own, since the identifier is bound to one domain and lives a day, but CNIL's condition on IP addresses asks for the last byte to be truncated, and a salted hash of the full address is a different operation. Neither the vendor's page nor the CNIL sheet says whether one satisfies the other, so that is the question to put to the provider.

Where does legitimate interest apply?

To the processing you do after the data reaches your server. The ePrivacy Directive carries a special rule for the storing and access step, and the EDPB has said it "does not contain a special rule for any prior or subsequent processing activities (e.g., the storage and analysis of data regarding web browsing activity...)", leaving data protection authorities fully competent over everything that follows 2.

So there are two questions, and they take two separate answers:

• May you store or read anything on the device? Article 5(3) of the ePrivacy Directive decides it, and the answer is consent or one of the two exemptions.
• May you analyse what you collected? Article 6 of the GDPR decides it, and legitimate interest is one of the bases on offer.

It is not a free pass, though. Three conditions have to hold together: a legitimate interest pursued by you or a third party, processing that is necessary for that interest, and a balancing exercise in which the interests and fundamental rights of the people concerned do not take precedence over yours 3. The balancing has to be performed before the processing starts, and Article 6(1)(f), the legitimate-interest limb, cannot be treated as a basis by default 3. Those conditions come from the EU's top court; the EDPB guidelines that collect them are still the version issued for public consultation 3.

One boundary matters. If your analytics feeds ad targeting or individual outreach, legitimate interest is the wrong answer: regulators have treated behavioural advertising and direct marketing as cases where consent is the appropriate basis for both the device access and the processing after it, "thus normally precluding reliance on Article 6(1)(f) in this context" 3. Counting in aggregate how many accounts opened a feature last week is a different operation with a different balancing test. The line falls between profiling individuals in order to act on them and measuring how a product gets used.

Server-side analytics is the cleaner case, with one caveat. If you count feature usage from events your backend already handles, and nothing is stored on or read from the visitor's device for that purpose, Article 5(3) has little to attach to. The caveat is the IP address: use it as the identifier that stitches visits together and you are back in the IP-only bullet above.

Can analytics run without consent at all?

In some member states, under conditions. France publishes the clearest version. CNIL, the French data protection regulator, exempts analytics from consent where all seven of these hold 4:

• You inform users of the trackers.
• You let them object.
• The purposes are limited to audience measurement and A/B testing.
• The data is not cross-checked with other processing.
• The tracker is scoped to a single site or app publisher.
• The last byte of the IP address is truncated.
• Tracker lifetime is capped at 13 months.

"Most large audience measurement offerings do not fall within the scope of the exemption, regardless of their configuration", CNIL then says 4. Ask your provider whether their product meets all seven, or self-host something you can configure yourself, which is CNIL's own suggested route.

Two limits on all of that. It is a French position, and ePrivacy is a Directive, so the operative law is each country's implementing statute rather than one European text. An exemption you can rely on in Paris is not automatically one you can rely on in Dublin. And the exemption is from consent under Article 5(3) only. You still owe an Article 6 basis for the analysis and the transparency duties that come with it.

What to write down before you change the stack

Three things, in this order.

1. List what each analytics tool stores or reads on the device. The vendor's data policy is the fastest source and devtools is the check. Record the mechanism, not the marketing claim.
2. Answer the two questions separately. For the device step: consent, or a named exemption you can satisfy in the countries your users are in. For the analysis: a lawful basis, with the balancing test written down if you land on legitimate interest.
3. Make the privacy policy say what you concluded. If it names legitimate interest for analytics while your tool writes an identifier into the browser, one of the two is wrong, and a well-documented balancing test for the analysis does not repair the storage step. Put the tool behind consent, or behind an exemption you can point to.

Writing it down matters because the answer has a shelf life: it is true of the stack you have today. Swapping analytics vendors, switching on session recording, or dropping in a pixel for one campaign each change what your published documents claim, and none of them feels like legal work at the time. I have written before about how that drift accumulates and what it looks like on real landing pages, where only 17% of the Product Hunt launches that set tracking cookies asked permission first.

Closing that loop is what we built Lawcel for. Lawcel reads the pull requests and tickets your team already writes and works out which of your published legal documents each change affects. When somebody merges the change that swaps one analytics tool for another, you hear which documents it touches and why, while it is still cheap to fix.