The symptom

The lead count climbs, cost per conversion drops, and the client's sales team says nothing usable arrived. Someone opens the CRM and finds the answer in the name field: keyboard mash, the same phone number four times, a mail address that bounces.

The harder version has no tell. A normal browser, a session with a few pageviews, a form submit, a thank you page. Nothing in the dashboard marks it, so the bid strategy sees a cheap conversion and buys more of whatever produced it.

What unsettles agencies is the direction of it. You are used to explaining a platform that reports fewer conversions than the business had. A number that is too high is a different conversation, because the reflex answer, that tracking under-counts, is the opposite of what happened.

Why it happens

Click filtering and conversion filtering are two different ledgers

Google does filter automated traffic. Per Google's Ad Traffic Quality resource centre, invalid traffic is "any interaction that doesn't come from real people with real interest in an ad", caught by automated detection plus manual review, and Google also states that some of it "may not have been detected by our automated systems".

Note what that machinery is pointed at: the click and impression ledger, the one you are billed on. The conversion is a separate record, and Google Ads Help says so: "In rare cases, a click may be deemed invalid and removed, but the conversion occurring from that click may not necessarily be. This can occasionally result in conversions being higher than clicks." Google's own word is "rare", so take that as the shape of the problem rather than its size. The two ledgers are cleaned separately, and only one of them is what your bidding learns from.

A conversion tag has no opinion about who fired it

A conversion action fires when the condition you defined is met. A page loaded, a form was submitted, an event arrived. Nothing in that sequence asks whether a person was involved. How often it fires is also just a setting: per Google Ads Help the One option counts a single conversion per ad click and is the recommendation for leads, so under the alternative a script reloading a thank you page adds a record each time.

Then the count becomes the target. A value-based strategy "analyzes and uses Google's AI to predict the value of a potential conversion" and sets bids to maximise the conversion value you reported, per Google Ads Help. Whatever sits in that count becomes the account's definition of a good auction, the same mechanism that makes the optimization target decide what your campaigns go shopping for. Inflated conversions do not just misreport, they move budget toward whatever produces more of them.

GA4 excludes known bots, which is narrower than it sounds

Analytics does apply a filter, and its scope matters. Google Analytics Help states that "known bot and spider traffic is identified using a combination of Google research and the International Spiders and Bots List, maintained by the Interactive Advertising Bureau", and that "at this time, you cannot disable known bot traffic exclusion or see how much known bot traffic was excluded".

That list is a catalogue. Per IAB Tech Lab it is managed by the Alliance for Audited Media and "updated monthly". A catalogue works on automation that identifies itself. A script driving a headless browser with an ordinary user agent is on no list, and since you cannot see what was excluded, GA4 cannot size what is left. It is one more reason the dashboards drift apart, alongside the causes behind Google Ads reporting more conversions than GA4.

Automated traffic is no longer one category

This is where confident answers get thin. Cloudflare's documentation classifies bots by behaviour rather than by good and bad, and one category is agent traffic: "automated activity acting in real time on a person's behalf to get something done, such as chat fetch bots and browser-use agents". An agent filling a form for a real person who wants a quote is not a scraper, and not obviously a fake lead either. No platform setting resolves that. It depends on what the client sells and on how sales treats an enquiry it cannot phone back.

Meanwhile the same count is also too low

On a standard browser-side setup, 15-30% of conversions are consistently never captured, and ad blockers strip 30-40% of events. So the dashboard number is wrong in two directions at once, and the errors do not cancel: the missing records are real buyers, the extra ones were never people. A total that looks about right after both is right by coincidence.

What good looks like

The decision about what counts has to happen somewhere you control, before the event reaches the ad platform. That place exists in a server-side setup and not in a browser-only one.

Google's own server-side tagging documentation describes the flow: the client "receives measurement data from a device, transforms that data into one or more events, routes data to be processed in the container", and then "triggers examine each event to look for certain conditions and, when appropriate, fire tags that send the event data to be processed". The words worth reading twice are "when appropriate". A suspect event can be kept in your own dataset and withheld from the platforms that bid on it, a distinction a browser-side tag cannot make.

No single input is a verdict on its own. Google Cloud's reCAPTCHA documentation is explicit that the output is a risk score, where "1.0 indicates that the interaction poses low risk and is very likely legitimate", and that you should "decide on thresholds by looking at the traffic". Where the line sits is a business decision about which mistake costs the client more, a rejected real lead or an accepted fake one. The second input is the CRM status, the one place a human judged the lead.

Putting that filter between the site and the ad platforms, and keeping what you filtered out visible to yourself, is what Archon Signal does. The same layer typically recovers 15-40% more conversions than a browser-side setup was reporting, so the count moves both ways: real conversions come back, junk stops being forwarded. That is a gain against today's baseline, not an arrival at completeness. Consent refusals, blockers and network failure keep roughly 95% of events a ceiling nobody reaches.

FAQ

Can we not just clean the bad conversions out afterwards?

Partly, and worth doing after an obvious spam wave. Google Ads Help describes retraction as permission to "permanently remove a conversion and change the conversion value to 0.00", but online conversions can only be adjusted "if you've used a transaction ID with your transactions", and once retracted a conversion "cannot be adjusted further". The bigger limit is timing: the bidding already used those conversions to decide where to spend, so an adjustment corrects the report, not the spend.

We added reCAPTCHA. Is that not the fix?

It is a useful input, not the fix. Google's own guidance is to act on the score in the context of your site and to set thresholds from your own traffic, so a human still chooses where the line sits. It also protects the form rather than the conversion record, so an event triggered elsewhere still reaches the ad platform unless something in between decides otherwise.

Our client is ecommerce, not lead gen. Does this apply?

Less, and for a good reason: a completed card payment has already passed a filter the client did not have to build, the payment processor. Where it still bites is the signals before it. If add to cart or begin checkout is used as a bid signal, or a competitor's price scraper walks the catalogue nightly, those events carry no such check.

How do we show a client this without accusing anyone?

Compare at record level, not at total level. GA4 will not size it for you, since the exclusion it applies is invisible by design, so the comparison that holds up is the platform's conversion count against the CRM for the same period, matched lead by lead. Present the ratio and the unmatched records themselves.

Will our reported conversions drop once we filter?

The junk share will, and that has to be said before the change, not explained after it. Expect the mix to shift more than the total, since server-side recovery adds real conversions back while filtering removes fake ones. Agree first that cost per qualified lead from the CRM is the metric everyone is judged on, otherwise a healthier account looks like a worse one.

If you want to know how much of a client's conversion count is doing real work, and where a filter would have to sit, a free tracking audit is the place to start.