IVT AI Plugin Real-Time Invalid Traffic Detection for Revive Adserver

In digital advertising, every click or impression is expected to come from a genuine, interested user. In practice, a meaningful share of traffic is generated by bots, scripts, or manipulated requests that never represent real human intent.

The IVT AI Plugin sits in the path of your incoming ad traffic and decides, in real time, whether a request looks genuine or fraudulent. Rather than relying on a single fixed rule, it evaluates each request using rule-based weighted scoring, an unsupervised machine-learning anomaly layer, and an optional AI-generated explanation of why a request was flagged. Every request gets a numeric risk score and a clear verdict — Clean, Suspicious, or Blocked — produced fast enough to sit on the real-time bidding/serving path without adding noticeable latency.

Data It Evaluates

No additional data collection is required — the plugin works from fields already part of a standard traffic event:

• event_id — uniquely identifies the request, so a decision can be traced back and the same event isn't processed twice
• timestamp — standardized to UTC internally, keeping velocity and duplicate-window calculations consistent regardless of where a request originates
• ip — the anchor for blocklist checks, velocity tracking, and duplicate detection
• user_agent — the client string identifying the browser or script; a strong bot/script signal
• creative_id — used together with IP and User-Agent to detect repeated, duplicate engagement with the same ad
• geo_declared / geo_ip — the location a request claims versus where its IP actually resolves; a mismatch is a strong fraud signal
• event_type — impression, click, or other interaction, since validation rules can differ by type

Detection Signals

Before scoring happens, each raw request is converted into a set of validation features:

• IP Reputation — checked against a blocklist (static, threat-intelligence feed, or internally generated); a hit is a strong signal, but a miss doesn't automatically mean the request is clean — the other checks still run
• User-Agent Validation — pattern-matched against known bot and script signatures (e.g. “bot,” “crawler,” “python-requests”) to flag non-browser clients
• Request Velocity — the number of requests from the same IP within a configurable window (e.g. 1,000 requests in 60 seconds), tracked in Redis; a burst far above normal human behavior is flagged
• Duplicate Detection — the combination of IP, User-Agent, and Creative ID is tracked in Redis; the same combination repeating within the window is flagged as a duplicate
• Geo Consistency — declared geography compared against IP-resolved geography (e.g. declared “US” but the IP resolves to “SG”)

Real-Time State with Redis

Velocity and duplicate-request detection rely on short-lived, shared memory of recent activity. Redis maintains a rolling window of recent request timestamps per IP, so the plugin can answer “how many requests came from this IP in the last N seconds” instantly, and stores short-lived keys for IP + User-Agent + Creative ID combinations that expire automatically. This shared state matters most once more than one instance of the plugin is running — every instance reads and writes the same Redis store, so velocity and duplicate checks stay accurate across your whole fleet. If Redis ever becomes unavailable, the plugin fails open — returning a safe “not flagged” default rather than blocking legitimate traffic — while logging the failure for visibility.

Detection Approach

Three layers work together — two decide, one explains:

• Rule-based weighted scoring — each suspicious feature contributes a configurable weight toward a 0–100 rule score. Deterministic, fast, and easy to tune; the primary decision-maker from day one.
• Unsupervised ML anomaly detection (IsolationForest) — trained on historical traffic features, this layer catches unusual patterns fixed rules wouldn't anticipate. It supplements the rule layer rather than replacing it. During a “cold start” with insufficient history, the plugin runs rule-only, with the rule score carrying 100% of the weight until the ML layer is enabled.
• Optional AI-generated explanation — once a risk score and verdict are already determined, an LLM turns the top contributing features into a short, human-readable explanation (e.g. “scripted client detected on a blocklisted IP with rapid repeated requests and geo mismatch”). It never influences the score or verdict, and if the explanation service is slow or unavailable, the plugin still returns the risk score and verdict without it. The underlying LLM provider is swappable without affecting detection logic.

Scoring, Blending & Verdict

The rule score and the normalized (0–100) ML anomaly score are blended into a single final risk score using a configurable ratio (70% rule / 30% anomaly by default), which then maps to a verdict:

Both the blend ratio and verdict thresholds are configuration values — they can be tuned over time as real traffic patterns are observed, with no code change required.

Key Benefits

• Real-time protection with no added latency — runs directly on the bidding/serving path without slowing delivery
• Goes beyond static rules — the ML anomaly layer catches patterns a fixed rule set wouldn't anticipate
• Explains itself — every flagged request can come with a plain-English reason, not just a score
• Fully tunable — feature weights, the blend ratio, and verdict thresholds are all configuration values you can adjust as traffic evolves, with no code changes
• Fails safe — if Redis or the explanation layer has an issue, the plugin never ends up blocking legitimate traffic
• No new data collection — works entirely from fields already present in a standard traffic event
• Scales across your fleet — shared Redis state keeps velocity and duplicate detection accurate even with multiple instances running