◾Dynamic bonuses
Last updated
Last updated
Dynamic Bonuses is a paid service that should be requested separately.
Please see the pricing concept explained below, contact your Customer Success Manager to get more details and activate the service.
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:
| Time window values | Automation Rules | Campaigns |
|---|---|---|
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.
Dynamic Bonus service is charged per amount of data that was read in order to make bonus calculations. The charges are reflected in the "credits", and each label has 10,000 credits available for bonus calculations every month.
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
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 that this delay should be adjusted carefully for your integration and should be big enough to get all transactions from your system into the Smartico.
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 Automation rules
How to manage Bonus templates
