Cascading
Why do we need the feature?
What is Cascading
There is often a need to use the output generated from one or more programs as an input to another program.
This feature of being able to use one program’s output in another program is called cascading.
Need for Cascading
By default, cascading is turned off as a feature.
It can be turned on by sending a request for the same to the Xoxoday team.
If the incentive structure has multiple sub incentives, that are to be added up to a singular final reward, then cascading will be needed, as the output of individual programs for each vertical will be used as input for the final program which will have the total incentives.
Cascading may end up complicating the programs for a non-technical user, if overused where not needed. Additionally, for any changes, one would need to propagate them to all the metrics and programs in the cascade deriving directly or indirectly from the modified metric/program. This may increase the time taken to implement changes. So, it is vital to use cascading ONLY when needed.
Using the feature
How Cascading works
The essence of cascading basically lies in the “Views” and Metrics.
Whenever a program is created with the cascading enabled, a View of the same name is also created.
This View of the program shows all the data generated by the program, along with the metrics used in the program.
Now in a particular program, the rewards within a single milestone can be denoted by Reward 1, Reward 2, Reward 3…, in order of their occurrence in the milestone.
So if a particular reward is at the 2nd position in each milestone, we can get the value of that reward as a metric by doing a summation of Points and so on for each milestone.
The view used to create this reward will be the program from which we want to sum the reward, i.e. the view that was automatically generated when the program was created with the same name as the program.
These metrics can be then used in another program to get another value by applying a formula on it, or as a task condition, or to display as it is.
A chain of such programs and their derived metrics will form a visual branch-like structure, with views at the bottom-most level.
The below shown screenshot shows how a simple 2- level cascading looks like.
It will be discussed in depth in the latter part of the documentation.
Processing of Programs in a cascaded structure
When programs are to be processed in a cascaded structure, the programs in the lower layer are to be processed first, and then based off the output of these programs, the programs in the higher levels are calculated.
So in a scenario where new/updated data is uploaded, the programs need to be reprocessed. But manually reprocessing/recalculating each program can be tiresome.
The simple process is to click on the 3 dots options menu for the program at the top level, and then click on view incentives. From there re-calculate this program at the highest level in the cascade. This will reprocess all the programs beneath it with the updated data.
In a case where there are multiple programs at the highest level, this reprocessing is not possible directly, as there are multiple branches for multiple programs. Although this scenario is rare, it is still possible.
To combat this, you can ask the backend team to set up ARP or Auto ReProcessing. Here the programs will be reprocessed at fixed intervals as mentioned by you.
For the system to know which programs to reprocess, you need to provide the team with the ID of the program group(s) that you want to be reprocessed periodically.
This eliminates the need to manually recalculate the programs from the “View Incentives” tab.
Program views for Cascading
As mentioned above, the views are automatically created when a program is created, with the same name as the program.
But, Program names are editable even after the program has been published.
So if the program name is changed, the view for that program still remains with the same name.
It is advised to keep a log of the original name of the program, and the subsequent changes, so as to know which the correct view for the program is.
Backtracking/Debugging
There may arise a need to backtrack on the so-called cascading structure. Or, if you come across an error, and need to know exactly which program in the flow is causing the error.
Backtracking basically means to map out the structure such that one can understand which programs are made from which metrics, and those metrics are made from which programs.
To backtrack, start with the topmost level of the program in the cascade.
Then note down the metrics used in this program, all of them. This includes the ones in task conditions as well as the reward.
For each of these metrics, look them up in the metric section and open them. Note the view/connection used to create this metric. This view refers to the program of the same name, where the metric was created.
Now repeat the process on the program/ programs in the above steps. Different metrics in a program may be generated from the same program/view or from different ones.
Repeat this process till one reaches the metrics that were made using the initial user-event view.
All the branches of the structure must end in a view that is not directly generated by a program.
This structure will help one understand where the calculation issue is occurring, and where to make the changes to correct it.
Documentation for ease of use
Cascading can get a bit complex for Admins to remember, especially if it is for a complex incentive structure.
If that is the casee, it makes sense to have it documented, so as to be able to replicate it when needed.
As seen in the above image, the cascade structure is mapped out in the visual format.
The View - “April 22” is the initial user-event view.
There are 4 metrics made from that view using some logic, so we can say that all metrics are derived from the same view.
Each of these metrics is for a different incentives vertical, which are used in respective programs to generate 4 different rewards with different logics.
Now, these 4 programs will generate a view with the same name, and from the view we can create the subsequent metrics.
These metrics are made as a sum of the reward in which the reward is given in each milestone, - Sum of Points, Sum of Score etc.
They denote the total summation of reward for that particular vertical from all of the milestones.
These 4 metrics, denoting each milestone are then used in a final program, which sums them all up, to display the individual reward from each vertical, as well as the total reward.
One can also add the view or program ID along with the names, so as the facilitate the ease to search when needed.
The program ID can be found by opening the program by clicking on it and then getting the alphanumeric code at the end in the URL.
Mapping this out also allows the admins to have a visual view of how the structure looks from the backend, facilitating clarity and ease of access of programs, metrics and views.
This is a scenario where cascading is necessary, as there are 4 different KPIs with different logics for reward calculation. If there is a straightforward KPIs then it would be preferable to not use cascading.
UI Elements
You can choose to make a program a cascaded one, i.e. a view will be created for it. You can select the checkbox as shown below to make the cascaded program in the settings tab of program creation, or uncheck it to keep it as a simple program.
When making a cascaded program , you can use either the same view, or a new view.
If there are no changes in the logic or the metrics, you need not create the metrics for the subsequent programs, only if you are using an existing view.
Analytics
How long it takes for people to interact with the feature for the first time, measure of ease of use and adaptability
May be a bit complex for users without technical experience to understand.
How often feature is being used
Used sometimes, when the Incentive structures are complex
How long users spend interacting with the feature
Around 30% of the time when setting up programs
Abandonment rate
None, usually used once set up
Last updated