GDPR governs personal data processing. The ePrivacy Directive (implemented in national cookie laws across the EU) governs storage and access on devices—cookies, local storage, SDK identifiers, and similar technologies. Marketing and analytics tags almost always touch both layers.

Understanding the split helps engineering, legal, and marketing make the same decisions instead of talking past each other.

GDPR: processing personal data

Key themes for tracking:

• Lawful basis — consent is the practical default for analytics/ad cookies in most EU member states
• Transparency — tell users who processes data, for what purposes, how long you keep it
• Rights — access, erasure, objection, restriction, portability where applicable
• Accountability — document decisions, DPIAs for high-risk processing, processor agreements

ePrivacy: cookies and device storage

Key themes:

• Prior consent typically required before non-essential cookies/scripts store or read information on a user’s device
• “Strictly necessary” exceptions are narrow—usually security, load balancing, cart session—not analytics or ads
• National implementations differ in details (France CNIL, Germany TTDSG, Romania ANSPDCP guidance)—geo matters

Why both matter for a single Meta Pixel

Installing Meta Pixel often:

• Sets or reads cookies / identifiers (ePrivacy question: consent needed?)
• Sends personal data or online identifiers to Meta (GDPR question: lawful basis, transparency, DPA)

Server-side forwarding reduces browser cookies but does not automatically eliminate GDPR obligations if personal data still flows to processors.

Practical implications for tag strategy

• Pre-ticked marketing consent is not valid—active choice required
• Legitimate interest is rarely a safe sole basis for analytics/ad cookies—legal should sign off explicitly
• Cookie walls (site blocked until accept) face increasing scrutiny—design carefully
• Fingerprinting and probabilistic identifiers fall under heightened scrutiny—disclose if used

Documentation teams should maintain

• Cookie / privacy policy aligned with live tags (update within days of new vendor, not months)
• Records of consent by region and version of banner text
• RoPA (Record of Processing Activities) entries for analytics and advertising
• DPIA when adding sensitive data flows: health/finance content, children, large-scale profiling
• Vendor DPAs and transfer mechanisms (SCCs) for US-based tools

Server-side tagging nuance

Server-side GTM can:

• Reduce third-party script count in browser
• Control which events hit ad APIs after consent checks on server

It does not:

• Automatically make Meta/Google processing “anonymous”
• Remove need for CMP if client-side cookies still exist
• Replace policy updates when you add new event parameters with PII risk

Cross-team workflow that works

1. Marketing requests new pixel → intake form with purpose and data fields
2. Legal reviews vendor and basis → approve/deny/conditional
3. Engineering implements in GTM with consent triggers → staging QA
4. Policy team updates cookie list → publish same release window
5. Analytics validates reporting → sign-off

Legal and engineering need the same source of truth: your CMP config and GTM container should match what the policy promises.

Red flags auditors look for

• Tags in production not listed in cookie policy
• Analytics on logged-in areas without clear disclosure
• Data sent to US tools without transfer documentation
• No process for user deletion requests affecting analytics profiles

Fix red flags before enterprise procurement or regulatory inquiry—not during.