A lot of sites run Google Analytics — or any other analytics tool — without a consent banner. Developers either don't know they need one, or they assume "anonymous" data is fine. Neither assumption holds up under GDPR.
The regulation doesn't care whether you call the data anonymous. It cares whether a persistent identifier can be used to re-identify a person across sessions. If yes, you need consent before setting it.
The 'GA Without a Consent Banner' Trap
In January 2022, the Austrian Data Protection Authority ruled that using Google Analytics violates GDPR. France, Italy, Denmark, and several other EU member states followed with their own decisions. NOYB — the privacy advocacy group behind the Schrems II case — has filed over 884 total enforcement cases. Regulators are no longer looking the other way.
The common thread in these cases: persistent identifiers sent to third-party servers. An analytics cookie that survives across sessions is, by GDPR's definition, a personal data point — because when combined with other signals, it can identify a natural person. Recital 30 spells this out explicitly.
Why the Persistent Visitor ID Is the Hard Part
Most analytics data is genuinely low-risk. Knowing that someone visited /pricing from a Google search, spent 40 seconds, and had a 3.1s LCP — that's aggregate behavioural data. It doesn't identify anyone. You can collect it without consent.
The problem is the persistent visitor ID. When you assign a UUID to a browser on the first visit and read it back on every future visit, you can link all of that anonymous-looking behaviour to the same individual over months. That linkage is what creates the identification risk GDPR is concerned about.
- Page views, referrer domain, UTM parameters — no persistent identifier, no consent required
- Core Web Vitals (LCP, FCP, CLS, TTFB, INP) — measured at request time, discarded after aggregation
- Session tracking via sessionStorage — scoped to one tab session, cleared when the tab closes
- Persistent visitor ID stored in a cookie — survives across sessions, enables returning-visitor tracking, requires consent
The line is: anything that outlives a single session and links behaviour across visits is a personal data point. Everything else is fair game.
What Statvisor Collects Before and After Consent
Statvisor draws a hard line between cookieless analytics and visitor identification. The majority of the data runs on load — no cookie read, no consent check.
Statvisor's split means you get real analytics from day one — even before a visitor has responded to the consent banner. Page views, Web Vitals, and campaign attribution all flow immediately. The only thing that gates behind consent is returning-visitor tracking.
Adding the Drop-In Consent Banner
The SDK ships a ready-made consent banner component. Drop it next to your analytics component in the root layout and it handles the rest — showing on first visit, storing the decision, and either creating or withholding the _sv_vid cookie accordingly.
import { StatvisorAnalytics } from "@statvisor/sdk/react";
import { StatvisorConsentBanner } from "@statvisor/sdk/consent";
export default function RootLayout({ children }) {
return (
<html>
<body>
{children}
<StatvisorAnalytics frontendKey="vl_fe_your_key_here" />
<StatvisorConsentBanner frontendKey="vl_fe_your_key_here" />
</body>
</html>
);
}Two cookies are involved. _sv_consent is written immediately on any interaction with the banner. It stores the decision (granted or denied) and is classified as strictly necessary — no separate consent is needed to remember the user's own choice. _sv_vid is only written if the decision was "accept".
Customising the Banner from the Dashboard
The Statvisor dashboard lets you configure the banner without touching code. Open your project, hit the settings icon, and you can adjust position (bottom bar, bottom-left, bottom-right), colors, heading and body copy, button labels, and a privacy policy link. Changes take effect within 60 seconds — no redeployment needed.
If You Already Have a Consent System
If your site already uses a consent management platform — OneTrust, Axeptio, a custom modal — skip the banner component and wire Statvisor's consent helpers into your existing accept/decline handlers.
import { grantConsent, revokeConsent, hasConsent } from "@statvisor/sdk/browser";
// Call from your existing "Accept all" handler
grantConsent(); // sets _sv_consent=granted + creates _sv_vid cookie
// Call from your "Decline" / "Necessary only" handler
revokeConsent(); // sets _sv_consent=denied + removes _sv_vid cookie
// Check current state anywhere in your app
if (hasConsent()) {
// visitor has accepted analytics cookies
}The Honest Tradeoff
If a visitor declines consent, you won't see them as a returning visitor. Your "returning vs new visitor" ratio will under-count if your consent acceptance rate is low. That's a real data quality tradeoff.
But page views, bounce rates, Core Web Vitals, campaign performance, and session-level behaviour all still work. For most product decisions, that's the data that actually matters. Returning-visitor identification is useful — it's not essential.
The alternative — running a persistent visitor ID without consent and hoping nobody notices — is a fine waiting to happen. The era of "everyone does it" as a legal defence is over.
Ready to monitor your API in production?
Statvisor gives you latency percentiles, error rates, and request volume for every route — in minutes, not days.
Get started free →