How onboarding works

PlayGenus onboarding is hands-on. We don't hand you a generic SDK and a docs link and wish you luck — we build your tracking plan with you, generate an SDK shaped to your game, and help you get it in.

That's a deliberate choice. Analytics fails most often at the schema, long before anyone looks at a model: events that don't capture the moment that mattered, properties missing the one dimension you'd want to slice by, a funnel you can't reconstruct because nobody logged the step. Those mistakes are cheap to fix at the planning stage and expensive to fix once six months of data is sitting on top of them.

What you'll do, and what we'll do

Step 1 — The questionnaire

We start with a short questionnaire about your game: the genre, how progression works, your core loop, how you monetise, and what you're actually worried about.

The most important answer is your progression model, because it determines which events are worth tracking at all:

A level-based puzzle game and an open-world survival game fail in completely different ways, so "player is stuck" means different things and has to be measured differently. Getting this right early is most of the value.

Step 2 — Your tracking plan

From your answers we build a tracking plan: the precise list of events your game will send, each with its properties and types.

It's drawn from a catalogue of 47 standard game events — sessions, progression, economy, monetisation, and so on — filtered down to the ones your progression model actually calls for, plus custom events for the mechanics that are specific to your game. Every custom event comes with a reason attached, so you can see why we think it's worth logging.

You review it. This is the moment to push back: if we've missed a mechanic that matters, or proposed an event you'd never fire, say so. We'd rather revise the plan now than discover the gap in three months. The plan is versioned, so revisions are cheap and nothing is lost.

Once you're happy, we lock the plan and it becomes the contract your SDK is built against.

Step 3 — Your SDK

We generate an SDK from your approved plan and send it over as a ZIP: one generated source file, a README, and your API key already embedded.

Available now:

Unreal is on the roadmap, not shipped. If you're on another engine, you can send events straight to the REST endpoint (/v1/events) against the same schema — talk to us and we'll work out the right shape for your setup.

Because the SDK is generated from your plan, it's typed to your game. You get methods for your events, not a generic track(string, dict) you have to remember the conventions for.

Integrating it

Drop the file in and initialise it with your key:

PlayGenus.Init("pgn_live_...");

The client SDK handles sessions on its own, and attaches device model, OS, platform, locale, and connectivity to what it sends. You call the generated methods at the moments that matter in your game. Errors are reported explicitly when you want them:

PlayGenus.Error("warning", "checkout_failed", context);

Integration is genuinely small — usually under an hour of engineering time for a client SDK. The work is in choosing the right call sites, which is exactly what the tracking plan already settled.

There's a validation endpoint (/v1/events/validate) that checks a payload against your plan and returns per-event errors without storing anything. It's worth a dry run before you ship.

Step 4 — Data, then predictions

Once events arrive, descriptive dashboards populate immediately: retention, funnels, ARPDAU, session metrics.

Predictions take longer, and it's worth being precise about why. Churn models train on players whose outcome has actually settled — we need to know who genuinely left, which means waiting for players to be around 14 days old — and they need a meaningful number of such players to learn from. LTV needs roughly 30 days. Forecasting needs about 30 days of history to have a trend to project. Models retrain daily as data accumulates.

So for a brand-new game starting from an empty dataset, meaningful predictions are a matter of weeks, not days. Anyone who tells you otherwise is selling you something.

Unless you already have history. If your game is live and you have data in GameAnalytics, PlayFab, Firebase, Unity Analytics, or a CSV export, you can import it — and your models train on that history straight away rather than waiting for it to accrue. This is the single biggest lever on how fast PlayGenus becomes useful to you, and it's why we ask about it early.

Timeline, honestly

The parts that depend on us — the plan, the SDK — move at the speed of a conversation, usually days rather than weeks, because we're doing them with you rather than queueing them.

The part that depends on physics is data. Descriptive analytics land as soon as your events do. Predictions land when there's enough settled data to train on: immediately if you import history, a few weeks if you're starting fresh.

Next steps

Questions, or want to start? Email support@playgenus.com.