Click Fraud Tools: The Hidden Tracking Nightmare

The Insane Tech Stack You Need for On-Site Click Fraud Protection

Dorian Vorn

Most click fraud protection services are built the same way. They live on your website. A JavaScript snippet is placed on the page, and it watches the behavior of every visitor after the click on your ad: how the cursor moves, how the scrolling goes, how much time the person spent on the page, from which IP and device he came. When the script decides that it is looking at a bot, it marks the visit as fraud. The most interesting part starts after that, and this is exactly what I want to talk about in detail, because behind it stands a whole layer of work that the advertiser is usually not told about.

A service like this recognizes the bot after the click already happened and the money for it was charged. Something can still be returned, and I don’t want to be categorical here. Google itself, when it recognizes traffic as invalid, returns the spent money as a credit on the next invoice, and such services help to collect evidence and file such a claim. But this is a slow, partial and roundabout path. The credit depends on whether Google itself agrees that the traffic was invalid, and not on the verdict of a third-party service, and it arrives with a delay. And, most important of all, the impressions bought with that budget never reached real people, and for a campaign with a daily limit the day can simply be burned through by lunchtime.

So the real task of an on-site anti-fraud service is different. Not to return the money, but to prevent the ad algorithm from learning on this garbage. It has essentially two mechanisms for that.

The first one is simple and crude. The service collects the IP addresses of suspicious visits and adds them through the API to the Google Ads exclusion list. I wrote separately about why IP blocking in search is almost useless today: a bot changes its address faster than the block manages to take effect.

The second mechanism is subtler and much more important. The service controls which conversions go back into the ad system to train its algorithm. If a bot reached the form and submitted a lead, the anti-fraud tries not to pass that conversion into Google Ads, so that the algorithm doesn’t count the bot as a good customer and doesn’t start looking for similar entities to show your ads to as often as possible.

Why This Works Only on Campaigns That Learn From Conversions

There is a moment hidden here that almost nobody says out loud. All this work with conversions on the website side makes sense in exactly one case: if your campaign is optimized for conversions, meaning the ad algorithm is self-learning, receiving conversion data and looking for ways to raise those conversions for you. This covers the automated bidding strategies that Google calls Smart Bidding: Target CPA and Target ROAS, as well as Maximize conversions and Maximize conversion value. By the same logic Performance Max falls here too, since it also pursues a conversion goal.

In all these strategies the neural network of the ad platform looks for regularities in the behavior of those who bring the business money, and adjusts the impressions toward similar people. Filtering conversions works here as reinforcement with a minus sign: you don’t give the algorithm a signal that the bot performed a valuable action, and so the algorithm doesn’t reach for bots, it prefers other entities that have a more human profile.

Let me make a reservation, so as not to mislead. Not every automated strategy in Google Ads is about conversions. Maximize clicks and Target Impression Share are automation too, but they optimize for clicks and impressions. Filtering conversions gives nothing there, because there is nothing to protect: the conversion signal simply doesn’t exist. The same on manual bids with optimization for clicks.

From this follows an uncomfortable conclusion. On-site anti-fraud by its nature assumes that you need conversion-based automated strategies. And conversion-based automated strategies are exactly the mode where the advertiser has the least control over traffic: the algorithm hides the bids, dilutes management at the query level, and you lose the ability to see fraud as clearly as on manual control. You get a closed circle. For on-site protection to make sense, you must hand over campaign management to the robot of the ad platform. And having handed management to the robot, you stop seeing the signals by which fraud in search is actually recognized. I manage campaigns differently and always explain to clients why, but that’s a separate conversation.

Handed your advertising over to the neural network of your ad platform? Then make sure fraud doesn’t reach your conversions, otherwise you will teach the neural network to feed you fraud under the mask of “hot customers”. And how do you make sure fraud doesn’t reach the conversions? Does on-site anti-fraud really cut off only non-humans? Answering this question today is not easy. Bots used to give themselves away with crude patterns: jerky straight mouse movements, instant clicks and things of that kind. Today it is smooth cursor trajectories, natural uneven scrolling, transitions through links and at the end a form submission, sometimes with the data of a real person. Telling it apart from human behavior is very hard. If your campaigns are optimized for leads on the site, part of those leads may be not from people, and at the same time well disguised as people. You need to trust your on-site bot filtering system a great deal to calm down and tell yourself: “My advertising runs as it should. Bots are cut off, only people convert on my site.”

False Conversions Mean Bad Training

And now the main problem. To cut off bad conversions and pass to Google only those made by people, you must have reliable and complete conversion tracking. The whole scheme rests on the assumption that you see all conversions at all, and that you can mark each of them as genuine or suspicious.

In reality, modern browser tracking leaks at every seam. Third-party cookies are becoming a thing of the past. Safari and Firefox cut cross-site tracking by default. In Safari, the ITP mechanism shortens the life of client-side cookies to one to seven days, and long delayed conversions with a long decision cycle simply get lost. iOS users massively opt out of tracking, and your tracking systems know almost nothing about those customers. The consent requirements of GDPR and CCPA mean that a growing share of customers is never attributed to the advertising that brought them. Add ad blockers on top, which cut out the data collection scripts.

The meaning is simple: a huge share of conversions happening on your site never gets connected to advertising as a source, and therefore is never given to the ad platform for its training. Meanwhile, in the remaining part, where the source data survived, the share of fraud traffic can be critically large.

And this is not only my reasoning. Accurate conversion tracking is the basic, non-negotiable condition of any strategy that learns on conversions. If conversions double, fire on the wrong page, or, for example, offline deals don’t enter the system or enter it with distortions, the algorithm optimizes toward a distorted picture. That is how these strategies themselves are built. Which means an anti-fraud service that sits on top of the current tracking and tries to filter the signals is by definition working with an already distorted picture. It may honestly cut out the bot conversions, but a skewed dataset will still be going to Google, only the skew will have a different cause.

Let’s take this apart on concrete users with the same ideal buyer profile.

  1. The first one comes from an old Android without blockers, buys, and the browser tag calmly passes both the conversion itself and its link to the ad click.
  2. The second one has an ad blocker turned on. This extension simply doesn’t let the client-side JS tag send a request to Google’s servers. The conversion never reaches the ad system at all, as if it never existed.
  3. The third one sits on Safari without a blocker. The tag works normally and the conversion is recorded, but the connection breaks. The click identifier (gclid), which is set by client-side JavaScript, is trimmed in Safari by the ITP mechanism to one day or a maximum of seven. On top of that, recent Safari versions simply cut this parameter out of the address before the page even loads. In the end the conversion exists, but there is nothing left to connect it to the ad click, and it gets marked as direct traffic, that is, source unknown.

The difference is fundamental: in the second case the conversion never got into the tag, in the third it did, but the source was lost. Yet the result for the robot is the same: it doesn’t see that the person who clicked the ad bought. The robot draws the false conclusion that an audience with such parameters doesn’t convert, and starts pessimizing impressions to the quality, solvent segment (in our examples, iOS users). This is the first skew.

The second one is even more insidious, because the robot always takes the path of least resistance. If, because of blockers and the short life of cookies in Safari, the system loses expensive delayed conversions, what remains in the account is mostly fast, cheap and impulsive actions. The campaign skews toward cheap and easily accessible, but absolutely non-targeted traffic. And it’s still good if these are living people, but if click bots converted “transparently”, it’s real trouble. The robot cheerfully reports growth in the number of conversions, and in the CRM there is silence.

Server-Side Tracking Is a Necessity

This is exactly why, under quality fraud protection and accurate attribution, you have to lay server-side infrastructure. I mean server-side tracking, which is often called server-side GTM.

It works like this: instead of the browser sending data directly to analytics and advertising systems, the data first goes to your own technical subdomain (for example, metrics.yourdomain.com). And already from there, from your server, it is sent further.

This gives several powerful advantages at once.

  • Bypassing blockers. Requests go to your own domain (first-party context), so AdBlock and similar extensions cannot block them by their standard lists. We can also proxy the data collection script itself through this subdomain, masking it from the simplest filters.
  • Cookie survivability. Browser restrictions (like Apple ITP in Safari) mercilessly cut standard cookies set through JavaScript. Cookies set directly from the server live longer, allowing you to bring back and evaluate customers with a long decision cycle.
  • Data cleanliness and enrichment. Server-side GTM simplifies cleaning the data before sending. On the server side you can conveniently enrich a conversion with real value from the CRM, sending to the ad system not the abstract fact of a form submission, but the actual amount of the closed deal.

On top of this lies the Enhanced Conversions technology from Google itself. The company launched it as a direct answer to the death of third-party cookies and the iOS restrictions.

It works like this: at the moment the form is submitted, the container picks up the user’s email or phone, immediately encrypts them into an irreversible string with the SHA-256 algorithm (so that personal data doesn’t travel anywhere in open form) and passes this fingerprint to Google. Google compares it with its own base of hashed data of users logged into accounts on YouTube, in Gmail, on Android. On a match, the connection between the click and the conversion is restored, even if the cookie burned out long ago and the person clicked from a phone but left the request from a work laptop. On the server side this technology works most stably, since it excludes failures of client-side scripts.

Google is clearly moving the market in this direction and is methodically gathering all the streams of data into a single ecosystem. If earlier the advertiser had to choose one rigid path of data transfer (tag, GTM or API), now the system allows using all sources in parallel, combining the settings of site conversions and leads from the CRM. For you as an advertiser this means one thing: your own first-party customer data becomes the only reliable foundation of attribution, because third-party tracking has essentially not remained.

And Here It Is Worth Stopping and Looking at the Whole Construction

Let’s put together everything that needs to be built for an on-site anti-fraud service to do its work correctly:

  • A server-side tagging container.
  • Hashing of personal data.
  • Hybrid stitching of events and integration with the CRM to pass real value.
  • Handling of user consent under GDPR and CCPA.
  • Enhanced Conversions on the server side.

And all of this for the sake of giving the ad algorithm a clean signal and not retraining it on false conversions. The work is big, honest, and in a number of projects genuinely necessary. I do it myself where it is justified.

But let’s call things by their names, and here I come to the main point. All this machinery influences the algorithm after the money has already left your account. The bot clicked, the budget was charged, the ads for that budget were no longer shown to real people. You built a fortress around a leak, and inside the fortress there is perfect order, and the money keeps dripping outside anyway.

There is another logic, and it is closer to me. Instead of cleaning the signals after the budget is already spent, fraud should be caught at the entrance to the ad system, with the means of the ad account itself, and part of it should be cut off before the auction charges you the money. In such a scheme, server-side infrastructure is something you need for the normal growth of your business and for accurate attribution, and not as a crutch under a reactive defense that is always one step behind the fraudster. The difference is that you stop fighting the consequences and start reducing the very area on which fraud is able to reach you.

The simplest first step is to understand whether you have a problem at the entrance at all, before building an expensive defense at the exit. Export your search terms report and run it through the free tool at https://clickfraudlab.com/free-fraud-check/. It will show three types of anomalies that passed Google’s filters and remained in the report: long low-frequency queries with abnormal impression volume, sharp spikes of one to three days, and statistical outliers by Z-score in stable high-frequency traffic. No registration, and the data is not stored anywhere.

A Quick Glossary

  • Where fraud is detected. In academic literature, click fraud protection is categorized by where the detection takes place:
    • Client-side: Detection happens on the user’s device, inside the browser, or via antivirus software.
    • Ad network-side: Detection runs on the ad network’s end, meaning on Google’s own servers and filters.
    • Advertiser-side: The advertiser catches fraud independently without relying on the platform. The term “advertiser-side” goes back to the work of Xu et al., 2014.
  • On-site click fraud software (advertiser-side, post-click). A third-party service installed on your website. It identifies bots after the click based on on-page behavior and attempts to mitigate the damage retroactively by blocking IP addresses and filtering conversions. While technically advertiser-side, the detection happens on the site and only after you’ve been billed. Market examples: ClickCease, Fraud Blocker, ClickGUARD, Lunio, TrafficGuard.
  • Pre-auction ad account optimization (advertiser-side, pre-click). My approach. This is also advertiser-side, but the detection and countermeasures happen inside the ad account itself using native tools: campaign architecture, negative keywords, match types, bidding, hourly monitoring, and search term analysis. The goal is to block fraud before the auction drains your budget. This specific workflow doesn’t have a standard industry name, which is exactly what makes it different.
  • Ad network-side (Google’s native filters). The built-in defense of the ad network itself — over 200 real-time filters plus manual reviews for disputed cases. It splits invalid traffic into obvious (GIVT) and sophisticated (SIVT). This is Google’s backend processing, not an on-site service or my approach. These filters let some fraud slip through, and that remainder is what you see in your search term reports.
  • Server-side tracking (Server-Side GTM). A tracking setup where user behavior data goes to your technical server first, and is then forwarded to the ad system. Because it routes through first-party contexts, it bypasses standard ad blocker blocklists, extends cookie lifespans, and allows you to securely enrich conversions with CRM values.
  • Enhanced Conversions. A Google technology launched in 2021. It sends SHA-256 hashed customer data (emails or phone numbers) to Google, which matches them against logged-in users to restore attribution when cookies fail.

Sources

Similar Posts