What Time Threshold Should I Use to Flag Suspicious Click-to-Conversion Speeds?

Click-to-conversion velocity is one of the clearest signals that separate human buyers from automated scripts. Bots can load a landing page, fill forms, and fire a conversion pixel in milliseconds — far faster than any person can read, decide, and act. Setting a velocity threshold lets you flag those impossible speeds for review or automatic rejection before they poison your optimization algorithms and inflate your cost per acquisition.

The exact number varies by funnel type. A single-page lead form with auto-fill might see legitimate conversions in 3–5 seconds. A multi-step e-commerce checkout with shipping, billing, and payment pages rarely completes under 30 seconds. Start with the baseline that matches your funnel, then refine using your own behavioral data.

Why Click-to-Conversion Speed Matters

Speed anomalies are a primary indicator of invalid traffic. When conversions happen faster than humanly possible, they usually come from scripts, headless browsers, or click farms that bypass normal navigation. These fake conversions do two things: they waste ad spend on clicks that never become customers, and they teach bidding algorithms to optimize for bot-like behavior. BotRefund's analysis shows that bot clicks steal up to 20% of Google and Meta ad budgets, and many of those clicks convert at superhuman speeds to mimic performance.

Beyond budget waste, velocity anomalies corrupt your conversion data. If your pixel fires on bot conversions, Meta and Google's machine learning models learn to target more bots. This creates a feedback loop where your best-performing audiences are actually the most fraudulent. Clean velocity thresholds break that loop by keeping bot conversions out of your training data.

How Bot Detection Measures Velocity

Modern detection doesn't just watch the clock. It builds a behavioral timeline from the first click through every scroll, hover, keystroke, and page transition. BotRefund's client-side telemetry tracks superhuman input speed (<1ms) for individual interactions, unnatural session durations that are too short, too long, or too uniform, and absence of humanlike mouse tremor that distinguishes real movement from scripted paths.

The system also watches for forms submitted immediately after landing and conversion events with no meaningful page engagement — no scrolling, no field corrections, no time on offer pages. These timing signals combine with pointer behavior (robotic linear movements, grid-aligned patterns) and engagement behavior (absence of clicks or scrolling) to build a composite velocity profile that's far more reliable than a single timestamp.

Main Threshold Options and Trade-offs

Three threshold bands cover most funnels. Each has distinct false-positive and false-negative risks.

Takeaway: Tighter thresholds catch more bots but flag more real users. Looser thresholds protect user experience but let patient bots through. The sweet spot is the lowest threshold that doesn't generate excessive manual reviews.

Decision Framework for Choosing Your Threshold

1. Map your funnel steps. Count page loads, required fields, and mandatory waits (3D Secure, OTP, address verification). Each step adds a realistic minimum.
2. Measure your human baseline. Pull the 5th percentile of real conversion times from the last 90 days. That's your floor — legitimate users rarely go faster.
3. Add a safety margin. Multiply the 5th percentile by 0.5 for aggressive filtering, 0.75 for balanced, 1.0 for conservative. This becomes your starting threshold.
4. Test in monitor mode. Flag but don't block for two weeks. Review flagged sessions: how many are real users with fast connections, auto-fill, or express checkout?
5. Adjust by segment. Mobile users on 4G may be faster than desktop on Wi-Fi. Returning customers with saved data are faster than new visitors. Device, geography, and traffic source all shift the baseline.
6. Lock and automate. Once false positives stay under 2–3% of flagged sessions, enable automatic rejection or refund evidence generation.

Practical Scenarios by Funnel Type

E-commerce Checkout (Standard)

A shopper hits a product page, adds to cart, enters shipping, chooses payment, confirms. Median human time: 45–90 seconds. 5th percentile: ~18 seconds. Starting threshold: 9–12 seconds (0.5–0.75×). Flag anything faster for review. Most bots complete in 2–4 seconds even with added delays.

Lead Gen Form (Single Page)

User clicks ad, lands on form, fills 5–7 fields, submits. Median: 25–40 seconds. 5th percentile: ~8 seconds with auto-fill. Starting threshold: 4–6 seconds. Watch for returning visitors — their 5th percentile may be 3 seconds.

B2B Demo Request (Multi-Step)

Landing page → qualification questions → calendar booking → confirmation. Median: 2–4 minutes. 5th percentile: ~45 seconds. Starting threshold: 25–35 seconds. Bots rarely simulate the calendar step convincingly.

Subscription Signup with 3D Secure

Adds mandatory bank redirect. Median: 60–120 seconds. 5th percentile: ~35 seconds. Starting threshold: 20–30 seconds. The bank step creates a hard floor bots can't easily compress.

Limitations and When This Advice Doesn't Apply

Velocity thresholds work best when you control the conversion event and can measure the full session. They break down in three cases:

• Server-side conversions only. If your pixel fires from a backend webhook (e.g., Stripe webhook after payment), you lose the client-side timeline. You only see the final timestamp, not the journey.
• Offline conversions imported later. CRM-matched sales, phone orders, or in-store pickups have no click-to-conversion velocity in the browser.
• Human fraud farms. Real people paid to click and convert will pass velocity checks. They exhibit human timing but zero intent. Behavioral detection (mouse tremor, scroll depth, field corrections) catches some, but not all.

In these cases, velocity is a secondary signal. Prioritize behavioral detection — the only reliable way to catch sophisticated bots that use rotating residential proxies and browser automation — and GCLID/FBCLID evidence capture for refund disputes.

Key Facts

Terminology

Click-to-conversion velocity

Elapsed time between the paid click (GCLID/FBCLID capture) and the conversion event firing on your thank-you or confirmation page.

5th percentile baseline

The time threshold below which only 5% of verified human conversions fall. Used as a statistical floor for legitimate speed.

Monitor mode

Flagging suspicious sessions for review without blocking or rejecting them, used to calibrate thresholds before automation.

Pixel poisoning

When bot conversions train ad platform algorithms to target more bot-like traffic, degrading audience quality over time.

GCLID / FBCLID

Google Click ID and Facebook Click ID — unique parameters appended to landing page URLs that link a click to a conversion for attribution and refund evidence.

FAQ

What if my threshold flags too many real customers?

Raise the threshold or segment by device, traffic source, and new vs. returning visitor. Mobile users on fast connections with auto-fill can legitimately convert in 3–4 seconds on simple forms. Create segment-specific thresholds instead of one global number.

Can bots just add random delays to beat my threshold?

Basic bots can, but sophisticated detection looks beyond total time. It checks for absence of humanlike mouse tremor, grid-aligned movement patterns, robotic linear mouse movements, and superhuman input speed (<1ms) on individual fields. A bot that adds a 10-second sleep but then fills 10 fields in 50ms still gets caught.

Should I block flagged conversions or just flag them for refund evidence?

Start with flag-only. Blocking risks false positives that hurt real revenue. Use flagged sessions to build compliance-ready refund reports with behavioral evidence linked to GCLIDs/FBCLIDs. Once your false-positive rate is consistently low (under 2–3%), consider auto-rejection for the most extreme velocities (<1 second).

How often should I recalibrate thresholds?

Quarterly, or after any major funnel change (new checkout, added 3D Secure, redesigned form). Seasonal traffic shifts (Black Friday, holiday sales) can also change baselines — run a monitor-mode week during peak periods before locking new thresholds.

Does this apply to view-through conversions?

No. View-through conversions have no click timestamp, so velocity can't be measured. They rely on impression-to-conversion windows (typically 1–7 days) which are a different fraud surface. Focus velocity thresholds on click-through conversions only.

What's the difference between this and Google's / Meta's built-in invalid traffic filters?

Platform filters run server-side on IP, user-agent, and click patterns. They miss bots on residential proxies with real browser fingerprints. Client-side behavioral detection — measuring pointer behavior, motion behavior, speed behavior, and engagement behavior in the browser — catches what server-side filters miss. The platforms also don't give you the granular evidence needed for refund disputes.

How much budget can I realistically recover with velocity-based detection?

BotRefund reports an 83% refund success rate for high-volume advertisers using client-side behavioral evidence. Recovery scales with spend and fraud level. Advertisers spending $50K–$250K/month typically see 5–15% of click spend flagged as invalid, with refund approval rates varying by platform and evidence quality.