Skip to main content

​
Session

A session starts automatically during SusaPlaySDK.Initialize(), which queues a session_start event. There is nothing to call and no session id to track. There is no session-end event. OnApplicationQuit does not fire reliably in a browser, so session length is derived from event timestamps on the server rather than reported by the game.

​
Custom events

LogEvent is synchronous and queues in memory — safe to call from gameplay code.

​
Flushing

Queued events are sent in batches. With the default configuration the SDK flushes on initialization, every five minutes, when the game is paused, and on quit. Only signed-in players’ events are stored; a guest’s are refused. Force a send at a moment that matters — for example right after a tutorial completes:
In a WebGL build, Flush() returns once the events are handed to the page, not once they are stored. The server refuses a batch of more than 500 events whole, so flush before the queue grows that large. Flush intervals and lifecycle triggers are configurable on the PlatformConfig asset. The minimum interval is 10 seconds. Events are batched and flushed automatically. Fire-and-forget — don’t await in hot paths.

​
Standard events

One event is emitted automatically. Everything else is up to your game. Games built against an SDK older than 1.3.0 emit no events unless the game calls LogEvent itself. Rebuild against 1.3.0 or later to appear in DAU, MAU, and retention. There is no automatic session_end. OnApplicationQuit is not reliable in a browser, so an end-of-session signal cannot be produced from Unity. Purchase revenue is recorded server-side from the payment webhook, not by the SDK. You do not need to log a purchase event yourself. SusaPlay asks every game to send these events where the game has the moment they describe. They cover what only your game knows — sessions, purchases, achievements, saves and level_up are already recorded by the platform, so do not log them again.
Use exactly these names and parameter names, so the same reports work for every game, and add any other events your game needs alongside them. levelId is a stable id your game already uses, not a display name. Skip an event your game has no moment for.
These events reach the raw event export today. They are not yet charted in the Developer Portal.

​
Viewing data

Analytics are available in:
  • Developer Portal → your game → Analytics (session DAU, revenue, retention)
  • Raw event export — for running your own queries (contact SusaPlay to enable)

​
Event naming

  • Use snake_case: level_start, not LevelStart. Keep names short and stable — a renamed event starts a new series.
  • Never put personal data (email, name, phone) in names or parameters.
  • An event without a name is dropped.
  • level_up is reserved: it reports the player’s level and needs a non-negative integer level parameter, such as "{\"level\":7}". Without one the event is dropped and the rest of the batch is kept.