> For the complete documentation index, see [llms.txt](https://kbase.whitelabel-loyalty.com/product/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kbase.whitelabel-loyalty.com/product/loyalty-engine/campaigns/rule-based-campaigns.md).
# Rule Based Campaigns
Learn how Rule Based campaigns use reactors to automate loyalty logic in response to user actions. Covers how reactors work within campaigns, when to use Rule Based campaigns, and practical examples.
### What are Rule Based campaigns?
Rule Based campaigns respond to events immediately. Every time a qualifying event is reported and conditions are met, the campaign's reactions fire. They don't track progress toward a completion target, but they do record how many times each user has earned — see [Tracking participation](#tracking-participation) below. The campaign runs continuously for as long as it is active.
Under the hood, Rule Based campaigns use reactors — the same event-driven rules engine that powers the Loyalty Engine. A Rule Based campaign is a reactor (or group of reactors) organised under a named campaign entity with a schedule and a clear purpose.
### When to use Rule Based campaigns
Rule Based campaigns are the right choice when you want the system to react to events as they happen, without tracking cumulative progress. Common use cases:
* **Baseline earning rules** — earn 1 point per £1 spent on every purchase
* **Promo code rewards** — issue a voucher when a valid code is submitted
* **Time-limited promotions** — double points during a specific weekend or holiday
* **Webhook notifications** — call an external service when a specific event occurs
* **Audience-targeted offers** — bonus points for VIP members on purchases
### How Rule Based campaigns work
A Rule Based campaign contains one or more reactors. Each reactor defines:
1. **Event trigger** — the [event type](/product/loyalty-engine/events/event-types.md) that activates the reactor
2. [**Conditions**](/product/loyalty-engine/campaigns/conditions.md) *(optional)* — criteria the event or user must meet
3. [**Reactions**](/product/loyalty-engine/campaigns/reactions.md) — what happens when a trigger fires and conditions are met
4. [**Activation limits**](#activation-limits) *(optional)* — how many times the reactor can trigger
When an event is reported to the Loyalty Engine:
1. The engine checks which active reactors are listening for that event type.
2. For each matching reactor, it evaluates conditions.
3. If conditions pass, the configured reactions fire.
This happens in real time — there is no delay or batching.
**Multiple reactors in a campaign**
A Rule Based campaign can contain more than one reactor. This is useful for grouping related rules under a single campaign. For example, a "Summer Sale" campaign might contain:
* A reactor awarding bonus points on purchases
* A reactor calling a webhook to send a promotional email
* A reactor issuing a voucher to users who spend over £100
All three are logically part of the same initiative and share the campaign's start and end dates.
{% hint style="info" %}
Each reactor within a campaign operates independently. They share the campaign's schedule and name but evaluate their own triggers, conditions, and reactions separately.
{% endhint %}
See [Reactors](/product/loyalty-engine/campaigns/rule-based-campaigns/reactors.md) for a detailed reference on configuring reactors within a campaign.
***
#### Rule Based campaign examples
| Campaign | Trigger | Conditions | Reaction |
| ------------------------- | ---------------------- | -------------------------------------- | ---------------------------------------------------- |
| **Core points earning** | `ORDER_PLACED` | None | +1 point per £1 spent |
| **Double points weekend** | `ORDER_PLACED` | Date between Fri–Sun | +1 point per £1 spent (concurrent with base earning) |
| **VIP bonus** | `ORDER_PLACED` | User in audience: VIP | +2x points multiplier |
| **Partner promo code** | `SUBMITTED_CODE` | Code = `FREE5`; limit: first 100 users | £5 voucher + webhook for thank you email |
| **Social mention reward** | `MENTIONED_YOU_SOCIAL` | User in audience: Over 5,000 followers | +2,000 points + Influencer badge |
***
### Tracking participation
Rule Based campaigns don't track progress toward a completion target the way missions do — but you can still see **how many times each user has earned** from a campaign.
From the campaign or the campaign list, choose **Track users** to see the list of participating users, each with a count of how many times they've triggered the campaign's reactors. Reporting a qualifying event increments that user's count.
Tracking respects each reactor's conditions. In a campaign with more than one reactor, a user is only counted against the reactors they qualify for — so if one reactor is open to everyone and another is limited to an audience, a user outside that audience is counted on the first but not the second.
***
#### For existing reactor users
If you've been creating standalone reactors, Rule Based campaigns will feel familiar. The reactor configuration is unchanged — same triggers, conditions, reactions, and activation limits. The difference is organisational: reactors now live inside a campaign, giving you a named, scheduled, manageable container for related rules.
Existing standalone reactors will continue to function. You can migrate them into campaigns at your own pace.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://kbase.whitelabel-loyalty.com/product/loyalty-engine/campaigns/rule-based-campaigns.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
