September Series 06 — How to detect fake clicks and bot traffic before reading growth data

September Series 06 · Growth measurement · By Avie Vu

Bot traffic deserves a quality check before the next growth decision. Use this practical guide to investigate fake clicks, reconcile real customer outcomes, and keep uncertainty visible.

Start with the decision, not the spike

Bot traffic can make a growth dashboard look busy while the business remains still. Before you celebrate a traffic spike, investigate whether the activity represents people, harmless automation, measurement errors, or abuse. A bigger denominator can hide a good funnel. Fake conversions can make a weak campaign look efficient. Both can push the next budget decision in the wrong direction.

This September Series 06 playbook explains how to detect fake clicks and bot traffic before reading growth data. It is an investigation framework, not a claim that one suspicious metric proves fraud. Start with a practical question: which decision would change if this cluster were automated? A budget increase, a landing-page redesign, and an incident response require different evidence.

Choose a time window, a comparison period, and the business outcome you trust. Record the campaign launch, tracking release, product change, and any infrastructure change that happened nearby. A sudden jump after a tag deployment may be a measurement problem. A burst of requests against a signup endpoint may need engineering attention. These possibilities should remain open until you reconcile the records.

1. Separate clicks, requests, sessions, and customers

An ad click is not a session. A request is not a visitor. A signup event is not necessarily a created account. A purchase event is not necessarily a settled payment. When bot traffic enters a report, these distinctions become the foundation of useful analysis.

Write down what each system counts before comparing totals. An advertising platform reports interactions under its own definitions. A CDN or server records requests, including assets and API calls. Browser analytics records events that reach its collection system. Your application records business state, and your payment provider records transaction state. They observe different parts of the journey.

Google explains several legitimate reasons why ad reporting and third-party tracking differ, including JavaScript availability, redirects, and repeat visits. See Google’s explanation of reporting differences. A discrepancy is a question to investigate, not automatic evidence of fake clicks.

Use a small measurement dictionary: metric, system, unit, time zone, event trigger, deduplication rule, and known gaps. Align the date boundaries and attribution window. If one report counts payment attempts and another counts successful first payments, fix that definition before estimating traffic quality.

2. Find the smallest suspicious segment

Sitewide averages can bury bot traffic inside otherwise healthy activity. Break the change into source, campaign, landing page, device family, geography, and hour. Begin with the dimensions that explain the largest part of the increase. Then compare each suspicious segment with its own normal pattern.

A campaign reaching a new market can produce unfamiliar geography and lower initial engagement. A mobile page that loads slowly can produce short sessions from real people. Neither observation proves automation. Your task is to identify a cluster that deserves a closer look, not label an entire audience as fraudulent.

Create an investigation row with the first unusual timestamp, affected path, source label, approximate volume, and the business outcomes associated with it. Keep unknown attribution in the record instead of forcing it into a paid channel. A campaign parameter is easy to copy; its presence alone does not establish that an advertising platform sent the request.

Check whether the segment existed before the spike. A stable background of monitoring requests may explain part of the difference. A genuinely new cluster concentrated on one endpoint is a more useful lead. Small, specific segments allow more proportionate responses than a sitewide block.

3. Look for repeated patterns across independent signals

Useful bot traffic signals include unusual bursts, repeated paths in an identical order, improbable repetition of form values, and a large volume of attempts without valid application outcomes. Each signal has innocent alternatives. Combine them and document the alternatives you tested.

For example, a short burst from one network could be a company team attending a webinar. Repeated requests could come from a health monitor. Shared IP addresses can represent offices, mobile carriers, or VPNs. A browser user-agent string can be copied. Low engagement can reflect a poor offer or a broken page.

Confidence grows when independent evidence agrees: repeated endpoint activity, a narrow time pattern, and failed or duplicated backend operations. Three charts built from the same analytics event are not three independent sources. They are three views of one source.

Use working labels such as unreviewed, suspected automation, explained legitimate activity, and confirmed abuse. Add an owner and the evidence needed to move a row between labels. Do not silently convert suspicion into certainty when presenting the weekly growth report.

4. Compare browser analytics with server or CDN evidence

Browser analytics alone cannot describe all bot traffic. Some automated clients do not execute the page’s JavaScript. Other automation can execute it. A high number of edge requests and a lower number of analytics sessions therefore need interpretation, rather than a subtraction presented as the number of bots.

Ask engineering to review the relevant paths and time window. Separate document requests, static assets, API calls, and retries. Look at response codes, endpoint sequence, and whether a successful application operation followed. Compare like units where possible, and explicitly state where the units differ.

Cloudflare documents a request-level bot score from 1 to 99. Lower scores indicate a greater likelihood of automation; availability and detail depend on the product and plan. See Cloudflare’s bot-score documentation. Treat the score as another signal, not a universal probability that an account is fake.

Keep legitimate crawlers, link previews, and uptime monitoring distinct from malicious automation. Security controls should protect the service while preserving useful activity. Review the effect on real visitors before tightening a rule. This article describes an audit; it does not change any live security configuration.

5. Reconcile events with real application outcomes

The most valuable bot traffic check is often downstream. Did the reported signup create a unique account? Was the account verified where verification is required? Did the lead contain a usable contact method? Did the customer complete a successful payment that remained valid after reconciliation?

Build a funnel from independently recorded states: landing activity, accepted form, created account, qualified action, successful first payment. Explain each transition and count unique entities consistently. Do not merge repeated attempts into new customers or count a client-side success message as proof of a backend operation.

A fake form submission may come from automation, but a real person can also submit inaccurate details. Separate traffic classification from lead qualification. An unqualified lead does not establish click fraud. The operational response may be clearer validation, better targeting, or a safer form rather than a network block.

For onboarding teams, the KYC drop-off diagnosis helps distinguish verification friction from weak acquisition. Once the quality of the incoming cohort is understood, diagnose the real product transition instead of treating every missing conversion as an acquisition problem.

6. Rule out broken tracking before blaming bots

Duplicate tags, repeated event listeners, staging traffic, and success events fired on page load can imitate a bot traffic problem. Review the recent implementation history with the person responsible for analytics. Test the intended customer action once and inspect how many records each system creates.

Check whether refreshes, retries, and returning to a confirmation page generate another conversion. Review server-side and browser-side collection together if both are used. An event name that looks like a purchase does not make the payload an authoritative financial record.

Google Analytics 4 automatically excludes known bots and spiders, using Google’s research and the IAB list. Google also says you cannot disable that exclusion or see how much was excluded. Read GA4’s known bot-traffic exclusion guidance. That protection should not be read as a guarantee that every form of automation is absent.

Record the tracking defect separately if you find one. Correcting a duplicated event can change historical comparability. Annotate the release date and make it clear which period used the old definition. Otherwise the fix may create an apparent drop in growth that is actually an improvement in measurement.

7. Review paid-click quality inside the advertising platform

When fake clicks are suspected, inspect the advertising platform’s own invalid-traffic reporting alongside the website evidence. Bot traffic on a landing page is not sufficient to calculate an advertising refund. The platform’s assessment and billing records matter.

Google Ads describes automated filters, machine learning, and manual reviews for invalid traffic. Its guidance also explains that credits may be applied where appropriate and possible when invalid traffic is found after invoicing. See Google Ads’ invalid-traffic guidance. Do not promise reimbursement based on a third-party flag.

Preserve the campaign, time window, affected landing paths, and a concise description of the pattern. If you request an investigation, provide relevant evidence through the platform’s supported process. Avoid sending raw personal identifiers or customer records in a public report.

Separate four questions: were clicks billed, did activity reach the website, were leads accepted, and did those leads become customers? A platform can filter an invalid click while the site still receives a request. Your form safeguards and qualification process remain part of the work.

8. Report sensitivity without manufacturing better growth

Consider an illustrative week with 10,000 recorded visits and 100 successful first payments. The raw conversion rate is 1%. Investigators identify a 1,500-visit cluster as suspected bot traffic, but have not confirmed every visit. If the whole cluster were excluded, the rate would be 100 divided by 8,500, or about 1.18%.

This is a sensitivity scenario, not a new verified conversion rate. The business still has 100 customers. No additional revenue appeared when the denominator changed. Present the raw total, the suspected cluster, the evidence, and the conditional calculation together.

Compare acquisition channels using the same quality rule. Removing suspicious visits from one campaign while leaving them in another makes the ranking misleading. If the evidence is incomplete, show the uncertainty and delay a large budget decision when that uncertainty could change the conclusion.

Keep the original records and use a versioned classification layer where your systems allow it. That makes the investigation reversible and lets another person reproduce the report. Bot traffic analysis should improve the quality of the decision, not make the slide look better.

A practical review workflow for the next growth meeting

Before the meeting, appoint one owner for analytics definitions and one for security or engineering evidence. They may be the same person in a small team, but the two responsibilities should remain clear. Marketing can identify the decision at risk; engineering can assess request behaviour and application state.

Start the review with a single-page brief. State the change, the affected cohort, the trusted outcome, and the plausible explanations. Include a raw metric table and the evidence status. Avoid a long list of screenshots without a question attached to each one.

Agree on a proportionate action. A tracking defect needs an implementation fix. Confirmed abusive submissions may need validation or rate controls. Legitimate automation may need a reporting exclusion and an allowlist. An uncertain cluster may need more observation before changing acquisition spend.

After any action, monitor real-user completion, error rates, qualified leads, and payments alongside request volume. Fewer requests is not automatically a win. A challenge that suppresses genuine customers could make bot traffic look cleaner while damaging growth.

Then return to lifecycle analysis. The Series 04 lifecycle-timing framework is useful after the cohort and product state are reliable. Messages should respond to meaningful user progress, not noise from unverified events.

Example: turn a suspicious spike into an investigation brief

Imagine that a paid landing page receives a sudden increase on Tuesday afternoon. The acquisition report looks stronger, but the count of accepted leads remains flat. Start by checking whether the campaign actually changed. Ask whether the page, consent setup, or analytics tags were released at the same time. Then isolate the affected hour and landing path.

Engineering finds repeated form attempts with identical content, while the application rejects most of them. This is stronger evidence of abusive submissions than a low engagement rate alone. It still does not establish how many billed ad clicks were invalid. Marketing should retain that distinction when contacting the platform and presenting the result.

The brief should say what was observed, what remains unknown, and what will happen next. For example: repeated rejected form attempts are confirmed; the share of automated analytics sessions remains under investigation; the team will test form safeguards and review real-user completion afterward. Set a review date and a named owner for the unresolved question.

If accepted leads stay stable after the safeguard, you have reduced operational noise. If genuine completion drops, revisit the control. Neither result should be reported as a campaign improvement without checking customer outcomes. This discipline keeps bot traffic analysis connected to business value and makes the next budget decision easier to defend.

The bot traffic review checklist

• Define the business decision and the trusted outcome.
• Align units, time zones, event triggers, and deduplication rules.
• Locate the smallest suspicious segment and compare its baseline.
• Collect independent behavioural and application evidence.
• Separate useful automation, measurement defects, and abuse.
• Review invalid-click reporting without promising a billing adjustment.
• Show raw results and conditional sensitivity scenarios separately.
• Record the action, owner, review date, and effect on genuine customers.

A good bot traffic review ends with an evidence-based next action. It may confirm that the spike was legitimate. It may reveal a tracking defect. It may identify an abusive cluster. All three outcomes are more useful than scaling a campaign because a dashboard became greener.

Frequently asked questions

Does a high bounce rate prove bot traffic?

No. Weak message match, slow pages, accidental clicks, and real visitors who do not need the offer can produce short sessions. Investigate the segment and reconcile application outcomes before classifying it.

Can I identify fake clicks from IP addresses alone?

No. Shared networks and VPNs make that unreliable. Use multiple independent signals, preserve legitimate explanations, and ask the relevant platform to assess its own invalid traffic and billing.

Does GA4 remove every bot?

Google describes automatic exclusion of known bots and spiders. That is a specific protection, not proof that every automation pattern is absent from your reports.

Should suspected traffic be deleted from the report?

Keep the raw record and show a clearly labelled investigation or sensitivity view. State the evidence and classification rule so readers can understand the difference.

Traffic is rising. Are real customers following?

If you need help connecting acquisition data to qualified leads and paying customers, start with a focused measurement and funnel review. Share your website URL, target market, the reporting period, and the decision you are trying to make. Aggregated examples are enough for an initial discussion; do not email customer-level logs.

Discuss my traffic quality and growth measurement →

Contact: growthwithavie.work@gmail.com. You can also explore Avie Vu’s growth marketing services to find the right scope for your challenge.