What a CMP does in a B2B SaaS product (and what it doesn’t)
In a B2B SaaS product, a Consent Management Platform (CMP) helps you collect, store, and act on user choices about tracking and data processing—especially for cookies and similar technologies used for analytics, advertising, and personalisation. For UK GDPR and PECR-aligned implementations, a CMP typically shows a consent banner or preference centre, lets users accept or reject non-essential categories, and records the decision with a timestamp, policy version, and consent string or log entry. It can also support geo-targeting (for example, showing a UK/EEA banner), multi-language experiences, and role-based administration so teams can manage tags and consent settings without code changes.
A CMP also helps enforce those choices by controlling when scripts fire. Many CMPs integrate with tag managers and common vendors so that marketing tags, heatmaps, and A/B testing tools only load after the appropriate consent signal. For B2B SaaS, this matters across marketing pages, app sign-in pages, and in-product areas where product analytics tools may otherwise start collecting data immediately.
What a CMP doesn’t do: it doesn’t automatically make your processing “compliant” on its own. It won’t decide your lawful basis, write your privacy notice, or determine whether a specific cookie is “strictly necessary.” It also won’t fix poor data governance—such as unclear retention, uncontrolled access, or vendors added without review. And it’s not a substitute for consent flows inside the product (for example, email marketing opt-ins, in-app permissions, or customer-configured tracking for their own end users).
UK GDPR + PECR essentials for consent banners, cookies, and tracking
For a B2B SaaS website, cookie banners and tracking are mainly governed by two rulesets: UK GDPR (how you process personal data) and PECR (when you’re allowed to store/read data on a user’s device). In practice, PECR drives the banner: most non-essential cookies and similar technologies (pixels, SDKs, local storage, fingerprinting) require prior consent before they fire. UK GDPR then shapes what “valid consent” looks like and how you document it.
A consent banner should offer a genuine choice: “Accept all” and “Reject all” with equal prominence, plus granular controls (e.g., Analytics, Marketing, Functional). Avoid pre-ticked toggles and avoid loading tags until the user opts in. If you use legitimate interests for certain processing, that does not override PECR’s consent requirement for non-essential cookies.
Essential cookies (e.g., security, load balancing, login sessions) can usually run without consent, but you should still explain them in your cookie policy. For analytics, many B2B SaaS teams prefer consented analytics or privacy-reduced configurations; either way, ensure your CMP blocks analytics scripts by default and only releases them after opt-in.
Your CMP should also help with accountability: record consent logs (timestamp, categories, policy version, consent string), support easy withdrawal (“Manage cookies” link on every page), and handle regional rules so UK users see a UK-compliant experience. If you share data with third parties (ad platforms, product analytics, chat tools), list them clearly and keep your vendor list aligned with what actually loads on the site.
When you actually need consent vs when legitimate interests may apply
For a UK B2B SaaS website, the key split is usually between privacy (UK GDPR) and cookies/trackers (PECR). You may have a lawful basis like legitimate interests for some processing under UK GDPR, but still need consent to place certain cookies.
Consent is typically needed when you use non-essential technologies such as advertising cookies, cross-site tracking, many third-party marketing tags, or “share” widgets that set identifiers. In practice, this includes most behavioural analytics and marketing platforms where users can be profiled or tracked across sessions or sites. If you’re emailing individuals for marketing, consent may also be required depending on the channel and context (for example, rules differ for corporate vs individual subscribers), so your CMP should support clear opt-in choices and easy withdrawal.
Legitimate interests may apply for processing that’s genuinely necessary for your business and has minimal privacy impact, where people would reasonably expect it. Common B2B SaaS examples include basic first-party security logging, fraud prevention, service improvement using aggregated metrics, and responding to inbound sales enquiries. Even then, you should document a balancing assessment, provide transparent notices, and offer an opt-out where appropriate.
A good UK GDPR consent management platform helps you operationalise this split by blocking non-essential tags until consent, keeping an auditable record of choices, and letting you configure purposes like “analytics”, “marketing”, and “functional” so your site behaviour matches your lawful basis decisions.
CMP requirements checklist for B2B SaaS (web app + marketing site)
- UK GDPR + PECR coverage: Ensure the CMP supports consent for cookies and similar technologies (PECR) and records a lawful basis choice under UK GDPR where relevant (for example, consent for non-essential cookies).
- Granular controls: Category-level toggles (analytics, marketing, functional) plus vendor-level controls where third parties are used. Avoid “all-or-nothing” designs.
- Equal choice UX: “Accept” and “Reject” presented with comparable prominence, and a clear “Manage settings” route. No pre-ticked boxes for non-essential cookies.
- Geo and context targeting: Ability to show different experiences for UK/EEA vs rest-of-world, and separate rules for marketing site vs authenticated web app.
- Consent logging: Exportable audit logs with timestamp, consent state, policy version, and a pseudonymous identifier. Retention controls to match your internal privacy approach.
- Easy change and withdrawal: Persistent link/button to reopen preferences on every page (including inside the app), and immediate effect on tags once updated.
- Tag governance: Built-in tag blocking until consent, plus support for Google Tag Manager, server-side tagging, and custom scripts. Verify it can prevent “accidental firing” on SPA routes.
- Support for logged-in users: Options to tie consent to an account (where appropriate) without forcing identification, and to handle multiple devices/sessions sensibly.
- Third-party vendor management: Clear way to document vendors, purposes, and data sharing; support for IAB TCF only if you actually run adtech that needs it.
- Accessibility and performance: Keyboard navigable, screen-reader friendly, and lightweight to avoid harming Core Web Vitals.
- Security and reliability: EU/UK hosting options, strong SLAs, and role-based access for marketing vs engineering teams.
How to implement a CMP without breaking attribution, analytics, or product telemetry
Start by mapping every data flow your SaaS relies on: marketing tags (Google Ads, LinkedIn), web analytics, in-app analytics, error logging, A/B testing, and server-side events. List what fires on page load vs after login, and which vendors receive identifiers. This inventory tells you what must be blocked until consent and what can run under strictly necessary purposes.
Implement your CMP in three layers:
- Tag governance: Route all browser tags through a tag manager and set default states to “denied” for non-essential storage. Only release tags when the CMP signals consent. Avoid hard-coding pixels directly in the app.
- Attribution-safe fallbacks: Preserve campaign parameters (UTMs, gclid/msclkid) in first-party storage that’s strictly necessary for user-requested functionality (e.g., remembering a quote request). If consent is later granted, you can stitch the session by sending stored parameters with the first consented event.
- Telemetry separation: Split product telemetry into (a) essential operational logging (security, fraud prevention, uptime) and (b) behavioral analytics. Keep (a) minimal, pseudonymised where possible, and independent of marketing identifiers; gate (b) behind consent.
Use server-side collection for reliability: send events from your backend to analytics endpoints only after checking the user’s consent state stored in your database. For single-page apps, ensure the CMP exposes an event listener so route changes don’t bypass consent checks. Finally, validate with a test plan: compare pre/post-consent event counts, confirm no third-party requests fire before consent, and verify lead-source attribution remains consistent across web-to-product handoff.
How to map vendors, cookies, and tags to purposes (and keep it maintainable)
Start by building a single “tracking inventory” that links every vendor to the exact cookies and tags it sets. In a B2B SaaS stack, this usually includes your analytics, product analytics, chat/support, A/B testing, advertising/retargeting, and CRM enrichment tools. Create one row per vendor and include: vendor name, tag manager trigger, cookie names/domains, data sent (events/fields), and where it runs (marketing site, app, docs).
Next, map each vendor to a small set of purposes that match how you present choices in your consent banner. Keep purpose labels user-friendly (e.g., “Analytics”, “Personalisation”, “Marketing”) and avoid overlapping definitions. If a vendor does multiple jobs, split it by implementation: for example, run analytics in one tag and marketing pixels in another, so consent can control them independently.
Then map cookies and tags to the same purposes. In practice, your CMP should block tags by default and only fire them when the user has opted into the relevant purpose. Use a consistent naming convention in your tag manager (e.g., “ANL-”, “MKT-”, “PERS-”) and attach a single consent check variable to every tag, rather than custom logic per vendor.
To keep it maintainable, set a monthly review: reconcile new vendors, confirm cookie lists, and remove unused tags. Treat changes like code: version the inventory, require approvals, and document why each vendor is needed.
How to handle consent across subdomains, environments, and logged-in users
Start by deciding what “one choice” means in your B2B SaaS: a user’s consent should follow them wherever they reasonably expect it to, without accidentally leaking between unrelated contexts. In a CMP, configure cookie scope so preferences can be shared across subdomains (for example, app.yourdomain.com and docs.yourdomain.com) by setting the consent cookie on the parent domain (e.g., .yourdomain.com). Keep it limited to your brand domain; avoid broad scopes that could unintentionally include third-party properties.
Separate environments deliberately. Use different CMP property IDs (or separate configurations) for production, staging, and development. This prevents test consents contaminating real reporting and avoids users seeing inconsistent banners. If you must test on a production-like domain, isolate with a dedicated subdomain and a distinct consent cookie name.
For logged-in users, treat consent as a user preference you can persist server-side in addition to the browser cookie. Map the CMP consent string (or categories) to your user record after login, and re-apply it on new devices by passing the stored state to your CMP on first authenticated page load. Keep the browser in control: if a user withdraws consent in one session, update the server record promptly and propagate the change.
Finally, handle edge cases: if a user is logged out, fall back to device-level consent; if they switch accounts, reset to the correct user profile; and if you use SSO across subdomains, ensure the consent signal is available wherever tags fire.
How to set up consent mode and server-side tracking in a UK-friendly way
Start by choosing a UK/EU-focused consent management platform (CMP) that supports Google Consent Mode v2 and can record consent signals in a way you can evidence later. Configure it to show a clear banner on first visit, with separate choices for analytics and advertising, plus an easy “change preferences” link in your footer. Avoid pre-ticked boxes and make “Reject non-essential” as easy to find as “Accept”.
Next, implement Consent Mode on your site so tags adapt to the user’s choice. In Google Tag Manager (web), set default consent to denied for ad and analytics storage, then update consent based on the CMP event. Keep your tag firing rules strict: only load analytics/marketing tags after consent, while essential tags (security, load balancing, login) can run without it.
For server-side tracking, create a server-side GTM container and route measurement through a first-party subdomain (for example, metrics.yourdomain.co.uk). Configure your CDN/DNS, then forward requests from your web container to the server container. In the server container, enforce consent again: drop or anonymise identifiers when consent is denied, and only set first-party cookies when consent is granted. Use allowlists to block unexpected vendors and strip URL parameters that could contain personal data.
Finally, document what fires under each consent state, test with browser dev tools, and keep a simple change log so your setup stays auditable as your B2B SaaS grows.