Deciding offers on the player's device or on the server

Something has to decide which offer a player sees. That decision can be made in the game running on the player's device, or on a server the game asks. The choice is usually made early, for reasons of convenience, and it constrains a great deal afterward.

What device-side decisions give you

Speed is the obvious one. A decision made locally has no round trip, so there is no delay and no failure case where the network is slow and the player is left waiting.

Availability is the second. A game that decides locally still works offline, which matters for a large share of mobile play — commutes, poor coverage, aeroplane mode. Games where the store is empty without a connection lose those sessions entirely.

The third is cost. No request means no infrastructure, which is genuinely relevant at scale.

The constraints are equally clear. A device-side decision can only use what the device knows, which is this player's local state. It cannot know what has worked for similar players, cannot use anything computed in batch, and cannot be changed without shipping an update to the game.

That last point is the significant one. If the logic lives in the built game, changing it means a release and a wait for players to update — during which some fraction of your players are running the old logic indefinitely.

What server-side decisions give you

The decision can use everything. What this player did, what comparable players did, what the current inventory of offers is, what the results of the last week were. None of that is available locally.

It can change immediately. Adjusting the logic is a server change, and every player gets it on their next request regardless of which version of the game they are running. For anything that needs to respond to how the game is performing, this is close to essential.

And it can be audited. A server-side decision leaves a record of what was decided and why, which matters when someone asks why a particular player saw a particular thing — a question that arrives from support, from a regulator, or from your own team investigating a complaint.

The costs are the round trip, the dependency on connectivity, and the infrastructure.

The split that most games end up with

The practical answer for most games is neither purely, and the split follows a consistent line.

The server decides what is available and why — the strategy, the eligibility, the selection from the catalog. This is where the logic that needs to change frequently and use broad information lives.

The device decides when — the moment to show something, based on what the player is doing right now. That decision is time-sensitive in a way a round trip cannot serve well, and it depends only on local state.

The practical shape is that the server supplies a small set of things this player may see, with the conditions under which each is appropriate, and the device picks the moment. The set gets refreshed periodically rather than requested per decision, which handles offline and removes the latency without giving up the ability to change strategy centrally.

See how we split offer decisions across the boundary →

The part that must be on the server regardless

A small set of decisions should never be made on the device, independent of the architecture.

Anything with a compliance consequence — age-based restrictions, market-based restrictions, spending limits. These need to be enforced somewhere a player cannot influence, and anything running on the device is influenceable by a determined person.

Anything with a money consequence — the actual price, whether a purchase is valid, what a player is entitled to after buying. Validating purchases server-side is standard practice for exactly this reason and the same logic applies to what things cost.

Anything that has to be provably consistent — if you need to be able to say what a player was shown and under what rule, that record has to exist somewhere you control.

The general principle for the split is that the device handles what is fast and local and harmless if manipulated; the server handles what is strategic, informed, or consequential. Getting that line in the wrong place is expensive to move later, because it is embedded in shipped clients that players may never update.

One more consideration favours keeping the strategy server-side regardless of the rest: it is where you can see what happened. A device-side decision leaves no record unless the device reports one, and devices report unreliably — offline sessions, dropped events, players who close the game. A server-side selection is recorded by construction. That difference matters less for a single decision and a great deal for understanding aggregate behaviour, because the missing records from device-side decisions are not random. They are concentrated among players with poor connectivity, which is exactly the group whose behaviour you would want to understand.

Talk to us about offer architecture →