How to measure campaign success
The metrics, thresholds, and testing rules to apply to every campaign.
Table of Contents
Every campaign should ship with three things: an experiment design, a primary metric, and a brand anchor. This isn't optional — don't launch a campaign without them. This article walks through the measurement framework, and how to design tests.
The Appcues App is in beta and rolling out gradually. If you don't see it yet at app.appcues.com, it hasn't been enabled for your account. See Introducing the Appcues App for more.
What the campaign builder can help create today: in-product experiences (Flows, Pins, Embeds, Checklists, Launchpads, Banners). Email, push, and Workflows aren’t part of the initial campaign product or Appcues AI building capabilities yet — where this article mentions them, treat them as a manual, separate setup, not something the AI can build for you.
Metric selection, in order
Follow this order:
- Start with your own metric, if you have one. If you have a defined success metric for the campaign, use it.
- If you don't have one, use a default from the stage-appropriate table below, with a 5–10 percentage point tolerance — if you're within that range of the benchmark, the campaign is working and you iterate from there.
- Always pair completion with a downstream-action Key Action. Never report completion rate alone.
Why completion rate isn't a success metric
A Flow can have an 80% completion rate and drive only three signups against a target of hundreds. Completion tells you whether users clicked through — it doesn't tell you whether they took the action that matters.
Always pair completion with a Goal that tracks the actual downstream behavior. On any A/B test, make sure both variants track the same Goal so you're comparing outcomes, not just engagement.
Default metrics by stage
| Stage | Leading indicators | Working threshold |
|---|---|---|
| Awareness | Open rates, clicks, page visits | 15% exposure-to-completion floor for clickable experiences |
| Activation | Activation rate (your definition) | 15% completion of the targeted action; iterate below |
| Adoption | Daily/weekly usage of the activated feature | 30%+ retained at week 2 |
| Re-engagement | Return rate from email or in-product nudge | 10%+ return within 7 days |
| Expansion | Handraise rate or feature-trial rate | 5%+ of targeted users |
The adoption, re-engagement, and expansion thresholds are starting points, not industry benchmarks — adjust based on your product's specifics and your historical data.
Each stage also ladders up to a business outcome — and that outcome usually lives outside Appcues:
| Stage | Business outcome to pair with | Where it's usually measured |
|---|---|---|
| Activation | Time to Value, Activation Rate | Product analytics |
| Adoption | Feature Adoption Rate | Product analytics |
| Retention | Churn Rate, Retention Rate | CRM or billing |
| Expansion | Expansion revenue by segment | CRM or billing |
Appcues measures exposure, completion, and Goal conversion. It doesn't directly track revenue, churn, or account health — those live in your CRM, billing system, or product analytics. Pair your Appcues-side metrics with that outcome data to show the full impact, and don't assume a metric is provable in Appcues alone just because a campaign influences it.
The 15% floor
Use 15% exposure-to-completion as the floor for "is this experience working at all." Below 15%, iterate before anything else. Above 15%, look at the downstream Key Action to determine actual success. The benchmark for completion itself is roughly 32% — use this as a reference point when your own data is thin.
When to run a test
Don't default to A/B testing everything. Run a test when:
- The audience is large enough. Any sub-segment in the test needs at least 150 users for the results to be readable. Below that, pick your best option, ship it, and learn from production data.
- There's genuine ambiguity. If you have a high-confidence choice, ship it instead of burning a test slot on something obvious. Tests are for real unknowns — different copy approaches, different experience types, different levels of interruption.
- You can measure it. Don't ship a test you can't evaluate rigorously.
How to design tests
- Variant construction: Duplicate-and-edit the existing experience, tied to the same campaign as a different variant. Don't build tests as separate campaigns.
- Key Action or Goal alignment: Every variant tracks the same Key Action or Goal. Outcomes, not just engagement, drive the decision.
- Traffic split: 50/50 for two variants, 33/33/33 for three.
- Duration: 3-week ceiling as a default. Check at day 3–5 — if the data is conclusive early, iterate; if it's still noisy, let it run.
- Alert: Set up a check-in window a few days into the test so you can review direction.
Example: Modal vs. no Modal
A common test to consider for an onboarding campaign:
| Variable | Setting |
|---|---|
| Control | 4-step Flow starting with a Modal, then 3 Tooltips. Modal asks the user to enter the tour via CTA. |
| Treatment | Remove the Modal, jump straight into Tooltips. Auto-decide for the user. |
| Traffic split | 50/50 |
| Goal | Same Goal on both — has the user completed the target action within 3 days of seeing either Flow |
| Duration | 3 weeks max; alert at day 3–5 |
The question this answers: does giving users a choice to enter the tour improve or hurt the downstream action?
Measurement mistakes to avoid
- No primary metric defined. The most common failure. Don't let a campaign ship without one.
- Vanity metrics treated as success. Exposure rate alone is vanity — it needs to be paired with completion and a downstream outcome.
- Measuring at the wrong stage. Adoption metrics on an awareness experience, or awareness metrics on an expansion campaign.
- Static list segments in tests. CSV-based segments age immediately — use dynamic behavioral segments for test targeting instead.