Case Study: Ad Click-Through Rate Prediction (Meta / Google Ads-style)
"Design the click prediction model for our ads system" is one of the most common ML system design prompts at Meta, Google, Amazon, Pinterest, Snap and every ad-tech company, because it is the model that pays everyone's salary. It is also a near-perfect interview problem: it forces you to reason about a business objective that is not a standard ML metric, about labels that arrive late and are wildly imbalanced, about features with billions of distinct values, and about serving a model billions of times a day inside a strict latency budget.
This subject is a model answer, structured with the 7-step framework from the ML System Design Framework subject: clarify requirements → translate the business goal into an ML objective → labels and data → features → model → offline and online evaluation → serving and monitoring. It applies the general theory of ranking, feature stores, serving and monitoring covered earlier in the track rather than re-teaching it. Where the ad problem differs from the organic feed (covered in the Case Study: Video Recommendation subject) — chiefly, that the score feeds an auction and must therefore be calibrated — it says so explicitly.
Read it as the answer you would give in 40 minutes, then use the follow-up questions at the end to pressure-test yourself.
Step 1 — Clarify Requirements and State Assumptions
Open by pinning down what "click prediction" means in this system, then state numeric assumptions out loud so the interviewer can correct them.
Questions to ask
- Which surface? Feed ads, search ads, or a display network? (Search ads have a query; feed ads rely on user history and the creative.)
- What is the model used for? Answer we expect: ranking candidates and pricing them in an auction. That single fact makes calibration a hard requirement.
- Are we predicting only clicks, or also downstream conversions (pCVR)? Assume both, click first.
- Latency budget for the whole ad request, and how much of it is ours?
- Do we own the candidate retrieval stage or only the final scoring? Assume retrieval exists and hands us 500–2,000 candidates.
Assumptions to state (Meta/Google scale)
| Quantity | Assumption |
|---|---|
| Daily active users | 1–2 B |
| Ad impressions per day | ~10–50 B (say 20 B) |
| Ad requests per second (peak) | ~500 k QPS, each scoring ~1,000 candidates → ~5 × 10⁸ candidate scores/s |
| Average CTR | ~1 % (feed), ~3–5 % (search) — so positives are rare |
| End-to-end ad request budget | ~100 ms p99, of which the pCTR model gets ~10 ms |
| Distinct users / ads / advertisers | 10⁹ / 10⁷ live ads / 10⁷ advertisers |
| Training data per day | 20 B rows × ~1 kB features ≈ 20 TB/day before downsampling |
| Freshness requirement | Model must react to new ads and shifting user interest within minutes to hours |
Saying "20 billion impressions a day at 1 % CTR gives 200 million clicks a day — plenty of positives in absolute terms, but a 100:1 imbalance" shows the interviewer you can turn scale into concrete engineering constraints.