> 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/concepts/scenarios-and-campaigns.md). # Scenarios and campaigns How Amply separates the product thinking ("what flow should this user get?") from the operational unit you configure in the dashboard ("this campaign, live today, for these users"). ## Scenario — the user flow you want to orchestrate A scenario is the product-level outcome you are trying to produce. It describes what should happen to a user across time: * A new install from a paid ad lands on an onboarding variant matched to the ad. * A user finishes their trial and gets a recovery offer on the next cold open. * A returning user who hasn't opened the app in 10 days gets a winback prompt. Scenarios are how PMs and growth managers think about the work. They have a start, a middle, an end, and a reason. They usually involve more than one thing happening in sequence. Amply does not store a "scenario" object. The scenario lives in your head, in the spec, and on the whiteboard. The dashboard stores the pieces that deliver it. ## Campaign — the primitive you configure in the dashboard A campaign is the unit of delivery. One campaign produces one user-visible outcome (a deeplink opens, the native rate prompt appears) under one set of conditions. A scenario is built from one or more campaigns working together. Every campaign has three parts: * **Who** — targeting conditions that restrict which users are eligible (attributes like country, OS version, app version, install date, custom properties you set on the user). * **When** — a triggering event plus frequency rules (how often, how many times). * **What** — the action to perform when the campaign fires (open a deeplink, show the native rate prompt). See [Targeting and audiences](/concepts/targeting-and-audiences.md) for the Who, [Campaign delivery](/concepts/campaign-delivery.md) for the When, and [Campaign actions](/concepts/campaign-actions.md) for the What. ## Campaign lifecycle A campaign moves between three states: | State | Meaning | | ------ | -------------------------------------------------------------------------------------------------------------- | | Draft | The campaign exists in the dashboard but is not delivered to any device. Use this while you are still editing. | | Active | The campaign is live. Eligible users will see it when its trigger fires. | | Cancel | The campaign is retired. It no longer evaluates on device. | State changes propagate to the SDK on its next configuration fetch. Because campaigns are evaluated from a server-delivered configuration, flipping a campaign to Cancel stops it for every user on their next refresh — no app release needed. See [Campaign delivery](/concepts/campaign-delivery.md) for the delivery model. ## How campaigns compose into scenarios A scenario is usually not one campaign. It's a handful of campaigns that share audience, track the same signals, and hand off to each other. Example — post-trial recovery scenario: * **Campaign A** detects trial end (triggered by a custom `TrialEnded` event you track) and deeplinks the user to a recovery offer screen on their next session start. * **Campaign B** targets the same users 48 hours later, triggered by `SessionStarted`, and routes to a second, softer offer. * **Campaign C** prompts for an app rating once the user has converted (triggered by `SubscriptionActivated`). Each campaign is simple. The scenario is the pattern across them. ## When to add another campaign vs. widen an existing one Split a campaign when the audience, trigger, or action changes. Keep it as one campaign when you only want to vary volume or cadence. * Two audiences receiving the same deeplink → one campaign, broad targeting. * Same audience receiving different deeplinks depending on a property → two campaigns. * Same audience and deeplink, but one should fire on session start and the other on a custom event → two campaigns. ## Campaign types Amply supports a small, fixed set of campaign types, each producing a specific user-visible action: * **DeepLink campaign** — opens a URL on the device. Route the user to a screen inside your app, or to an external URL. See [Campaign actions](/concepts/campaign-actions.md). * **RateReview campaign** — presents the platform's native rating prompt (App Store, Google Play). > **On naming.** This documentation uses `DeepLink` and `RateReview` when talking about campaign types as an abstract concept. The dashboard UI labels the same types as **Deep Link** and **Rate & Review** on buttons and tabs. Both refer to the exact same thing. ## Related * [Targeting and audiences](/concepts/targeting-and-audiences.md) — how the "Who" is built * [Campaign delivery](/concepts/campaign-delivery.md) — how the "When" is built and how rollout works * [Campaign actions](/concepts/campaign-actions.md) — the "What" actions * [Creating a campaign](/user-guide/creating-a-campaign.md) — step-by-step how-to in the dashboard * [Testing and rollout](/user-guide/testing-and-rollout.md) — how to take a campaign from Draft to Active safely --- # 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: ``` GET https://docs.amply.tools/concepts/scenarios-and-campaigns.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.