Jul 7, 2026 · 4 min read · GameMantra Team

Infrastructure costs scale with DAU, not with revenue

Backend costs track active players, not paying players. A DAU spike from a free UA campaign can quietly erode margin before revenue ever moves

A studio runs a successful UA push, DAU jumps, the team celebrates, and two months later someone in finance is asking why infrastructure spend went up faster than revenue did. The answer is usually simple and usually overlooked: your backend costs track how many players are active, not how many of them pay. A DAU spike is a cost event before it's ever confirmed as a revenue event.

Revenue and cost don't scale on the same axis

Revenue in a free-to-play game is driven by a small share of active players — the paying minority carries almost all of the top line, and that concentration is well understood across the industry. Infrastructure cost doesn't follow that same concentration. Every active player, paying or not, triggers session starts, generates telemetry events, pulls player state, and in most architectures makes at least an offer-evaluation call whether or not they ever see an offer worth taking.

This means a UA campaign that drives a large volume of low-intent installs — the kind that generate DAU without ever converting to a paying player — is adding cost on the same curve as a campaign driving high-intent installs, while adding almost nothing on the revenue curve. Two campaigns with identical DAU impact can have wildly different margin impact, and a dashboard that only reports DAU and revenue side by side won't surface that difference on its own.

Where the cost actually accumulates

The specific cost drivers are worth naming because they're easy to reason about once you see the list: event ingestion scales linearly with active sessions, since every session generates a stream of gameplay and economy events regardless of whether the player spends. Offer computation, if it runs synchronously per session, scales the same way — a personalization or targeting pipeline evaluating every active player costs the same whether that player converts or not. Player feature stores and caching layers scale with the size of your active player base, not your paying base. And player support load, while not strictly infrastructure, follows active players too and often gets missed in a pure-compute cost conversation.

None of these costs are wrong to incur — they're the mechanism by which you find the players worth monetizing in the first place. The point isn't that active-player cost is avoidable. It's that it needs to be modeled explicitly against the value of the traffic driving it, rather than assumed to be a rounding error next to revenue.

Why this matters more as UA gets more expensive

As acquisition costs have risen, studios have gotten more disciplined about measuring payback windows on the revenue side — how long it takes a cohort's spend to recover its acquisition cost. The same discipline rarely gets applied to the infrastructure side of that same cohort. A cohort with a good payback window on pure UA-spend-versus-revenue can still be a net drag on the business if the infrastructure cost of serving that cohort's DAU isn't factored into the same calculation.

This is particularly relevant for campaigns optimized purely for install volume or DAU targets rather than for downstream value — the kind of campaign that looks efficient on a cost-per-install basis while quietly generating a disproportionate share of low-value active sessions that cost real infrastructure spend to serve.

Building the cost side into the same model

The fix isn't complicated, but it requires treating infrastructure cost as a per-cohort metric the same way revenue already is. If your analytics stack can already segment revenue and retention by acquisition cohort, the same segmentation applied to session volume and event volume gives you a reasonable proxy for infrastructure cost per cohort, even without a full activity-based costing exercise.

Once that number exists, UA channel evaluation stops being a pure cost-per-install-versus-revenue conversation and becomes a genuine margin conversation — which is closer to what the business actually needs to know before scaling a channel. A channel that looks cheap on install cost and generates a lot of low-converting DAU may be more expensive, once infrastructure is priced in, than a channel with a higher install cost and a leaner, higher-intent player base.

See how gamemantra's architecture separates real-time offer serving from batch analytics to keep per-session compute costs predictable as DAU scales, or talk to us about what this looks like for your current player volume.

Share this post

See what this looks like for your game.

SDK for Unity and Unreal. A 20-minute call to walk you through it.

Book a demo