Seatext library / BotRefund evidence
How Cross-Checking IP and Device Signals Improves Bot Detection
Cross-checking IP reputation with device fingerprinting catches bots that use proxies or emulators by comparing network signals (IP, port, geolocation) against hardware and browser attributes. When these signals disagree — such as a residential...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
Combining IP reputation with device fingerprinting helps identify bots that use proxies or emulators. A single signal — whether an IP address or a browser attribute — can be spoofed or legitimately unusual. Cross-checking compares independent evidence across network, device, browser, and behavior layers so that only consistent patterns pass as human.
What cross-checking IP and device signals means
Cross-checking means collecting separate facts about a visit — where the connection comes from, what hardware the browser reports, how the user behaves — and testing whether they tell the same story. BotRefund runs 106 independent checks across browser, network, device, and behavior evidence, then feeds each signal into a prediction model that weighs the complete pattern instead of trusting a raw rule.
For example, a real visitor on a home laptop in Chicago will show a residential IP, a timezone matching Central Time, a browser language set to English, and hardware attributes like a standard CPU core count and a common GPU. A bot using a proxy might show a residential IP from a different country, but the device fingerprint still reveals a virtual machine or a headless browser environment. Cross-checking exposes that inconsistency.
Why single signals fail on their own
An IP address alone is weak. Residential proxy networks rotate IPs that look clean. Many bots now use real residential IPs to bypass basic IP blacklists. Conversely, a clean IP may be shared by a company behind a corporate proxy, making it look suspicious even though the visitor is human.
A device fingerprint alone is also weak. Anti-detect browsers can spoof user agents, canvas hashes, and WebGL parameters. They can emulate a realistic device profile. But they rarely align that profile with the network layer. For instance, a spoofed fingerprint might claim a MacBook in California while the IP geolocates to a data center in Virginia. Cross-checking catches that mismatch.
Privacy tools, travel, corporate networks, and unusual devices can make genuine visitors look anomalous on any one check. A single anomaly is not a bot verdict. BotRefund keeps each signal as evidence — not a verdict — and cross-checks it against independent browser, network, device, and behavior data.
How the cross-checking process works
- Collect independent signals. Network checks capture IP reputation, port usage, geolocation, and language headers. Device checks capture CPU concurrency, GPU renderer, font list, audio stack, and browser APIs. Behavior checks capture mouse movement, click timing, scroll patterns, and session duration.
- Compare for coherence. A real visitor's connection, location, language, and timing normally agree with one another. Proxy rotation, location masking, or browser spoofing can make separate network facts disagree. For example, the CPU Concurrency Lie check looks for a mismatch where the claimed hardware profile does not match the actual processor behavior. Suspicious Ports checks detect non-standard ports that often signal proxy or VPN usage.
- Weight the pattern. The prediction AI evaluates the complete picture across browser, network, device, and behavior evidence. It does not rely on a single red flag. It looks at how many signals point in the same direction. If three independent checks agree that a visit is automated, the confidence is high. If only one check is off, it may be a false positive.
- Preserve context for review. Each signal remains traceable so analysts can see which checks agreed and which disagreed. This audit trail supports refund disputes with Google and Meta, as seen in the FinTrust case study where $140,000 was recovered after cross-checking exposed bot registrations.
Key signal categories that get cross-checked
- Network layer: IP reputation, suspicious ports, VPN/proxy indicators, geolocation consistency, timezone vs. IP mismatch. A bot using a proxy may exit through a port commonly used by data centers, even if the IP itself is residential.
- Device layer: CPU concurrency, GPU fingerprint, canvas hash, audio context, font enumeration, battery API, WebGL parameters. Virtual machines often report CPU core counts or GPU renderer strings that differ from typical consumer devices.
- Browser layer: User-agent consistency, feature support, JavaScript engine quirks, navigator properties, automation flags (e.g.,
navigator.webdriver). Anti-detect browsers may fail to mimic subtle browser engine differences. - Behavior layer: Mouse tremor, click timing, scroll patterns, tab-switch speed, form completion velocity, session duration distribution. Headless browsers often produce linear mouse paths or superhuman input speeds under 1ms, as highlighted in BotRefund's detection methods.
Each check adds one objective fact. Alone, any check can be fooled. Together, they form a web of evidence that is extremely hard to fake consistently.
Common mismatches that reveal bots
| Mismatch type | What it looks like | Why it suggests automation |
|---|---|---|
| IP vs. hardware | Residential IP but CPU/GPU signatures match cloud instance types | Proxy exit node hides data-center origin |
| Geolocation vs. timezone | IP says New York, browser timezone says UTC+8 | Spoofed location without matching system clock |
| Language headers vs. IP country | Accept-Language: en-US but IP geolocates to Brazil | Browser profile not aligned with exit node |
| Port behavior vs. device type | Mobile user-agent but connection uses data-center port ranges | Emulator running in server farm |
| Behavior vs. device capability | High-DPI device reporting but zero mouse tremor | Headless script driving a spoofed fingerprint |
| Tab speed vs. human limits | Tab switches in under 50ms repeatedly | Impossible tab speed reveals scripted interaction |
These mismatches are not proof by themselves. They are triggers for deeper evaluation. The AI model looks at the whole pattern before deciding.
Practical scenarios where cross-checking matters
Ad fraud protection
Google and Meta ads can be clicked by bots that inflate costs and distort conversion data. Cross-checking blocks these bots before they generate fake leads or conversions. In the FinTrust neobank case, cross-checking reduced bot click rates from 14% to a manageable level and improved conversion rates by 18%.
Lead quality
Forms are a common target for automated submissions. A bot might fill a form in under a second, which is impossible for a human. Cross-checking the submission speed with the device's input capabilities and the IP's history helps separate real leads from fake ones.
Account security
Login pages face credential stuffing and account takeover attempts. Cross-checking the device fingerprint against known device profiles for a user can flag unusual sessions. If a user typically logs in from a Windows laptop in London, a login from an iPhone in a data-center IP raises a red flag.
Price scraping and inventory abuse
Competitors may use bots to scrape pricing or hold inventory. Cross-checking IP and device signals helps identify server farms that run headless browsers to automate these actions.
Limitations and false positives
Cross-checking is not perfect. Privacy tools like Tor or VPNs can cause false positives. A traveler using a hotel network might show a mismatched timezone. A developer testing a site from a virtual machine could trigger multiple signals.
The key is to require multiple independent signals to agree before flagging a visit as a bot. A single anomaly is kept as evidence, not a verdict. BotRefund's model weighs the complete pattern, which reduces false positives. However, edge cases still occur. Analysts should preserve attribution before changing campaigns and verify CRM outcomes against ad-platform data.
For example, a genuine user on a corporate VPN might show a data-center IP but a hardware profile consistent with a typical office laptop, and their behavior will be humanlike. The model sees the coherent behavior and passes them. Only when several layers disagree does the system flag the visit.
Key facts
| Fact | Detail |
|---|---|
| Independent checks per visit | 106 |
| Signal categories | Browser, network, device, behavior |
| Reported accuracy | 99% (from corroboration across signals) |
| Single-anomaly policy | Kept as evidence, not a verdict |
| Refund lookback window | Google Ads spend dating back to 2017 |
| Setup time | About one minute to add to website |
FAQ
Does cross-checking require personally identifiable information?
No. The signals are technical attributes — IP reputation, hardware fingerprints, browser APIs, interaction timing — not personal data. The system evaluates pattern coherence without identifying the individual.
Can sophisticated bots pass cross-checks by spoofing every layer?
Spoofing all 106 independent checks consistently is extremely difficult. Anti-detect frameworks may align user-agent and fingerprint, but they rarely replicate the full behavioral distribution (mouse tremor, click latency variance, tab-switch timing) while also maintaining coherent network signals across rotating proxies.
How does this affect legitimate users on VPNs or corporate networks?
VPN and corporate traffic often shows coherent mismatches (e.g., data-center IP with matching hardware profile). The model weighs the complete pattern; a consistent corporate profile across network, device, and behavior layers typically passes. Isolated anomalies trigger review, not automatic blocking.
What happens when signals disagree but the visitor is human?
The visit is flagged for analyst review rather than auto-blocked. Preserved attribution data lets teams compare ad-platform clicks, website sessions, and CRM outcomes before taking action.
How quickly does the cross-checking run?
Signals are collected and evaluated in real time during the visit. The prediction model returns a bot/human classification before the session ends, enabling real-time pixel protection and suppression of conversion events from automated traffic.
Can I see which specific signals triggered a bot classification?
Yes. Each signal remains traceable in the audit trail. Analysts can review which of the 106 checks agreed or disagreed for any visit, supporting refund dispute reports submitted to Google and Meta.
Is cross-checking effective against residential proxy botnets?
Residential proxies make IP reputation less decisive, but they do not hide the device fingerprint or behavior anomalies. A residential IP with a cloud-based GPU renderer and robotic mouse movements is still flagged by cross-checking. This is exactly why the multi-layer approach is superior to IP-only filtering.
What is the cost of a false positive?
False positives can waste analyst time and potentially block a real customer. That is why the system uses a confidence score rather than a binary rule. Only visits that meet a high threshold of inconsistency are automatically blocked. Lower-confidence cases go to review.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.