Server side events: why studios are moving

Client-side event tracking sends a purchase or progression event from the player's device at the moment it happens, which sounds direct but depends on a chain of things going right on a device the studio does not control: the app staying open long enough to fire the event, the network connection holding, the SDK not being delayed by the operating system's battery or background-activity rules, and the device not running tracking-prevention software that drops the call before it leaves the phone. Every one of those points is a place an event can be lost, and on Android in particular, background restrictions introduced across recent OS versions have made client-side event loss a bigger practical problem than most dashboards make visible, since a dropped event simply does not appear rather than appearing as an error.

Server-side tracking moves the event's origin from the device to the studio's own backend. When a purchase completes, the game server, which already has to validate the receipt with Apple or Google to prevent fraud, sends the event to the MMP or ad platform directly, without depending on the client to also fire a duplicate signal. The same applies to progression events a studio wants to use as SKAdNetwork conversion value triggers or as inputs to a predicted lifetime value model: the server already knows a player reached a given level or spent a given amount, and sending that event from a system the studio controls removes an entire category of loss.

What server-side buys beyond completeness

Fraud resistance is the second reason studios have been moving this direction, alongside completeness. A client can be manipulated, an SDK spoofed, an event replayed by a device farm mimicking real play. A server-side event tied to a validated receipt or a server-authoritative progression state is materially harder to fake, because the fraud would have to compromise the backend rather than just the client, which is a different order of difficulty for most bad actors currently working the mobile ad ecosystem.

Meta and other platforms have pushed their own version of this pattern for years through conversions API style integrations built originally for web commerce, and the mobile game version follows the same logic: a direct, authenticated, server-to-server event feed that does not depend on a browser or an app SDK surviving the trip. Studios adopting the pattern typically route purchase validation, meaningful progression milestones and any event feeding a bidding algorithm through the server-side path, while leaving lower-stakes engagement events on the client where the completeness bar matters less.

The engineering cost is real and worth pricing honestly

None of this is free. Server-side event tracking requires backend engineering time that a purely client-side SDK integration does not: building and maintaining the server-to-platform connections, keeping event schemas in sync between client, server and each ad platform's expected format, and handling the platforms' own API changes on a backend team's release cycle rather than through an SDK update a mobile engineer can ship quickly. For a small studio without dedicated backend capacity, that cost can outweigh the benefit, particularly for a game with a simple monetisation model and low fraud exposure to begin with.

The practical trigger for most studios is scale rather than a fixed rule: once UA spend or purchase volume reaches a point where a percentage of lost or fraudulent client events represents real money, the backend investment pays for itself quickly, and the studios moving on this now are mostly the ones that have already run the numbers on what client-side loss and fraud were quietly costing them.

A migration that rarely happens all at once

Studios that go through this migration tend to do it event by event rather than as a single cutover, starting with the purchase event because it is the one already tied to a server-side receipt validation step and therefore the cheapest to extend. Progression events, used to feed a conversion value schema or a pLTV model, usually follow once the purchase pipeline is stable, since they carry lower individual stakes but higher volume, and a partial migration that covers purchases while leaving progression on the client still closes off the most costly failure mode even before the rest of the schema moves across.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• AppsFlyer, Adjust, Singular: a buyer's comparison
• Anatomy of an ad fraud incident, buyer side