Most of your visitors were not people

What happened on a pilot account, what it cost, and how to check your own data.

---

The number that was wrong

A B2B diagnostics company had been running the pixel for months. Their identified-visitor count looked healthy and grew steadily. Then someone asked a question nobody had asked before: how many distinct people are behind these events?

224,084  "human" visitors over 90 days
 10,496  of them were crawlers          (4.7%)
     59  distinct crawler user agents, every one self-identifying

On the paired staging tenant the proportion was far worse: 69.4% of events were unflagged crawlers. Roughly seven in ten "visits" were a machine.

Why the bot filter missed them

There was a bot filter. It matched a list of names — googlebot, bingbot, semrushbot and a few dozen others. It missed:

• Every Google crawler that is not Googlebot. AdsBot-Google, GoogleOther, Google-InspectionTool, Feedfetcher-Google, Google-Read-Aloud, Storebot-Google. Six products, one name in the list.
• Semrush's site auditor. Its token is SiteAuditBot. The list contained semrushbot. Same vendor, different string, no match.

The filter was not broken. It was a list, and a list is only ever as complete as the last person who edited it.

The fix that generalises

A crawler that puts a URL inside its own user agent is telling you what it is:

Mozilla/5.0 (compatible; SiteAuditBot/0.97; +http://www.semrush.com/bot.html)
Mozilla/5.0 (compatible; DuckAssistBot/1.0; +https://duckduckgo.com/duckassistbot/)

So alongside the name list, one rule:

\+https?://\S*(bot|crawl|spider)

That single pattern caught SiteAuditBot, DuckAssistBot and the Facebook crawler without anyone having enumerated them. It generalises to crawlers that do not exist yet, which a list cannot.

What it actually cost — and what it did not

This is the part most write-ups get wrong, so it is worth being exact.

Barely affected: identified people. A crawler has no email to resolve, so it almost never becomes an identified visitor:

19,517  unflagged crawler events, all time
   124  of those ever resolved to an identity   (0.6%)

Against 34,841 identified visitors on that account, 124 is noise.

Badly affected: anything counted per event. Traffic totals, page-view counts, "most visited pages", funnel step counts — every statistic not scoped to an identified person was inflated, and the inflation was concentrated on the pages crawlers like: pricing, sitemap-linked landing pages, anything in the nav.

The first version of our own internal write-up claimed identified-visitor counts were inflated by one in twenty. That was wrong, and we only found out by measuring instead of reasoning. If you take one thing from this: the blast radius of a data-quality bug is rarely where you first assume.

How to check your own data

Before believing any behavioural statistic, check that the number of events is plausible against the number of distinct actors:

curl "https://app.signal.geysera.com/signal-api/v1/visitors?page_size=1" \
  -H "Authorization: Bearer sk_sig_…"

The response's total is people. If your event counts are orders of magnitude larger than that and you are not a high-frequency consumer app, something in between is not a person.

Two rules worth adopting permanently:

1. n ≈ distinct visitors. If one "visitor" accounts for hundreds of page-views in a session, look at the user agent before building a funnel on it.
2. Treat unknown as unknown. Our own is_bot column was NULL — never evaluated — for 28.9% of rows. A query written as WHERE NOT is_bot drops every one of those, because NOT NULL is not TRUE. WHERE is_bot IS NOT TRUE is what you want. A three-state column read as two states is a silent filter.

What we changed

• The self-identifying-crawler rule now runs at ingest, so this cannot accumulate again.
• History was corrected in a migration that marks the rows it touched, so the change is reversible and auditable.
• Crawler-only visitors are hidden by default and still viewable — a filter, not a delete. Somebody eventually wants to know how much crawler traffic a page gets, and deleting the evidence to clean up a number is how you end up unable to answer that.