B2B Website GDPR Compliance Checklist Guide

Most B2B teams believe their analytics setup is GDPR-compliant because they have a cookie banner. A B2B website GDPR-compliant analytics setup requires more than a banner. It requires a specific technical architecture.

A banner without proper Consent Mode V2 integration, a CMP that does not block tracking tags before consent, or GA4 that fires regardless of user choice, any of these creates legal exposure. This article explains what a compliant setup looks like and how to build it.

Key Takeaways

• A cookie banner alone does not make your analytics GDPR-compliant: The banner must be connected to a Consent Management Platform that actually blocks tracking tags before consent is given.
• Google Consent Mode V2 is required for EU-targeting sites using GA4: Without it, your Google tags operate in a non-compliant mode for EU visitors. This became a requirement in March 2026.
• B2B visitors have the same GDPR rights as consumers: The regulation applies to any personal data processing, including IP addresses and device identifiers, regardless of whether the visitor is a business user.
• Privacy-first analytics tools can operate without consent: Plausible, Fathom, and self-hosted Matomo provide traffic data without personal data collection, but they offer less attribution capability than GA4.
• The data you cannot collect without consent is broader than most teams expect: User IDs, cross-device tracking, behavioral retargeting signals, and heatmap session recordings all require explicit opt-in under GDPR.

B2B Website Development

Websites That Win Enterprise Clients

We build high-converting B2B websites with modern no-code technology—designed to generate leads, build trust, and support your sales team.

Let's talk

What Does GDPR Actually Require from Your Analytics Setup?

The broader guide on GDPR compliance for B2B websites covers the full regulatory picture beyond analytics, including data subject requests, privacy notices, and third-party vendor obligations.

Understanding the legal requirements before evaluating your current setup prevents the common mistake of optimizing for the appearance of compliance rather than the substance of it.

• Personal data definition as it applies to analytics: GDPR defines personal data as any information that can identify an individual. IP addresses, device identifiers, cookies, and UserIDs all qualify, even if you never see a name attached to them.
• Legal basis for analytics tracking: Most B2B websites rely on consent as their legal basis for analytics. This means tracking must not start until the user has actively opted in. Not pre-ticked boxes, not implied consent from continued browsing.
• Legitimate interest as an alternative: Some analytics processing can be justified under legitimate interest, such as server logs and basic site functionality. Behavioral tracking, third-party cookies, and cross-site data sharing cannot be justified this way.
• Accountability requirement: GDPR requires documented evidence of your compliance approach. Your analytics setup must be recorded in a Record of Processing Activities, or ROPA, documenting what data is collected, why, and under what legal basis.
• Data minimization principle: Collect only what you need for a defined purpose. GA4's default data retention should be set to the minimum required, and User ID tracking should only be active if there is a documented operational need.

What Does a GDPR-Compliant Analytics Stack Look Like in Practice?

The B2B website GDPR checklist covers every component of a compliant setup across analytics, forms, third-party embeds, and data retention. Use it alongside this guide.

A compliant analytics stack is not a single tool. It is five components working together, and each one must be implemented correctly for the stack to hold.

• Component 1, Consent Management Platform: A CMP such as OneTrust, Cookiebot, Axeptio, or Usercentrics intercepts page load, presents the consent banner, stores user consent choices, and signals consent state to all downstream tags. Without a CMP, tracking tags fire regardless of user choice.
• Component 2, Google Consent Mode V2: Required for any site using Google tags targeting EU visitors. Sends consent state signals to Google's systems so Google can use modeled data where consent is absent. Must be implemented via the CMP or GTM.
• Component 3, Tag Management: Google Tag Manager or equivalent must be configured to fire tracking tags only when the CMP signals that the relevant consent category has been granted. Tags that fire before consent is checked create violations.
• Component 4, Analytics tool: GA4 with Consent Mode V2 active is compliant for most B2B use cases. Privacy-first tools such as Plausible, Fathom, and Matomo operate without personal data collection and may not require consent at all, depending on configuration.
• Component 5, Data Processing Agreements: All analytics vendors that process personal data on your behalf must have a signed DPA. Google provides this for GA4. Verify it is in place in your Google account. Do the same for any heatmap, session recording, or form analytics tools.

The compliant stack for most B2B sites: Cookiebot or Usercentrics as CMP, GTM with consent triggers, GA4 with Consent Mode V2, and HubSpot or Salesforce for CRM data with a separate DPA for each.

How Do You Configure GA4 in a GDPR-Compliant Way?

Once the compliance configuration is in place, the GA4 lead attribution setup guide covers how to configure conversion events and CRM connections for accurate lead tracking.

GA4's default settings are not GDPR-compliant. Each setting below requires an active change from the default configuration.

• Consent Mode V2 via GTM: In GTM, use the Consent Initialization trigger type for all Google tags. This ensures tags check consent state before firing. Configure the GA4 Configuration tag to fire only when analytics_storage consent is granted.
• Data retention setting: Set to 14 months under Admin, Data Settings, Data Retention. This is the maximum recommended for most B2B use cases and reduces the data window while maintaining enough history for meaningful analyzis.
• Google Signals: Disable unless you have explicit consent for cross-device tracking. Google Signals enables remarketing audiences and demographic data but requires consent under GDPR. The default is on.
• Ads personalization: Disable in GA4 if you are not using GA4 audiences for Google Ads. This reduces data shared with Google's advertising systems and limits your processing exposure.
• User-ID feature: Only enable if you have a legitimate, documented purpose and users have consented to cross-session tracking. The default should be off unless there is a specific and justified need.
• IP anonymisation: GA4 anonymises IP addresses by default. This is not configurable and is a positive for compliance. Document this in your ROPA as a privacy-by-design control.

Which Analytics Tools Work Without Consent, and Which Do Not?

The guide on what to track and how to set it up covers the full event taxonomy for B2B analytics, including which events are worth the consent complexity and which can be replaced with simpler signals.

Understanding which tools require consent, and which do not, lets you make a deliberate decision about your analytics architecture rather than discovering compliance gaps after implementation.

• Tools that always require consent for EU visitors: GA4 uses cookies and device identifiers that constitute personal data. Hotjar and Microsoft Clarity capture session recordings and always require explicit consent. LinkedIn Insight Tag, Meta Pixel, and Google Ads cannot be justified under legitimate interest.
• Tools that can operate without consent: Plausible Analytics is cookieless, collects no personal data, and can operate without a consent banner for EU visitors under most interpretations. Fathom Analytics is similar in design and compliance posture. Self-hosted Matomo in cookieless mode with IP anonymisation can also operate without consent when properly configured.
• The honest trade-off: Privacy-first tools provide traffic volume, referrer data, and page-level engagement. They do not provide user-level journey data, cross-session attribution, or CRM-linked lead tracking. For B2B teams that need attribution, GA4 with Consent Mode V2 is the realistic choice. For teams prioritizing simplicity and compliance certainty, Plausible or Fathom are viable alternatives.

What Are the Broader Security and Data Handling Requirements That Affect Analytics?

The guide on B2B website security practices covers the technical controls, SSL, access management, and data handling, that sit alongside analytics compliance in a complete GDPR setup.

Most analytics compliance guides stop at the tracking tag level. The obligations continue into how analytics data is stored, who can access it, and how it responds to subject access requests.

• Data subject access requests and analytics data: If a visitor submits a DSAR requesting all data held about them, your analytics data falls in scope. GA4's UserID data can be deleted via the User Deletion API, but only if you can link a UserID to a specific individual. Document this process before you receive a request.
• Third-party analytics vendor DPAs: Every tool in your analytics stack that processes EU personal data must have a signed Data Processing Agreement. Review your GA4 account for the Google DPA. Check heatmap, chat, and form analytics tools separately.
• Analytics data in email marketing platforms: If GA4 data is pushed to HubSpot, Mailchimp, or similar platforms via audience imports, those platforms become processors of the data. Their DPAs and data handling must be reviewed as part of your compliance setup.
• Analytics cookie duration disclosure: Cookie banners must disclose the duration of each cookie. GA4's primary measurement cookie has a two-year default duration. This should be reviewed, disclosed, and ideally reduced to limit regulatory exposure.
• Staff access to analytics data: GA4 provides individual user-level reporting in some configurations. Role-based access in GA4 should be set so that only those with a documented need have access to user-level data.

Conclusion

A GDPR-compliant analytics setup for a B2B website is a technical architecture, not a banner. It requires a CMP that actually blocks tags, Consent Mode V2 that passes consent signals correctly, GA4 settings configured to minimize data collection, and documented agreements with every analytics vendor.

Audit your current setup in three steps: test whether your tracking tags fire before consent is given using GTM's preview mode with cookies blocked, check whether Consent Mode V2 is active in your GA4 configuration, and verify you have a signed DPA with each analytics vendor in your stack.

B2B Website Development

Websites That Win Enterprise Clients

We build high-converting B2B websites with modern no-code technology—designed to generate leads, build trust, and support your sales team.

Let's talk

Building a B2B Website With Analytics Compliance Built In From Day One

Most B2B analytics setups are compliant in the policy and non-compliant in the implementation. The CMP is present but does not block tags. Consent Mode V2 is not configured. DPAs with analytics vendors have never been executed. These are implementation failures, not legal gray areas.

At LowCode Agency, we are a strategic product team, not a dev shop. Our B2B website development process includes analytics architecture and GDPR compliance configuration from the start, not scrambled into compliance after launch.

• CMP selection and integration: We select and implement the right Consent Management Platform for your requirements, with server-side cookie blocking that genuinely prevents non-essential scripts from firing before consent is given.
• Consent Mode V2 configuration: We implement Consent Mode V2 through GTM, configure the Consent Initialization trigger for all Google tags, and verify correct consent state signaling before launch.
• GA4 compliance settings: We configure data retention, disable Google Signals by default, turn off ads personalization where not required, and document IP anonymisation in the ROPA.
• Privacy-first analytics evaluation: Where your attribution requirements allow it, we evaluate Plausible or Fathom as simpler alternatives that eliminate the consent complexity entirely and are compliant by design.
• DPA audit and execution: We identify every analytics vendor in your stack that processes personal data and verify that valid, current DPAs are in place before launch.
• ROPA documentation: We produce the analytics section of your Record of Processing Activities with the data collected, legal basis, retention period, and vendor details required for regulatory accountability.
• Full product team: Strategy, design, development, and QA from a single team that treats analytics compliance as a build requirement, not a post-launch legal task.

We have built 350+ products for clients including Coca-Cola, American Express, Sotheby's, Medtronic, Zapier, and Dataiku. We have implemented compliant analytics architectures across regulated B2B environments where data handling is scrutinised.

See our client results or get in touch to discuss what a compliant analytics setup looks like for your site and your attribution requirements.