> For the complete documentation index, see [llms.txt](https://docs.amply.tools/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amply.tools/user-guide/testing-and-rollout.md).

# Testing and rollout

Every campaign change goes live the moment you save it and move the campaign to **Active**. There is no app release, no review window, and no store approval. That release-free control is what Amply's orchestration is for — and it's also why you need a testing routine. This page covers how to validate a campaign in staging, how to stage the rollout yourself using audience targeting, and how to pull a campaign instantly if something is wrong.

**Use this when** you are about to publish a campaign to real users, or a live campaign is misbehaving. **Don't use this when** you are still iterating on the rule design and haven't yet decided what to validate.

{% hint style="info" %}
Amply has no staging/QA state — the safest test is an Active campaign with an audience of one. Draft campaigns are not evaluated for live traffic.
{% endhint %}

## Why "no release required" matters

Changing in-app behavior normally means: code change → internal QA → store submission → store review (often days) → phased store rollout → users finally see the change. Amply skips all of that for anything you express as a campaign.

* **Change a trigger**: edit the **When** step, save. Users who start a session after the change use the new rules.
* **Change the audience**: edit the **Who** step, save.
* **Change the deeplink URL**: edit the **What** step, save.
* **Pull the campaign**: change state from **Active** to **Cancel**. New evaluations stop immediately.

The app code — the deeplink handler, the popup screen, the SDK — does not change. Only the rules the dashboard evaluates change.

## Phase 1 — Validate in staging before publishing

Only **Active** campaigns are evaluated. To test without exposing users, narrow the **Who** rules so the campaign matches only your test device, then move it to **Active**. Keep the narrow rules until you have verified behavior, then widen.

### Step 1: wire the staging build to the same project

Your mobile team runs a staging build that points at the same Amply project used for production. If they run a separate project for staging, make the test campaign in that project instead — and remember to re-create it in production after validation.

### Step 2: make yourself match the audience

The cleanest way to test: temporarily narrow the campaign to an audience that is only you.

* Set a **Custom Property** condition like `qa_tester == "your-name"` and set that property from the staging app.
* Or narrow by **Country**, **OS Version**, or **App Version** to a combination only your test device matches.

If the campaign will eventually target everyone, keep the narrow version Active until you have verified behavior, then widen the audience.

### Step 3: fire the trigger and confirm delivery

1. Ensure the campaign is **Active** while you test (Draft campaigns are skipped).
2. Fire the **Triggering event** by doing whatever action calls `Amply.track(...)` in the app, or by restarting the app if the trigger is `SessionStarted`.
3. Watch the deeplink listener (for Deep Link campaigns) or the native review sheet (for Rate & Review).
4. If nothing happens, check the campaign detail page for the trigger count — it increments when a match is recorded, regardless of whether the action visibly succeeded.

### Step 4: widen the audience and move to production use

Once behavior is correct:

1. Edit the **Who** step to the real production audience.
2. Save. The campaign is now targeting real users but still in Active state on your test device, so double-check once more.

### Troubleshooting

| Symptom                                                         | Likely cause                                                                                 |
| --------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| No trigger count increments                                     | Campaign is in **Draft**, or the triggering event name has a typo (they are case-sensitive). |
| Trigger count increments but nothing visible happens in the app | Deeplink handler not registered, or the URL scheme doesn't match what the app expects.       |
| Some users trigger but not others                               | Audience conditions exclude them. Check country, app version, and custom property filters.   |
| Campaign fires too often                                        | **Frequency Limits** not set or set too permissively.                                        |
| Campaign does not fire again for the same user                  | Frequency limit was hit. Increase the window or raise the cap.                               |

## Phase 2 — Control who sees it (phased rollout)

Amply does not ship a percentage-based rollout slider today. You get the same effect by widening the audience in steps.

1. **Start narrow.** When moving from Draft to Active, keep the **Who** targeting tight: one country, latest app version, maybe a specific custom property.
2. **Wait, then measure.** Check the campaign detail view for trigger counts and any downstream events (for example, post-popup `feedback_given`). Cross-reference with product analytics for any regression on the core KPIs.
3. **Widen.** Edit the **Who** step and remove one constraint (add more countries, drop the app-version filter). Save.
4. **Repeat** until the audience is what you want it to be.

Because edits to an Active campaign take effect within minutes, each widening step lands in minutes, not days.

## Instant rollback

If a live campaign is hurting users — wrong screen, broken deeplink, prompt firing too often — stop it immediately:

1. Open the campaign.
2. Change state from **Active** to **Cancel** (or use the state control on the list view).

From that moment on, the campaign stops matching and no new deliveries happen. Work that was already dispatched to an in-flight session may still complete, but nothing new starts.

A cancelled campaign stays in the list. You can fix the issue, then either:

* Return it to **Active** (same campaign, same ID, keeps historical counts), or
* Duplicate it into a new **Draft**, edit, validate, activate (use this if the fix is significant).

## Checklist before you move a campaign to Active

* [ ] The campaign ran end-to-end on a staging or real test device.
* [ ] The audience condition that narrowed it to you has been removed or broadened.
* [ ] **Frequency Limits** are set. At least one cap per device per time window.
* [ ] The deeplink URL or review-prompt behavior is what you expect.
* [ ] Someone else on the team knows the campaign is going live.

## Related

* [Managing deeplinks](/user-guide/managing-deeplinks.md) — testing deeplink campaigns specifically.
* [Rate & Review flows](/user-guide/rate-review-flows.md) — testing native review prompts.
* [Custom popups](/user-guide/custom-popups.md) — testing popup content.
* [Testing your integration](/developer-guide/testing-your-integration.md) — the engineer-side checklist.