Context
Your store gets more visits, but sales barely move. Product pages attract unusual bursts of activity, abandoned carts pile up, and the marketing report suggests that a previously reliable campaign has stopped converting. Before changing your prices or rebuilding checkout, check who is creating those visits.
Bot traffic can distort analytics while something more serious happens elsewhere: automated price scraping, fake registrations, coupon abuse or payment attempts with stolen card details. The useful question is whether the activity represents a customer journey you want to serve.
This guide explains how to investigate suspicious traffic, what Google Analytics 4 can filter, and how to protect the actions that matter without making ordinary visitors work harder to use your site.
How bot traffic distorts your business decisions
A simple example shows the problem. Imagine 1,000 visits and 100 orders, giving an orders-per-visit ratio of 10%. Add 500 automated visits with no orders and the ratio falls to about 6.7%, although actual orders have not changed. This is an illustrative calculation, not the definition of every conversion metric in GA4.
The next decision can be costly. A team may cut a profitable campaign, discount a product that already sells well, or investigate a checkout fault that does not exist. Conversely, automated registrations can make a lead-generation campaign look successful even when the sales team receives no useful enquiries.
For publishers, a spike in pageviews can misrepresent readership and encourage the wrong commissioning decisions. Repeated automated article requests may also be scraping the archive. A clean audience report helps editorial planning, but stopping bulk extraction requires controls on the website itself.
Automation can affect product popularity, geographic demand, acquisition reports, remarketing audiences and experiments. Investigate the measures that influence real decisions first. A suspicious pageview total matters more when it changes budget allocation, stock planning or the evaluation of a new customer journey.
What GA4 already filters, and what remains
Google says that GA4 automatically excludes traffic from known bots and spiders. That exclusion cannot be disabled, and GA4 does not show how much known-bot traffic it removed. See Google's explanation of known bot traffic exclusion.
The scope matters: this describes known automation, so it should not be treated as evidence that every remaining session belongs to a person. A browser-driven bot can execute JavaScript, keep cookies and visit several pages. Some unwanted activity therefore looks plausible in a report.
Other automation may never appear in your browser analytics at all. A script that requests product data directly can burden the site without running the measurement tag. Compare analytics with application and infrastructure evidence; neither gives a complete picture on its own.
Traffic arriving from an unfamiliar country, a VPN or a shared connection is a lead to investigate. Those attributes alone do not establish abusive intent. A real shopper travelling abroad and an automated operation can both produce unusual network signals.
Investigate the anomaly before adding a filter
Start with a defined period and a specific symptom. “Product views doubled between Tuesday and Thursday, while paid orders stayed flat” is actionable. “Our traffic looks fake” leaves everyone searching for a different problem.
First check measurement changes. A duplicated tag, a release that fires purchase events twice, a consent change, a campaign landing-page mistake or a reporting time-zone mismatch can create contradictions without an attack. Compare paid orders with the store's order records, and enquiries with accepted submissions. Allow for differences in what each system measures.
Next, narrow the activity by landing page, source, device category, time and subsequent actions. Look for a concentrated pattern: the same product sequence, rapid repetitions, large volumes of incomplete carts or account requests that do not resemble normal shopping.
Bring in request logs for the affected routes. Check frequency, errors and response times, then follow the path into registration, login, cart, coupon and payment endpoints. Failed payments require attention even if the analytics anomaly began on a harmless-looking product page.
Record the hypothesis and the evidence that could disprove it. For example, a traffic burst may be a legitimate newsletter campaign whose tracking parameters were lost. That possibility deserves checking before its visitors are removed from a performance report.
Connect behaviour across visits and accounts
An IP blocklist gives you a partial view. Attackers can change connections, and several legitimate people may share a network. Device relationships and browser signals are useful additions, but shared devices are common too.
The stronger question is whether several signals support the same explanation. Consider accounts that use related device characteristics, browse inventory in the same order, create carts seconds apart and repeatedly attempt the same promotion. Coordination across those actions is more informative than a single unusual request.
Keep business context in the investigation. A customer refreshing a page during a limited release may be waiting to buy. Automated carts that repeatedly hold scarce stock until a reservation expires affect availability for everyone else. Whether carts reserve inventory depends on your platform, payment state and store configuration; verify the actual stock behaviour before calling it inventory hoarding.
The same discipline applies to publishers. Repeated requests may come from a search crawler, an approved syndication partner or an unauthorised scraper. Check the identity and the agreed access pattern before restricting a legitimate partner.
A useful decision record includes the affected workflow, contributing signals, confidence, action taken and an owner. It should be possible for another team member to understand why a session was classified and to revise that decision when new evidence arrives.
Keep reporting decisions separate from access decisions
Excluding traffic from a sales dashboard does not stop it reaching checkout. Blocking a request does not automatically explain a historical change in a marketing report. Plan both jobs.
Use a small set of classifications that people can understand:
- Approved automation: recognised crawlers or partners operating within their permitted access.
- Confirmed unwanted automation: activity you do not want included in customer-performance reporting.
- Suspicious activity: evidence is incomplete and the traffic needs a separate analytical view.
- Confirmed abuse: a documented pattern targeting accounts, inventory, promotions or payments.
For uncertain activity, compare reports with and without the suspected segment. If the conclusion about a campaign changes substantially, investigate further before making the exclusion permanent. Keep the original period and the classification rule available so colleagues can reproduce the comparison.
Preserve the operational evidence needed for investigation in an appropriately controlled system, with a defined retention period. The business dashboard can exclude confirmed unwanted activity while the security team retains the trail that explains it.
Share only the analytical labels you actually need. Do not send names, email addresses or other prohibited personal identifiers to Analytics; Google's PII guidance covers this requirement. A client-side label is also not a trustworthy access-control decision: enforcement belongs in the systems that handle the request.
Use GA4 controls for the job they actually perform
GA4's documented data filters cover internal, developer and web-hostname traffic. Active exclusions affect incoming data permanently and do not repair historical records. Excluded events will not become available later in Analytics or BigQuery. Use a report-level filter when you need a reversible analytical view. Google explains the differences in its data-filter documentation.
For staff traffic, define the relevant internal-traffic rule and validate it before activation. Google's internal-traffic instructions describe a Testing state and the “Test data filter name” dimension. Check who matches the rule, especially if office networks, agencies or remote staff are involved.
Another common mistake is using the unwanted-referrals list as a bot blocker. Its purpose is to control referral attribution; it does not block a visitor or remove all of their events. See Google's unwanted-referrals guidance. A payment provider appearing as a referral source and a scraper requesting your catalogue are different problems.
For historical investigation, work with data you already retained and document the segment used. A warehouse export cannot recover events discarded before processing. If you introduce a traffic classification, decide how it will reach your measurement workflow, test the implementation and check its limitations. Do not assume an analytics setting will discover arbitrary malicious behaviour for you.
Protect the customer journey where the abuse happens
Choose controls according to the action and the evidence. Reading a public article rarely deserves the same restrictions as repeated payment attempts or an account-recovery sequence.
For product scraping, consider route-specific request limits and responses to persistent bulk access. For fake registrations, examine repetition across accounts and require an additional check when the pattern warrants it. For promotion abuse, enforce eligibility on the server and investigate related accounts. For card testing, coordinate with the payment provider and protect the payment route rather than relying on a cleaner pageview report.
Work through the store's actual behaviour. Some abandoned carts are ordinary comparison shopping. Failed payments can come from valid customers. The useful evidence is repeated, coordinated activity and its outcomes, not the mere existence of either event. Our guide to fake accounts and multi-account fraud explores the account side in more detail.
Avoid blanket restrictions on entire countries, networks or device categories simply to improve a dashboard. Challenge failures, support requests and completed orders help reveal when a control is hurting real customers. Make the rule narrow enough to explain, and retain a practical way to adjust it.
Approved automation needs an explicit policy too. Give it access appropriate to its purpose and monitor whether it stays within that scope. A familiar-looking user-agent string alone should not be enough to grant unrestricted access.
Roll out changes with an agreed baseline
Before enforcing a new policy, observe its proposed matches and review a sample of legitimate journeys. Include mobile shoppers, returning customers, shared devices and any approved partners that use the affected routes.
Set a baseline that covers ordinary weekdays, promotions and known traffic changes. Compare the same measurement definitions before and after the change; switching both the classification and the conversion definition makes the outcome difficult to interpret.
Review more than the number of blocked requests. Track abuse on protected routes, paid orders, accepted leads, payment failures, challenge failures, latency and support complaints. For a publisher, include access to subscriptions and authorised content distribution. Lower session counts alone do not demonstrate success.
Assign an owner to the rule and someone to review its commercial impact. Marketing, engineering and fraud teams need shared definitions and a recorded change date. If a control is overbroad, revise it promptly instead of allowing a tidier chart to hide lost customers.
How Kairal helps you investigate the pattern
Kairal connects activity across requests, devices, accounts and visits. COMPOSITE® combines browser and environmental signals into a hashed device identifier that helps link repeat activity. These relationships provide investigation context; a shared device still needs to be assessed alongside behaviour.
That context can help explain whether inflated traffic is connected to repeated registrations, scraping or checkout abuse. Your measurement workflow still needs its own classification and validation. The aim is to make better decisions about both reporting and access, with evidence your team can review.
If your reports are changing faster than your actual business, start with one affected journey and trace it. Then apply a measured response and verify the result.
Start for free and tell us which website and customer journey you want to protect. The Kairal team will prepare your account and contact you with the next steps.