How to gamify your platform by adding a rule engine
The relevance of gamification extends beyond the traditional gaming industry. More and more tech companies are starting to incorporate elements and principles of games into non-game contexts, with the intention of engaging and motivating individuals to achieve specific goals or desired behaviors.
In this post, I would like to share how we created a gamification layer on our video platform by adding a rule engine. The post will cover the high-level architecture, but I will not deep dive into the full technical stack.
What are we playing for?
One of the goals of the product we work on is to give the user the best video experience. When we asked ourselves how we could make the experience more enjoyable and get users more engaged in our platform, gamification came into the picture.
Users on our platform can watch videos, manage their content, create virtual events, and much, much more. The first thing we needed to do was identify what actions in the platform we wanted to increase engagement on. Those actions would be rewarded with points upon completion.
Since our platform is very large and there can be many actions and use cases, we focused on a subset of actions that related to the user who performed them, like submitting a quiz, and actions that related to other users, like writing a comment. That way, we could get two for the price of one. The user would use the platform more, and also be more collaborative, which could affect other users as well.
Rule engine, here we go
After we went over the full list of actions, we saw that most of them had a pattern:
- Get X points for doing an action
- Get X points if you were one of the first Y to do an action
- Get X points if you did specific action at least Y times
and so on.
Implementing a generic rule engine immediately came into our minds as the best solution.
First, let’s understand what a rule engine is
A rule engine is a software component or system that allows you to define and execute business rules in an automated and efficient manner.
Working with a rule engine usually consists of several parts. The main ones we will talk about are:
- Facts — the data we want to run on
- Rules — a set of conditions that need to be fulfilled
- Operation — what needs to be done when rules are fulfilled
Getting the facts
After the wanted actions set was collected, we needed to recognize all the relevant flows in the platform that we needed to get data from and structure our facts. We took every user action we wanted to run the engine on and created a matching JSON structured fact for it.
For example, here is a fact that our engine can run on for a user who registered to a specific course:
The facts were produced from all the different components to an event stream so that later, they would be consumed by our rule engine.
Defining the rules and conditions
How could we utilize this structure to define a matching rule? At this point, we broke down the rules to conditions that needed to be matched to an event (fact).
For the purpose of clarity, let’s focus on the following rule:
Give 50 points to the first 100 users who register for courseId X.
We created a rule object that would contain conditions for matching the facts, and some additional config to help us with the needed post calculations.
The conditions part was built in such a way that they would provide us with the first match for the type and courseId fields, while we had the additional setup that could help us with the later required processing.
Supporting packages to create the basic conditions structure exist in multiple coding languages, so you can just choose your favorite one and play with it.
We have a match! What’s next?
Some of the rules we were required to support were simpler, but some were more complex. For each rule whose conditions were fulfilled, we had an additional layer of processing in order to understand whether the user was indeed eligible for getting points or not. For this calculation, we added to our architecture post-processors.
The processors we created can run different custom logic based on the specific rule settings. Some examples of such logic are:
- Aggregate a value from one of the facts fields and store it
- Count the number of similar facts we’ve gotten until this point, and if it reaches a certain threshold, do a calculation.
In the example I showed earlier in the blog post, we needed to add a processor with the following custom logic: each time the conditions for the rule are fulfilled, take the userId and try to add it to a list of users registered to the course. If the user is not already part of it, and the length of the list is smaller than 100, give the user 50 points and store their userId in the list.
In the end, at a high level, the architecture looked as follows:
This structure allowed us the freedom to create different types of facts, rules, and processors that could run the post-operation.
What are our game options?
Now that we have the implementation that allows users to gain points, we can utilize it and do many fun things with it!
The rules we created can be connected to different game settings based on the goal to achieve.
Implementing a leaderboard can be one great way to stimulate competition between users. Due to the fact that everyone sees how many points they gain, people tend to do more actions and be more engaged.
Another fun option is adding badges to the platform that users can gain. This can increase personal engagement and the feeling of accomplishment for users.
Wrap up
As you can see, rule engines are a powerful tool that can be used for multiple diverse use cases.
The technical stack and internal implementation can be varied based on your personal preferences, but as long as it is built in a generic way, you can add more and more layers to your service and enrich your platform with multiple gamification options, by changing just the input, rules and operators.
In the end — everyone loves to play, so by adding gamification to your platform, you can make it much more appealing and fun for your users and potential customers.
