Tuning Claim Gates

The Core Trade-off

Every claim gate trades volume vs. quality and exclusivity. Tighter gates mean fewer sessions clear — but each cleared claim carries higher confidence. Looser gates let more sessions through at the cost of accepting some mismatches or lower-quality leads.

There is no universally correct setting. The right thresholds depend on your lead economics: what you pay per lead, what a conversion is worth, and how much review capacity you have. Gates are a tool to express your own acquisition policy in code.

requireVerticals

Set this to the vertical(s) you actually buy. The gate rejects cross-sold or mislabeled leads — the "auto form sold as a home insurance lead" problem. When a claim request includes requireVerticals, Verfi checks whether the session's declared intent verticals overlap with your list. No overlap means rejection.

• This is a hard categorical match — it is low risk to set tight.
• A session with no declared intent is treated as a mismatch and rejected.
• Rejected with 409 intent_mismatch.

{
  "requireVerticals": ["mortgage", "home_insurance"]
}

requireVerifiedScore (0–1)

This gate controls how strictly the recorded behavior must match the declared vertical. Verfi computes a content-verification score by analyzing the session recording and comparing it against the declared intent. A score of 1.0 means strong alignment; 0.0 means little or no signal.

• Higher threshold = you only pay for leads whose session content genuinely resembles the declared vertical.
• Rejected below threshold with 409 verification_below_threshold.
• The score is computed lazily on the first claim that checks it, then cached on the session.

{
  "requireVerifiedScore": 0.4
}

minQualityScore (0–100)

This gate is your bot and lead-quality floor. Verfi scores each session on a 0–100 scale based on behavioral signals — interaction patterns, timing, mouse movement, and other signals that distinguish human-driven sessions from automated or low-quality ones.

Use the table below as a rough guide to what score ranges typically indicate:

• Rejected below threshold with 409 quality_below_threshold.
• Raising toward 70+ is appropriate for premium or high-cost verticals where the cost of a bad lead is high.
• Lowering it means you'd rather review borderline sessions manually than auto-reject them.

Combining Gates & Gate Order

All three gates can be combined in a single claim request to express a complete policy. Gate evaluation runs in a fixed order:

1. verticals — categorical match first
2. verifiedScore — content-verification check second
3. qualityScore — bot/quality floor last

Evaluation is fail-fast: the first gate that fails returns immediately. A 409 response tells you the first thing that failed, not everything that failed. If you want to know which of several gates would have failed, you can temporarily remove the earlier ones — but in production, the fail-fast behavior is intentional and keeps latency low.

A combined policy example — "mortgage leads, content-verified ≥ 0.5, quality ≥ 60":

{
  "requireVerticals": ["mortgage"],
  "requireVerifiedScore": 0.5,
  "minQualityScore": 60
}

This body, added to a claim request, means: only claim this session if it was declared as a mortgage lead, its recorded content scores ≥ 0.5 on mortgage-relevance, and its quality score is ≥ 60. Any failure returns 409 at the first failed gate.

Recommended Starting Points

• requireVerticals — set to your actual buys immediately; this is a low-risk, high-value gate.
• requireVerifiedScore — start around 0.3–0.5; observe rejection rates and tune from there.
• minQualityScore — start around 50; raise toward 70+ for premium / high-cost verticals.

Remember that 409'd claims are not consumed and not charged. Running a period of parallel observation — logging what would have been rejected without actually gating — can give you confidence before tightening.