Seatext library / BotRefund evidence
How to Verify Your Console Debug Evaluator Is Correctly Identifying Bots
To know if your console debug evaluator is working, run controlled tests with known automated browsers and real human sessions, then compare the debug output. A correct tool flags automation mismatches, leaves normal sessions...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
You know your console debug evaluator is working when it consistently flags known automated browsers and leaves normal sessions alone. Start by testing with a headless browser or an automation tool that patches browser APIs, then verify those same visits produce the expected debug output and that clean human sessions do not. The whole point of this check is to catch mismatches that a real browser never creates.
What the console debug evaluator does
The console debug evaluator is one of 106 independent checks BotRefund uses to build a reliable picture of whether a visit is human or automated. It looks for a mismatch that a real browsing session does not normally create. Automation tools often patch or hide browser APIs, but those changes can break when the browser is checked from another angle.
In practice, a normal browser runs standard browser APIs as they were designed – properties, permissions, and rendering contexts stay consistent without hiding anything. An automated browser often shows inconsistencies in those APIs. The evaluator is designed to notice that difference.
What you need before you test
- A test page with the console debug evaluator active (or access to the debug console feature).
- A way to run a known automated browser, such as Puppeteer, Playwright, or Selenium.
- A normal browser like Chrome or Firefox for comparison.
- Access to the debug output or console logs to inspect what the evaluator records.
Step-by-step: Run a controlled validation test
- Open your test page in a normal browser. Confirm the debug console shows no mismatch for this session.
- Repeat with a headless browser, for example Puppeteer with
headless: true. Open the same page. - Check the console output for the specific mismatch the evaluator is designed to catch – for instance, an API that behaves differently in the automated environment.
- Verify the debug output labels the session as having an anomaly but does not automatically declare the whole visit as a bot. In BotRefund, a single anomaly is never a verdict.
- Run a few more automated sessions with different tools. Also have a couple of real users on varied devices and browsers check your page. Confirm those sessions stay clean.
How to read the debug output
Look for the signal name, typically “Console Debug Evaluator.” You should see whether it records a mismatch or not. A correct evaluator will clearly show what it detected, such as an API inconsistency.
Remember: one anomaly is not a bot verdict. BotRefund cross-checks this signal against independent browser, network, device, and behavior data. The debug output is evidence, not a final classification.
When you see a mismatch, ask yourself: does the logged reason match something an automated browser would do? If you tested with Puppeteer and see a specific API difference, that is expected. If a clean human session shows the same mismatch, you might be dealing with a false positive from a privacy tool, corporate network, or unusual device.
Common mistakes that make your validation misleading
- Trusting one anomaly as proof of a bot. A single mismatch is not enough. BotRefund weighs the complete pattern across 106 checks.
- Testing only one automation tool. Different tools patch different APIs. Try several to see if the evaluator catches them all.
- Forgetting to compare with a clean human session. Without a baseline, you cannot tell if the evaluator is overly sensitive.
- Ignoring the cross-checked context. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people. The evaluator flags a mismatch but needs corroboration.
- Expecting a verdict from the debug console. The debug console shows diagnostics, not a final answer. The final decision comes from AI prediction that combines all signals.
Cross-check against real user sessions
Validation is meaningless if you never compare with real browsing. Enlist a few teammates or users to visit your test page in their normal browsers. Confirm the debug output does not flag them.
Then, run your automated test again and compare the two outputs side by side. A correct evaluator will show a clear difference: no anomaly for real humans, a consistent anomaly for known bots.
Also note that a single anomaly is only one piece of evidence. BotRefund cross-checks this signal with browser, network, device, and behavior data. If you see a mismatch on a human session, check whether something like a VPN or a corporate proxy could explain it. The tool is built to treat anomalies as evidence – not as a conviction.
Limitations and when this check alone is not enough
The console debug evaluator is a useful data point, but it is not self-sufficient. Sophisticated bots may avoid detectable API mismatches entirely. Also, privacy tools, corporate networks, and unusual devices can create false positives for genuine visitors.
BotRefund explicitly states that a single anomaly is not a bot verdict. Accuracy comes from corroboration across independent signals. The full system uses 106 checks and an AI model that weighs the complete pattern. Relying on only this one evaluator to decide “bot or human” will give you incomplete results.
If your debug console shows no mismatches, that does not prove a session is human. It only means this particular check did not find a problem. Always consider other behavioral signals like click patterns, pointer movement, and session timing.
Key facts about the console debug evaluator
| Fact | Why it matters |
|---|---|
| One of 106 independent checks | It is a single piece of evidence, not the whole picture. |
| Looks for mismatches in browser APIs | Automation tools often patch or hide APIs, creating detectable inconsistencies. |
| A single anomaly is not a bot verdict | Privacy tools, corporate networks, and unusual devices can cause unexpected behavior. |
| Cross-checked with other signals | It is tested against independent browser, network, device, and behavior data. |
| AI prediction weighs the complete pattern | The final decision uses all signals together, not a raw rule. |
| 99% accuracy comes from corroboration | Accuracy improves when many independent signals point to the same conclusion. |
FAQ
What is a console debug evaluator?
It is a diagnostic check that looks for mismatches in browser APIs. Automated browsers often patch or hide those APIs, and the evaluator detects when that consistency breaks.
Can a single mismatch prove a bot?
No. A single anomaly is evidence, not a verdict. Genuine users can have mismatches from privacy tools, corporate networks, or unusual devices. The full system cross-checks many signals.
Why do automation tools cause mismatches?
Automation tools like Puppeteer or Playwright patch or hide browser APIs to mimic a real browser. Those changes can break when the browser is checked from another angle, exposing an inconsistency.
What should I do if the debug console shows a clean session but I suspect a bot?
Look at other signals such as click behavior, pointer movement, session duration, and network patterns. The console debug evaluator is only one of many checks.
How accurate is this type of detection?
BotRefund reports 99% accuracy for its full system, not for this single check. That accuracy comes from corroboration across 106 independent signals and AI prediction.
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.