Quests allow you to challenge your users to achieve desired outcomes

Scrimmage offers an innovative and user-friendly approach to creating and managing quests in gamified systems. Quest definitions are separated from Quest Distribution. Your dashboard can have thousands of quests, and the user will see only 2, which you will configure him to see using storylines and workflows.

Using our quest system, you can create quests like

  1. Complete reading this article in the next 30 seconds and get ten coins.
  2. Buy one new item from our shop every month for six months and get the unique perk.
  3. Spend more than $100 in our bar 5 times a row and get a trophy.
  4. With a team of 4 other strangers, run at least 100 miles in the next month and get lifetime access.
  5. Click here to complete 2FA and get your sign-up bonus.
  6. Woohoo, you have a win streak of 5. Win five next games and get a legendary perk

Event Completion conditions

Once the user accepts the quest, it starts listening to every event happening with the user and changing progress. The most straightforward quest can be created by just beginning to count the amount of events the user receives. More complex quests can be made by adding additional event filters.

To gain a deeper understanding of how event conditions function, explore the Introduction to Events section

Event Filters

Every event has a data type attached to it. Data type automatically tracks (indexes) what possible properties and values an event can have. Admin can also modify potential properties and values from the admin panel to start making quests without integrating data.

Event filter uses data type information to render a UI that helps the admin find correct properties visually. That allows the admin to know available event properties and enables cross-functional collaboration.

In-row events

The hardest part of product gamification is to make quests that are challenging enough so that users don't feel bored. Scrimmage allows admins to increase the complexity of quests with in-row event configurations, forcing you to receive events that will pass the event filter N times in a row.

It is essential to understand loose conditions in this case. If the user receives the same event you attached to the quest but this event will fail condition - the quest's progress will get reset.


Skill based challenges

You can use an in-row filter to create skill-based quests like "Win bet three times in a row."

Completion period

Admins can define the time frame for completion, adding a sense of urgency and enhancing user motivation. Quest with a deadline, on average, performs better than quests without it.


Sometimes, we want to make users form a habit, and nothing can be more straightforward than giving them a quest to visit the app seven days in a row. You can choose different completion periods like "Visit app at least once per week for four weeks.” Occurrence can help you to do that.

Reward and price

Quests are a crucial part of the loyalty economy as they can represent authentic user engagement. By default in our system, we have two user properties: GoldenTrophies and FeaturedTrophies. Those are two types of trophies you can reward users for completing quests. It is also a common practice to reward tokens.

Acceptance price

Sometimes, you want to make your users more serious about quests. In this case, you can add an acceptance price to your quest. While doing this, be sure you configured your economy so the user will have money to buy the quest. Also, ensure that the quest reward is better than the price.


All quests have to be accepted.

By default, the user must accept all quests, even with a price of 0. If you want to make quests taken automatically, please request the feature via [email protected]

Quest reward

Quests are integrated into a global rewards framework, enabling a flexible and customizable selection of rewards. This system allows for personalization at both the individual user and segment levels. Detailed information on the variety of rewards is available in the rewards section of our documentation. Transaction histories will reflect the quest and the bonus earned, enhancing transparency and user engagement.

For completing quest you can reward your users with everything that global rewards framework supports including:

  1. Tokens
  2. Perks
  3. Status Points
  4. etc.

Group quests

If you want to make your app more social or already have a party system, you can utilize group quest functionality, allowing your customers to complete quests together. By default, users are randomly distributed into parties after the quest starts. Additional customizations and integrations are available by request to [email protected]


Group quests are not configurable

By default, all group quests have 5 participants, 5 minutes to accept, and 5 minutes of lobby time. If the quest doesn’t get enough participants, it will be canceled. Additional configurations are possible; please reach out to [email protected]

Quest management


Quests need to be distributed.

Your users won't see the quest you just created. There are two methods to give quests to users. It gives you more flexibility toward which quests the user will have and in which order.


Workflows can be used for a variety of reasons, including distributing quests. Here are a couple of workflow use cases:

  1. Use quests as a powerful re-engagement tool by integrating them with registration or checkout process workflows.
  2. Distribute one, multiple, or random quests from the workflows.
  3. Pause the workflow until the distributed quest is completed. Y
  4. Attach workflow to your existing system using HTTP Webhook, which gives you direct control over quest distribution.

Quest lines

A more automated way to give users quests is quest lines. They allow the admin to group quests into meaningful stories. The storyline also limits the number of active quests a user can have from this storyline. There are two primary storyline types:

Random Distribution Type

This distribution type will give the user a random quest from quests in the storyline. If you want one quest to be distributed simultaneously, you must configure it on a quest level using the appropriate configuration.

If you want control over which quest a user should get, you can utilize a grouping mechanism to ensure that users have a balanced amount of quests in every group. It is helpful if you have a quest line, "Daily quests," and players have two quests available every time. Now, there are two types of quests: referral-related and chat-related. You don't want your users to have two chat-related daily quests; you want to balance the variety. You can put all chat-told quests into Group 0 and referral quests in Group 1.

Ordered Distribution Type

With ordered distribution time, you are getting the power to distribute quests not randomly but in a specific pre-defined order. This distribution type also allows you to customize your user experience for different system parts.

Most of our widgets support quest line filtering, which means you can show different quests on different pages. You can also use it to build long-term user journeys and on-boardings.


Gamified on-boarding

You can quickly develop gamified and interactive on-boardings and product tours using quest lines.


Don't forget to set a limit to the quest.

If you create an ordered storyline with a quest that can be completed more than once, the user will get this quest again after completion. To avoid that, configure all quests in the ordered storyline to be "Complete only once."

Users get quest lines after leveling up.

Every quest line has a level requirement for the user. Once the user achieves that level (or after registration in the case of level 1), the questline will distribute to the user the appropriate number of quests based on the configurations.


If you created a quest line after launch, you must distribute it manually.

Every quest line is getting distributed only after leveling up. That means if you generate a questline after the user already registered, he will skip the whole quest line. You can manually distribute the storyline from the admin dashboard to fix that.

Users can get quests after the previous quest is completed

With this configuration, the user will get the next quest after completing the previous one.

If the user cancels or loses the previous quest, the next quest won't be distributed, so it is essential to ensure that quests are not cancelable if you want to use them as part of such a quest line.

Users can get quests Every N minutes.

With this configuration, quests are getting distributed every N minutes. The total number of quests will never be more significant than the configured number in the quest line, which means that if the user hasn't completed, canceled, or failed a previous quest, he won't get a new one. This type of distribution is helpful for mechanics like "Daily quest" or "Weekly quest.”

Quest Distribution

As a part of the quest definition, you can choose which users are eligible to receive this quest. This configuration won't mean that all qualified users will immediately receive this quest; it instead means that even if some workflow or quest line decides to give users this quest - they won't be able to do it because it will be blocked from the quest side.

User Requirements

Quests can describe requirements for users who will receive it. It gives us an additional layer of control over quest distribution, which you may lack in the quest lines or workflows.

You have direct access to all available system and custom user properties from the quest. This means you can create conditions for levels, experience, perks, or any other custom parameter you make.

Acceptance period

Some quests can have a limited availability time, and you miss it if you don't accept it before the timer goes down. The acceptance period is frequently used to create event-specific quests that will be distributed on the event evening and available for the event period.


The acceptance timer starts after the distribution.

It means that if you give a user a quest at night and the quest has an acceptance period of 3 hours, the user may never even have the option to accept it. You must be careful with time zones and quest distribution while working with the acceptance period.

Scheduling dates

You can allow your quest to be distributed only during specific dates. It can allow you to create seasonal quests or whole battle-pass seasons. Expired quests will be automatically removed from quest lines and moved to backlog. You can enable them again later by setting a new expiry date.

Completion Frequency

From the inside of the quest, you can control how much time a single user can complete this quest. You can make it a one-time quest or allow users to complete it a maximum of once per month.

Non-cancelable quests

In some cases, like onboarding, you don't want your users to be able to cancel a quest. In this case, you can make the pursuit non-cancelable, and the user will be stuck with this quest forever.

UI configurations

If you plan to use our widgets, you may be interested in the UI customizations of the quests.

Quests Widget

We have designed a separate small widget that allows you to use our quest page separately from everything else using a small configurable iFrame widget.

Provide Description

You can customize the description of every quest. Our widget usually counts on descriptions of various sizes so that you can insert whole stories into quests or short tasks.


AI helps to generate descriptions.

To further automate admin work, we built a GPT4 integration, which generates quest descriptions based on configurations.

Provide Units

Every quest will count something, whether referrals you made or money you spent. Our system can't automatically detect what we are measuring, so you can set anything appropriate to show the user.

Quest Redirects

Sometimes, you want the user to be able to click on quest and get redirected to the specific page or website where he can complete the desired action. Due to iFrame limitations and security reasons, we can't directly redirect users. However, we can make signals that can be listened to from your application that will do redirects and other native events like vibrations.