Most reported conversions are wrong in a way nobody has checked

Compare three numbers for the same period: what the analytics property reports, what each advertising platform reports, and what your CRM or order system actually recorded. They will never match exactly, because they count different things over different windows, but the size and direction of the gaps tell you a great deal.

Specific warning signs are worth knowing. Ad platform conversions far exceeding recorded enquiries usually means double-firing or a trigger that fires on a page reload. A sudden step change with no campaign behind it usually means a site release. And a total that has been suspiciously round and stable for months usually means something is firing on every page view.

It lets your tags respond to the choice a visitor made in your consent banner instead of ignoring it. When the relevant consent is granted, tags behave normally. When it is denied, Google tags adjust their behaviour so they do not read or write the identifiers they otherwise would, and send a limited signal instead of the full one.

Google then models some of the missing conversions to fill part of that gap in reporting. That is a legitimate approach and it is an estimate rather than a count, so a report that mixes observed and modelled conversions without labelling them will eventually be challenged by somebody in finance who is right to challenge it.

What consent mode is not is a way to keep collecting from people who said no. If a vendor describes it that way, they are describing a compliance problem.

Sometimes, and considerably less often than it is recommended. It genuinely helps with three things: control over exactly what data leaves for each platform, resilience against browser restrictions on how long a client-side cookie survives, and reducing the number of third-party scripts running in your visitors’ browsers.

It does not recover consent-declined data, it does not fix a badly defined event, and it costs money to run every month. We recommend it when the accuracy of the signal you send to advertising platforms is materially affecting bidding, or when page weight or data control is a genuine problem, and not simply because it is available.

Because the booking system is usually on a different domain, and without cross-domain measurement configured the browser treats the arrival there as a brand new visit from a new person. The original source is lost, one session becomes two, and the conversion gets credited to a referral from your own website.

The fix is configuration rather than rebuilding anything: the domains have to be declared to each other, the identifier has to be passed across in the link, and the receiving system has to be set up to accept it. The tell-tale sign that it is missing is your own domain appearing as one of your largest referral sources.

That is the main constraint on how we work. Nothing is deleted on the basis of appearing unused. We document what each tag currently does, run the replacement alongside the existing setup where the platform allows it, and compare the two before anything is switched off.

Where a change is unavoidable, we do it at a defined point, record the date prominently, and annotate the reporting so that six months later nobody mistakes an implementation change for a change in performance.

Often you do not, and where a developer has implemented a data layer properly we would rather build on that than replace it. The work is faster and better when the underlying implementation is sound.

The gap we usually find is not technical skill but definition. A developer implements what was requested. Whether a form submission on the contact page and a quote request should count as the same conversion, and how either reconciles with what sales calls a lead, is a commercial decision that was rarely made by anybody before the tags were written.