performance
Bidding on now, not on yesterday
The hot tier runs at memory speed, so pacing, bid multipliers, and placement decisions optimize against what's happening this second — not signal that's still hours from landing in a warehouse.
Real‑time bidding means resolving a bid decision and its downstream attribution against high‑cardinality event streams — every user, device, and campaign — inside the tens of milliseconds an auction actually allows, on signal that's current, not hours behind.
Most analytical platforms are built for BI: seconds‑to‑minutes of latency is fine when a human is reading a dashboard. Real‑time bidding doesn't get seconds — so ad‑tech companies bolt a low‑latency key‑value store onto their warehouse for the bidding hot path, and keep the warehouse for reporting and attribution on a separate, slower track. That split creates a reconciliation tax, but that's not the expensive part: attribution riding the batch path means pacing, bid multipliers, and placement decisions optimize against signal that's hours old, not what's happening right now — continuous wasted spend, every hour the loop is behind. The same lag delays fraud and invalid‑traffic detection, so fraudulent impressions get paid for in real time and caught, if at all, after the money's already gone.
The hot tier runs at memory speed, so pacing, bid multipliers, and placement decisions optimize against what's happening this second — not signal that's still hours from landing in a warehouse.
Invalid‑traffic and bot scoring run at the same speed as decisioning, against fresh history — not a batch job that flags the fraud after the impression's already been paid for.
Bidding and attribution can query the same continuously ingested data in Oliver, reducing the drift and reconciliation work created by separate hot‑path and reporting stores.
User, device, and campaign identifiers are exactly the high‑cardinality shape Oliver's columnar engine is tuned for — where general‑purpose platforms slow down most.