Real-Time Movements
This page will explain how to create a new Real-Time Movement computation.
❓ When to use a Real-Time Movement?
You should use a Real-Time Movement type of calculation for your computation when you wish to trigger a players' change of class as a result of a real-time event.
Such movements are not calculated by looking at previous player data, playing patterns or data that needs to be calculated over time. Instead, they react to a real-time event that occurs, such as player log-in, deposit or registration.
FT Singularity Model Example
In this example from the FT Singularity Model, we want to calculate the player movements within the Lifestage Player Feature to understand if a player is active, inactive or newly registered.
Player Feature: Lifestage - The current life stage of the player, an active player is anyone with a real money transaction in the last 30 days.
Feature Type: Lifestage - Lifestage determines whether the player is New, Active or Inactive.
Classes: New, Active and Inactive
Real-Time Computation/Movement: Change a players life stage class from Inactive or Registered to Active when the player makes a successful deposit and a casino bet.
Let's set up the above 👆computation together and go step-by-step through the process of setting up a real-time movement.
🎥 New Action
Firstly you need to select if your new action should be a real-time movement or a time-based query.
In our example above, we want the players class to be changed to Active when they make a successful deposit and make a bet on any casino game. Therefore, we need to create a real-time movement, as the change or class is dependent on a real-time event happening on-site.
Real-Time Movement
Real-Time Movement
⚡ Computation Triggers
Next, it is important to set the necessary triggers to determine when the computation should take place. It is possible to define multiple triggers, as in the example below.
Simply click on the 'Add a Trigger' section to select an existing trigger from the list, or click the ➕icon to create a new trigger.
In this example, we want the players to change their class once a successful deposit and a casino bet has taken place. Therefore, we have added two computation triggers.
Computation Triggers
Computation Triggers
🧑🏫 Qualifying Classes
In this section, you can see all the possible classes for your Player Feature. This is where we define who, which players, will be affected. Select the class or classes that qualify as part of this computation.
In this example, the players who are classified as Registered or Inactive at the time of a Successful Deposit and On Casino Bet will be affected by the computation, as they will be moved to the Active class.
Select qualifying classes
Select qualifying classes
Note 🧠: It is possible that you don't need to select any qualifying classes at all.
In the case you want to apply the computation to all players regardless of their current class, you can simply not select any qualifying classes.
↔️ Specify Movements
Select the segment on the left-hand side of the players who will be affected by this movement. On the right-hand side, you define which new class the players will belong to once the computation has happened. This step defines what will happen when the computation occurs.
In this example, we want all players who qualify (Registered and Inactive players) to be moved to the Active class, once the triggers (successful deposit and casino bet) have fired. Therefore you need to select from the drop-down list or create a new segment for All Players. Then set the New Class, on the right-hand side, to Active.
Specify player movements
Specify player movements
Note 🧠: You can add as many movements as you need. In this example, we only need to create one movement.
An example of a real-time movement that has multiple movements is:
On Successful Deposit for all classes assign the player to the correct class depending on the deposit amount.
In this example, we want to assign a player to a class depending on the amount of their first deposit. As you can see from the image below 👇, the segment defines the deposit amount and the player is assigned to the corresponding new class.
Additional example of multiple movements in one computation
Additional example of multiple movements in one computation
Important: When using multiple movements the order is important.
The first qualifying or matching segment will be evaluated for the player and will cause the movement to occur. Any other specified movements will be ignored.
Tip: To avoid any potential issues with the segments, where possible make sure that they exclude one another and that a player could not fall into multiple segments.
🤔 Why is it useful to classify your players?
Once you have set up Feature Types and Classes, they can be used in Player Features to assign classes to your players based on the new data we are capturing about each player.
You can take full advantage of these classes by using them as segment fields within your segmentation.
Player Features will be available as segment fields when building a segment, and all classes within that Feature will be available to select as options. For example;
Lifestage is equal to Active
Lifestage is equal Inactive
📛 Name your Computation
Finally, give your computation a descriptive name. Please make sure the name is informative enough for you and your team to understand what is being calculated inside the movement.
Once you are ready, Update Computation to save your work.
Name your computation
Name your computation
✅ Active Movements
All of your movements (real-time and time-based queries) will be displayed under Active Processes on the Manage Movements tab of the Player Feature.
Active Processes
Active Processes
📈 Dashboards: You can see the results of the real-time movements in the Dashboards tab of the selected Player Feature.
Here is a full run-through of the set-up process for the real-time movement used in the example featured on this page:
Full example of a real-time movement set-up
Full example of a real-time movement set-up