Bot Detection Setup Guide

Every account has bot traffic. Most of it looks like real Chrome sessions. The bots fill out forms, trigger conversion events, and inflate your numbers in ways that are invisible until you start scoring behavior instead of just checking user-agent strings.

We built Advanced Bot Detection to catch the bots that traditional detection misses. The algorithm scores every event from 0 to 100 based on behavioral signals: mouse movement patterns, scroll behavior, click timing, keyboard activity, and interaction diversity. A bot can fake a Chrome user-agent string. It cannot fake natural human behavior across all of those dimensions at once.

This guide covers three common problems bot traffic causes and how to solve each one. All three start with the same foundation: turning on behavioral scoring.

Foundation: Enable Advanced Bot Detection

Every recipe below starts here. Advanced Bot Detection requires a one-line SDK change. Without it, scoring falls back to user-agent analysis only, which misses bots that spoof their identity.

Copy-paste snippet:

ours('init', 'YOUR_TOKEN', { bot_detection: true });

NPM SDK:

import ours from '@oursprivacy/web-cdp';

ours.init('YOUR_TOKEN', { bot_detection: true });

Via the tag manager: Enable the Advanced Bot Detection checkbox in your Init tag settings. No code changes needed.

Once enabled, the SDK passively collects behavioral signals. Collection is throttled and lightweight. No PII is collected. Raw signals are processed server-side and stripped after scoring. They are never stored.

Every event will now include:

• bot_score (0 to 100): the behavioral likelihood score

• bot_category: human, likely_human, suspicious, likely_bot, or bot

• bot_signals_used: which signals contributed to the score

Deploy this change and let it run for a few days before configuring filtering. The scores are calculated and stored regardless of your filtering mode, so there is nothing to break while you observe.

For the full list of scoring signals and how they work, see the Bot Detection and Filtering documentation.

Recipe 1: Stop Bot Form Fills From Polluting Your CRM

The problem: Your CRM is filling with leads that never convert. Form fill volume looks healthy, but sales is chasing contacts that do not exist. The leads came from bots submitting your forms with fake data, and every one of them flowed downstream because nothing flagged them on the way in.

The fix: Block bot traffic from reaching your CRM destination specifically, without affecting other destinations that might still want the data.

Steps

1. Enable Advanced Bot Detection (see Foundation above).

2. Confirm you have bot form fills. In your event data, filter for form fill events and check bot_score. If you see form fills scoring above 50 with signals like clicks_without_mouse, uniform_mouse_velocity, or no_keyboard_activity, those are bot submissions.

3. Add a stop condition to your CRM destination. In your CRM destination's mapper, add a condition that blocks dispatch when event.bot_score >= 50 for form fill events. Use a lower threshold here (50 instead of the default 70) because the cost of a false negative (a bot lead in your CRM) is higher than the cost of a false positive (a real lead that gets re-captured on a follow-up visit).

4. Verify. Check your CRM destination's recent dispatched events. Form fills with high bot scores should no longer appear. Monitor for a week and adjust the threshold if legitimate leads are being blocked.

Why per-destination instead of source-level filtering: You probably still want form fill events flowing to your analytics tools so you can measure total volume and bot percentage. Blocking at the CRM destination keeps your analytics complete while protecting your pipeline.

Recipe 2: Stop Optimizing Ad Platforms for Bot Traffic

The problem: You are sending conversion events to Meta, Google Ads, or other ad platforms, and some of those conversions are bots. The platform's optimization algorithm treats every conversion signal equally. When bots trigger your lower-funnel events (form fills, demo requests, purchases), the algorithm optimizes toward the traffic patterns that produced those conversions. You end up paying to acquire more traffic that looks like bots.

The fix: Block bot traffic from reaching your ad platform destinations for lower-funnel events while keeping upper-funnel events (page views, content engagement) flowing normally.

Steps

1. Enable Advanced Bot Detection (see Foundation above).

2. Identify which events you are sending to ad platforms. Check your destination mappers for Meta CAPI, Google Ads, or similar. Note which event types you are dispatching. Typically this includes page views, form fills, and custom conversion events.

3. Add stop conditions for lower-funnel events. In your ad platform destination's mapper, add a condition that blocks dispatch when event.bot_score >= 50 for conversion events (form fills, demo requests, purchases). Keep page view events unfiltered or use a higher threshold (70 or 80), since bot page views are less damaging to optimization than bot conversions.

4. Consider using Global Data Governance rules if you want the same bot filtering applied across multiple ad platform destinations at once. Create a rule that stops dispatch to ad platform destinations when event.bot_score >= 50 and the event type is a conversion event.

5. Verify. Compare your ad platform's reported conversion volume before and after filtering. You should see a drop in conversions that corresponds to the bot traffic you were sending. Over the following weeks, watch whether your cost per acquisition improves as the optimization algorithm trains on cleaner signals.

Why lower-funnel events matter more: A bot page view is noise. A bot conversion is poison. Page views add volume but do not steer optimization. Conversion events directly influence which audiences the platform targets and how much it bids. Filtering bot conversions has an outsized effect on ad spend efficiency.

Recipe 3: Get Analytics You Can Actually Trust

The problem: Your session counts, page view totals, and engagement metrics include bot traffic that makes it impossible to report accurately. You suspect the numbers are inflated but do not know by how much. Decisions are being made on data that includes an unknown quantity of automation.

The fix: Enable source-level threshold filtering to remove bot traffic from all destinations at once.

Steps

1. Enable Advanced Bot Detection (see Foundation above).

2. Observe your traffic for 3 to 7 days. Go to Sources > [Your Source] > Settings and confirm Bot Control Mode is set to Allow. Check the Bot Analytics dashboard to understand your bot traffic volume and composition:

3. Set your threshold. Navigate to Sources > [Your Source] > Settings > Bot Control Mode and switch to Threshold. Start with the default of 70, which is conservative and minimizes false positives. If your observation period showed heavy bot traffic in the 50 to 70 range, consider lowering to 50 for more aggressive filtering.

4. Verify. Compare your analytics before and after filtering. Look for:

5. Tune over time. If legitimate traffic is being filtered, raise the threshold. If bots are still getting through, lower it. Use bot_signals_used on suspicious events to understand what the algorithm is detecting. Common signals include uniform_mouse_velocity, linear_mouse_path, no_scroll_activity, and interaction_monotony.

When to use source-level filtering vs. per-destination: Source-level filtering is simpler and cleans everything at once. Use it when your primary goal is accurate analytics across the board. Use per-destination filtering (Recipes 1 and 2) when different destinations need different levels of sensitivity.

For the full feature reference including all scoring signals, event properties, and filtering modes, see the Bot Detection and Filtering documentation.