Reaching into the device at all is the eprivacy Directive's concern. What you then do with the personal data falls under the General Data Protection Regulation (GDPR).
Working out which applies, and at what moment, is what tells you whether a script can load, when a tag is allowed to fire, and what you need to keep a record of. This guide follows that divide — eprivacy Directive vs GDPR — from the banner all the way to the server.
ePrivacy Directive vs GDPR: The Short Version for Engineers
When you're looking at a tag or an SDK and trying to place it, the question that helps is where the action lands. Anything that writes to or reads from the device — a cookie, a localStorage entry, a pixel that loads, an SDK that spins up — puts you under eprivacy, and Article 5(3) may require consent before it runs, whether or not the thing being stored counts as personal data.
GDPR comes in once that activity produces data tied to a person: an identifier, an event, a profile. In practice, one tracker often raises both questions. An advertising pixel may need to wait before it loads, and the conversion event it later sends still needs a lawful basis, a purpose, and a retention rule.
What the ePrivacy Directive Means in Code
Article 5(3) of the eprivacy Directive (Directive 2002/58/EC, as amended by 2009/136/EC) is easy to misread as a cookie rule. It is broader than that. It governs storing or reading information on a user's device, with exceptions for technical transmission and for what is strictly necessary to run the service the visitor actually asked for.
Cookies are only the most familiar example.
The same issue can appear even when document.cookie is never called. A software development kit (SDK) might store a value in localStorage. A tracking pixel might fire from an email. An embedded widget might write its own storage, or a fingerprinting script might read device characteristics.
The European Data Protection Board (EDPB) Guidelines 2/2023 on the technical scope of Article 5(3), finalized in October 2024, work through this in detail, and the categories they cover include:
- First and Third Party Cookies
localStorage,sessionStorage, and IndexedDB- Tracking pixels and beacons
- Scripts, tags, and third-party SDKs that read or write client-side state
- Embedded content that sets its own storage
- Device fingerprinting and unique identifiers, including some carried in URLs
If the code stores or reads information before the visitor has agreed, Article 5(3) may be in scope. The next question is whether consent is required or a narrow exemption genuinely applies.
What the GDPR Covers After Tracking Starts
After the event leaves the page, the question changes. It may land in an analytics report, be sent to an ad platform with an identifier attached, or sit in a log beside an IP address. Those identifiers can be personal data, though not in every setup. The issue is whether they can be linked back to a person through behavior, an account, or a profile.
Once they can, GDPR governs how you handle them.
And handling doesn't always come down to asking for consent. GDPR does not always require consent — it requires a lawful basis, and consent is one of six under Article 6, alongside legitimate interests and the rest. Which one fits depends on the purpose and, often, on whether ePrivacy has already put a consent gate in front of the data upstream.
Most obligations under this area are reflected in your schemas, records, and data flows, not in the Cookie Banner:
- A lawful basis recorded for each purpose
- Clear information to users about what you collect and why
- A way to withdraw consent wherever consent is the basis
- Records of processing, where they're required
- Contracts with the vendors and processors you send data to
- Retention limits, and collecting only the fields a purpose needs
- A route for access and deletion requests that reaches the data
Session replay is the case that catches people out: the moment a recording can be tied to the shopper, it's personal data, so it needs a basis, a defined reason to keep it, and a point where it's deleted — none of which the Cookie Banner decides.
When ePrivacy and GDPR Apply to the Same Tracker
Most real trackers sit under both rules, and it plays out differently from one tool to the next.
The Meta Pixel creates both problems quickly. It reads and writes cookies the instant it runs, so it belongs behind consent, but the harder part is everything it forwards to Meta afterward—events, identifiers, match keys—all of it personal data you need a lawful basis and a signed contract to share.
Google Analytics is often treated too casually because it sits under “analytics.” But if it reads or sets a client ID, there is still device access to consider.
The reports built on top may also involve personal data when they can be tied back to an identifiable visitor. Whether it can run before consent depends on the jurisdiction and configuration.
An embedded YouTube video is the one that catches people off guard, because a plain iframe fires third-party requests and sets storage the moment the page loads — before anyone clicks play.
The privacy-enhanced embed changes what loads, but that's something to confirm in the network tab rather than assume.
Server-side tagging is where a wrong assumption does the damage. Moving tags to your own server doesn't remove the consent question when the identifiers feeding it were read off the device to begin with — that read is still device access, and the data now on your infrastructure is yours to handle.
What Can Load Before Consent — and What Should Wait
This is not a final answer for every site. Local law and the way a tool is configured can change where it belongs.
| Usually can load before consent | Usually should wait for consent |
|---|---|
| Core HTML and CSS | Advertising and conversion pixels |
| Essential JavaScript needed to render the page | Remarketing/retargeting tags |
| Login/session cookies | Social media tracking plugins |
| Cart and checkout cookies | Most third-party analytics |
| Security, CSRF, load-balancing, and narrowly necessary fraud-prevention tools | Heatmaps and session replay |
| The consent-preference cookie itself | Embedded videos or maps that set non-essential trackers |
Analytics is where teams usually need to slow down. For most third-party analytics, waiting for consent is the safer starting point.
There are exceptions, but they are narrow: CNIL has criteria for limited First-party audience measurement, and the UK now has a limited statistical purposes exception. Neither should be treated as permission to run ordinary analytics before consent.
Strictly Necessary Cookies Are Not Whatever the Business Wants
There is an exemption for strictly necessary cookies, but this is a narrow exemption: the storage has to be strictly necessary to provide what the visitor asked for and cannot be extended to any other information the business might want to collect about the visitor. A retargeting pixel isn't strictly necessary just because marketing depends on it.
What usually qualifies:
- Authentication and session cookies
- Checkout and cart persistence
- Security tokens and CSRF protection
- Load balancing
- Storing the consent choice itself
What usually doesn't, whatever the internal argument for it:
- Retargeting pixels and cross-site advertising
- Broad analytics
- Social media tracking
- Heatmaps and session replay
- Personalization past what was asked for
- A/B testing, unless a specific exemption covers it
The test is whether the feature in front of the visitor would break without it. A login session would; a retargeting pixel wouldn't, which is exactly why it waits for consent.
Coding for ePrivacy: Script Blocking, Tags, and Consent States
The job of the front end is to keep everything nonessential off the device until the consent state says it's OK. The consent layer — a Consent Management Platform (CMP), or your own stored preference — has to resolve before other scripts run, with everything non-essential blocked by default until its category is cleared.
This is why scripts that fire on page load rather than wait tend to break. Scripts that execute on page load instead of waiting: script blocking has to happen before the request goes out, not after it.
Tags fired from the main bundle before the consent state is known, so that when the check resolves a moment later the pixel has already loaded. Google Tag Manager (GTM) triggers left on "All Pages" for analytics and advertising with no consent condition attached. Auto-loading embeds that would be better as click-to-load placeholders.
Withdrawal usually deserves at least as much care as the original choice. When a visitor turns tracking off, the tags have to actually stop firing — not just vanish from the banner while the requests keep going out.
Coding for GDPR: Consent Records, Preferences, and Data Lifecycles
The back-end job is, however, very different: it concerns proof and life cycle rather than blocking. If you're leaning on consent as your basis, you need to be able to show it was given — the choice stored with its time, region, purpose, and the version of the notice the visitor saw, not just a flag flipped in memory.
The parts that matter in code are the ones that tend to get skipped. Withdrawal has to propagate: one that stops a front-end tag but keeps feeding a server-side pipeline hasn't really been honored. Retention has to be enforced, with event schemas that collect only the fields a purpose needs.
Vendor and processor records have to match what's actually in production and stay in step with the privacy and cookie policies. Access and deletion requests need a path that reaches the stored data.
Logging consent and enforcing it are different matters; delivering one does not guarantee the other. An exquisite consent record will not matter if the tags continue firing after rejection, simply because nothing on the page reads the stored choice and acts on it.
Common Developer Mistakes That Break Cookie and Tracking Compliance
- Tags that fire before the banner even renders — the banner is decoration at that point.
- GTM triggers that ignore consent because they were never wired to it.
- A consent choice that's saved but never enforced, so tags run regardless.
- Withdrawal that updates the UI and nothing else.
- Server-side tracking used as a way around the consent model.
- Categories so broad that one toggle hides trackers with very different risk.
- A cookie declaration listing five vendors while the site loads twelve.
You do not get any of this from the banner: it only comes to the surface if you look at network requests and browser storage while cycling through accept, reject, and withdrawal states.
EU/EEA vs UK: ePrivacy, PECR, and UK GDPR
The same consent architecture can often be reused across markets, but the legal assumptions should not be hard-coded. Across the EU/EEA, the ePrivacy Directive is implemented through each country's own law, which means the device-access details vary, while GDPR applies uniformly to the data side.
The UK runs on its own instruments — the Privacy and Electronic Communications Regulations (PECR) for storage and access, and the UK GDPR for processing.
The reference point now is the Information Commissioner's Office (ICO) guidance on storage and access technologies, finalized on 29 April 2026, which ties the rules to what a technology does rather than what it's called and reflects the Data (Use and Access) Act 2025.
The Data (Use and Access) Act 2025 introduced a limited statistical purposes exception, which can cover some analytics storage without consent where its conditions are met. The conditions still matter, and the ICO does not treat it as a broad analytics exemption. Outside the relevant PECR exceptions, consent is still required.
The practical implication is that your consent layer needs to be regionally configurable rather than hardcoded with one set of defaults, notices, and exceptions.
Where a Consent Management Platform Fits in the Engineering Stack
Your CMP connects the dots between your banner, your tags, your scripts on the page, your consent records, and your published policies.
A good CMP will scan for cookies and trackers; categorize; display region-sensitive banners; block scripts until consent is given; store the consent choice; allow visitors to change it; and support Google Consent Mode v2.
CookieScript is one such tool; depending on plan and configuration, it can support the practical pieces around consent management, including:
- cookie banner and cookie banner sharing
- Cookie Scanner and automatic monthly scans
- Automatic script blocking and third-party cookie blocking
- User consents recording and advanced reporting
- geo targeting and support for 42 languages
- Google Consent Mode v2 and IAB TCF 2.3 integration
- Cookie Policy Generator and Privacy Policy Generator
What it can't do is wire itself in — someone still has to connect it correctly to the site, the tag manager, the embedded tools, and the downstream data flows.
CookieScript is a Consent Management Platform used by organizations around the world. Its fourth consecutive G2 Leader badge in 2025 reflects ongoing customer recognition and its continued standing among established CMP solutions.
Engineering Checklist: What to Review Before Launch
- Scan representative, not just home, pages.
- Inventory the cookies, storage, pixels, scripts, tags, embeds, and third-party requests they make.
- Separate strictly necessary from analytics, marketing, and personalization.
- Check what loads before the visitor has chosen anything.
- Confirm GTM triggers actually respect consent.
- Test accept, reject, granular choices, and withdrawal — including embedded video, maps, chat, and social widgets.
- Cover single-page-app route changes, not only the first load.
- Make sure server-side tracking isn't ingesting device identifiers before consent where consent is required.
- Store consent evidence, and keep the policies matched to what's actually running.
- Re-run all of it after campaigns, plugin changes, new vendors, or redesigns.
Frequently Asked Questions
What's the difference between ePrivacy and GDPR for cookies?
ePrivacy is about storing or reading something on the device; GDPR is about what you do with any personal data that comes out of it. A typical marketing or analytics tag runs into both — one when it loads, the other once it starts sending data somewhere.
Do analytics cookies need consent under ePrivacy?
Usually they should wait for it, but not always. A few regimes allow a narrow, First-party audience-measurement exemption on strict conditions — CNIL's criteria in France and the UK's limited statistical purposes exception are the main examples — and whether either fits comes down to the jurisdiction and how the analytics is configured.
Can legitimate interests replace Cookie Consent?
Not for the device-access step. If ePrivacy or PECR requires consent to store or read non-essential information on someone’s device, legitimate interests cannot replace that consent. It may be relevant later as a GDPR lawful basis for some processing, but it does not remove the consent requirement for the storage or access itself.
Is server-side tracking a way around Cookie Consent?
No, not by itself. Server-side tracking changes where the tag runs, but it does not change how the identifier was collected. If that identifier came from reading or writing information on the visitor’s device, the ePrivacy question is still there.