> For the complete documentation index, see [llms.txt](https://help.impact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.impact.com/brand/what-would-you-like-to-learn-about/advocate-program/advocate-program-settings/test-your-advocate-program.md).
# Test Your Advocate Program
You can test your Advocate program by simulating your [program's rules](/brand/what-would-you-like-to-learn-about/advocate-program/getting-started-with-advocate/advocate-program-rules-explained.md) against sample data to confirm a rule behaves as expected before you rely on it in production.
{% hint style="success" %}
**Note:** You need to set up at least 1 program rule to test your program.
{% endhint %}
{% stepper %}
{% step %}
## Access Test My Program
1. From the left navigation menu, select  **\[Engage]** :arrow-right: **Program Rules** :arrow-right: **Test My Program**.
1. Select **Next** to move between steps.
{% endstep %}
{% step %}
## Confirm the program & version
2. The program is prefilled from your current context. Switch it only if you need to test a different one.
3. From the *Version*  **\[Drop-down menu]**, select whether to simulate the **Draft** or **Live** version.
1. Learn more about what a draft and live version of your Advocate program entails.
{% endstep %}
{% step %}
## Choose the event & fill in its inputs
4. Select which event you want to simulate, then enter information the way they'd occur in your program:
* **Referral starting**
* **Friend makes a purchase**
* **Friend refunds a purchase**
* **Friend performs an action**
Field reference
| Field | What it does | Available for |
| -------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------ |
| **Purchase event** | The tracked purchase event to simulate. | Friend makes a purchase, Friend refunds a purchase |
| **Purchase Date** | The date of the simulated purchase. | Friend makes a purchase, Friend refunds a purchase |
| **Event type** | The tracked event to simulate. | Friend performs an action |
| **Event date** | The date the event occurred. | Friend performs an action |
| **Currency** | The currency of the simulated purchase amount. | Friend makes a purchase, Friend performs an action |
| **Purchase amount** | The amount of the simulated purchase. | Friend makes a purchase (required), Friend performs an action (optional) |
| **Referral started on** | The date the referral began. | All events |
| **Referral converted** | Specify if and when the referral has already converted. | All events except Referral starting |
| **Advocate segments** (optional) | Limit the test to a specific Advocate segment. | All events |
| **Friend segments** (optional) | Limit the test to a specific Friend segment. | All events |
{% endstep %}
{% step %}
## Run the test
5. Select **Run Test**. Your rules are evaluated against the selected program, version, and the inputs you provided.
{% endstep %}
{% step %}
## Read the preview output
6. Review the *Preview* panel:
1. A triggered rule summary, the date range if date-based actions apply, and a checkmarked row for each resulting action. Confirm whether it matches what you expected.
{% endstep %}
{% endstepper %}
## Test cases
These test cases use example rules you can set up to confirm your program behaves the way you want before you publish it. Each scenario below walks through a specific situation in more detail. Adapt the specifics, like trigger, amounts, and segments, to match your own program's configuration.
Basic trigger logic
**Goal:**
* Confirm a basic purchase-trigger rule matches and returns the expected result.
* Confirm there's no incorrect fallback behavior.
**Rule setup:**
* Trigger: Friend makes a purchase.
* Action: Reward and Email to Advocate, with a cash reward to the Advocate.
* No default action needed.
**Test inputs:**
* Event: Friend makes a purchase.
* Purchase event, purchase date, purchase amount, and currency matching your rule.
* Referral started on the same date.
* Segments left open.
**Expected result:**
* The rule matches, and the preview shows exactly which rule matched.
* The Advocate reward row shows your configured reward amount.
* The Advocate email row is shown.
* No other, incorrect fallback action appears.
Time-window match vs. fallback
**Goal:**
* Confirm a date inside a time-based window applies the time-based action.
* Confirm a date outside the window falls back to the default.
**Rule setup:**
* Trigger: Friend makes a purchase.
* A time-based action scoped to a date window, based on the referral start date.
* A default action outside that window.
**Run A (in window):**
* Set the referral start date inside the window.
**Expected A:**
* The preview shows exactly which time-based rule matched.
* Its reward and email are applied.
**Run B (out of window):**
* Set the referral started date outside the window.
**Expected B:**
* The time-based action doesn't match.
* The default reward and email apply instead.
Tiered reward selection
**Goal:**
* Confirm the correct reward tier is selected based on purchase amount.
**Rule setup:**
* Trigger: Friend makes a purchase.
* Action: Tiered Reward and Email to Advocate.
* At least three reward tiers by purchase-amount range (for example, a low, mid, and high tier).
**Test inputs:**
* Run once per tier.
* Enter a purchase amount that falls inside each tier's range.
* Keep every other input the same across runs.
**Expected result:**
* Each run shows the reward configured for the tier its amount falls into, not a different tier's reward.
Segment-gated eligibility
**Goal:**
* Confirm a segment condition controls whether the rule applies.
**Rule setup:**
* Trigger: Friend makes a purchase.
* A condition requiring the Advocate to be in a specific segment.
* Ideally, a default action for everyone else.
**Run A (match):**
* Set the Advocate's segment to the eligible one.
**Expected A:**
* The eligible action applies.
* The default is skipped.
**Run B (non-match):**
* Set the Advocate's segment to an ineligible one.
**Expected B:**
* The default action applies if one is configured.
* If not, no qualifying action fires at all.
Commission calculation
**Goal:**
* Confirm a commission reward is calculated from the purchase amount and shown in the right currency.
**Rule setup:**
* Trigger: Friend makes a purchase.
* Action: Reward and Email to Advocate.
* A commission-based reward — a percentage of the purchase amount — in the transaction's currency.
**Run A and B:**
* Two different purchase amounts, same currency.
**Expected A and B:**
* Each shows the commission rate applied correctly to that amount.
**Run C (if your program supports multiple currencies):**
* The same amount as Run A, but a different currency.
**Expected C:**
* The commission is calculated correctly and shown in the new currency.
* This isolates currency handling from the amount calculation.
No-match with no default configured
**Goal:**
* Confirm the preview clearly shows no action when nothing matches and there's no fallback.
**Rule setup:**
* A time-based action with no default action configured.
**Test inputs:**
* Set the referral started date outside the time window.
**Expected result:**
* No time-window match.
* No default fallback available.
* The preview clearly shows no qualifying action will occur.
No-match from an unmet rule condition
**Goal:**
* Confirm the preview shows no action when a rule's own conditions aren't met — not just a time window.
**Rule setup:**
* A rule with two conditions on the triggering event: a specific purchase event, and a minimum purchase amount.
**Test inputs:**
* Enter a purchase event that doesn't match, an amount below the minimum, or both.
**Expected result:**
* No rule condition is matched.
* The preview clearly shows nothing will happen.
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.impact.com/brand/what-would-you-like-to-learn-about/advocate-program/advocate-program-settings/test-your-advocate-program.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.