Choosing your SDK
Client SDK, Server SDK, or plain REST — which PlayGenus integration fits your game's architecture, and why revenue events should always come from your server.
The rule of thumb: the client tells you about the device and what the player experienced; the server tells you what actually happened. Most games with a backend end up using both. Games without a backend use the client SDK alone, and that's fine too.
Client SDK
Runs in your game build, on the player's device. Today that means Unity (C#); other engines can hit the REST API directly with the same schema. The client SDK captures:
- Session lifecycle — app open, close, background (automatic)
- Device information — model, OS, screen size, locale (automatic)
- Unhandled exceptions, as
app_crashevents (automatic) - UI interactions — screen views, button taps (you call these)
- Ad events — impressions, clicks, rewards (you call these from your ad SDK's callbacks)
- Performance samples — FPS, memory (you sample and send these yourself)
Sessions, device info, and crashes are collected automatically — you only write code for the things the SDK can't know about, like which screen counts as "the shop".
Delivery is handled for you: events batch locally and send in the background, and if the player goes offline, they queue and send when connectivity returns. You never touch networking. Event delivery has the full story.
| Setting | Default | What it means |
|---|---|---|
| Flush interval | 30 seconds | How often batched events are sent |
| Flush batch size | 50 events | Send early when this many events are queued |
| Max queue size | 10,000 events | Local cap before the oldest events are dropped |
| Persist queue | On | Queued events survive an app crash (stored to disk) |
Server SDK
Runs in your game backend — Java or Node.js / TypeScript today, and anything else can use the REST API. The server SDK handles authoritative game state:
- Purchases, with receipt validation
- Progression — level start, complete, fail
- Economy — currency earned and spent, items
- Player lifecycle — registration, login, level-up
- Matchmaking and match results
- Social features — guilds, friends, gifts
- LiveOps events and moderation actions
Why send these from the server? Because your server is the source of truth. A player can't fake a purchase, spoof a level completion, or edit their currency balance if the event comes from your backend after the action is verified. Revenue data especially should always be server-side.
| Setting | Default | What it means |
|---|---|---|
| Flush interval | 5 seconds | Servers have stable connectivity, so we deliver faster |
| Flush batch size | 50 events | Send early when this many events are queued |
| Retry | 3 attempts | Exponential backoff (1s, 2s, 4s) on 5xx or network errors |
| 4xx errors | Not retried | Bad requests and auth errors are logged and dropped |
Call shutdown() when your server stops — it flushes whatever's still queued.
Recommended, not enforced
Every event has a recommended source, but PlayGenus doesn't reject events based on which side sent them. If your architecture wants it differently, send it differently:
- MMOs often send
session_startfrom the server — the moment the player connects to the game server — rather than the client. - Server-gated tutorials send
tutorial_stepfrom the server. - Offline games with no backend send progression and economy events from the client, because there's nowhere else to send them from.
If the same event arrives from both sides, we deduplicate automatically and keep the server version.
Quick start
Send your first PlayGenus event from Unity, a Java or Node.js server, or the REST API. Integration is a single generated file — most studios are live in under an hour.
Progression models
PlayGenus tags every game with one of four progression models — discrete levels, match-based, soft progression, or open world — and that tag decides which analytics events your game should track.