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.

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.

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 — testing deeplink campaigns specifically.

• Rate & Review flows — testing native review prompts.

• Custom popups — testing popup content.

• Testing your integration — the engineer-side checklist.