◾Dynamic Rewards
Dynamic rewards consist of two main types: Dynamic Bonuses and Dynamic Points/Gems/Diamonds. Both types allow you to create a formula calculating the amount of the bonus or the number of points that will be issued to the players.
Introduction to Dynamic Rewards
Dynamic Bonuses is a tool for calculating cash bonuses based on user activities, including bets, wins, deposits, and withdrawals. This tool enhances user engagement by providing rewards directly corresponding to their actions.
Consider offering a 5% cashback on the net loss (the bet amount minus the won amount) for every 100 bets on the “Gold Quest” game.
Building Blocks of Dynamic Bonuses
Dynamic Bonuses are structured around three key components.
1st step: define a bonus formula. E.g., "5% of Bets - Wins" and optionally filter transactions that should be counted, for example, you can exclude games of category Roulette. In this step, you should also define the calculation result: "amount" or "template."
When the concept is ready, you must build a formula definition using the building blocks in the left menu. The example below shows the "tired" bonus definition with 5% of bets if the total bet amount is above 500, 3% if above 300, and 1% otherwise.
The left menu contains fundamental building blocks for building formulas.
Here are a few examples of how you can use them.
Calculate Net-Deposit amount:
Calculate NetDeposit capped by 100
Define "tiered" bonus:
50% of the deposit, if above 500, max 1000
30% of the deposit, if above 300
10$ deposit, if above 100
else 0
Defined "tiered" bonus based on deposit count
10% of total deposits capped at 500 for users who made more than five deposits
5% of total deposits capped at 500 for users who made more than five deposits
Skip giving a bonus otherwise
2nd step - you need to decide the logic that will give a dynamic bonus - it can be a Real-time or Scheduled Automation rule or a Real-time or Scheduled Campaign. Here are some examples that will provide an understanding of which logic to choose:
You want to provide a 50% bonus for each deposit and send communication to the user about the calculated bonus amount - use Realtime Campaign (Journey)
You want to give 5% of net loss for every 100 bets - use the Real-time Automation rule with accumulation enabled for every 100 bets.
Every Monday, you want to give 10% off all deposits made during the weekend - use Scheduled Campaign or Scheduled Automation rules.
For our example, we will set up an Automation rule to trigger the bonus after every 100 bets on the “Gold quest” game.
We will set a limit of 100 bets and the Dynamic bonus formula we created in the previous step.
Using Dynamic Bonuses to give specific bonus templates
The bonus formula can calculate either a cash amount to be given to the end user, e.g., "10% of Net Deposit". Or the logic of the formula can define which bonus template to give, e.g., if NetDeposit > 100$, then give template "10 Free Spins on Golden Quest", otherwise don't give any bonus
To achieve this, select "Result type" as "Bonus template" during dynamic bonus creation.
After defining this type of Dynamic Bonus, you can use the "Bonus template" building block in the formula definition.
Bonus Approval Queue
The bonus approval queue will show the history of all bonus calculations.
Important: the history of the bonuses is keeping transactions only for last 30 days
From here, the operator can monitor the issued bonuses and "approve" them if the dynamic formula is set for manual approval.
In the manual approval flow, you can also adjust the formula definition and recalculate all non-issued bonuses.
For every calculated bonus, you can check the details of the underlying transactions used in the calculation.
Advanced Usage of Dynamic Bonuses
Using Qualification in the Automation Rules
Dynamic bonuses can be further refined with "Qualifications" in the automation rule.
Example: set a qualification such as a minimum deposit of 100 EUR, combined with the rule of 100 bets on the “Gold Quest” game. This ensures only users who meet the deposit criteria are eligible to receive bonuses after making 100 bets.
Restricting Qualifications
You can limit the qualification to a certain number of executions. For example, a user might receive a bonus three times for every 100 bets. Post this, a new deposit is required to re-qualify for further bonuses.
Integration with Campaign Flows
Dynamic bonuses can be part of scheduled and real-time campaigns (Journeys)
Example: A weekend promotion where users receive a 10% cashback for bets placed during the weekend. The promotion can be announced on Friday, and bonuses are calculated on Monday based on weekend betting activity.
You can also define relative time periods for Dynamic Bonuses calculation, such as "Last full month", "Last full week", "Last weekend", "Last full day", etc. These periods can be defined either relative to the user's time zone or aligned to a fixed time zone. In the case of user-specific time zones, each user will have their own time window used for bonus calculation.
The main benefit of using Dynamic Bonuses in Campaigns is the ability to send communications to users when a bonus is issued. For this purpose, you can build the following connections in the flow builder.
Skipped - will be triggered if the bonus formula doesn't determine the bonus amount/template. See the reasons for this below in the FAQ.
Calculated - will be triggered once the bonus calculation is complete. Note that the bonus has not yet been issued.
Issued - will be triggered when the bonus is issued
You can use the "calculated" and "issued" triggers to connect to any communication channel and notify the end user of the bonus amount. You can use placeholder {{event.bonus_amount}} that will be replaced with the calculated value of the bonus
Period for which to take transactions
With the ‘Period of time, for which to take transactions’ option, you can define the time window for the dynamic bonus; the formula will use only transactions within this period. The time window options for Automation Rules and Campaigns are different.
Here are the relevant values of the 'Period of time, for which to take transactions' for Campaigns and Automation Rules:
Fixed dates
✅
✅
Time back period
✅
✅
Relative period with timezone
✅
✅
Time between first and last transaction in the rule
✅
⛔
Time between qualification and last transaction in the rule
✅
⛔
Time between first transaction in the rule and fixed end-date
✅
⛔
Time between qualification and fixed end-date
✅
⛔
From campaign entrance till now
⛔
✅
Limit the amount for Dynamic Bonuses.
You can set a minimum bonus amount or cap the bonus amount. The options are available in the Dynamic Bonuses template and are called:
Min allowed bonus amount - bonuses with amounts lower than defined will be treated as invalid and won’t be issued
Cap amount for bonus - bonuses will be limited to a specified amount. If the calculated bonus exceeds this limit, only the capped amount will be issued. For example, if the cap is set to 200 and the bonus amount is 1000, the bonus issued will be 200.
Rounding options for the Bonus amount
In the Dynamic Rewards configuration, when the result type is set to "Bonus amount," two additional settings become available to control how the calculated bonus value is rounded before issuance.
Rounding behavior - determines the mathematical direction of rounding. You can choose between "Round to Nearest," "Round Down," or "Round Up," each affecting how fractional values are treated. For example:
Round Down (e.g. 2.735 → 2.73)
Round Up (e.g. 2.735 → 2.74)
Round to Nearest (e.g. 2.735 → 2.74, 2.734 → 2.73).
Round bonus amount to decimals - specifies the number of decimal places to retain in the final bonus amount. This setting works in conjunction with the selected rounding behavior. For instance, setting the decimal precision to 3 means that a value like 2.735 will be rounded according to the chosen rounding mode and then truncated or extended to 3 decimal places. If you setup the value to 0 there will be no decimals after the number. Here are examples based on the different behaviors, for instance:
Round Down (e.g. 2.735 → 2)
Round Up (e.g. 2.735 → 3)
Round to Nearest (e.g. 2.735 → 3).
Multiple Checks blocks
You can use multiple check blocks to simplify the process of building a formula that checks multiple conditions.
For example, instead of creating a complex formula to evaluate multiple conditions on the SUM of Deposit amounts, you can streamline it by using various IF blocks, making the formula more efficient and easier to manage. So instead of building it like this:
You can build it like this:
User State properties in the Formula Builder
The formula builder also supports user-state properties; you can define the type of data for the formula calculation inside the formula template.
Financial transactions & User properties
Use this when your formula needs to calculate values based on Base/Secondary events (e.g., deposits, withdrawals) or a combination of these events with User state properties (e.g., Logins count ever). For instance, you could build a formula that calculates bonuses or points based on the last deposit amount plus the total number of deposits made by the user.
User properties only
Select this option when you want to build a formula where the calculations are based only on the User state properties. For example, the ‘Logins count ever’ property can be included to create a formula based on the total number of times a user has logged in.
When the ‘User properties only’ option is selected:
There are no Base and Secondary events in the formula template
Inside the formula builder, there are only user state properties
When this type of formula is used in Automation Rules and in Campaigns, there are no Transaction period options
❗ Important note about the usage of user properties
User state properties have a 5-10-minute lag in updating our database used for the Dynamic Rewards calculation. You need to consider it when building a logic for a formula calculation and c.
Let's look at an example where the calculation will be incorrect.
You want to give 50% on the first deposit. To achieve this:
You built an automation rule that, on every deposit, triggers a dynamic formula on the first deposit
You build a formula that returns 50% of the "Total deposit amount" (user state property).
Given that the automation rule triggers only on the first deposit, the "total" will equal the value of that deposit, so it should work.
In fact, the behavior will be inconsistent. Let's assume the following timing of events:
12:30 user does a deposit, which triggers the automation rule
12:35 dynamic rewards starting to calculate the value of the bonus.
Depending on the lag of updating the user state in Smartico analytical DB, "Total deposit amount" could be updated before or after 12:35, which will lead either to correct bonus calculation or to a zero value.
How to mitigate it
First option, you can request Smartico Success Manager to increase the delay of the Dynamic Reward calculation to 15 minutes; in this case, the calculation will be done at 12:45, when the state will already be updated.
Second, and even better, use transactional events with the "Last" operation, for example, as shown in the picture. This way the calculation engine will take the last value of deposit amount and it will exactly correspond to the value you are looking for
Using variables with fixed values and multi-currency support
Dynamic bonus formulas support variables, providing enhanced flexibility and precision, especially for multi-currency setups.
There are two types of variables:
Custom Variables: Operators can define variables within bonus formulas to tailor bonus calculations.
Multi-Currency Support: Easily configure bonuses to account for currency-specific caps, ensuring accurate, compliant rewards across currencies.
Service pricing concept & saving tips
For example, if your bonus formula is calculating 5% of the Bet minus the Win amount every Monday for all transactions done during the last weekend, then the calculation will need to read all the bet & win transactions for the days of the weekend.
You can analyse credit usage using the following report.
There are a few recommendations on how to keep pricing low:
Avoid large time windows for transactions with high volume. For example, calculating the formula for bet/win transactions for the previous month will require reading a large volume of data.
If you can afford to delay bonus calculations, ask your Success Manager to increase the "batch waiting time period". By default, all calculations are batched by 5-minute intervals. Increasing the batch size will reduce credit usage, but it will also increase the delay in bonus calculations.
Limit segment size appropriately in Campaigns and Automation rules. E.g. if you are building a dynamic bonus as 5% of net loss on the bets done "yesterday", you should limit the segment to include only users who did bets in the last 2 days (considering different timezones), otherwise, if you include all users, the calculation will be done for the whole database, while actually, only limited number of users had bets in the needed period.
To summarize, the amount of used credits depends on:
How many transactions need to be analyzed
For how many users does the bonus need to be calculated
How can these users be grouped into batches
Dynamic Points, Gems, or Diamonds
You can calculate and issue a dynamic amount of Points, Gems, or Diamonds using the formula builder. To enable this, set the Result type to Points amount / Gems amount / Diamonds amount.
With the "Min allowed amount" field, you can define a threshold. If the dynamic formula's calculated result falls below a minimum threshold, reward issuance will be suppressed, and the user's reward will be considered invalid.
In the case of gamification points, specifically, you can decide where they apply:
In the player’s current balance
In the Leaderboards progress
In the Levels progress
Points issuance follows the same mechanics as dynamic bonuses and can be triggered via automation rules or campaigns. If Auto Approval is disabled, points must be manually approved in the Approval Queue.
Once issued, points are logged in the user's Points Log under the new source type: Dynamic Formula, allowing you to easily filter and track.
FAQ
How fast are bonuses calculated?
By default, bonuses are calculated in 10-15 minutes after the triggering logic is issued. For example, if you have an automation rule that gives a Dynamic Bonus after every 100 bets, the bonus will be calculated in 10-15 minutes after the last bet the user makes.
Note:
This delay should be carefully tuned for your integration and large enough to capture all transactions from your system in Smartico.
It's possible to adjust parameters to trigger bonuses almost in real-time, in case your bonus logic is based on a per-transaction concept. (e.g., give 30% the deposit)
Are there any time limits on the transactions included in the bonus formula?
The maximum time period is 31 days. For example, you can calculate the bonus based on all game activities for the previous month.
Are the "credits" consumed when bonus results are 0, not defined, or negative
Credits are consumed in all listed cases; computing resources are used regardless of whether the results make sense from a business perspective.
Why do some bonuses fail to calculate?
There are 3 cases when bonuses can fail during calculation:
The formula is not defined properly, or it is returning zero or a negative value
There are no transactions matching for the specific user
The time period for transactions is above 31 days
What can I do if my credit usage is high?
If you notice that your credit usage is high, you can take the following steps to reduce it:
Review your transaction windows and reduce their range if possible.
Discuss with your Success Manager about adjusting batch waiting times.
Fine-tune segmentation in Campaigns and Automation rules to only include relevant customers.
By implementing these changes, you should see a reduction in credit consumption.
Is there a way to forecast how many credits I will use?
You can forecast your credit usage by analyzing patterns in your historical data and considering the frequency of your bonus calculations. The Credits Usage Report can also provide insights into your typical usage, helping to anticipate future needs.
If the formula definition is changed from "issue manually" to "issue automatically", will it issue already calculated bonuses?
Only new bonuses will be issued automatically. All bonuses that were calculated before need to be manually issued by the operator from the "Approval queue" screen
Can credits be rolled over to the next month if I don't use them all?
Credits do not roll over and must be used within the month they are allocated.
Related articles:
How to manage Automation rules
How to manage Bonus templates
I cannot find dynamic bonuses transactions that were calculated previous month, what happened with them?
We are keeping only the last 30 days' records of dynamic bonuses that you can find in the "Approval queue".
For the approved bonuses, you will be able to find them in the issues bonuses, for example, in the "CRM \ Bonus history" in Smartico BackOffice, or you can also access all the data over the Smartico Data Warehouse.
Last updated
Was this helpful?