Understand player identities
Every player in your game has an identity in Satori: a persistent behavioral profile that accumulates session history, in-game events, and computed properties over time. Targeting decisions, experiment assignments, live event eligibility, and message delivery all draw from this record.
What an identity contains #
A player identity is a structured profile with multiple data layers, each built from different sources and serving different parts of your operation.
| Component | What it stores | What it powers |
|---|---|---|
| Properties | Default, computed, and custom key-value attributes | Audience definitions, event eligibility, experiment enrollment |
| Events | Chronological record of in-game actions | Computed properties, behavioral analysis |
| Audiences | Current segment memberships | Targeting for live events, experiments, and messages |
| Experiments | Active variant assignments | Consistent experience delivery across sessions |
| Live events | Current and past event participation | Enrollment state, reward history |
| Messages | Sent and received message history | Engagement tracking |
For a full reference on property types and how to set custom properties from the client, see Understand player properties. For how audiences are built from those properties, see Understand audiences.
Browse and manage your player base #
The Audiences > All Players tab shows a searchable table of every identity in your project. Use it to find a specific player by identity ID and inspect their full profile, or to confirm that a player’s data is in the expected state before or after running a live event or experiment.
From the player list you can also delete an identity. Deletion is permanent. Use this to fulfill player data deletion requests under GDPR or similar privacy regulations: deleting the identity removes all associated events, properties, and history from Satori.
Inspect player activity per identity #
The identity detail view includes a tab for every part of Satori that touches that player. Use these tabs to debug targeting, validate that a specific player is receiving the expected configuration, or to confirm event and audience state before an event goes live.
Events tab shows the chronological history of actions recorded for this player. This is the live behavioral record Satori uses to compute properties and power audience filters. For a full reference on event types, data structure, and instrumentation requirements, see Understand events.
Audiences tab shows all segments this player currently belongs to. Audience membership recomputes every 10 minutes by default. You can also permanently or temporarily exclude an identity from a specific audience from this tab, regardless of what their properties evaluate to.
Experiments tab shows the variant currently assigned to this identity. Once a player is assigned to a variant in an experiment phase, that assignment is fixed for the duration of that phase. If their audience membership changes during the experiment (for example, they go from non-spender to spender), their variant assignment doesn’t change. This is intentional: stable variant assignment prevents contaminated results.
Feature flags, Live events, and Messages show the active configuration, current enrollment, and delivery history for this player.
Future-date testing #
Use future-date testing to simulate what Satori returns for an identity at a specific date in the future. If configured, all the new sessions will be bound to the specified point in time for their whole duration. This is the correct way to validate live event schedules, offer timing, and any other time-dependent configuration before it goes live.
To enable future-date testing:
- Open the identity in the console.
- Click the three-dot menu in the top right and select Set future-date testing (QA).
- Choose the target date.
- When you’re done, reset the identity from the same menu.
After setting a future date, the identity must re-authenticate (for example, by restarting the game client) before Satori responds with the simulated time. API calls made before reauthentication continue to use the real server time.
