Unibo requires a complete list of players and games from your platform. This data represents the current state of your player base and game catalogue and is used internally by Unibo to enable campaign setup, targeting, and processing.
The Metadata integration ensures that Unibo has an up-to-date view of players and games as changes occur on the platform.
Unibo does not require or store any personally identifiable player information (PII), such as names, email addresses, phone numbers, or physical addresses.
Players are referenced exclusively by a platform-generated player ID, and never by personal identifiers such as name or email. Only a minimal set of technical and account-related attributes is required (e.g., player ID, currency, registration date, and status).
Additional non-personal player attributes may be shared at the platform’s discretion. Providing richer player metadata enables more advanced campaign configuration and segmentation, but is entirely optional and controlled by the platform.
Unibo supports two complementary methods for providing player and game data. The exact setup is aligned during integration.
Player and game data may be sent via the Event Stream as part of normal event reporting. This typically includes:
- An initial seed when Unibo is enabled, containing all existing players and games
- Incremental updates to reflect changes such as new players, new games, or updates to relevant attributes
Alternatively, or in addition, the platform may expose dedicated endpoints that allow Unibo to fetch player and game data.
This typically includes:
- Endpoints to fetch all players and games, used for initial synchronization and periodic reconciliation
- Endpoints to fetch players or games created or updated within a recent time window (e.g. last 5 minutes), allowing Unibo to poll regularly (e.g. every 10–60 seconds)
The fields below represent the minimum required core attributes used by Unibo.
Platforms may optionally provide additional non-personal player attributes beyond the core fields. The number, structure, and naming of such attributes are platform-defined and aligned during integration.
"ACTIVE", "BLOCKED", "FROZEN", or "INACTIVE"
ISO 3166-1 alpha-2 country code
Optional player display name or alias used for UI elements such as leaderboards
Platforms may optionally provide additional non-personal player attributes beyond the core fields above. These attributes are platform-defined and may represent concepts such as , , , , , or other custom classifications.
The structure, naming, and number of such attributes are fully controlled by the platform and agreed upon during integration.
Example: "4399" or "btg/bonanza"
Example: "Big Time Gaming"
Example: Fruits, Ancient Egypt, Halloween, Christmas
Example: Megaways, BonusBuy, Free Spins, Bonus Game, Sticky Wilds
Example: "desktop", "mobile", "all".
Example: yes, no . Used to filter games during free spin reward creation.
Platforms may optionally provide additional game attributes beyond the core and capability fields above.
These attributes are platform-defined and may represent concepts such as RTP, volatility, or other custom classifications.
Additional game attributes can be used for filtering and segmentation during campaign creation. The structure, naming, and number of such attributes are fully controlled by the platform and agreed upon during integration.
The data model above may be adjusted depending on platform structure and use case, and is finalized during the integration kickoff.