One morning, I opened GA4 and saw sessions up by almost 30% from the month before.

I was excited for about ten seconds. Maybe a post had started ranking. Maybe I should publish another one quickly and catch the traffic.

Then I opened the country report and froze.

Ninety percent of the increase came from Singapore. Average engagement was zero to one second. Bounce rate was close to 100%. I had never targeted Singapore, distributed content there, or had a customer there.

I opened Clarity, Microsoft’s free session-recording tool, to see what those “users” had done. There was not a single recording.

GA4 could see the visits. Clarity could not. That changed the whole diagnosis.

In about eight minutes, this historical case study shows how I recognized suspicious traffic, why GA4’s built-in filter was insufficient, what the data looked like after I excluded the suspicious segment, and the monthly check I now use before changing content or code.

Illustrative diagram. Historical example: an unexpected country spike needed behavior evidence before it could be treated as real audience growth.

Two wrong turns I nearly took

Before I understood what I was looking at, I had spent half a day moving toward each of two bad conclusions.

The first involved a blog post I liked. GA4 showed an 86% bounce rate. I assumed the search intent was wrong and had already started outlining a rewrite. Without another look at the data, I would have rewritten it.

The second involved device performance. Desktop bounce was 59%, while mobile was 27%. A DTC site often shows the opposite pattern because mobile experience has more ways to go wrong. I started checking the cookie banner and font loading for a problem that was not there.

After excluding the Singapore segment, the picture changed:

• The post that showed an 86% bounce rate had a 41% bounce rate. The post itself was fine.
• Desktop and mobile bounce both landed around 40%. Desktop had not broken.

I had nearly rewritten a good post because bots had distorted it. I had nearly changed code for a mobile bug that did not exist.

At that point the answer was plain: the article was good, desktop was fine, and the measurement was dirty.

What the suspicious visits had in common

The Singapore traffic had a remarkably consistent fingerprint. Once I had seen it, I could recognize the pattern quickly:

Those resolutions matter. 1280x1200 and 1366x1366 are square-like screens. 800x600 is an old VGA resolution. Seeing these alongside the source and behavior signals gave me a usable filter.

Why Singapore? My historical interpretation was that Shopify’s site-crawling infrastructure was concentrated there. Crawlers could visit product and price pages around the clock. When they also ran the site’s GA4 gtag.js tracking script, their visits appeared in the analytics data.

My site was one of the sites being crawled. Any publicly accessible Shopify store could be exposed to this kind of traffic.

Illustrative diagram. Historical example: repeated technical and behavioral signals were compared with a varied human-behavior path. This is not an analytics screenshot.

Why the built-in GA4 bot filter did not help

It was enabled. It still did not help.

The GA4 setting “Exclude all hits from known bots and spiders” works from the IAB Tech Lab bot list. It can block crawlers such as Googlebot, Bingbot, and Pingdom when they identify themselves in the user agent, the string a browser sends to identify itself.

This Singapore traffic looked different. It impersonated desktop Chrome. The user-agent string, JavaScript execution, and cookie handling all looked plausible, while the crawler hid that it was a bot.

GA4’s filter was useful for known signatures. It was not a real-time detector for a crawler that blended in. I needed evidence from the traffic pattern itself.

Five checks in ten minutes

This process was not limited to my store. I use it whenever an unusual metric appears on a Shopify or independent site.

Three signals together were enough for my historical bot classification. It was a working rule for this site and period, not a universal production threshold.

The fourth pattern, a landing page with more than 80% bounce, less than ten seconds of engagement, and (not set) source, looked more like server probing than a person reading content. That was the point to stop planning a rewrite.

The fifth check gave me a second observation channel. Bots did not produce Clarity session recordings in this case, so Clarity-to-GA4 reconciliation was more informative than GA4 alone.

I turned steps 1 through 4 into a short Python script that prints four tables. Developers can use the script. Everyone else can paste the prompt below into an AI tool. Both routes use the same evidence.

"""GA4 bot health-check script: print four tables for the five-step review.
Dependency: pip install google-analytics-data
Preparation: create a service account in GA4 Admin, download the JSON credential, and note the property ID.
"""
import os
from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import (
    DateRange, Dimension, Metric, RunReportRequest, OrderBy,
)
=== Change these two lines ===
KEY_PATH    = r”C:\path\to\your-service-account.json”
PROPERTY_ID = “YOUR_GA4_PROPERTY_ID”
DAYS        = 14
os.environ[“GOOGLE_APPLICATION_CREDENTIALS”] = KEY_PATH
client = BetaAnalyticsDataClient()
def run(dims, metrics, limit=15):
req = RunReportRequest(
property=f”properties/{PROPERTY_ID}”,
date_ranges=[DateRange(start_date=f”{DAYS}daysAgo”, end_date=“today”)],
dimensions=[Dimension(name=d) for d in dims],
metrics=[Metric(name=m) for m in metrics],
order_bys=[OrderBy(metric=OrderBy.MetricOrderBy(metric_name=metrics[0]), desc=True)],
limit=limit,
)
return client.run_report(req)
def show(title, rows, dim_labels, metric_labels):
print(f”\n=== {title} ===”)
header = ” | “.join(dim_labels) + ”  ||  ” + ” | “.join(metric_labels)
print(header); print(”-” * len(header))
for r in rows:
d = ” | “.join(v.value[:30] for v in r.dimension_values)
m = ” | “.join(f”{float(v.value):.2f}” if ”.” in v.value else v.value
for v in r.metric_values)
print(f”{d}  ||  {m}“)
Step 1: country distribution. Look for SG/HK/VN/RU suddenly appearing.
r = run([“country”], [“sessions”, “bounceRate”, “averageSessionDuration”])
show(“Step 1: country”, r.rows, [“country”], [“sess”, “bounce”, “avgSec”])
Step 2: source × country. Where do direct/none visits concentrate?
r = run([“sessionSource”, “sessionMedium”, “country”], [“sessions”, “bounceRate”])
show(“Step 2: source × country”, r.rows, [“src”, “medium”, “country”], [“sess”, “bounce”])
Step 3: OS × resolution. Find square-like or obsolete resolutions.
r = run([“operatingSystem”, “screenResolution”], [“sessions”, “bounceRate”])
show(“Step 3: OS × screenResolution”, r.rows, [“os”, “screenRes”], [“sess”, “bounce”])
Step 4: landing page × bounce. High bounce plus low engagement can indicate probing.
r = run([“landingPage”], [“sessions”, “bounceRate”, “averageSessionDuration”])
show(“Step 4: landingPage × bounce”, r.rows, [“landingPage”], [“sess”, “bounce”, “avgSec”])
print(“\nRule used in this historical case: three matching signals led to a bot classification.”)

You are a GA4 traffic-diagnosis assistant. Help me identify suspicious Singapore bot traffic. I will send you GA4 report data. Work as follows.
Step 1: First send me one opening message so I know which data to prepare. Say this exactly:
“Paste these four GA4 reports here (screenshots or copied table content both work):

Reports → Demographics → Country: country × sessions × bounce rate × average engagement time
Reports → Acquisition → Traffic acquisition: source/medium × country × sessions × bounce
Reports → Tech → Tech details: OS × screen resolution × sessions × bounce
Reports → Engagement → Landing page: landing page × sessions × bounce × average engagement time
Optional: Microsoft Clarity sessions for the same period.”

Step 2: After you receive the data, evaluate these five checks one by one. For each, tell me whether it matches, why, and which number supports the judgment:

SG / HK / VN / RU enters the top three countries → match
(direct)/(none) + (not set)/(not set) is more than 50% of total traffic and concentrates in the countries from step 1 → match
1280×1200, 1366×1366, 800×600, or other square-like / obsolete VGA resolutions appear → match
Any landing page has bounce above 80%, engagement below 10 seconds, and source (not set) → match
If I provide a Clarity number: Clarity sessions ÷ GA4 sessions is below 50% → match

Step 3: Give a conclusion.

Three or more matches: say bot contamination is present. Give a “post-bot estimate” for likely real sessions and real bounce rate.
One or two matches: say it is suspicious and name the next report I should inspect.
Zero matches: say the traffic structure looks normal.

Step 4: Give two improvement suggestions.

Inside GA4: which internal-traffic filter and unwanted referrals to consider.
At the edge: which Cloudflare / WAF bot-challenge configuration to consider.

Every time you mention a GA4 term, add one plain-language sentence. Assume I have not pasted the data yet. Start by sending only the opening message above.

Illustrative diagram. Historical example: behavior evidence changed the reading of a traffic signal. It does not reproduce a real report or operating metrics.

Filtering comes after diagnosis

Filtering only made sense after I understood the pattern. If I filtered first, I would have had no way to tell whether I had blocked people or machines.

There were two layers.

The first was what GA4 could do. I added my fixed IP as internal traffic and put obvious referral spam on a blocklist. That handled my own visits and low-effort junk referrals. It did not stop a Singapore bot impersonating Chrome.

The second was edge filtering. My historical setup used Cloudflare Bot Fight Mode and Super Bot Fight Mode and added challenges for suspicious resolutions and unusual user agents. I had only recently configured it, so I did not yet have a full period of backtest data. I could not claim how much it blocked or whether it created false positives. That needed its own follow-up.

Bot patterns move. A segment in Singapore today may appear in Vietnam tomorrow. Filtering needs periodic maintenance.

The monthly check I kept

I now do this once a month:

• Run the country, source, and OS × screen-resolution views.
• Check the share of SG, VN, RU, and HK. In the historical rule, more than 15% meant I treated that month’s data as “exclude suspected bots before deciding.”
• Calculate Clarity sessions divided by GA4 sessions. A result below 50% meant most GA4 traffic had no Clarity recording, often a bot signal in this case.
• For any landing page with more than 70% bounce, inspect the source before deciding to change content.
• After adding a Cloudflare challenge rule, compare its logs with Googlebot and Bingbot access so the rule does not block them by mistake.

The ratio has to be written in the correct direction. With 30 Clarity sessions and 100 GA4 sessions:

Clarity ÷ GA4 = 30 ÷ 100 = 30%

Thirty percent is below 50%, so it matches the historical signal. Reversing the formula to GA4 ÷ Clarity produces 100 ÷ 30 = 333%, which can never satisfy a below-50% test. The arithmetic takes seconds and catches a direction error before it becomes a decision rule.

The first month changed how I read traffic. From the second month on, I had a bot-filter layer in my judgment. A quick scan could tell me which line deserved trust and which line needed another source.

That morning, one extra click into Clarity saved me from rewriting a blog post and investigating a mobile bug that was not there. Together, those two detours could have cost a week.

My rule from the incident is simple: when a metric suddenly improves, verify the data source before you credit the product.

GA4 going up can be good news. First confirm that the number belongs to people.

If you run your own independent store, apply these checks to one unusual traffic spike. I would be interested to know how much Singapore traffic you find. My historical bet was that at least 10% of readers would see a meaningful share.