# Campaigns

The dashboard campaign reference: how the list view is organized, the per-type options each campaign exposes, and the When-step mechanics for repeat rules and frequency limits.

> Reference for the dashboard. For the model — what a campaign is, how it composes into a scenario, the lifecycle — see [Scenarios and campaigns](/concepts/scenarios-and-campaigns.md). For step-by-step creation, see [Creating a campaign](/user-guide/creating-a-campaign.md).

## The campaign list

Open **Campaigns** in a project. The list shows every campaign in any state and offers four filter tabs:

* **All**
* **Draft**
* **Active**
* **Cancel**

Open a campaign to view, edit, change state, or delete it. The new-campaign action is **New campaign** at the top right.

What you can do per state:

| State  | State-change button on the detail screen | Other actions |
| ------ | ---------------------------------------- | ------------- |
| Draft  | **Start campaign** (moves to Active)     | edit, delete  |
| Active | **Stop campaign** (moves to Cancel)      | edit          |
| Cancel | **Start campaign** (re-activates)        | edit, delete  |

A state change propagates to every device on the next configuration fetch — see [Campaign delivery](/concepts/campaign-delivery.md).

## Campaign types and their options

### Rate & Review

Prompts the user to rate your app using the platform's native review dialog — the App Store review prompt on iOS, the Play Store in-app review on Android.

Use it for:

* Asking satisfied users to leave a review after a positive moment (completing a purchase, finishing onboarding, earning an achievement).

Options the form exposes:

* **Who** — audience rules. See [Targeting an audience](/user-guide/targeting-an-audience.md).
* **When** — triggering event, optional event-parameter filters, repeat rules, frequency limits.
* No **What** step — the platform dialog is fixed.

Notes:

* On Android, the Play Store's in-app review API only produces a real prompt in release builds distributed through Play. Debug builds show a simulated dialog.
* The platforms cap how often the prompt actually shows, regardless of your repeat rules. Treat "asked" as best-effort.

### Deep Link

Opens a URL when the campaign fires. The URL can be:

* A standard `https://` link (opens in the browser or an in-app web view, depending on how the app handles it).
* A custom URL scheme (for example, `myapp://promo/spring`) handled by your app's deep-link code.

Use it for:

* Routing users into a specific in-app screen (paywall, offer, onboarding variant, feature tour).
* Sending users to a web destination (blog post, survey, support article).
* Triggering an in-app flow that's already wired up to a scheme your app owns.

Options the form exposes:

* **Who** — audience rules.
* **When** — triggering event, event parameters, repeat rules, frequency limits.
* **What** — the **DeepLink** URL to open.

For the URL to do anything useful, your app needs a deep-link handler registered via the SDK. See [Android integration](/developer-guide/android-integration.md) and [iOS integration](/developer-guide/ios-integration.md).

### Blocking

Marked **Soon** in the dashboard. Not available yet.

## The When step — repeat rules and frequency limits

Every campaign is triggered by an event. The When step lets you control how often a single user is eligible to see it, beyond the audience filter.

**Triggering Event.** Pick an event name — system events like `SessionStarted` or any custom event your app sends. Optionally filter by **event parameters** ("only when `screen_name` equals `paywall`").

**Repeat Rules.** How often the campaign is allowed to fire for one user:

* **every** N events — "every 3rd purchase".
* **on** the Nth event — "on the 1st purchase only".

Scope: **globally** (across sessions, across time) or **in session** (this session only).

**Frequency Limits.** Overall caps, independent of the repeat rules:

* Per **session** — at most N times in a single session.
* Per **device** — at most N times per device, optionally over a window (seconds, minutes, hours, or days).

A campaign that fires too often is almost always a repeat-rules or limits problem, not a targeting one.

## Choosing a type — quick table

| Goal                                               | Type                       |
| -------------------------------------------------- | -------------------------- |
| Ask users to rate the app                          | Rate & Review              |
| Open a paywall variant in-app                      | Deep Link (custom scheme)  |
| Send users to a web offer or survey                | Deep Link (`https://`)     |
| Route marketing cohorts into different onboardings | Deep Link (custom scheme)  |
| Block a flow until something happens               | (Blocking, when available) |

## Related

* [Scenarios and campaigns (concepts)](/concepts/scenarios-and-campaigns.md) — what a campaign is and how it fits a scenario
* [Creating a campaign](/user-guide/creating-a-campaign.md) — step-by-step walk-through
* [Targeting an audience](/user-guide/targeting-an-audience.md) — the Who step in depth
* [Sessions and events](/user-guide/sessions-and-events.md) — events the When step can listen for
* [Campaign delivery](/concepts/campaign-delivery.md) — how a campaign is evaluated


---

# Agent Instructions: 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/user-guide/campaigns.md?ask=<question>
```

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.