Seatext library / BotRefund evidence
Which CPU Concurrency Anomalies Signal Bot Traffic — And How to Read Them
CPU concurrency anomalies that most strongly suggest bot activity are mismatches between the number of logical processors a browser reports and the actual execution behavior of the JavaScript runtime. Real devices show consistent hardware...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
CPU concurrency anomalies that most strongly suggest bot traffic are mismatches between the number of logical processors a browser reports via navigator.hardwareConcurrency and the actual execution behavior of the JavaScript runtime. Real devices show consistent hardware fingerprints; virtualized or spoofed environments often report one CPU topology while behaving like another. BotRefund treats this signal as one piece of corroborating evidence, not a standalone verdict, and cross-checks it against 105 other browser, network, and behavioral checks before scoring a visit.
What CPU Concurrency Means in Browser Fingerprinting
navigator.hardwareConcurrency returns the number of logical CPU cores the browser believes are available. On a genuine laptop, phone, or desktop, this number aligns with the device's actual processor — a modern MacBook might report 8 or 10, a typical phone 6 or 8, a budget desktop 4. The value is not random; it correlates with the GPU renderer, screen resolution, memory, and OS version that the same browser session also reports.
Bots running in headless Chrome, Puppeteer, Playwright, or Selenium often execute inside containers or virtual machines where the reported concurrency is either hard-coded to a common default (like 4 or 8) or inherited from the host in a way that doesn't match the claimed device profile. A session that says it's an iPhone 15 but reports 16 logical cores is lying. A session that claims to be a Windows desktop with 2 cores but runs WebGL benchmarks at speeds only a 16-core machine achieves is also lying.
High-Risk Anomaly Patterns
1. Device-Profile Mismatch
The clearest red flag is a discrepancy between the user-agent's implied device class and the reported concurrency. Mobile user-agents reporting 8+ cores, or desktop user-agents reporting 1-2 cores, appear frequently in automated traffic. Legitimate edge cases exist — some high-end tablets and foldables blur the line — but the combination of an unlikely concurrency value with other mismatched signals (GPU renderer, screen dimensions, battery API) compounds the suspicion.
2. Static or Round-Number Values Across Sessions
Real traffic shows a distribution of concurrency values that matches the market share of actual devices. Bot fleets often reuse the same browser profile across thousands of sessions, producing an unnatural spike at a single value (e.g., 4 cores for every visit). When 90% of your traffic from a campaign reports exactly 4 logical cores while your organic traffic spreads across 4, 6, 8, 10, and 12, the campaign traffic warrants scrutiny.
3. Concurrency That Contradicts Performance Timing
JavaScript benchmarks (e.g., parallel Web Workers, performance.now() micro-tasks) reveal the real parallelism available. A browser reporting 8 cores but completing a parallel workload at 2-core speed suggests CPU throttling, container limits, or a spoofed hardwareConcurrency value. This mismatch is harder to fake consistently because it requires the bot to simulate realistic scheduling behavior across varying workloads.
4. Inconsistent Values Within a Single Session
Some sophisticated bots rotate fingerprints per request. If navigator.hardwareConcurrency changes between page loads without a corresponding devicechange event or OS-level explanation, the session is almost certainly automated. Real browsers do not change their logical core count mid-session.
Why a Single Anomaly Is Not a Verdict
Privacy tools, corporate networks, and unusual devices can produce unexpected behavior for genuine people. A user on a corporate VDI (virtual desktop infrastructure) might report 2 cores while the underlying host has 32. A privacy-focused browser might randomize hardwareConcurrency to resist fingerprinting. A traveler using a hotel business center PC might encounter hardware that doesn't match their usual profile. BotRefund keeps this signal as evidence — not a verdict — and cross-checks it against independent browser, network, device, and behavior data.
The Three-Step Corroboration Process
- Independent evidence: The CPU concurrency check adds one objective fact about the visit. It does not trigger a block or flag on its own.
- Cross-checked context: BotRefund tests whether other signals support the same story. Does the GPU renderer match the claimed device? Do mouse movements show human tremor? Is the IP residential or data-center? Are click intervals superhuman?
- AI prediction: The model weighs the complete pattern instead of trusting a raw rule. By seeing how all 106 signals fit together, it identifies a visit as bot or human with 99% accuracy.
How CPU Concurrency Fits Among Other Bot Signals
CPU concurrency is a static fingerprint signal — it describes what the browser claims about its hardware. Behavioral signals (mouse tremor, click timing, scroll patterns) describe what the visitor does. Network signals (IP reputation, proxy detection, ASN) describe where the request comes from. No single category is sufficient.
| Signal Category | Example Checks | What It Catches | Limitation |
|---|---|---|---|
| Static fingerprint | CPU concurrency, GPU renderer, canvas hash, font list, battery API | Spoofed profiles, headless defaults, VM artifacts | Privacy tools can randomize; legitimate rare devices look odd |
| Behavioral | Mouse tremor, click intervals, scroll velocity, focus events | Scripted interactions, replay attacks, linear paths | Accessibility tools, motor impairments, mobile touch differ |
| Network | IP reputation, residential proxy detection, TLS fingerprint | Data-center bots, proxy rotation, VPN exit nodes | Corporate proxies, shared residential IPs, mobile carriers |
| Challenge-response | CAPTCHA, proof-of-work, behavioral challenges | Unsophisticated scripts, bulk automation | Human-in-the-loop solving, AI CAPTCHA breakers |
The CPU concurrency check is valuable because it is cheap to compute, hard to fake perfectly without a real device, and orthogonal to behavioral signals — a bot can mimic human mouse curves but still betray its containerized CPU topology.
Practical Scenarios
Scenario A: E-commerce Checkout Spike
A flash sale produces 50,000 checkouts in 10 minutes. 87% report hardwareConcurrency: 4; organic traffic averages 35% at 4 cores. Mouse tremor is absent in 91% of the spike sessions. Click intervals cluster at 12ms. The concurrency anomaly aligns with behavioral and timing anomalies — high confidence bot traffic.
Scenario B: B2B Lead Form Submissions
A partner drives 2,000 form fills. Concurrency values match expected device distribution. But 60% show zero mouse movement before first input, and 40% use disposable email domains. Concurrency alone would miss this; behavioral signals catch it.
Scenario C: Corporate VPN Users
Legitimate employees access the site via corporate VDI. They report 2 cores (VDI limit) but their user-agents say modern laptops. Mouse tremor, scroll behavior, and session duration are human. Concurrency anomaly is real but explained by infrastructure — cross-checking prevents false positives.
Limitations and When This Advice Does Not Apply
- Privacy-hardened browsers: Brave, Tor, and some Firefox configurations may randomize or mask
hardwareConcurrency. Treat these as "unknown" rather than "suspicious." - New device form factors: Foldables, ARM Windows laptops, and cloud-gaming thin clients can report unconventional core counts. Maintain an allowlist updated quarterly.
- Server-side rendering bots: Some scrapers execute only the initial HTML and never run the client-side fingerprinting script. CPU concurrency is invisible for these visits; rely on server-side log analysis (request rate, user-agent entropy, IP reputation).
- Sophisticated device farms: Real phones in racks, controlled by automation software, will report authentic concurrency values. Behavioral and network signals become primary.
Key Facts
| Fact | Detail |
|---|---|
| Total independent checks in BotRefund | 106 |
| CPU concurrency check role | One objective evidence signal, not a verdict |
| Cross-check categories | Browser, network, device, behavior |
| Model accuracy claim | 99% (corroboration across all signals) |
| False-positive sources | Privacy tools, corporate VDI, travel, unusual devices |
| Setup time for free audit | About one minute, no credit card |
| Refund lookback window | Google Ads spend back to 2017 |
| Estimated bot click waste | Up to 20% of Google and Meta ad budget |
Terminology
- Logical cores / hardware concurrency: The number of threads the OS schedules simultaneously, reported by
navigator.hardwareConcurrency. - Headless browser: A browser running without a visible UI, typically automated via Puppeteer, Playwright, or Selenium.
- Spoofed fingerprint: A deliberately altered set of browser attributes (user-agent, canvas, fonts, concurrency) to mimic a target device.
- VDI (Virtual Desktop Infrastructure): Corporate remote-desktop environments where users access a shared host; often limits visible CPU cores.
- Residential proxy: An exit IP belonging to a consumer ISP, often from a compromised IoT device or opted-in user, used to mask bot origin.
- Pixel poisoning: Invalid clicks corrupting the conversion data that ad platforms use to optimize targeting.
FAQ
Can a legitimate user have a CPU concurrency mismatch?
Yes. Corporate VDI, privacy browsers, virtual machines for development, and rare device form factors can all produce mismatches. That's why BotRefund treats it as evidence, not a verdict, and requires corroboration from other signals.
How do bots fake hardware concurrency?
Most don't bother — they run in containers that inherit the host's value or use the automation framework's default (often 4). Sophisticated bots may inject a plausible value via Object.defineProperty on navigator, but keeping it consistent with WebGL benchmarks, battery API, and device memory across all pages is difficult.
Does blocking based on concurrency alone work?
No. It produces false positives from privacy tools and corporate networks, and misses device-farm bots running on real phones. Use it as a weighting factor in a scoring model, not a block rule.
What's the difference between CPU concurrency and device memory?
navigator.deviceMemory reports approximate RAM in GiB (e.g., 8, 16). hardwareConcurrency reports logical CPU cores. Both are static fingerprint signals; both can be spoofed; both are more useful when cross-checked against each other and against performance benchmarks.
How often should I review concurrency distributions in my traffic?
Weekly for high-spend campaigns; monthly for lower volume. Look for sudden shifts in the histogram — a new peak at a single value often signals a new bot fleet or a tracking script change.
Can I see this data in Google Analytics?
Not natively. You need client-side fingerprinting JavaScript that collects navigator.hardwareConcurrency and sends it to your analytics or bot-detection endpoint. BotRefund installs in about one minute and surfaces this alongside 105 other signals.
What should I compare when evaluating bot detection vendors?
Compare: (1) number of independent signals and whether they're corroborated or used as single rules, (2) false-positive handling for privacy tools and corporate networks, (3) client-side vs server-side coverage, (4) refund/recovery workflow integration with Google and Meta, (5) setup time and maintenance burden. Ask for a live audit on your own traffic before committing.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
How BotRefund can help
BotRefund runs the CPU concurrency check as one of 106 independent signals. Each signal adds objective evidence; the AI model weighs the full pattern across browser, network, device, and behavior data to reach 99% accuracy. You can install the script in about a minute with no credit card, run a free live bot audit on your own traffic, and see exactly which visits show concurrency mismatches alongside mouse tremor, click timing, IP reputation, and 100+ other signals. If bot clicks are found, BotRefund compiles the client-side evidence into audit-ready reports and handles the refund dispute process with Google and Meta — including spend going back to 2017.
Limitation: the CPU concurrency signal alone will not block or flag a visit. It requires corroboration. Privacy-hardened browsers, corporate VDI, and rare device form factors can produce legitimate mismatches that the cross-checking process is designed to resolve without false positives.