A lot of company-data schemas have an arpu field: total revenue divided by monthly active users, stored as one number per company per period. It's a fine number to report. It's a bad number to model a business on, and Meta is the clearest example of why.
Meta's advertising business doesn't monetize "a user." It monetizes a user on a surface, at a data density, in a geography. A single global ARPU figure averages away exactly the three variables that explain the revenue. North American ARPU runs several multiples higher than Asia-Pacific ARPU on the same platform, not because the ads are different, but because advertiser willingness-to-pay per impression tracks disposable income and ad-market maturity, not usage. Collapse that into one column and you've thrown away the variable that actually explains the business model.
The practical schema fix is unglamorous: stop treating ARPU as a stored fact and start treating it as a derived view over (revenue, users, dimension) tuples, where dimension is at minimum geography and ideally product surface (feed ads vs. Reels vs. click-to-WhatsApp). If your table can't answer "ARPU for what surface, in what region" it can't actually explain how the money is made, only how much of it there was.
I ended up writing this up after digging into how Meta's business model actually breaks down by segment for a data project, worth a look if you want a concrete example of what the disaggregated numbers look like in practice.
Curious how others have modeled this. Do you store per-surface ARPU as a materialized column, or compute it at query time from raw revenue/user facts?
Top comments (0)