Most Analytics tools have some basic start-up data including an anonymised PlayerID, StartTime, perhaps even DeviceID.
Some platforms like Unity Analytics have a whole set of standard events intended to streamline the setup of standard elements from onboarding, monetisation, progression, etc.
Always check the basic implementations for your platform of choice. This can really save a lot of time and will usually improve the results you get from that service.
Even if you are using a fully featured platform it is likely you will still want to create a series of ‘custom events’ which allow you to try to answer questions very specific to your game design.
The event are specific triggers we can use need to give some deeper insight to the behaviour of that player whether that is a specific path taken, a shot, a trap triggered, a line of candies swiped.
It’s essential to define these trigger points in a way which allows us to make useful comparisons rather than duplicate any existing standard events. Generally, this means defining the event as a moment in the flow of play, rather than being too worried about the details that will be captured at that point as data.
So rather than creating a trigger event called ‘EndLevelOne’, we look at ‘EndLevel’ and make which level the player has completed a data point instead. So if we are looking for the players' progress we should look at the events like ‘StartSession’, ‘StartLevel’ and ‘EndLevel’ if your game has that kind of progression.
If the game has a series of objectives you may have ‘ObjectiveComplete’ with a list of events as data. If you are using an experience points-based system you may want something like ‘XPAwarded’ with a score.
As a quick aside its worth checking if your analytics platform supports standard terminology for the events you need to support. If you can leverage common terms for these triggers with other games it will make it much easier to gain deep intelligence about how your game performs.
At the end of the day events allow us to capture a meaningful moment in time; a snapshot into the players progress in the game and usually specific functions in the code of the game.
We use them to paint a picture of the player experience in your game. The following show a set of some common events that can help you get started thinking about what your game needs (n.b. these are generic examples only):