Conversion tracking that your ad platforms and your bank account both agree on

Everything between a click and your reports. That means GA4 events, key events and audiences configured to your business model; a rebuilt and documented Google Tag Manager container; server-side tagging and Meta Conversions API; enhanced conversions for Google Ads; consent mode; cross-domain measurement where your funnel needs it; and a UTM convention your team can follow. The work is scoped from the audit, so you see the specific list for your stack before committing rather than buying a generic package.

A typical audit takes two to three business days and a full implementation about a week. Complex stacks — multiple domains, a headless storefront, server-side tagging with several destinations, or a CRM integration — can take two. The audit comes first and is deliberately separable: you get the findings and a prioritised list of what is broken, and you can act on that yourself, hand it to your developer, or have us implement it.

Server-side tracking routes conversion events through a server you control before they reach Google or Meta, instead of relying on a pixel in the visitor's browser. You need it if a meaningful share of your revenue comes from paid media, because browser tracking prevention and ad blockers now hide a substantial portion of conversions from the platforms that are bidding on your behalf. If you spend very little on ads and use analytics mainly for directional reporting, browser-side tracking with clean configuration may be enough.

A large share of them, though nobody honest will promise all. Events sent from your server are not subject to browser-side tracking prevention, so purchases that a client-side pixel silently drops still reach the platform, deduplicated against the browser event so nothing is double-counted. The practical effect is that the platforms see more of the conversions that actually happened, which improves both the accuracy of your reporting and the quality of what smart bidding is learning from.

Because they are measuring different things, and some of the difference is legitimate. Meta counts a conversion against the ad it believes influenced it within its attribution window; GA4 uses its own model and session rules; Shopify counts orders that were actually placed. Some divergence is expected and normal. Divergence beyond that indicates real problems — duplicate events, missing purchases, referral exclusions not set, or a broken checkout event. The audit separates the expected difference from the broken part, which is usually the first time anyone has done so.

Yes. Consent mode, data redaction and state-level US privacy requirements such as CCPA are part of the standard setup, alongside GDPR handling for UK and EU traffic. The aim is to keep marketing measurement working within the rules rather than treating compliance and analytics as mutually exclusive: configured properly, a visitor who declines tracking degrades your data rather than corrupting it, and you retain a defensible record of what is collected and why.

Yes, and starting from nothing is easier than repairing a stack that has been half-configured by several people. A clean build means a measurement plan first — what the business needs to know and which events answer that — then GA4 configured to it, a Tag Manager container built to a naming convention from day one, and a dataLayer specification your developers can implement against. Building it right initially costs less than the archaeology of untangling it in two years.

Yes, and Shopify is the most common stack we work in. That covers checkout and post-purchase events, Meta Conversions API tied to real orders, GA4 ecommerce with correct item-level data, and the awkward parts particular to the platform — the difference between Basic and Plus checkout access, apps that add their own conflicting pixels, and theme updates that quietly remove a dataLayer push. We also build on Shopify, so the tracking work and the store work do not require you to mediate between two suppliers.

Yes. For B2B and SaaS the meaningful conversion happens weeks after the click and inside the CRM, not on the website, so we pass a click identifier through the form into HubSpot or Salesforce and import offline conversions back to the ad platforms when a lead becomes qualified or closes. That lets bidding optimise towards opportunities and revenue rather than form fills, which is usually the difference between a channel that looks expensive and one that is proven to work.

Completely. Everything lives in your accounts — your GA4 property, your Tag Manager container, your tagging server — and you get documentation for every tag, trigger and event. If you take the work elsewhere or bring it in-house, nothing needs to be handed over because nothing was ever held. Support is available afterwards if you want it, but the setup is designed so that you are not dependent on us to change it.

It is scoped from the audit, because the range is genuinely wide: a Shopify store needing GA4 corrected and CAPI implemented is a very different job from a multi-domain B2B funnel with CRM integration and server-side tagging to several destinations. The audit gives you a fixed scope and price before implementation begins, and the audit stands alone — if you take the findings and fix them yourself or with your own developer, that is a legitimate outcome.

Enhanced conversions send hashed first-party data — typically an email address captured at checkout — alongside a Google Ads conversion, so Google can match a sale to a click it would otherwise have missed. The data is hashed before it leaves, so you are not sending raw customer details. If you run Google Ads it is worth having: it recovers attributable conversions that would otherwise go unrecorded, which both improves reporting and gives smart bidding more of the signal it needs.

Almost certainly, because the ground has moved underneath it. Universal Analytics was replaced by GA4 with a different data model, browsers have repeatedly tightened tracking prevention, consent requirements have expanded, and both Google and Meta now depend far more heavily on server-side signal than they did. A setup that was correct several years ago is not wrong through neglect; it is measuring a web that no longer works the way it did when the tags were written.

Yes. The documentation is written to be used rather than filed, and we walk your team through the container, the measurement plan and the dashboard so changes do not require a call to us. Teams that understand their own tracking catch breakages early, which is worth considerably more than the implementation itself — most of the damage from broken tracking comes from how long it runs before anyone notices.