Usually yes, for the step that reads or writes something on the user's device — and that is a different question from which lawful basis covers the analysis afterwards. Two regimes apply in sequence. The ePrivacy rules govern storing and accessing information on a device and generally require consent. The GDPR then governs the processing that follows and requires an Article 6 basis, which may or may not be consent.
This article covers why the two questions separate, how narrow the strictly-necessary exemption is, where legitimate interest genuinely helps and where it cannot rescue you, what changes with server-side or first-party analytics, and how logged-in product analytics differs from website analytics.
There Are Two Questions Here, With Different Answers
The mistake that causes most of the confusion is treating "do I need consent for analytics" as one question. It is two, asked of two different laws.
Question one. Are you storing information on, or gaining access to information already stored on, the user's device? Cookies, localStorage, device fingerprinting and most SDK identifiers all qualify. Under the ePrivacy Directive as implemented nationally — PECR in the UK — this requires consent unless the access is strictly necessary for a service the user has explicitly requested.
Question two. What is your lawful basis under Article 6 for processing the personal data you then hold? Consent under 6(1)(a), contract under 6(1)(b) and legitimate interests under 6(1)(f) are the candidates.
They can produce different answers, and the first constrains the second. If you needed consent to set the identifier and did not obtain it, having a legitimate interest in the analysis does not make the collection lawful. Getting this order right is what separates a defensible analytics setup from one that looks defensible.
The Strictly Necessary Exemption Is Narrower Than It Reads
"Strictly necessary" means necessary to deliver the service the user asked for — a session cookie that keeps them logged in, a load-balancing cookie, a cookie remembering items in a basket, and the cookie that stores their consent choice.
Analytics is not strictly necessary in that sense, however useful it is to you. The user asked for the product, not for the measurement of their use of it. Regulators have been consistent on this point, checked 8 August 2026, and the fact that the analytics improves the product the user requested does not convert it into something the user requested.
Some supervisory authorities have taken a more relaxed view of genuinely first-party, aggregate-only audience measurement, but the conditions attached are strict and vary by country. It is not a general exemption and building a product on the assumption that it is available in your market is a poor bet.
Where Legitimate Interest Helps, And Where It Cannot
Legitimate interest under Article 6(1)(f) is a real and useful basis for analytics, and it is frequently the right one for the processing stage — analysing usage patterns to improve a product is a textbook legitimate interest, subject to a documented balancing test and an honest read of user expectations.
What it cannot do is displace the consent requirement for the device access step, because that requirement comes from separate legislation. This is the single most common error on this topic and it appears in a lot of otherwise careful writing, including material that correctly says analytics can rely on legitimate interest without adding that the cookie still needs consent. Both statements can be true at once; only stating the first produces a setup that fails at the first step.
The practical position for most B2B SaaS: obtain consent for non-essential storage and access, then rely on legitimate interest for the subsequent analysis where that is genuinely more appropriate than consent, and document the balancing test. Whether the vendor you use can be configured to work that way is a separate matter, and whether Google Analytics is GDPR compliant covers the configuration and transfer side of that question in detail. This article stays on the basis.
Server-Side And First-Party Analytics Change The Analysis, Not Always The Answer
Moving collection server-side is often described as a way around consent. It is more accurate to say it changes which question is engaged.
If the server-side setup still relies on an identifier stored on the device — a first-party cookie set by your own domain, a persistent ID in localStorage — you are still storing and accessing information on the device and question one still applies. The data path changed; the trigger did not.
Where server-side genuinely helps is question two and the transfer position: less data leaves the browser, you control what is forwarded, and you can strip identifiers before anything reaches a third country. Those are real benefits for the balancing test and for the transfer analysis. They are not a consent exemption.
Truly stateless measurement — no device identifier at all, no cross-session linking, aggregate counts only — sits differently, and is the closest thing to an exemption available. It is also, by construction, much less useful than the analytics most teams want.
Logged-In Product Analytics Is A Different Conversation
Website analytics and in-product analytics are usually treated as one topic and they are not quite the same.
Inside an authenticated product, you are already processing the user's personal data under a contract with your customer. The device-access question still applies, but the framing changes: your customer is the controller, you are the processor, and the consent obligation is theirs to discharge with their users rather than yours to discharge directly. What you owe your customer is the ability to honour that — a way to turn analytics off, or to not fire it before their consent signal arrives.
Two things are worth stating plainly to customers. Contract necessity under 6(1)(b) covers what is needed to deliver the service; it does not stretch to behavioural analytics, and the same limit applies to free trial and beta users, whose acceptance of terms does not import a basis for measurement. And session recording is its own case with its own analysis — whether session replay is legal under GDPR turns on questions this article does not settle.
Common Mistakes With Analytics Consent
Answering the cookie question with a lawful basis. Legitimate interest is an Article 6 answer to an Article 6 question. It does not address the separate requirement to obtain consent before storing or accessing information on a device.
Firing the analytics tag before the consent signal arrives. A banner that appears while the tracker has already loaded is the most frequently detected failure in this area, and it is a configuration problem rather than a legal one.
Treating anonymised as a synonym for aggregated. Truncating an IP address or hashing an identifier usually produces pseudonymous data, which is still personal data. Genuine anonymisation is a high bar and it is not reached by removing one field.
Relying on contract necessity because the user accepted terms. Article 6(1)(b) covers processing necessary to perform the contract. Measuring how someone uses the product is not necessary to provide it, and accepting terms of service is not consent to analytics.
Assuming a self-hosted tool removes the question. Self-hosting resolves the international transfer problem and improves the balancing test. It does not change whether you are storing an identifier on the user's device, which is where the consent requirement comes from.
FAQ
Do we need consent for analytics on a B2B product where users are at work?
Yes. The consent requirement for device storage and access attaches to the person using the device, not to whether they are acting in a business capacity. Business context can affect the balancing test at the Article 6 stage, but it does not remove the first question.
Can we make product analytics a condition of using a free tier?
That is difficult. Consent must be freely given, and conditioning access on consent to processing that is not necessary for the service is the situation the "freely given" condition was written to address. A free tier does not change the analysis, though the strength of your position depends on how genuinely optional the alternative is.
What about error monitoring and performance tools — do those need consent too?
Ask the same two questions. Where the tool is genuinely necessary for security or to deliver the service and stores nothing beyond what that requires, a stronger case exists for the strictly-necessary route. Where it also builds a user profile or links sessions over time, it has moved into the same territory as analytics.
Our customer's users are the data subjects. Whose job is the consent?
Where you act as processor, the controller is your customer and the obligation to obtain consent is theirs. Your obligation is to make it possible — to respect a consent signal, to allow analytics to be disabled, and to describe accurately in your documentation what fires and when. Silently collecting regardless of their configuration puts them in breach and you in breach of your instructions.
Closing Thought
The reason this question generates so much contradictory advice is that the two regimes have different tempers. GDPR is a risk-balancing instrument: it gives you six bases, asks you to reason, and rewards a documented judgement. The ePrivacy consent rule is not like that. It is a rule with a narrow exemption and no balancing available, and reasoning well about the second question does nothing for the first. Most bad analytics advice is the sound of someone applying GDPR habits to an ePrivacy question.
Getting it right is mostly sequencing: consent gate first, basis and balancing test second, both written down. ComplyDog provides a cookie consent banner alongside a compliance portal on your own domain covering your DPA, subprocessor list, data subject request forms and security page. It does not configure your analytics stack, write your balancing test or decide whether a given tool is strictly necessary — those are decisions about your product that stay with your team.
