Events

From Fuseboxx Wiki
Jump to: navigation, search

This page is under construction.


Fuseboxx In-Game Events

The FuseboxxTM Event system allows you to track user behavior within your app. This information can be analyzed to inform any changes you need to make to your app in order to increase its performance, making event tracking one of the most powerful tools available to game developers. By including the function calls from the Fuse API at specific locations in your game code, you are able to gather information that can be displayed and analyzed on the Fuseboxx dashboard. Every Fuseboxx event has three levels of detail. We start with the Event, which gains specificity from its Parameters, and records values from a selection of Variables at the time of collection.

Events

Events refer to the exact point in your code’s execution that information is gathered and relayed to our servers. They typically refer to something that occurs more than once during gameplay, but not the specific instance of that occurrence. Some examples include:

Event Name: ACHIEVED_LEVEL
For games where players have a level assigned to them, often starting at one and increasing based on how many experience points they gather. This event would be fired whenever a player increases their level. Exactly which level was achieved would be specified in the event’s parameters (see below.)
Event Name: IAP_COMPLETE
Its always a good idea to know at what point in gameplay your players are making purchases. Having an IAP event fire whenever a purchase is completed is an excellent way of pinpointing exactly where in your game players are most motivated to convert, or to analyze the effectiveness of your intended conversion points. Exactly which purchase was made would be specified in the event’s parameters (see below.)
Event Name: QUEST_COMPLETED
If your game requires that players complete specific, skill-challenging quests in order to advance, having an event fire every time one of those quests complete is a great way to track player progress. By using parameters to specify which quests are being completed, you can keep track of any quests that your players might be getting frustrated with, and not advancing past. Recognizing this and modifying your game appropriately can be an extremely powerful tool to increase player retention.

Parameters

If events are the names of frequent occurrences in your game, parameters refer to the exact instances of those occurrences. Parameters, unlike events, have values that communicate exactly which version of the associated event has fired. Having the right parameters paired with your events is important to precisely tracking player behaviour. Below are some examples of events paired with their appropriate parameters and their values.

NoteBubble.png

Parameter values are string variables, and can therefore contain letters or numbers. Parameters are counted and the total number of occurrences are displayed in the Fuseboxx dashboard. For this reason, parameter values should never be widely varied values like timestamps or scores.

Event Name: ACHIEVED_LEVEL
Parameter: PLAYER_LEVEL
Parameter Value: (0,1,2,3,4 etc…)

The parameter PLAYER_LEVEL specifies the ACHIEVED_LEVEL event by passing it the exact value of the level being achieved.

Event Name: IAP_COMPLETE
Parameter: IAP_NAME
Parameter Value: (Coin Pack 1, Gem Pack 1, etc…)

While the IAP_COMPLETE event fires whenever a transaction is completed, the value of the IAP_NAME parameter specifies exactly which IAP has been completed. This is extremely useful when analyzing the spending habits of your players.

Event Name: QUEST_COMPLETED
Parameter: QUEST_ID
Parameter Value: (0,1,2,3,4 etc…)

In this example, quests have been associated with identification numbers. This does not necessarily have to be the case. The event’s parameter could just as easily be a quest name, and the parameter value could be a string with the completed quest’s name. At a granular level, this information can be extremely useful in tracking player progress through critical interface sections, such as tutorials.

Variables

Every time an event fires, it can record any relevant information from the game at its time of collection. This can be extremely useful when tracking the play habits of your players in order to create the desired experiences within your game. You can record the values of more than one variable at the time of collection. Below are some examples of events, their associated parameters, and the variables being recorded.

Event Name:ACHIEVED_LEVEL
Parameter:PLAYER_LEVEL
Parameter Value:(0,1,2,3,4 etc…)
Variable:GEM_BALANCE
VariableValue:(0,1,2,3,4 etc…)
Variable:COINS_SPENT_THIS_LEVEL
Variable Value:(0,1,2,3,4 etc…)

The GEM_BALANCE variable would record the exact value of the player’s gem balance at the time of achieving a new level. This could be used to evaluate the effectiveness of intended currency pinches in your game flow. Alternatively, your game code could be written to collect the value of a variable that records how many coins a player is spending from level to level, and pass it to the COINS_SPENT_THIS_LEVEL variable.


Event Name: IAP_COMPLETE
Parameter:IAP_NAME
Parameter Value:(Coin Pack 1, Gem Pack 1, etc…)
Variable:PLAYER_LEVEL
VariableValue:(0,1,2,3,4 etc…)
Variable:GEM_BALANCE
Variable Value:(0,1,2,3,4 etc…)

By recording the average player level and gem balances of your users at the time of purchase,
you’re able to see which of your currencies, when depleted, are most effective at driving monetization.
This can be useful when planning further monetization strategies.


NoteBubble.png

Variable values cannot be strings. The values collected from variables are summed and averaged before being displayed in Fuseboxx.

Unique Event Cap

It is important to note that Fuseboxx imposes a limit of 5000 unique database entries per app. Every unique event name, parameter name, and parameter value count towards that total. Variables are not counted towards the total. In the following example, four database entries would be counted towards the total limit:

Event Parameter Name Parameter Value ACHIEVED_LEVEL PLAYER_LEVEL 1 ACHIEVED_LEVEL PLAYER_LEVEL 2


The four unique entries being made are: 1 Event (ACHIEVED_LEVEL) 1 Parameter Name (PLAYER_LEVEL) 2 Parameter Values (1 and 2)