Before You Start

Cookie consent is one of the most misunderstood compliance requirements in nonprofit digital. Most organisations either over-engineer it — spending weeks on configuration that isn't warranted by their actual tracking setup — or under-engineer it, running a banner that looks compliant but isn't blocking anything correctly.

This guide covers the setup I use for nonprofit clients on Webflow. It's specific and sequential. By the end you'll have a working implementation that correctly gates analytics and advertising tags behind user consent, passes Google Consent Mode V2 signals, and is defensible to the ICO if questioned.

What you need before starting:

• A Webflow site on a paid hosting plan with a custom domain connected
• A Google Tag Manager account with the GTM container code not yet added to the site (or already added — this guide covers both)
• A CookieYes account (free plan covers most nonprofits; paid plan required for advanced features including custom domains on the consent log)
• Access to your GA4 property
• A clear list of every third-party tool your site uses that sets cookies or collects data

Two scenarios this guide covers:

Scenario A — Analytics only (GA4, Webflow Analyse). The client runs no advertising. The setup is simpler: CookieYes, GTM, GA4, Consent Mode V2 for analytics signals. No advertising consent signals required.

Scenario B — Full advertising consent (GA4 + Meta Pixel and/or LinkedIn Insight Tag). The client runs or plans to run paid advertising targeting European audiences. Full Consent Mode V2 implementation required including ad storage, ad user data, and ad personalisation signals.

If your organisation operates in or targets European countries, Consent Mode V2 is not optional — it's a legal requirement for running Google advertising products and a strong expectation under GDPR for any consent-based tracking. If you only operate in the UK with no European advertising, the GDPR obligations remain but the Google advertising enforcement mechanism is less direct.

Start with Scenario A and add Scenario B elements if they apply to your organisation.

Step 1: Create Your CookieYes Account and Connect Your Domain

Go to cookieyes.com and create an account. On the free plan, you can manage one domain with basic consent collection and cookie scanning. For most nonprofits that don't need the consent audit log or multi-domain management, the free plan is sufficient.

Once logged in, add your website domain. CookieYes will scan your site for cookies and categorise them automatically. The scan isn't exhaustive — it catches most common cookies but won't find everything, particularly cookies set by third-party scripts that load conditionally. Review the results and manually add any cookies you know the site sets that the scan missed.

CookieYes organises cookies into four categories:

• Necessary — session cookies, security tokens. Cannot be declined.
• Functional — preference cookies, language settings.
• Analytics — GA4, Webflow Analyse, Microsoft Clarity.
• Advertisement — Meta Pixel, LinkedIn Insight Tag, Google Ads.

Confirm every cookie on your site is in the correct category. An analytics cookie miscategorised as Necessary will fire without consent — a compliance failure.

Screenshot placement: [Screenshot showing the CookieYes dashboard with a domain added and cookie scan results displayed across the four categories]

Step 2: Style the Banner to Match the Brand

CookieYes provides a default banner layout that works well without modification. I don't adjust the layout, position, or structure — the default is designed for compliance and usability and doesn't need changing.

The only thing I style is the buttons, so they match the client's brand colours. In CookieYes's banner customisation settings:

1. Navigate to the Customise section of your CookieYes dashboard
2. Find the button colour settings
3. Set the Accept button background colour to the client's primary brand colour
4. Set the button text colour to ensure sufficient contrast (WCAG AA requires a minimum contrast ratio of 4.5:1 for normal text)
5. Apply the same logic to the Decline and Manage Preferences buttons

Leave everything else at the default. The banner position (bottom bar or popup), the text layout, and the preference centre design are all functional as they come. Adding custom CSS or structural changes to the banner introduces the risk of breaking consent flows — not worth it for aesthetic reasons.

Screenshot placement: [Screenshot showing CookieYes banner customisation panel with button colour fields highlighted]

Step 3: Install CookieYes via the Native GTM Integration

CookieYes integrates with Google Tag Manager natively, which is the recommended installation method. It means CookieYes loads through GTM rather than requiring a separate script in your Webflow custom code, and it allows GTM to receive consent signals directly from CookieYes without additional configuration.

First, if GTM isn't already installed on the Webflow site:

In GTM, create a new container for the site (or use an existing one). GTM provides two code snippets — one for the <head> and one for the <body>. In Webflow, add these in the site's Custom Code settings:

• Head code snippet → Webflow Site Settings → Custom Code → Head Code
• Body snippet → Webflow Site Settings → Custom Code → Footer Code

Screenshot placement: [Screenshot showing Webflow's Custom Code settings panel with the head and footer code fields]

Publish the Webflow site after adding the GTM snippets so they go live on the domain.

Now install CookieYes via GTM:

1. In your CookieYes dashboard, navigate to the Integration or Installation section
2. Select Google Tag Manager as the installation method
3. CookieYes will provide a GTM tag template — follow the instructions to import it into your GTM container, or find the CookieYes template in the GTM Community Template Gallery
4. In GTM, go to Tags → New → search for CookieYes in the template gallery
5. Add the CookieYes tag with your CookieYes site ID (found in your CookieYes dashboard)
6. Set the trigger to Consent Initialization — All Pages — this ensures CookieYes loads before any other tags attempt to fire

Screenshot placement: [Screenshot showing GTM tag creation with CookieYes template selected and Consent Initialization trigger applied]

Step 4: Set Consent Defaults to Denied

Before any other tag fires — before GA4, before Meta Pixel, before anything — GTM needs to establish default consent states. The default for all signals must be denied. This is the "privacy by default" principle required by GDPR.

In GTM, create a new tag:

1. Tag type: Google Tag (or Custom HTML if using the legacy consent initialisation method)
2. Tag ID: your GA4 Measurement ID (format: G-XXXXXXXXXX)
3. Add the following configuration:

gtag('consent', 'default', {  'analytics_storage': 'denied',  'ad_storage': 'denied',  'ad_user_data': 'denied',  'ad_personalization': 'denied',  'wait_for_update': 2000});

4. Set the trigger to Consent Initialization — All Pages
5. This tag must fire before the CookieYes tag — set tag sequencing in GTM to ensure the consent default fires first, or use a lower tag firing priority

The wait_for_update value (2000 milliseconds) tells Google tags to pause for two seconds while waiting for the CMP to update consent. This prevents a race condition where GA4 attempts to fire before CookieYes has loaded and communicated the user's consent choice.

Screenshot placement: [Screenshot showing the GTM consent default tag configuration with the denied default values and Consent Initialization trigger]

When a user accepts analytics cookies, CookieYes fires a consent update event through GTM:

gtag('consent', 'update', {  'analytics_storage': 'granted'});

For Scenario B clients who accept advertising cookies:

gtag('consent', 'update', {  'ad_storage': 'granted',  'ad_user_data': 'granted',  'ad_personalization': 'granted'});

CookieYes handles firing these update events automatically via the GTM integration — you don't need to write this code manually. It fires when a user makes their consent choice in the banner.

Step 5: Install GA4 via GTM with Consent Mode Triggers

With consent defaults in place, install GA4 through GTM:

1. In GTM, create a new tag → Google Analytics: GA4 Configuration
2. Enter your GA4 Measurement ID
3. Set the trigger to All Pages
4. In the tag's Advanced Settings, enable Consent Checks — set the tag to require analytics_storage consent before firing

When analytics_storage is denied, GA4 will not set cookies or collect user-level data. When consent is granted, GA4 fires normally. Consent Mode V2 allows GA4 to collect modelled data even when consent is denied — this gives you aggregated, anonymised insights without violating individual consent preferences.

Screenshot placement: [Screenshot showing GA4 Configuration tag in GTM with consent check settings visible]

Step 6: Install Meta Pixel and LinkedIn Insight Tag (Scenario B Only)

Skip this step if your organisation doesn't run advertising on Meta or LinkedIn.

Meta Pixel:

1. In GTM, create a new tag → Custom HTML (or use the Meta Pixel template if available in your GTM container)
2. Paste the Meta Pixel base code from your Meta Events Manager
3. Set the trigger to All Pages
4. In Advanced Settings, require ad_storage and ad_user_data consent before the tag fires

LinkedIn Insight Tag:

1. In GTM, create a new tag → LinkedIn Insight Tag (use the GTM template from the Community Gallery)
2. Enter your LinkedIn Partner ID
3. Set the trigger to All Pages
4. Require ad_storage consent before firing

Neither tag should fire until the user has accepted advertisement cookies. Verify this in Step 7.

Step 7: Webflow Do Not Track Setting (Webflow Analyse Clients Only)

If your client is paying for Webflow Analyse — Webflow's built-in analytics — you need to configure one additional setting in Webflow's site settings.

In Webflow, navigate to Site Settings → Integrations or Analytics (the label may vary as Webflow updates its interface). Find the Webflow Analyse settings and enable Do Not Track by Default. This setting tells Webflow Analyse to respect the user's browser Do Not Track signal and to not collect data until consent is confirmed.

Without this setting, Webflow Analyse collects data regardless of the user's CookieYes consent choice — because Webflow Analyse is a platform feature rather than a GTM tag, it doesn't receive GTM consent signals automatically.

If your client is not paying for Webflow Analyse, skip this step entirely. The standard Webflow site plan doesn't include Analyse, and this setting is irrelevant without it.

Screenshot placement: [Screenshot showing Webflow site settings with the Webflow Analyse Do Not Track toggle visible and enabled]

Step 8: Verify the Implementation

Verification is not optional. A consent implementation that looks correct but isn't blocking tags is worse than no banner at all — it gives the appearance of compliance without the substance.

Test 1: Open the site in an incognito window.

Open your browser's developer tools (F12) and go to the Network tab. Filter by google-analytics.com. Load the page. Before interacting with the consent banner, confirm that no GA4 requests appear in the Network tab. If GA4 is firing before consent is given, the consent default is not configured correctly.

Screenshot placement: [Screenshot showing browser developer tools Network tab with GA4 domain filter applied and no requests visible before consent]

Test 2: Accept analytics consent and confirm GA4 fires.

Click Accept on the CookieYes banner. Confirm that GA4 requests now appear in the Network tab. This confirms the consent update event is working and GA4 is responding to it correctly.

Test 3: Use GTM Preview Mode.

In GTM, open Preview Mode and connect to your live site. You'll see a real-time panel of every tag, trigger, and variable. Check:

• Does the CookieYes tag fire on Consent Initialization?
• Does the consent default tag fire before GA4?
• Does GA4 remain blocked until consent is granted?
• When you accept cookies, does GA4 fire immediately?

Screenshot placement: [Screenshot showing GTM Preview Mode panel with tag firing sequence visible — CookieYes and consent default firing before GA4]

Test 4: Decline all cookies and verify nothing fires.

Open a fresh incognito window, load the site, and click Decline All in the CookieYes banner. Confirm in the Network tab that no analytics or advertising requests appear. If any do, there is a consent configuration error that must be fixed before the site goes live.

Common Problems and How to Fix Them

GA4 fires before consent is given

The consent default tag is either not configured, not set to fire on Consent Initialization, or firing after the GA4 tag. Check tag firing priority in GTM and confirm the consent default has a lower priority number (higher priority) than GA4.

CookieYes banner appears but consent choices aren't respected

The CookieYes GTM integration may not be passing consent signals correctly. Confirm the CookieYes tag is using the Consent Initialization trigger and that the GTM container has been published after the CookieYes template was added.

Webflow Analyse is collecting data despite cookie decline

The Do Not Track setting in Webflow site settings hasn't been enabled. This is a separate configuration from GTM — GTM signals don't reach Webflow Analyse.

The banner doesn't appear on the site

The GTM container code hasn't been published after adding the CookieYes tag, or the GTM snippets in Webflow Custom Code weren't saved correctly. Confirm the GTM container is published and the Webflow site has been republished after adding the custom code.

A Note on When Full CMP V2 Is Required

Not every nonprofit needs the full Consent Mode V2 advertising configuration.

If your organisation doesn't run Google Ads, Meta advertising, or LinkedIn campaigns targeting European audiences, the advertising consent signals (ad_storage, ad_user_data, ad_personalization) are less immediately critical — there are no advertising tags to gate. You still need analytics consent configured correctly for GDPR compliance, but the advertising layer of CMP V2 is only enforced by Google and Meta when you run advertising through their platforms.

If you do run advertising targeting European audiences — or plan to — implement the full configuration from the start. Retrofitting advertising consent signals after campaigns are already running is more disruptive than doing it correctly upfront.

When in doubt, implement the full configuration. The additional steps are minimal and the protection it provides is complete.

Further Reading

• GDPR Compliance for Nonprofit Websites: What Your Board Needs to Know
• How to Prepare Your Nonprofit Website to Go Live
• WCAG AA Accessibility on Webflow: What Nonprofits Need to Implement