How to Use the Console Debug Evaluator to Detect False Positives

The Console Debug Evaluator gives you a direct look at one browser-level signal inside BotRefund's 106-check detection system. To detect a false positive, you open the evaluator on a real session, read the browser API flags it reports, and compare them with what a normal browser shows. A mismatch alone is not a verdict. You confirm a false positive only when the flag disagrees with the rest of the browser, network, device, and behavior evidence.

You do not need to read code to use the evaluator. It shows two columns: what a normal browser usually exposes and what an automated browser often reveals. Your job is to see which side your session matches.

What the Console Debug Evaluator Checks

The evaluator looks for API inconsistencies that automation tools create. Automation tools often patch or hide browser APIs so they look normal. Those patches can break when the browser is checked from another angle, and that broken state is the signal the evaluator records.

A real browser runs standard browser APIs as they were designed. Its built-in properties, permissions, and rendering contexts stay consistent without needing to hide automation. When the evaluator finds a mismatch, it flags that one objective fact about the visit.

Common mismatches include a navigator.webdriver property that is true, a missing window.chrome object, an altered permissions query result, or a canvas fingerprint that returns a generic value. Automation frameworks like Puppeteer or Selenium often leave these traces because they must hook into the browser at a low level. The evaluator detects the difference between a natural API surface and a patched one.

This matters for false positives because privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people. BotRefund treats the signal as evidence, not a verdict, and cross-checks it against independent browser, network, device, and behavior data.

Prerequisites Before You Run a Test

• A page running BotRefund's detection script. The evaluator only works where the script is installed.
• Access to the debug evaluator. You can reach it through your BotRefund dashboard or a free bot audit session.
• A test session you control. Open the page in a real browser with a clean profile and extensions disabled, so extension noise does not distort the reading.
• An optional automation session. If you want a direct comparison, run the same page in a headless browser or an emulated environment to see what a real bot signal looks like.

Set up both sessions on the same device and network if possible. That reduces variables. If you use a VPN, turn it off during the baseline test. If you use a corporate laptop, ask IT about any security software that may alter browser APIs.

Step-by-Step: How to Use the Evaluator

1. Open the protected page in a clean browser. Use a fresh profile without privacy extensions or a VPN first, so you see the baseline reading.
2. Start a session in the BotRefund dashboard. The evaluator attaches to the session and collects browser API signals while you browse.
3. Open the Console Debug Evaluator view. You will see the normal-browser column and the bot-browser column from the evaluator.
4. Read the flags for your session. Check whether the built-in properties, permissions, and rendering contexts match the normal-browser pattern.
5. Note any mismatch, but do not stop there. A single anomaly is not a bot verdict. It is one piece of evidence.
6. Cross-check the other signals. Review the session's network, device, and behavior data. Do they tell the same story as the evaluator flag?
7. Let the AI prediction weigh the full picture. The model treats the complete pattern as the decision, not a raw rule. If the other signals look human, the evaluator flag is likely a false positive.

For example, you might see that navigator.webdriver is true in your session. That alone could mean a bot. But if your session also shows natural mouse movement, scroll pauses, and a consistent reading history, the flag becomes less suspicious. The evaluator does not tell you to block; it tells you to investigate.

Practical Example: Reading a Flag That Looks Like a Bot

Imagine you run a lead form for a financial service. A session arrives from a US IP address, completes the form in 30 seconds, and submits a valid email. The Console Debug Evaluator shows that window.chrome is undefined and navigator.plugins is empty. Those are classic automation signatures.

You next check the behavior data. The user scrolled slowly through your pricing page, paused on the FAQ, and moved the mouse in a curved path. The network data shows a residential IP, not a data center. The device profile matches a common Windows laptop with a standard user agent.

Now you have two groups of evidence that disagree. The evaluator says bot, but the other signals say human. BotRefund's AI weighs all five categories. If the behavior and network are strongly human, the evaluator flag is very likely a false positive caused by a privacy extension or a corporate security suite that strips browser metadata.

You can verify by asking the user to open the page in a different browser or disable extensions. In this scenario, the flag disappears, confirming the false positive.

Troubleshooting: When the Evaluator Says Bot But User Is Real

If the evaluator shows a mismatch and you believe the visitor is human, follow these steps:

• Check the network data. A VPN, proxy, or Tor exit node can produce unusual browser fingerprints. Compare the IP reputation and ASN with the expected geography.
• Check the device profile. Some devices, like smart TVs or gaming consoles, have incomplete browser APIs. They may trigger a false flag even though the user is real.
• Look for corporate proxies. Many companies intercept traffic and inject headers that alter browser behavior. Ask the user if they are on a work network.
• Test with extensions disabled. Privacy tools like uBlock Origin, Privacy Badger, or Brave Shield often remove or modify browser properties. Run the same page in a private window with no extensions.
• Compare with a second device. If the same user visits from their phone without a VPN, does the flag disappear? If yes, the first environment caused it.
• Check the timing. If the session has natural dwell time and scrolling, it is less likely to be a bot, even if a single API flag is odd.

If you cannot remove the mismatch, treat the session as suspicious but not confirmed. Use other tools like a full session replay to see if the behavior matches a human.

Verification: Confirm the False Positive

To verify, re-open the same page in a second clean browser without extensions, VPN, or privacy tools. If the mismatch disappears, your original flag came from something in that environment. If the mismatch stays and the other signals agree with automation, the visit is a bot.

When the session is part of an ad campaign, preserve attribution before you change anything. Keep campaign, ad set, creative, placement, and click data intact so you can compare the before and after picture. A false positive might cause you to exclude a valuable audience, so you need the full data to decide.

Document your test. Write down which evaluator flag appeared, what the other signals showed, and what final decision you made. This becomes a reference for future false positive cases.

How the Evaluator Fits the Bigger Decision

BotRefund treats the Console Debug Evaluator as one layer in a three-step decision:

1. Independent evidence. This signal adds one objective fact about the visit.
2. Cross-checked context. BotRefund tests whether other signals support the same story.
3. AI prediction. The model weighs the complete pattern instead of trusting a raw rule.

That structure is what protects real users. A single browser tell never defines the verdict. The flag only matters when the rest of the evidence agrees.

In a real campaign, you might see dozens of evaluator flags per day. Do not manually review each one. Instead, use the evaluator when you suspect a false positive, such as when a known customer gets blocked or a placement underperforms. The evaluator helps you isolate whether that specific signal is breaking the system.

Key Facts: The Console Debug Evaluator at a Glance

Common Mistakes and Limitations

• Trusting one flag. A browser API mismatch alone does not prove a bot. The value comes from corroboration with other independent checks.
• Ignoring legitimate outliers. Privacy tools, travel, corporate networks, and unusual devices can flag genuine people. Always cross-check before acting.
• Calling every bad lead fraud. A weak campaign can attract real people who are not ready to buy. Separate lead-quality variation from automated behavior.
• Skipping attribution. If you change a campaign before verifying the signal, you lose the data needed to confirm the fix.
• Expecting the evaluator to work alone. The debug evaluator is one signal. The verdict comes from the full cross-checked pattern.
• Forgetting to test on mobile. Mobile browsers have different API surfaces. A desktop test result does not always hold for mobile users.
• Not updating your exclusion list. If you confirm a false positive, add the specific environment fingerprint to your allowlist so the same legitimate user is not flagged again.

FAQ

What is a false positive in bot detection?

A false positive is a real human visitor that the detection system flags as a bot. It often happens when a single check like the Console Debug Evaluator sees an odd value caused by extensions, networks, or unusual devices.

Why would the evaluator flag a normal browser?

Because privacy tools, corporate networks, travel connections, and unusual devices can produce unexpected browser behavior. Automation is one possible cause, but so are legitimate tools and environments.

How do I know a mismatch is a real bot signal?

Cross-check the mismatch against the session's network, device, and behavior data, then let the AI prediction weigh the whole picture. If the other signals agree with automation, treat it as a bot. If they look human, treat it as a false positive.

What is the difference between a signal and a verdict?

A signal is one objective fact about a visit, such as a browser API mismatch. A verdict is the conclusion the full model reaches after weighing all independent signals together.

Does the evaluator work on every browser and device?

The evaluator records what each browser exposes. Unusual browsers, corporate networks, and privacy tools can produce atypical values, which is why BotRefund cross-checks rather than relying on a raw rule.

How accurate is the full prediction?

BotRefund identifies a visit as bot or human with 99% accuracy when its prediction AI evaluates all browser, network, device, and behavior evidence together.

What should I do if I confirm a false positive?

Document the environment, add it to your allowlist if possible, and adjust any campaign exclusions. Then monitor future sessions from that environment to confirm they pass.

Can the evaluator cause a false positive on a specific campaign?

Yes. If your ad targets a demographic that often uses VPNs or corporate networks, you may see more evaluator flags. Use the full evidence before changing your targeting.