Skip to main content

Marketing & Analytics Tools

GA4 setup done properly: e-commerce event tracking that matches your checkout actually completing, Consent Mode v2 configured so EU visitors don't destroy your data, and server-side tagging when client-side blockers start costing you numbers. Typical project: a GA4 account that has been running for six months, is missing half of its transactions because of ad-blocker losses, and needs a server-side migration plus Consent Mode v2 wiring.

Best fit
EU merchants where consent-mode compliance isn't optional, teams with an existing GA4 account that nobody trusts the numbers on, or anyone planning paid acquisition who needs the conversion signal clean.
Not a fit
sites under 1,000 monthly sessions (the data is too sparse to be useful), or teams with nobody internally to act on the reports.

Common reasons clients come to us with this

The first scenario, the one we see most often, is a GA4 account that's been running for six to twelve months and the e-commerce numbers don't match the order management system. Off by 15%, off by 30%, sometimes off by half. The cause is almost always one of three things: ad-blocker losses on the client side, Consent Mode v2 misconfigured so consent-denied traffic isn't being modeled, or purchase events firing on a thank-you page that some users skip via a payment redirect. We figure out which one in week one.

The second is a merchant about to start paid acquisition (Google Ads, Meta, TikTok) who realizes their conversion signal is unreliable, and any optimization the platforms do based on that signal is going to be optimizing the wrong thing. Spending 3,000 EUR a month on Google Ads with broken conversion tracking is worse than spending zero, because the algorithm is actively learning to find the wrong customers. We come in before the campaigns ramp, not after.

The third is a compliance push. The merchant got a letter from the Latvian, Estonian, or German data-protection authority about cookie consent or analytics-without-consent, and they need to be on Consent Mode v2 with a properly configured CMP yesterday. We've done this one enough times to have a 48-hour fix kit: Cookiebot or Iubenda configuration, GTM consent triggers, GA4 server-side tagging where it makes sense, and a written audit document we hand over so the client has something to send back to the regulator.

Phases / Timeline

A typical analytics engagement runs four to six weeks. Week one is the audit. We get read access to GA4, Google Tag Manager, the CMP, the Search Console, and the order management system the merchant uses for the source-of-truth revenue number. We compare three windows: GA4 reported revenue, GTM events fired, and actual orders. The gap between those three is the project. By Friday of week one we have a written document that says where each of the broken pieces is.

Weeks two and three are the rebuild. Tag Manager gets rewritten with a clean structure (one container, named triggers, no orphan tags from a previous agency), Consent Mode v2 wired through to the CMP with proper update calls, and the e-commerce events set up to match the actual GA4 schema. If the data is leaking enough that client-side tagging won't recover it, we set up server-side GTM on a gtm.merchant.com subdomain. That's about a 20 EUR/month Google Cloud Run bill plus a one-time setup fee, and it usually recovers 15 to 25% of the lost data.

Week four is verification. We run real test purchases through the checkout, compare GA4 against the OMS for that day, and tune until the gap is under 5%. We deliver a Looker Studio dashboard the client can actually read (not the GA4 default reports, which nobody trusts), a written runbook for when something breaks again, and a 30-day post-launch check-in where we look at the data again and confirm nothing has regressed.

Got a project that needs sorting?

Tell us what's broken and we'll tell you whether we can help.