vrih

Those numbers aren't too far off. That's making a decision on every auction at 1M QPS, which is most of what is worth listening to in RTB globally. Most of those decisions won't actually involve much ML though, it'll be straight targeting rules matching and checking whether there is any budget.

The actual attribution shouldn't be on 80B though. It's pointless analysing requests you didn't buy. There might be some value in using that data in ML to feed into a pricing algorithm, but it would be marginal and I doubt cost/benefit would ever stack up. it would technically be in breach of pretty much every SSP contract I've seen (although everyone does it).

This article is actually a bit of an advert for when not to do batch processing. Processing 30 X 80B events every day when the same result can be achieved by maintaining state on about 30B users (more than enough for acceptable global coverage) and stream the data through to update that state. If all you were doing is the attribution part you would be looking a near an order of magnitude saving on their current costs and deliver results in real time.

The ML side may well benefit from batch but I bet splitting out the attribution component would allow them to be more flexible and cost efficient in their approach there.

There are lots of suggestions here of how it's done but it's essentially really really simple.

There are 2 pieces of information that need to be joined.Google have your cookie and email and MasterCard have your address and probably email. If both sides have your email then job done. If not then they can use your physical address via a data broker. All it needs is some e-commerce sites that allow cookie syncing and have a privacy policy that allow them to sell that part of your data.