Design an Ad Click-Through Tracking System

Problem statement

Design a system that collects ad impression and click events from browsers, mobile SDKs, and server-to-server postbacks, matches each click to the impression and campaign that caused it, attributes downstream conversions (click-through and view-through), and serves near-real-time dashboards for CPC, CTR, spend, and ROI. The system must survive duplicate pixels, retrying SDKs, bot traffic, late-arriving events, and regional outages without double counting money-relevant metrics.

This is not an analytics dashboard bolted onto a request log. Every click can invoice an advertiser. Every impression denominates CTR. A duplicate click that survives deduplication becomes wrong billing; a dropped impression becomes a wrong CTR that pauses a healthy campaign. The design therefore separates three correctness classes: billing-grade facts (clicks, conversions, spend) which must be durable, deduplicated, and reconcilable; operational metrics (impressions, CTR, pacing) which must be fast and approximately right with explicit freshness; and learning data (features, fraud scores, attribution models) which may be eventual and replayable.

Why the problem is distinctive

A generic event pipeline retries on failure. An ad pipeline must retry without double counting: the same click retransmitted by a flaky SDK three times must produce exactly one billable click, yet zero loss is acceptable for spend. That tension - at-least-once transport with exactly-once business semantics - is the spine of this design. Add multi-touch attribution with 30-day click and 1-day view lookback windows, and the join problem becomes temporal: a conversion today must find a click from 20 days ago and an impression from yesterday, across petabytes of history, in seconds.

Public scale evidence

Real ad platforms publish the order of magnitude. The Trade Desk states its AI analyzes up to 15 million ad opportunities each second. Criteo's invalid-traffic system receives 341 billion bid requests and 3.8 billion displays per day. Criteo also reported 30 billion HTTP requests and 20 terabytes of new data per day at a 37-petabyte raw footprint. LinkedIn's Apache Pinot serves 250,000+ queries per second across 50+ user-facing applications. Meta's Scuba was built precisely for sub-second interactive analysis over live ads data at roughly a million queries per day. Google's MillWheel paper describes exactly-once stream processing with watermarks that revenue-processing customers depend on, including a continuous anomaly detector for ad traffic. These are cited, company-reported figures; every uncited number in this answer is an explicit design assumption.

The four planes of the design

1. Ingestion plane: edge collectors, schema validation, authentication, dedup keys, and durable append to the event backbone.
2. Truth plane: the deduplicated, enriched, attributed event ledger and its OLAP projections.
3. Serving plane: rollups, caches, and query APIs that power advertiser dashboards and alerting.
4. Governance plane: consent, retention, privacy, fraud policy, schema evolution, and replay tooling.

A strong interview answer keeps these planes separate: ingestion may shed load, serving may show stale rollups, but the truth plane must never silently lose or double count a billable event.