TrueAudience: Real-Time Ad Fraud Detection at Millions of Events per Day
A high-throughput fraud scoring engine that fuses behavioral analysis, device fingerprinting, and multi-database IP intelligence into a single real-time score—before ad budget is spent on bots.
The Problem
Ad networks lose millions to bot fraud, and the loss happens in real time: every fraudulent click spends budget the instant it lands. The existing detection options forced a bad trade—solutions accurate enough to matter added latency that degraded ad serving, while solutions fast enough to sit inline could not process the event volume or the breadth of signals needed to catch sophisticated bots.
Catching modern fraud requires fusing many weak signals—behavioral patterns, device fingerprints, IP reputation across multiple databases, geographic anomalies—and doing it at millions of events per day with response times that do not disturb the serving path. That combination of breadth and speed is what no off-the-shelf option delivered.
What We Built
We built a real-time fraud scoring engine in Go, architected for high-volume daily event ingestion with low API latency as the explicit capacity target. The scoring path fuses behavioral analysis, device fingerprinting, and IP intelligence from five-plus fraud databases—Scamalytics, AbuseIPDB, MaxMind GeoIP2 among them—queried concurrently with goroutines so external lookups happen in parallel rather than in sequence.
The data layer is built for sustained throughput: MySQL sharded across eight databases with read replicas, a Redis caching layer for hot lookups, and file-based buffering that decouples API writes from the database so traffic spikes are absorbed instead of dropped. In production the platform runs as a fleet of 61+ specialized services for collection, intelligence, analysis, and reporting, managed under systemd with cron-driven batch processing and automated email alerting.
Real-time multi-signal scoring
Behavioral analysis, device fingerprints, and IP reputation from 5+ intelligence sources merge into a single fraud score, computed with parallel external queries to keep latency low.
High-throughput ingestion architecture
File-based buffering between the API and the database absorbs traffic spikes, sustaining millions of events per day without dropping writes.
Sharded, cached data layer
MySQL sharding across 8 databases with read replicas and a Redis hot-lookup cache keeps queries fast at ad-tech volumes.
Production service fleet
61+ specialized services handle collection, intelligence enrichment, analysis, and reporting, running under systemd with automated batch processing and alerting.
How It Works in Practice
An ad network routing live traffic through the scoring API while a botnet ramps up click activity on a campaign.
- 1
Ingest the event
Each click event hits the API and lands in the file-based buffer, keeping the ingest path fast regardless of database load.
- 2
Fuse the signals
Goroutines query the IP intelligence sources in parallel while behavioral and device-fingerprint checks run, assembling the full signal set in one pass.
- 3
Score in real time
The fused fraud score returns within the latency budget, and the network filters the botnet traffic before further budget is spent on it.
- 4
Report and alert
Batch services aggregate the incident into reporting, and automated alerts notify the operations team of the anomalous traffic pattern.
Screenshots
Engineering Approach
Latency as a design constraint, not a metric
The scoring path was architected backward from a low-latency budget—parallel lookups, hot caches, buffered writes—because inline fraud detection is only useful if it never becomes the bottleneck.
Many weak signals over one strong one
No single database catches sophisticated bots; fusing behavioral, device, and multi-source IP intelligence makes the score robust to any one signal being evaded.
Boring, resilient operations
Systemd-managed services, cron batch processing, and email alerting keep a 61-service fleet operable by a small team without a heavyweight orchestration platform.
Have a similar problem?
Tell us what you're working on and we'll tell you honestly whether we can help.
