Conversion tracking

In an account running manual bids, broken tracking produces bad reports. In an account running automated bidding, which is most accounts, it produces bad spending, and it does so immediately and at scale.

The mechanism is worth being precise about. Target CPA and Target ROAS optimise toward the conversion signal they are given. If that signal fires on every page load, the system learns that cheap, high-bounce traffic converts beautifully, and it buys as much of it as the budget allows. Nothing errors. The dashboard looks excellent.

By the time somebody notices the mismatch between platform conversions and actual enquiries, the bidding model has weeks of training on false data, and fixing the tag does not undo it. The model has to relearn, which takes as long again.

This is why tracking verification belongs before the first day of spend rather than in the first month review, and why it is worth writing down. An agency that verified and documented it is in a very different position from one that assumed, on the day the client asks why the leads are not real.

Almost none of the real-world breakage is exotic. Four patterns account for most of it, and all four are visible in ten minutes with the browser network tab open.

A tag on the wrong page is the most common and the most expensive. Firing on the cart or the form page rather than the confirmation page inflates conversions by a factor that depends entirely on the drop-off rate, which means nobody can spot it from the number alone.

Duplicate events are second: a tag installed through a tag manager container and also hard-coded in the template, each firing once. Conversions double, cost per conversion halves, and the account looks like it improved on the day somebody tidied up the implementation.

Third is a conversion that counts every occurrence when it should count one per click, or the reverse. A contact form counted every time somebody submits it will over-report the enthusiastic and the confused equally.

Fourth is silent breakage after a site release. A template change, a new consent banner or a framework upgrade can stop a tag firing with no error anywhere. The only protection is checking after deployments rather than only before, and watching for a conversion count that goes flat rather than down.

Browser-based tracking has been eroding for years. Ad blockers remove the script, Safari and Firefox restrict cookie lifetimes, and consent rejection prevents the tag firing at all. The share of real conversions a browser tag can see has fallen and continues to.

The platform response has been to accept events from the client server instead of the visitor browser: Meta Conversions API, Google enhanced conversions, and server-side tagging in Google Tag Manager. These send the event from infrastructure the client controls, which is not affected by an ad blocker and does not depend on a cookie surviving.

The trade is real work. Server-side implementations need developer involvement, a place to run the container, and careful handling of the data being sent, which is usually hashed identifiers rather than anonymous pings. That is a bigger conversation with the client than adding a tag.

It also does not remove the consent obligation. Sending an event from a server rather than a browser changes the transport, not the lawful basis, and an implementation that quietly routes around a rejected consent is worse than the browser tag it replaced.

Under GDPR and the ePrivacy rules, setting non-essential cookies or similar identifiers before consent is unlawful in the EU. Analytics and advertising tags are non-essential. This is not a grey area and has not been for some time.

Google requires Consent Mode signals for EEA traffic in its advertising products, which means the tracking setup and the consent banner have to be wired to each other rather than installed independently. A banner that blocks nothing, or a tag manager that fires regardless of the banner, is a common and entirely invisible failure.

The exposure lands on the client as the data controller, but an agency that installed tracking without checking the consent setup has created it. That is worth being explicit about at kickoff, in writing, because it is the kind of thing that surfaces during a due diligence or a complaint rather than during normal operation.

The practical consequence for reporting is the one that comes up monthly: consent rejection removes a measurable share of visits from analytics entirely. Modelling fills some of the gap in Google products and does not fill all of it, which is why the analytics number and the reality diverge in a direction that is consistent and growing.