Skip to main content

Event Tracking

GameAnalytics features the following event types:

EventDescription
AdAds shown and clicked, fill rate.
BusinessIn-App Purchases supporting receipt validation on GA servers.
DesignSubmit custom event id’s. Useful for tracking metrics specifically needed for your game.
ErrorSubmit exception stack traces or custom error messages.
HealthAutomatically submits health metrics related to your game such as FPS.
ImpressionImpression data from different ad networks
ProgressionLevel attempts with Start, Fail & Complete event.
ResourceManaging the flow of virtual currencies - like gems or lives
tip

Read more about events here

danger

Event id’s are strings separated by colons defining an event hierarchy – like "kill:robot:large". It is important to not generate an excessive amount of unique nodes possible in the event hierarchy tree.

A bad implementation example: level_name]:[weapon_used]:[damage_done]

level_name could be 100 values, weapon_used could be 300 values and damage_done could be 1-5000 perhaps. This will generate an event hierarchy with:

100 * 300 * 5000 = 150M possible nodes.

This is far too many. Also the damage should be put as a value and not in the event string. The processing will perhaps be blocked for a game doing this and cause other problems when browsing our tool.

The maximum amount of unique nodes generated should be around 10k.

Business Events

FieldTypeDescriptionExample
currencystringCurrency code in ISO 4217 formatUSD
amountintegerAmount in cents99 is $0.99
itemTypestringThe type/category of the itemGoldPacks
itemIdstringSpecific item bought1000GoldPack
cartTypestringThe game location of the purchase. Max 10 unique valuesEndOfLevel
receiptstringINAPP_PURCHASE_DATA. Null allowed. Read more about Android receipt here
signaturebase64 stringINAPP_DATA_SIGNATURE. Null allowed. Read more about Android signature here.
tip

For more information on Business Events go here.

Resource Events

Resource events are used to register the flow of your in-game economy (virtual currencies) – the sink (subtract) and the source (add) for each virtual currency.

Before calling the resource event it is needed to specify what discrete values can be used for currencies and item types in the Configuration phase.

FieldTypeDescriptionExample
flowTypeenumA defined enum for sourcing and sinking resources.GAResourceFlowType.SOURCE
currencystringThe resource type/currency to track. Has to be one of the configured available resource currencies. This string can only contain [A-Za-z] characters.Gems, BeamBoosters, Coins
amountfloatAmount sourced or sinked. 0 or negative numbers are not allowed.100.0
itemTypestringFor sink events it can describe an item category you are buying (Weapons) or a place (Gameplay) the currency was consumed. For source events it can describe how the currency was gained. For example “IAP” (for in-app purchase) or from using another currency (Gems). Has to be one of the configured available itemTypes.Weapons, IAP, Gameplay, Boosters
itemIdstringFor sink events it can describe the specific item (SwordOfFire) gained. If consumed during Gameplay you can simply use “Consumed”. For source events it describes how the player got the added currency. This could be buying a pack (BoosterPack5) or earned through Gameplay when completing a level (LevelEnd).BoosterPack5, SwordOfFire, LevelEnd, Coins400
caution

Be carefull to not call the resource event too often !

In a game where the user collect coins fairly fast you should not call a Source event on each pickup. Instead you should count the coins and send a single Source event when the user either complete or fail the level.

For more information on Resource Events here.

Progression Events

Progression events are used to track attempts at completing some part of a game (level, area). A defined area follow a 3 tier hierarchy structure (could be world:stage:level) to indicate what part of the game the player is trying to complete.

When a player is starting a progression attempt a start event should be added. When the player then finishes the attempt a fail or complete event should be added along with a score if needed.

Add a progression start event.

It is not required to use all 3 if your game does not have them.

  • progression01
  • progression01 and progression02
  • progression01 and progression02 and progression03
FieldTypeDescriptionExample
progressionStatusenumStatus of added progressionStart
Fail
Complete
progression01stringRequired progression location.World01
progression02stringNot required. Use if needed.Stage01
progression03stringNot required. Use if needed.Level01
scoreintegerAn optional score when a user completesor fails a progression attempt. Remember to set progression02 and/or progression03 if they are not used when using score parameter.1023
tip

For more information on Progression Events go here.

Error Events

Used to track custom error events in the game. You can group the events by severity level and attach a message.

FieldTypeDescriptionExample
severityenumSeverity of errorDebug
Info
Warning
Error
Critical
messagestringError message (can be null)“Error when entering level12”
tip

For more information on Error Events go here.

Design

Every game is special. Therefore some needed events might not be covered by our other event types. The design event is available for you to add your own event-id hierarchy.

info

Please note that custom dimensions and progression filters will not be added on design and error events. Therefore you cannot (at the moment) filter by these when viewing design or error metrics.

FieldTypeDescriptionExample
eventIdstringThe eventId is a hierarchy string that can consist of 1-5 segments separated by ‘:’. Each segment can have a max length of 32.“StartGame:ClassLevel1_5”, “StartGame:ClassLevel6_10
valuefloatA float event tied to the eventId. Will result in sum & mean values being available.34.5
danger

It is important to not generate an excessive amount of unique nodes possible in the event hierarchy tree.

A bad implementation example. [level_name]:[weapon_used]:[damage_done]

level_name could be 100 values, weapon_used could be 300 values and damage_done could be 1-5000 perhaps. This will generate an event hierarchy with:

100 * 300 * 5000 = 1.5M possible nodes.

This is far too many. Also the damage should be put as a value and not in the event string. The processing will perhaps be blocked for a game doing this and cause other problems when browsing our tool.

The maximum amount of unique nodes generated should be around 10k.

tip

For more information on Design Events go here.