How bot traffic filtering works
What Ordinary classifies as bot traffic, how we identify it, what gets excluded from your session counts, and what you can verify if a number looks off.
Written by The Ordinary Team · Updated How bot traffic filtering works
Short version: every store gets some traffic from automated visitors — search-engine crawlers, AI scrapers, SEO tools, uptime monitors, etc. — that show up on your storefront but aren’t real shoppers. Ordinary classifies these as bot traffic and excludes them from session, visitor, and funnel reports so the numbers reflect what real humans actually did.
This is why your Ordinary session counts should line up closely with Shopify Admin’s analytics — both filter bots out of the headline number.
What gets classified as bot traffic
Ordinary classifies the following as bot traffic:
- Search engine crawlers — Googlebot, Bingbot, DuckDuckBot, YandexBot, Baidu, Applebot, etc.
- AI scrapers — GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Bytespider (ByteDance), CCBot (Common Crawl), Google-Extended, meta-externalagent.
- SEO and analytics tools — AhrefsBot, SemrushBot, MJ12bot, DotBot, Screaming Frog, DeepCrawl, etc.
- Social link unfurl previews — Facebook, Twitter, LinkedIn, Slack, Discord, Telegram, WhatsApp.
- Uptime monitors and performance auditors — Pingdom, UptimeRobot, GTmetrix, Lighthouse, Datadog Synthetics, etc.
- Headless browser tooling — Selenium, Puppeteer, Playwright, HeadlessChrome, PhantomJS.
- HTTP client libraries — curl, wget, python-requests, axios, PostmanRuntime, when used without disguising themselves.
- Context-free automated requests — a page request that arrives with no browser identity at all and no sign of where it came from (no referrer, no campaign tag). Real shoppers’ browsers always identify themselves; a request carrying none of that is automated.
How Ordinary identifies bots
Two layers of classification work together:
1. User-agent pattern matching at the moment of capture
Every event the pixel sends includes the browser’s user-agent string. When the event arrives, Ordinary checks it against a catalog of hundreds of known bot signatures. If it matches, the event is tagged as bot traffic immediately.
This catches the polite, well-identified bots — search engines, AI scrapers, SEO tools, etc. — which is the majority of automated traffic.
2. Context-free request detection
Some automated traffic doesn’t identify itself with a recognizable bot name. For these, Ordinary looks at whether the request has the basic hallmarks of a real visit. A real shopper’s browser always announces what browser it is, and a real visit almost always shows where the shopper came from (a search engine, an ad, a link). A page request that arrives with none of that — no browser identity, no referring source, no campaign tag — is an automated cold request, and Ordinary tags it as bot traffic.
This check is deliberately conservative: if a request carries any of those signals (a recognizable browser, a referrer, or a campaign tag), it is treated as a real visitor and counted. A real shopper who lands on one page and leaves — a bounce — is a normal session and is always counted; Ordinary never treats a short visit as a bot on its own.
What’s excluded from your reports
Once a visitor is tagged as bot traffic, all their events are excluded from:
- Daily session counts and unique-visitor counts
- Funnel conversion rates (session → ATC → checkout → order)
- Channel attribution (you won’t see “Googlebot” listed as a traffic source dragging your numbers around)
- Cohort and retention reports
- Device, browser, and geographic breakdowns
- Page performance and product performance reports
- Onsite search reports
Order revenue is not affected — bots don’t complete orders, so no real order numbers shift. Only the upstream visitor / session metrics tighten.
What’s NOT excluded
- Raw pixel event records — we still capture every event, including ones from bots. Filtering happens at the report layer, not at ingest. This lets us reclassify if we discover a rule was too aggressive, and gives the support team a way to investigate edge cases.
- The cart-stitch coverage metric in the admin dashboard — this measures how reliably the bridge identifier propagates through the funnel; filtering bots would skew the ratio.
- Webhook-synthesized order rows — orders that arrived via webhook without a corresponding pixel event are never bot candidates by construction.
How bot filtering settles in over time
Bot filtering works on the browser’s identity, which Ordinary captures most completely on visits that happen after you’re fully set up. For very recent visits, every bot is caught right away. For older visits in your history, Ordinary only excludes the ones it can positively confirm as bots — it never guesses, because a cautious guess on older data risks dropping a real shopper.
The practical effect: if your store has a lot of bot traffic, your reported sessions tighten toward your true human number over the first few weeks of use as more of your reporting window is made up of fully-classified recent visits. If your store has little bot traffic, you won’t notice a change — your numbers already reflect real shoppers. Either way, Ordinary only ever excludes confirmed bots; it never removes a real visit to make a number look better.
If a session number looks off versus Shopify Admin in either direction, mention it to support — we can look at your store’s specific traffic mix and confirm what’s driving the difference.
How this compares to Shopify Admin
Shopify Admin’s analytics also filters bot traffic from session counts. Ordinary uses a similar posture, which is why the two numbers should line up closely. If you see a meaningful gap in either direction, mention it to support — there are a few specific cases where they can diverge (deep-link campaigns, very old historical periods, etc.) and we can walk through what’s driving it.