Dynamic Rewards
Last updated
Was this helpful?
Last updated
Was this helpful?
Dynamic rewards consist of two main types: Dynamic Bonuses and Dynamic Points. 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.
Dynamic Bonuses is a tool offering a way to calculate cash bonuses based on user activities like 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 each 100 bets on the “Gold Quest” game.
Dynamic Bonuses are structured around three key components.
1st step - you need to 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 result of the calculation - "amount" or "template."
When ready with the concept, 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.
There are basic building blocks available in the left menu that can be used to build 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$ of deposit, if above 100
else 0
Defined "tiered" bonus based on deposit count
10% of total deposits capped by 500 for users who made more than five deposits
5% of total deposits capped by 500 for users who made more than five deposits
skip giving 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 give an understanding of which logic to choose:
You want to give 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 done 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.
The bonus formula can calculate either an amount of cash that will 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.
The bonus approval queue will show the history of all bonus calculations.
From here, the operator can monitor the issued bonuses and "approve" them if the dynamic formula is set for manual approval.
In the case of manual approval flow, you also have the flexibility to adjust the formula definition and recalculate all non-issued bonuses.
For every calculated bonus, you can check the details of underlying transactions used in the calculation
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.
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.
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 the weekend's betting activities.
You can also define relative time periods for Dynamic Bonuses calculation like "Last full month", "Last full week", "Last weekend", "Last full day" etc. These periods can be defined according to the user's timezone or aligned with a strict timezone. In the case of user-specific time zones, every user will have their own time window that will be used for bonus calculation, for example.
The main benefit of using Dynamic Bonuses in the Campaigns is the ability to send communication to the users when the 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 when the calculation of the bonus is done. Note that the bonus is still not issued at this point
Issued - will be triggered when the bonus is issued
You can use "calculated" and "issued" triggers to connect to any of the communication channels and notify the end user about the bonus amount. You can use placeholder {{event.bonus_amount}} that will be replaced with the calculated value of the bonus
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
⛔
✅
You can define the minimum bonus amount or cap the amount for the bonus. 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 at 200 and the bonus amount is 1000, the issued bonus will be 200.
You can use multiple check blocks to simplify the process when building a formula that needs to check multiple conditions.
For example, instead of creating a complex formula to check multiple conditions for the SUM of Deposit amounts, you can streamline it using multiple check blocks, making the formula more efficient and easier to manage. So instead of building it like this:
You can build it like this:
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 event in the formula template
Inside the formula builder, there is only user state properties
When this type of formula is used in Automation Rules and in Campaigns, there are no Transaction period options
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 big-time windows on transactions with big volumes. For example, calculating the formula on bet/win transactions for the previous month will require reading a lot 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 decrease credit usage, but on the other sides, there will be a bigger delay in the bonus calculations
Limit the segment size properly in the 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 these users can be grouped in the batches
You can also calculate and give a dynamic amount of points with the formula builder, by using the Result type setting: Points amount. This improvement allows you to calculate gamification points based on your custom formula and 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 these points.
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 adjusted carefully for your integration and should be big enough to get all transactions from your system into the Smartico.
its possible to adjust parameters to trigger bonuses almost in realtime, in case your bonus logic is based on per-transaction concept. (e.g. give 30% of deposit)
Are there any limitations for the time period for 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, the computing resources are used no mater if the results make sense from business perspective or not.
Why do some bonuses fail to calculate?
There are 3 cases when bonuses can fail during calculation:
The formula is not defined properly or returning 0 or a negative value
There are no transactions matching for specific user
The time period for transactions is above 31 days
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.
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.
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
Credits do not roll over and must be used within the month they are allocated.
Related articles:
How to manage
How to manage
