Event Tracking and Consent Mode: Engineering Data Collection Without Losing Performance

Introduction: Tracking Without Trust Is a Liability

The world after GDPR is not a world without data. It is a world where data must be collected with care, consent and transparency, or you risk regulatory action and user mistrust. In the UK, the ICO outlines strict standards for valid consent. In DACH countries, regulators enforce them even more tightly, particularly when it comes to event tracking, cookies and analytics.

I help clients build technical solutions that collect the signals they need for optimisation and attribution, while respecting the user's right to opt out. This article explains how I use Google Consent Mode, server side Tag Manager, and fallback logic to achieve both compliance and marketing performance.

Understanding Consent Mode: The Core Idea

Consent Mode is a Google framework that lets you adjust how tags behave based on the user's consent state. If the user agrees to marketing or analytics cookies, everything fires normally. If not, tags still fire, but without setting or reading cookies, and without sending personal identifiers.

Instead of blocking tags entirely, Consent Mode signals:

analytics_storage: whether analytics cookies are allowed
ad_storage: whether advertising cookies are allowed
functionality_storage: whether non essential UX cookies are allowed

You configure this through the gtag or Google Tag Manager layer:

window.gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied'
});

Then update it once consent is granted:

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

Consent Mode ensures that your tag ecosystem respects the user's choice while still collecting anonymous, aggregate data that Google can use for modelling.

Practical Example: SaaS Free Trial Tracking

Let's say you run a SaaS product with a free trial signup. You want to track which campaigns drive trial signups, but roughly 40% of your German visitors decline cookies. Without Consent Mode, you would lose all attribution data for those visitors.

With Consent Mode enabled, Google can still model conversions based on aggregate patterns. In one project I worked on, we recovered approximately 25% of previously "invisible" conversions through this modelling, enough to significantly improve our Google Ads bidding accuracy.

Why This Matters More in DACH

In Germany and Austria, regulators like the DSK and Austrian DPA (Datenschutzbehörde) demand:

Real opt in before any tracking cookies
Equal prominence of accept and reject buttons
Full audit trail of consent (timestamp, scope, version)

In contrast, the UK ICO allows cookie walls in some cases and does not yet demand the same server side safeguards. Still, I apply the DACH standard everywhere, because it future proofs the setup and avoids reputational risk.

The Consent Rate Problem

In my experience, DACH consent rates typically hover around 55 to 65%, while UK rates often reach 75 to 85%. This means you can lose up to 45% of your tracking data in Germany if you do not have proper fallback mechanisms in place.

For an eCommerce client selling premium outdoor gear, this translated to roughly €180,000 in annual ad spend being optimised against incomplete data. That is a significant blindspot.

Server Side GTM: A Privacy Upgrade

I implement server side Google Tag Manager on most of my projects. Why?

Tags fire through your own subdomain (e.g. tag.yoursite.com), reducing third party exposure
You can strip IP addresses, User Agent or other identifiers
You control which data is passed to vendors, and which is suppressed

The architecture is simple:

User browser sends event to your endpoint (e.g. via GTM client)
That event hits your Tag Manager container running on App Engine, Cloud Run or your own server
Server logic checks consent and filters event data accordingly

This reduces risk significantly. You are no longer blindly sending raw data to Google, Meta, or others. You inspect and control it first.

Cost Considerations

Server side GTM is not free. You will pay for compute resources, typically around £30 to £100 per month depending on traffic. For most businesses doing £50k+ monthly revenue online, this is negligible compared to the compliance risk and data quality improvements.

First Party Event Tagging

For clients in Germany or Switzerland, I often bypass GA4 or Meta Pixel entirely for some flows and use custom endpoints to log user behaviour in first party databases.

Example:

fetch("/events", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    event: "product_viewed",
    product_id: "1234",
    consent: localStorage.getItem("userConsent")
  })
});

These are stored in PostgreSQL or BigQuery, anonymised, and later joined with CRM or campaign data (only where lawful).

Practical Example: eCommerce Checkout Funnel

For a Solidus based fashion retailer, I built a first party event pipeline that tracks:

Product views with category and price band (no personal data)
Add to basket events with product count
Checkout initiation with cart value ranges (e.g. £50 to £100, £100 to £200)
Purchase completion with order ID (hashed for privacy)

This data flows directly to our BigQuery warehouse, where we can analyse funnel drop offs without relying on third party cookies at all. The retailer now has complete visibility into their conversion funnel regardless of consent state.

Fallback Modelling: Still Measuring When Consent Is Denied

When consent is denied, you lose user level granularity, but not all signal. Google uses conversion modelling to estimate impact. I supplement this with server side logic:

Count consent denied sessions separately
Model conversion lag and attribution curves using observed data
Use cohort level metrics (e.g. campaign → CTR → anonymous conversion) for optimisation

This lets my clients preserve directionally accurate data for decisions, without breaching rules.

The Maths Behind Modelling

If you have a known conversion rate $CR_{consented}$ for users who accepted tracking, and you know the proportion of traffic that declined consent $p_{declined}$ , you can estimate total conversions as:

C_{total} \approx C_{observed} + (Sessions_{declined} \times CR_{consented} \times \alpha)

Where $\alpha$ is an adjustment factor accounting for potential behavioural differences between consenters and non consenters. In practice, I find $\alpha$ typically ranges from 0.7 to 0.9, as privacy conscious users tend to convert at slightly lower rates.

Implementation Checklist

Here is what I typically set up for a new client:

Consent Management Platform – Cookiebot, Usercentrics or similar, configured for proper DACH compliance
Consent Mode v2 – Implemented with default denied state and proper update triggers
Server Side GTM – Running on Cloud Run with custom domain
First Party Event Layer – For critical conversion events that must not be lost
BigQuery Export – Raw event data flowing to warehouse for custom analysis
Fallback Dashboard – Blended metrics combining consented and modelled data

Final Thought: Privacy First Is Performance Ready

You do not need to break the law to grow fast. With the right architecture, you can collect high value signals, optimise campaigns and attribute results, while treating user data with respect.

If your tracking setup still relies on hope, tags and disclaimers, I can help you engineer a consent aware, performance optimised system that works in the UK, in DACH and beyond, and does not collapse at the next audit.