Tracking despite consent loss

Tracking loss depends heavily on the setup — the question isn't whether you lose, but how much.

Classic browser tracking without server-side: 30–50% data loss is standard today. For iOS-heavy audiences (premium, health, beauty), more toward 50%; for Android-heavy B2B audiences, toward 30%.

With a server-side setup & CAPI: match rate rises to 70–90% — depending on data quality (hashed email, hashed phone, click ID, IP).

With your own data lake: 95%+ data retention, because you don't depend on platform reports but analyze your own raw data.

What's “normal” says nothing about what's possible. 30–50% loss is common — but doesn't mean you have to accept it.

There are three key metrics — and all three can be checked concretely.

1. Event match rate (EMQ in Meta): visible in Meta Events Manager. Values below 6.0 (out of 10) are critical, 7.0–8.5 is good, 9.0+ is very good. A low EMQ means: Meta can't assign your events to user profiles — optimization suffers.

2. Server-side vs. browser discrepancy: in the Tag Manager container, compare the number of server-side events vs. browser pixels. With a clean setup, server-side should see 15–30% more events than browser — otherwise the advantage of server-side is lost.

3. Platform report vs. real sales: the most honest test — compare conversions in the Meta or Google report with the actual orders from the shop backend. A discrepancy under 10% is very good, 10–20% is normal, more than 20% means broken tracking.

What these values say about your stack: all three metrics must be in the green zone at the same time.

One of the most frequent questions — and one of the most frequently misunderstood. The short answer: you need both, in parallel.

The pixel (browser tracking) sees everything that happens in the browser (UTM parameters, click IDs, referrer), but is heavily restricted by ITP, ad blockers and consent refusal.

CAPI (Conversions API) sends conversions server to server, independent of the browser. It's not blocked by ITP or ad blockers. It needs richer data (hashed email, phone, IP, user agent) for good matching.

With event deduplication, Meta automatically detects whether an event came from the pixel and CAPI — and counts it only once. You get the advantages of both worlds: browser click data + server-side robustness.

Rule of thumb: the pixel alone is no longer sufficient today. CAPI alone loses click attribution. Both together with clean deduplication is the standard.

Server-side isn't automatically GDPR-compliant, but it's the better foundation for GDPR compliance than pure browser tracking.

• What server-side enables: pseudonymization on the server (hashing email/phone/IP), selective data sharing per platform, audit logs for all data transfers, control over sub-processors
• What server-side doesn't solve: the consent requirement (user consent is still needed), US data transfer (the Schrems II risk remains), the cookie-banner requirement for first-party cookies
• What you need: a consent management platform (Cookiebot, Usercentrics), a privacy policy noting server-side tracking, possibly a DPIA, contractual arrangements with sub-processors — I set this up by default.

BigQuery is the strategic question behind server-side tracking — and it's worth it more often than you'd think.

What BigQuery costs monthly: for mid-sized setups (1–5M events/month) typically €30–100 storage + query costs. Scales linearly with volume.

Rule of thumb: if you're serious about tracking and see data as a long-term asset, BigQuery (or an equivalent like Snowflake) is the one-time investment you'll have to make eventually anyway. The earlier, the cheaper.

• When BigQuery makes sense: more than 100k pageviews/month (GA4 sampling otherwise critical), several data sources to connect, custom attribution models, compliance requirements for your own raw data
• When it's overkill: small sites with a clear funnel and one channel, no SQL/dbt resources on the team, pure performance reporting is enough

Yes — and then it's often especially valuable. A server-side setup doesn't automatically mean a good setup — many implementations still leave 30–50% of the data on the table without anyone noticing.

What you get: a match-rate check, event-deduplication verification, reconciliation of pixel ↔ CAPI ↔ actual sales. Plus an action plan with concrete optimization levers.

Typical findings in existing setups: misconfigured triggers in the sGTM container, missing user properties in CAPI, unused optimization fields, enhanced conversion mode not activated.

How the collaboration works: I clarify the technical findings directly with your dev team or external agency. No provider switch needed.