Analytics & Consent on Webflow: GTM, GA4, and Consent Mode V2 with CookieYes
Key takeaways
- Set all consent defaults to denied before any tag fires, following GDPR's privacy-by-default principle.
- Install CookieYes through the native GTM integration using the Consent Initialization trigger.
- Categorise every cookie correctly, since an analytics cookie marked Necessary fires without consent.
- Consent Mode V2 is a legal requirement when running Google advertising to European audiences.
- Enable Webflow Analyse's Do Not Track setting, as it ignores GTM consent signals.
- Verify by testing that no analytics tags fire before consent and none fire after declining.
Summary
A step-by-step guide to setting up CookieYes, Google Tag Manager, and Consent Mode V2 on a Webflow nonprofit website — including when you need full CMP v2 and when you don't.
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.
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:
- Navigate to the Customise section of your CookieYes dashboard
- Find the button colour settings
- Set the Accept button background colour to the client’s primary brand colour
- Set the button text colour to ensure sufficient contrast (WCAG AA requires a minimum contrast ratio of 4.5:1 for normal text)
- 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.
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
Publish the Webflow site after adding the GTM snippets so they go live on the domain.
Now install CookieYes via GTM:
- In your CookieYes dashboard, navigate to the Integration or Installation section
- Select Google Tag Manager as the installation method
- 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
- In GTM, go to Tags → New → search for CookieYes in the template gallery
- Add the CookieYes tag with your CookieYes site ID (found in your CookieYes dashboard)
- Set the trigger to Consent Initialization — All Pages — this ensures CookieYes loads before any other tags attempt to fire
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:
- Tag type: Google Tag (or Custom HTML if using the legacy consent initialisation method)
- Tag ID: your GA4 Measurement ID (format: G-XXXXXXXXXX)
- Add the following configuration:
- Set the trigger to Consent Initialization — All Pages
- 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.
When a user accepts analytics cookies, CookieYes fires a consent update event through GTM:
For Scenario B clients who accept advertising cookies:
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:
- In GTM, create a new tag → Google Analytics: GA4 Configuration
- Enter your GA4 Measurement ID
- Set the trigger to All Pages
- 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.
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:
- In GTM, create a new tag → Custom HTML (or use the Meta Pixel template if available in your GTM container)
- Paste the Meta Pixel base code from your Meta Events Manager
- Set the trigger to All Pages
- In Advanced Settings, require ad_storage and ad_user_data consent before the tag fires
LinkedIn Insight Tag:
- In GTM, create a new tag → LinkedIn Insight Tag (use the GTM template from the Community Gallery)
- Enter your LinkedIn Partner ID
- Set the trigger to All Pages
- 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.
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.
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?
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.
Step 3: Publish the GTM Container
GTM has its own publishing step separate from Webflow. After any change in GTM, click Submit, add a version name and description, and click Publish. GTM maintains a full history of published versions, so any change can be rolled back. Write descriptive version names — they make debugging much easier later.
What GTM Is Not the Right Tool For
GTM is excellent for deploying third-party tags. Advanced event tracking — scroll depth events, form submission tracking, button click events, conversion tracking — requires someone with GTM and analytics experience to configure. I install GTM and configure GA4 and consent tags, but I'm explicit with clients that advanced event tracking is a separate engagement handled by a digital marketer or analytics specialist.
Step 1: Create a GA4 Property
Go to analytics.google.com and sign in with the Google account your organisation uses for analytics. If you do not have an account yet, you will be prompted to create one.
Click Admin (the gear icon at the bottom left). Under the Property column, click Create Property. Enter your organisation’s name as the property name. Select your reporting time zone (this affects how days are counted in reports) and your currency.
On the next screen, select Nonprofit as the industry category if available, otherwise select the closest match. For business size, select the range that fits your organisation. Click Create.
Step 2: Set Up a Web Data Stream
After creating the property, GA4 will ask you to set up a data stream. Select Web. Enter your website URL (e.g. www.yourorganisation.org) and give the stream a name (e.g. ‘Main Website’).
Leave Enhanced Measurement enabled — this automatically tracks page views, scrolls, outbound clicks, site search, and file downloads without any additional configuration. These are useful baseline metrics for nonprofit websites.
Click Create Stream. You will see a Measurement ID that starts with G-. Copy this ID. You will need it in the next step.
Step 6: Configure Key Events for Nonprofits
GA4 uses Key Events (previously called Conversions) to track the actions that matter most. For nonprofit websites, the key events to configure are:
Donation completions. If your donation platform (Fundraise Up, Donorbox, every.org, Givebutter) fires a JavaScript event or redirects to a thank-you page after a completed donation, you can track this as a key event. The exact implementation depends on your donation platform — most provide GTM integration documentation.
Form submissions. Webflow native forms trigger a form submission event that GA4’s Enhanced Measurement can detect automatically. Check whether your contact, volunteer sign-up, or enquiry forms are appearing in GA4 under Events. If they are, you can mark them as Key Events by clicking the toggle in the Events list.
Newsletter sign-ups. If your email sign-up is handled through a third-party embed (Mailchimp, Campaign Monitor), you may need a custom event tag in GTM to track completions. This typically involves firing a tag when the user reaches the thank-you state of the sign-up widget.
File downloads. GA4’s Enhanced Measurement already tracks file downloads (PDFs, documents). Check under Events for file_download events. For nonprofit websites, this captures downloads of annual reports, governance documents, and impact reports — all useful signals of funder engagement.
To mark any event as a Key Event, go to Admin → Events, find the event in the list, and toggle the Mark as key event switch.
Step 7: Link Google Search Console
If your organisation has Google Search Console verified (and it should — see Technical SEO Audit for Nonprofits), link it to GA4 for integrated search data.
In GA4, go to Admin → Product Links → Search Console Links. Click Link and follow the prompts to connect your Search Console property. This allows you to see search queries, landing pages, and search performance data directly within GA4 reports.
Step 8: Set Up a Basic Reporting View
GA4’s default reports are adequate for most nonprofit websites. The reports you should review monthly are:
Acquisition overview. How people find your site — organic search, direct, social, referral. This tells you which channels are driving traffic and where to invest effort.
Engagement overview. Which pages people visit, how long they stay, and what actions they take. Focus on your programme pages, donation page, and governance section.
Key Events report. How many donations, form submissions, and newsletter sign-ups occurred. This is the data your Board actually needs to see.
For how to translate these metrics into Board-level reporting, see the upcoming post on Website Analytics That Matter for Board Reporting.
What GA4 Does Not Tell You
GA4 tells you what is happening on your website. It does not tell you why. A drop in traffic could be a seasonal pattern, a technical problem, or a content relevance issue. A low conversion rate on your donation page could be a design problem, a trust problem, or a targeting problem.
Analytics data is an input to decision-making, not a substitute for it. Combine what GA4 shows with stakeholder feedback, accessibility testing, and periodic content audits to build a complete picture of how your website serves the organisation.
For the broader performance monitoring framework, see Website Performance Monitoring for Nonprofits. For setting up the tag management foundation that GA4 depends on, see Google Tag Manager Setup for Webflow Nonprofits.
A Blueprint Audit maps this across your own site, as part of a full governance diagnostic.
Further Reading
Blueprint Audit
See what a funder sees.
The Blueprint Audit is a £2,500 governance diagnostic with a Board-ready roadmap. It stands alone, with no obligation to continue.
Related resources
How to Optimise Nonprofit Website Images for Performance and Accessibility on Webflow
How to Set Up Webflow Forms for Nonprofit Data Collection: Contact, Volunteer, and Event Registration