Insights / Measurement / 8 min read

Your tracking is probably broken.

Eight ways a conversion event dies quietly, why none of them shows up as an error, and a three-hour self-test that needs no developer and no consultant.

Published 3 September 2026 by CurrentAds

"Probably" is doing real work in that headline, so it is worth saying what it rests on, and what it does not. It does not rest on a percentage. There are figures circulating about how many ad accounts have broken conversion tracking, and we have quoted one of them on this page in the past; we have taken it down, because we could not trace it to a named study with a stated method and a date, and a number you cannot attribute is a number you should not repeat. The argument for "probably" is structural instead, and it is stronger than a statistic because you can check every step of it against your own setup this afternoon.

Here is the structure. Conversion tracking has no failure alarm: nothing anywhere tells you an event stopped arriving. It decays by default, because every deploy, plugin update, form change, consent-tool release and platform deprecation is an opportunity to break it. It has no owner in most organisations, because it sits exactly on the seam between the people who build the website and the people who buy the media. And it is verified, if ever, once — at launch — and then trusted for years. A system with no alarm, constant change, no owner and no re-verification is not a system that stays correct. It is a system that is correct on the day it was built and drifts from then on.

Why a broken tag is invisible

Most software failures announce themselves. A broken payment form loses a sale somebody complains about. A broken deploy pages an engineer. Conversion tracking is different in kind: when it fails, the reporting does not go blank and it does not throw a warning. It shows a smaller number, or a larger one, in exactly the format it always used, on the same dashboard, next to the same chart. There is no visual difference between a genuinely quiet week and a week in which the event stopped firing. Nothing in the interface distinguishes twelve conversions from twelve conversions plus the eleven that were never recorded.

That is why broken tracking survives for months in accounts that are otherwise competently run, and why it is usually discovered by accident — during an agency handover, a platform migration, or the week somebody finally opens the CRM and the ad platform side by side. Everything in this article is an attempt to make that accident happen on purpose, on a schedule, before a year of budget has been steered by it.

The eight ways it actually dies

These are not exotic. Each is a one-line defect, and each has a signature you can recognise once you know to look for it.

Consent blocking, which is not the same as consent mode

There is an important difference between a consent banner that blocks tags outright and a consent framework the tags understand. Google's published Consent Mode documentation describes tags changing their own behaviour according to the consent state your banner sets, sending limited cookieless signals when consent is absent; Google required Consent Mode v2 from March 2024 for advertisers sending data from visitors in the European Economic Area who wanted to keep using measurement and audience features. The common misconfiguration is the other thing entirely: a consent tool set to prevent the tag from loading at all until a click that most visitors never make. Then nothing is sent, nothing is modelled, and the effect on your dashboard is indistinguishable from a collapse in demand from that region.

Ad blockers and browser tracking prevention

Content blockers work at the network layer. The browser simply never fetches the tracking script, so there is no error in your console, no failed event in the platform, and no signal of any kind that a visit happened. Browser storage policy compounds it even where nothing is blocked: Apple's WebKit team documented in 2019 that cookies written by JavaScript in Safari are capped at seven days of storage, which silently truncates any attribution window longer than a week for those visitors. The signature of this failure mode is a stable proportional gap between platform and CRM counts rather than a cliff — which is exactly why it gets rationalised as normal variance for years.

The form that submits and fires nothing

This is the most common single defect we find on lead-generation sites, and it comes from a reasonable assumption made years earlier. The conversion event was wired to the load of a thank-you page. Then the form was replaced with a modern embedded one that submits in the background and swaps in a success message without navigating anywhere. The thank-you page still exists; nobody ever lands on it. Leads arrive in the inbox, the sales team is busy, and the ad platform records nothing at all. The same failure appears with chat widgets, booking embeds and click-to-call links, all of which complete a conversion without a page load.

Two containers, or a tag counted twice

A previous developer hardcoded the conversion snippet into the template. A later one added a tag manager and rebuilt the same event inside it. Nobody removed the first. Now every sale is counted twice, cost per acquisition reads as roughly half the true figure, and the account looks like the best performer in the portfolio. The duplicate-container version is the same defect one level up: two tag manager containers on the same page, often because a theme installs one and a plugin installs another. The signature is arithmetic — platform conversions run near a whole multiple of the orders in your own system.

Refresh inflation

A confirmation page that fires a conversion on every load will count the reload, the back button, the bookmark and the forwarded link. On mobile, where people leave and return to a page constantly, this inflates steadily rather than dramatically. It is a close cousin of duplicate firing and it is fixed the same way: deduplicate on an order or lead identifier so the same transaction cannot be counted twice, whatever the browser does.

The redirect that eats the parameters

Ad platforms identify a click with a parameter appended to the landing page URL, and campaign reporting depends on UTM parameters travelling the same way. A redirect that rebuilds the destination URL rather than passing the query string through will drop both. So will a link shortener configured to strip parameters, an http to https hop that loses the query, a www redirect, or a consent tool that reloads the page cleanly. The visitor arrives, converts, and lands in your reports as direct traffic from nowhere. This is the mechanism behind most of the blank source fields people puzzle over, and it is unpicked link by link in why your leads have no source.

The rebuild that dropped the tag

A redesign ships. The new templates are cleaner, faster and missing the container snippet, because the person who rebuilt them was briefed on design and speed and was never told what else lived in the header. The signature here is unmistakable once you look: a clean cliff edge on a specific date. If you keep no record of deploy dates, you will not be able to connect the cliff to its cause, which is the whole argument for date-stamping every tracking verification you ever do.

The import that quietly stopped

Offline and CRM conversion imports are the mechanism by which a business with a sales cycle tells the ad platform which leads actually became customers. They are also a scheduled job, and scheduled jobs fail. A credential expires, a field is renamed, a file format changes. The uploads stop, nobody is notified, and the platform gradually reverts to optimising for raw lead volume because that is the only signal still arriving. The most valuable conversions are the first to disappear and the last to be missed.

Failure modeHow the event diesWhat it looks like on a dashboard
Consent blockingThe tag is gated behind a banner and never fires for anyone who declines or ignores itConversions fall for one region or one traffic source, not across the board
Ad blockers and browser preventionThe tracking script is blocked at the network layer, or its cookie is expired earlyA stable gap between platform-reported and CRM counts, worst on desktop
The silent form handlerThe form submits without a page change, and the event was wired to a thank-you page loadLeads arrive in the inbox and nothing arrives in the platform
Duplicate containers or tagsThe same event is fired by a hardcoded snippet and by a tag manager tagCost per acquisition looks roughly half of what the bank statement implies
Refresh inflationA confirmation page fires a conversion on every load, including reloads and back buttonsConversions exceed orders, and the gap grows with mobile traffic
Parameter-stripping redirectsA redirect drops the click id or the UTMs before the landing page ever reads themTraffic and conversions collect under direct or unassigned
The rebuild that dropped the tagA redesign, a template change or a plugin update ships without the containerA clean cliff edge in the data on a date nobody connects to a deploy
Import that quietly stoppedAn offline or CRM conversion import fails and nothing raises an alarmThe highest-value conversions vanish while the cheap ones keep reporting

An algorithm fed wrong data does not underperform. It confidently optimises for the wrong thing.

Client-side, server-side, and what neither one fixes

Client-side tracking runs in the visitor's browser: a script loads, watches for an action, and sends an event straight to the platform. It is simple to install, which is why almost everything starts there, and it is exposed to everything the browser does — blockers, storage limits, script errors, slow networks and the visitor closing the tab before the request leaves.

Server-side tagging moves the collection point to a server you control. The browser sends one first-party request to your own endpoint, and your server forwards clean, enriched events onward. That is genuinely more robust against blocking, gives you control over exactly what leaves, and lets you attach information the browser never had — an order value confirmed after a refund window, a lead your sales team later marked as qualified. It is not a magic fix, and the honest framing matters: server- side tagging repairs a collection problem. It cannot repair a logic problem. A form that never fires an event, a redirect that eats the click id, a duplicate tag that counts every sale twice — all three follow you to the server, arriving faster and more reliably wrong. Fix the logic first. Move the collection point when the logic is sound and the remaining gap is genuinely a blocking gap. The order to build all of this in is set out in build the measurement floor first.

Why this costs more than it looks

If tracking were only a reporting concern, a broken tag would cost you an argument in a meeting. Modern buying makes it much more expensive than that. Automated bidding on the major platforms takes your conversion signal as the definition of success and steers the entire budget toward producing more of it. Overcount, and the system scales spend into audiences that are not buying, because as far as it knows they are. Under- count, and it starves the campaigns that are working while you conclude the channel does not suit your business. Send a value field that is empty, or in the wrong currency, and value-based bidding optimises toward whatever your data implies is valuable, which may be your cheapest product.

The damage compounds daily and it is self-reinforcing, because the misallocated spend generates more of the same wrong signal and the model grows more confident. Broken tracking does not merely distort the report. It redirects the money, with machine learning behind it, in a direction nobody chose. It also quietly corrupts every decision made downstream of the report, which is why a plausible-looking dashboard is a poor defence — the questions worth asking about one are in is your report telling you anything.

The self-test, in three hours, without a developer

You do not need a consultant to find out where you stand. You need an afternoon, a phone, and permission to submit a few test leads. Nothing below requires you to write or read code.

  1. 01 Convert on your own site, as a stranger would. Use your phone on mobile data rather than the office network, click a live ad rather than typing the address, and complete every path a customer can take: the main form, the second form nobody remembers, the chat widget, the booking embed, the phone number. Note which ones you used and at what time.
  2. 02 Watch the events arrive live. Both major platforms provide a real-time event view and a browser diagnostic extension for exactly this. Write down every event that fired zero times, and every event that fired twice. Those two lists are most of your defect log.
  3. 03 Check the URL you landed on. After clicking your own ad, look at the address bar. If the click identifier the platform appended is missing, a redirect ate it, and no amount of tag work will fix attribution until that is repaired.
  4. 04 Reconcile thirty days. Put platform-reported conversions next to the count in your CRM, order system or call log for the same window and time zone. Do not expect agreement. Look instead at whether the gap is stable, and whether you can name a reason for it. A gap you can explain is a measurement characteristic. A gap you cannot explain is a defect.
  5. 05 Look for the cliff. Chart conversions daily for the last twelve months. A step change on a single date is almost never a market event; it is a deploy. Find what shipped that day.
  6. 06 Open the tag manager and read the inventory. Any paused conversion tag, any tag whose name mentions a page that no longer exists, any second container, any event with no value or a hardcoded value of one — all four are worth an hour of somebody's time.
  7. 07 Confirm the scheduled jobs ran. If you import offline or CRM conversions, check the last successful upload date. If it is not this month, the highest-value half of your signal has been missing for as long as that.

One caveat while you reconcile, because it prevents a false alarm. Both major platforms fill measurement gaps with modelled conversions, statistical estimates of activity they can no longer observe directly — a practice that expanded after Apple introduced App Tracking Transparency in iOS 14.5 in April 2021. Modelling is legitimate, disclosed by the platforms, and not a defect. It does mean the platform figure is partly forecast rather than purely a count, which is exactly why the comparison that matters is against your own order system: it is the one ledger in the stack that does not estimate.

Give it an owner and a date

Whatever you find, write it down and date it, because the fix is not the hard part — keeping it fixed is. Tracking is perishable, and the only durable defence is a named owner and a recurring reconciliation, monthly at a minimum and after every deploy that touches a template, a form, a checkout or a consent banner. That is not a large commitment. It is smaller than the meeting you will otherwise spend arguing about whose number is right.

It is also why we verify or rebuild conversion tracking in the first two weeks of every engagement, before scaled budget moves, and why the free growth plan includes a tracking audit whether or not you ever become a client. The advertisers running broken tracking are not careless. They are ordinary, competent people who were never given a reason to check, because nothing in the system was ever going to tell them. Now you have a reason, and it costs an afternoon.

If you want a rough sense of the size of the problem before you commit that afternoon, the ad waste calculator takes your own spend and your own numbers and does the arithmetic in front of you. Nothing is sent anywhere, and it will not tell you what your result would be with us, because that is not a thing anybody can honestly tell you.

FAQ

Questions about conversion tracking

How would I know my conversion tracking is broken if the dashboard looks fine?

You would not, and that is the entire problem. A broken tag does not raise an error in your reporting. It produces a plausible number that happens to be false, and a plausible number is indistinguishable from a true one until you compare it against something outside the platform. The only reliable detector is reconciliation: put platform-reported conversions next to the count in your CRM, your order system or your phone log for the same date range, and look at the gap. Perfect agreement is not the goal and is not achievable. A stable, explainable gap is healthy. A large or drifting one is a defect.

Does consent mode mean I simply lose the visitors who decline?

Not entirely, but you do lose the observed ones. Google's published Consent Mode documentation describes tags adjusting their behaviour according to the consent signals your banner sets, and Google required Consent Mode v2 from March 2024 for advertisers sending data from EEA users who wanted to keep using measurement and audience features. What matters operationally is the difference between consent mode configured and consent banner blocking. In the first case the tag loads and sends limited, cookieless pings. In the second the tag never loads at all, so nothing is sent and nothing can be modelled from it. The second is a common misconfiguration and it looks exactly like a traffic decline.

Do ad blockers make conversion tracking pointless?

No, but they make client-side-only tracking systematically incomplete in a way that is invisible unless you look for it. Blocking happens at the network layer, so the request for the tracking script simply never resolves and no error appears anywhere you would normally look. Browser storage limits compound it: Apple's WebKit team documented in 2019 that cookies written by JavaScript in Safari are capped at seven days, which quietly truncates any attribution window longer than a week for those visitors. Server-side tagging and first-party data collection reduce both effects. Nothing eliminates them, which is why the CRM remains the ledger of record.

Is server-side tagging worth it for a small advertiser?

It depends on what is actually broken. Server-side tagging moves the collection point from the visitor's browser to a server you control, which improves resilience against blocking, gives you control over what is sent, and lets you enrich events with data the browser never had, such as a value that only exists in your order system. What it does not do is fix a form that never fires an event, a redirect that strips the click id, or a duplicate tag counting every sale twice. Those are logic errors and they follow you to the server. Fix the logic first; move the collection point when the logic is sound and the remaining gap is genuinely a blocking gap.

Why do platform numbers and my CRM never agree exactly?

Because they are counting different things by different rules, and some of the difference is legitimate. Attribution windows differ. Attribution models differ, so a platform may credit a conversion to a click that your CRM attributes to a phone call. Time zones differ. Both major platforms also fill measurement gaps with modelled conversions — statistical estimates of activity they can no longer observe directly, a practice that expanded after Apple introduced App Tracking Transparency in iOS 14.5 in April 2021. Modelling is legitimate and disclosed, but it means the platform figure is partly forecast rather than purely a count. Your order system is the one ledger in the stack that does not estimate.

Whose job is conversion tracking, the developer's or the marketer's?

Nobody's, which is why it breaks. The developer assumes the marketer verified the events. The marketer assumes the platform would flag a problem. The platform has no way to know your CRM logged sixty leads while it recorded nineteen. The web agency that rebuilt the site was never told the tags mattered. The only entity that could catch the discrepancy is one that compares two systems on a schedule, and in most companies that entity does not exist. Name an owner, put a monthly reconciliation in a calendar, and the class of failure largely disappears.

How often should tracking be re-verified once it is fixed?

Monthly as a floor, and on every deploy that touches a template, a form, a checkout or a consent banner. Tracking is not a build, it is a perishable. Sites get redesigned, plugins update themselves, form vendors change their markup, consent tools push new versions, and platforms deprecate tags on their own schedule. The reason to date-stamp every verification is that the date is what lets you find the cliff edge later: when conversions drop on the eleventh, the useful question is what shipped on the tenth.

Platform behaviour described from published Google and Apple documentation. No third-party prevalence statistic is asserted anywhere on this page.

Want a second set of eyes?

The free growth plan includes a full tracking audit, a competitor teardown and a 90 day media plan. Yours to keep whether or not you hire us.