Multiple player identities using aliases
Sometimes you want to give players the option to login with different services like Steam or Epic. Talo lets your players have multiple aliases, all tied back to a central player.
This means that regardless of what service they use to sign in, all of their progress, saves and leaderboard entries will be available to them. Aliases also bring the additional benefit of being able to segment players and leaderboards by platform (e.g. Steam leaderboards vs. Epic leaderboards).
From the Talo dashboard, you can view any player's profile and inspect all of their aliases. Currently, Talo supports 5 types of identities: Steam, Epic, Username, Email or Custom.
Talo even provides identity merging for when you've discovered two players that are actually only one - e.g. if a player wants to link their Username to their Steam account.
Persistence with props
Players can have any number of arbitrary properties that will persist between game sessions and all of their identities. You can use these, for example, to store a player's current health or level.
You can add, remove or update properties directly from the Talo dashboard. For example, you could tag all players that you want to be part of a closed beta test with a "hasBetaAvailable" property. When the beta is over, you can then remove this property. This behaviour pairs well with player groups to automatically unlock content without needing a new update.
Debugging with meta props
Events send through metadata about the player such as their operating system and version of the game they're running. This allows you to easily debug common problems based on players' configurations.
Meta props are also used to clearly identify players that were created as part of internal builds, i.e. test players owned by developers. See the docs to learn more about how Talo separates development data. These players can be hidden from the dashboard and omitted from data exports easily using the "dev data toggle" on the dashboard.
Create distinct segments
Using groups, you can divide your player-base into clear segments. For example, you can have a group of beta testers or all the players who have completed the game.
Groups can have incredibly complex filters. You can combine requirements with 'AND' and 'OR' conditions, filter by values such as when the player last logged in or filter by player props allowing ultimate flexibility.
Once you've created your group, it will automatically continue to add players who are eligible and remove players who are not. In-game you can check what groups players are part of and run the relevant logic where needed.