The event is the basic structure that drives the analytics in deltaDNA.
Events represent actions in the game, they provide a snap shot of the players state at that point and give a point in history that can then be used to build up a behaviour of the player. Events are sent to deltaDNA as small JSON documents that describe a player action and state at a particular point in your game.
Getting the event list right is vital, everything else is based on having robust events that provide the right level of detail.
Unlike other analytics providers deltaDNA takes a slightly different approach to events and event management.
The key steps in building an event list are:
- Play/Analyse the Game
- Build the Event List
- Sign off the Event List
- QA the Event List
Complex events
deltaDNA supports complex events that aim to encompass as much information about the action as possible within a single structure. This means an achievement event will provide information on the achievement itself and the rewards the player receives for that achievement. Each event can consist of as many parameters as the game feels is useful to send to fully describe that action.
This is useful because all this information is held together, making future analysis much easier as you are able to easily look at the results of that action.
This doesn’t stop you from creating much simpler events and you can create an event structure that is predominately based on key/value simple events but this is not using the full power of the deltaDNA system.
Pre-defined events
There are 50 pre-configured events that should cover 80% of all the use cases in games. We automatically instrument a subset of these events with every game added so you can start to send data straight away. The other pre-defined events are there to make it as easy as possible to quickly build up an events list for your game. Each pre-defined event can be customized with game specific parameters and you can always create your own custom events.
When is an event significant?
The aim is to collect significant events. Events are defined points in the game that something happens, they should represent a point in time in which a player has initiated an action.
Events are not game initiated actions, they should always be initiated by the player. The definition of significant is harder to define, it should be an action that has a substantive change to the gameplay that would invoke a reaction from the player. Shooting your gun is not a significant event, but killing someone would be.
Defining significant can only be taken in the context of the game, so shooting may be defined as significant in a sniper game where the player only takes a very small number of shots and each shot has a large impact to the player by using up a very limited ammo supply.
Event validation
Every event that is sent to deltaDNA is validated against the event list before it is allowed into the data warehouse. Each event has a set of criteria that has been defined, you can make the validation as strict as you like by adding in extra levels of enumeration.
The advantage of this approach is it stops bad data getting in to the data warehouse and impacting analysis down the line. The biggest issue with doing good analysis that drives decisions is poor or incomplete data and having the data validated means that the data warehouse is as clean and complete as possible.
Environments
When a new game is created, it is always created with two environments (DEV & LIVE). Each environment acts independently, with a full set of dashboards and the data is kept completely separate between the environments. This allows games to be developed and tested against the DEV environment and then released using the LIVE environment. Changes to the events for subsequent versions can be continued to be tested against DEV without impacting the LIVE environment and creating erroneous data.
Events can only be created and edited on the DEV environment and then must be published to the LIVE environment. Once an event has been pushed to LIVE it can never be deleted on LIVE. Events can be published individually or multiple events can be published simultaneously.
Sending events
Events can be sent from either the Client or the Server. Most Facebook and Web games are what are known as “Thin Client” games. This means that the majority of the game logic is on the server with only a small amount of code on the client which runs the visuals. The deltaDNA REST API should be used for sending events from thin client games.
The alternative is known as a “Thick Client” game. These are games where the majority of the processing is done on the client with a very small server to manage player interactions and the virtual store. All mobile games are built like this because they cannot rely on a constant server connection and therefore need to keep the processing on the client. The deltaDNA SDKs should be used on mobile devices where possible as they manage local event caching to mitigate intermittent network connectivity. However, the REST API can also be used on thick client games, but you would need to manage local event caching within your implementation code. The deltaDNA SDKs are light wrappers that use the REST API to send event data.
Server events
If the events come from the server, we will get them from a single consistent location. There is much less likelihood of losing events. The events will be sent as soon as they are triggered, there should not be any delay on the events.
The events are timestamped at the deltaDNA server so will all have a consistent time which will not be related to the time at the client. This needs to be taken into consideration in the analysis as the time will be stamped with UTC no matter where the player is playing the game.
The geo-location option in your game details page should disabled if you are sending events from a server as it would incorrectly set the players location to the location of your server.
Some events are not part of the game play data and therefore do not belong in a session. Typically these will be server events that are triggered due to something other than the player playing the game. Therefore it would be inconvenient if sending an event would make it seem like the player was playing at this point in time. If you want to send such an event then you can omit the session ID and the eventTimestamp, we will then stitch the event back into the end of the last session for that player. This can be useful for attribution data or enriching old users with newly acquired data, for example.
Batched server events
This is when the server holds on to events and send them in bursts on a regular basis. The events are time stamped at the server but it means we get a delay before we see the events which can range from minutes to hours.
Client events
All mobile games and an increasing number of PC games are sending the events from the client. Events sent from a client will be sent from a huge number of devices, this adds an increased chance that events will be lost.
As clients lack information about the other players, some information is harder to calculate. Anything that needs information about more than the current player will be very hard, invites and installs on a Facebook game are more complex if the data is being sent from the client rather than the server.
There is also a much higher likelihood that the data can be hacked, although the user will only see the data being sent from their client it does make denial of service attacks on deltaDNA servers an increased concern.
Hybrid client/server events
Some games use a hybrid model where some events come from the server and some from the client. This is generally because the client simply does not have the information required or the information on the client cannot necessarily be trusted. This typically happens when transaction events may be sent from a server or when user registration is sent from the web server but gameplay events from the client.
Take care with your userID, sessionID and timestamp usage in these cases and disable automated geo-location to prevent the server location overwriting the player’s location.
Mobile client events
The most complex type of events are those sent from a Mobile Client. This is because not only are these devices ‘thick’ they are also not always connected. The games often do not rely on connectivity and players can happily play games offline.
The data is still collected using the deltaDNA SDK and stored locally on the device. At frequent points the game will try to upload the data to the deltaDNA server. If this is not possible either due to no connectivity or a problem with the deltaDNA server the data will be held on the client.
This means that data will often appear late, this can be anything from a couple of minutes to weeks late. Because the data is being stored locally, each event has to be time stamped by the device. This means that the data collected has a local timestamp and not the server timestamp as with every other device.
This also means that we are dependent on devices having the correct time, what we find is a small number of devices have their time in the past or in the future. As we can get events from the past due to the device not being connected and with time zones we can also get future time stamps we do make a cut off.
Any events that are either more than a month old or two days in the future are rejected by the collect server.
