> 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/targeting-an-audience.md).

# Targeting an audience

How to narrow a campaign from "everyone" down to the right slice of users, using the rule builder in the campaign form's **Who** step.

> Dashboard walkthrough. For the targeting model and the attributes you can target, see [Targeting and audiences](/concepts/targeting-and-audiences.md).

**Use this when** a campaign should only apply to some users — a country, an app version, users who installed recently, users who did (or never did) something in your app, or users who match a property you control. **Don't use this when** you want to control *when* a campaign fires (that's the **When** step and the triggering event) or *what* it shows (that's the **What** step).

## Where to find it

Audience rules live in the **Who** step of the campaign form:

1. Open a project → **Campaigns** → **New campaign** (or open an existing draft).
2. Fill in the name and type in step one.
3. On the **Who** step, start from **All users** and click **Add rule**.

Every rule you add narrows the audience. Multiple rules combine with **And** — a user must match all of them. There is no "or" between rules; if you need an either/or audience, make two separate campaigns.

## Rule types and operators

Each rule lives in its own card. Add, edit, or remove rules in any order.

| Rule                        | Operators                                                                              | Example                                           |
| --------------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------- |
| **Countries**               | include / exclude one or more countries                                                | Include **Germany, France, Spain**                |
| **OS Version**              | `=`, `!=`, `>`, `<`, `>=`, `<=`                                                        | `>=` `17` (iOS 17 and up). Add twice for a range. |
| **App Version**             | same as OS Version                                                                     | `>=` `4.2.0`                                      |
| **App Install Version**     | same as OS Version                                                                     | `>=` `3.0.0` and `<` `4.0.0` (twice)              |
| **Applications**            | include / exclude one or more applications in the project                              | Include the iOS build only                        |
| **Custom Property**         | depends on the value type — see below                                                  | `tier` `=` `premium`                              |
| **Install Date — absolute** | is, is before, is after                                                                | "is after 2026-01-01"                             |
| **Install Date — relative** | is less than N days, is more than N days                                               | "is less than 7 days"                             |
| **Event**                   | count of times done, first/last occurrence date, optional property filters — see below | `Purchase` at least **3** times                   |

Custom Property operators by value type:

| Type     | Operators                                           |
| -------- | --------------------------------------------------- |
| String   | `=`, `!=`, is set, is not set                       |
| Number   | `=`, `!=`, `>`, `<`, `>=`, `<=`, is set, is not set |
| Boolean  | `=`, `!=`, is set, is not set                       |
| DateTime | is, is before, is after, is set, is not set         |

**Is set** and **is not set** check whether the property exists on the user at all — they don't need a value. Property keys are suggested from what the SDK has reported for this project; pick from the dropdown to avoid typos.

## Adding an Event condition

Target users by what they have done in your app — how often, and when.

{% hint style="info" %}
Event conditions require apps built with SDK 0.6.1 or later. On older app builds, a campaign that uses an Event condition never matches — it fails safely and silently.
{% endhint %}

![Event conditions in the Who step: counts, occurrence dates, and property filters](/files/8iMAizsJDkkEM6tNubkz)

1. On the **Who** step, click **Add rule** and choose **Event**.
2. Pick the event — for example `Purchase` or `WorkoutCompleted`.
3. Choose what to check:
   * **How many times** — exactly / not exactly / more than / fewer than / at least / at most **N** times, or simply **has happened (ever)** / **has never happened**. Counts cover the lifetime of the install.
   * **First occurrence** or **Last occurrence** — relative ("more than **14** days ago", with an "…or never" variant that also matches users who never did it; "within the last **7** days") or absolute ("before" / "after" a date). Absolute dates cover whole calendar days (UTC); relative days are rolling 24-hour windows, not calendar days.
4. Optionally add **property filters** — type a key and value, compared with equals or not equals (number values also support greater / less). `Purchase` with `product` equals `pro` counts only pro purchases: occurrences that don't match the filters are ignored for both the count and the first/last dates.

Like every other rule, Event conditions combine with **And**, are evaluated live on the device, and work offline. Event history starts when the app is installed. A campaign can have up to 20 Event conditions.

## Worked examples

### Paying users on iOS 17+ in Germany

1. **Custom Property** — `subscription_status` `=` `active`
2. **Countries** — include **Germany**
3. **OS Version** — `>=` `17` (and consider filtering by application for iOS-only)

### New users on the latest app version

1. **Install Date** — is less than **14** days ago
2. **App Version** — `>=` `5.0.0`

### Everyone except early adopters on old builds

1. **App Install Version** — `>=` `4.0.0`
2. **App Version** — `>=` `5.0.0`

### Power users with a specific flag

1. **Custom Property** — `lifetime_purchases` `>=` `5`
2. **Custom Property** — `beta_opt_in` is set

### Win back lapsed workout loggers

1. **Event** — last `WorkoutCompleted` occurrence more than **14** days ago
2. **Install Date** — is more than **30** days ago (so brand-new users don't get a win-back message)

### Repeat pro buyers

1. **Event** — `Purchase` at least **3** times, with property filter `product` `=` `pro`

## Tips

* **Start broader than you think.** A too-narrow audience that matches almost nobody looks the same as a broken campaign. Widen, confirm it fires, then tighten.
* **Name custom properties consistently.** Amply's convention is `snake_case` for property keys (and `PascalCase` for event names). The dropdown shows exactly what the SDK reported — match whatever your developer set up.
* **If a property isn't in the dropdown,** the SDK hasn't sent it yet from any device in this project. Trigger it on a test device first.
* **Country rules use device region, not IP.** A user travelling abroad still counts as their device's region.
* **Install date reflects the first install Amply saw.** Uninstall and reinstall resets it.

## Related

* [Targeting and audiences (concepts)](/concepts/targeting-and-audiences.md) — the model behind rules and attributes
* [Creating a campaign](/user-guide/creating-a-campaign.md) — full walk-through of the campaign form
* [Sessions and events](/user-guide/sessions-and-events.md) — confirm your custom property is arriving
* [User attributes](/developer-guide/user-attributes.md) — how developers set custom properties from the SDK