> ## Documentation Index > Fetch the complete documentation index at: https://helium-mintlify-create-navigation-structure-42614.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Audiences > Segment users for targeted experiences An **audience** is a segment of your users defined by a set of rules. Audiences determine *who* sees what inside a workflow — you can route different user groups to different paywalls, experiments, or suppress the paywall entirely. Audiences are used through a workflow's **targeting criteria**, where each rule maps an audience to an action. They're the "who" to the workflow's "what." *** ### **Anatomy of an Audience** | Field | Description | | :-------------- | :------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | A human-readable label (e.g., "US Power Users"). Must be unique within your organization. | | **Description** | An optional note explaining the segment. | | **Rules** | A set of conditions that define which users belong to this audience. Rules use AND/OR logic across device, app, and custom user attributes. | *** ### **Rules and Conditions** An audience's rules define membership. Each rule tests a **variable** against a **value** using an **operator**. Rules are combined with **AND** or **OR** at the top level. #### Variables You can target on two categories of attributes: * **System variables** — Built-in device and app properties available for all users. Examples: * `locale.currentCountry `— The user's country * `deviceInfo.systemVersion` — OS version (supports semver comparisons) * `applicationInfo.version` — App version (supports semver comparisons) * `applicationInfo.heliumSdkVersion` — Helium SDK version * Device type, OS name, language, and more * **Custom user traits** — Properties you pass to the Helium SDK from your app (e.g., subscription\_tier, days\_since\_install, has\_completed\_onboarding). These are fully custom and scoped to your organization. #### Operators Available operators depend on the variable type: | Type | Operators | | :-------------------------- | :---------------------------------------- | | **String** | =, !=, exists, not exists | | **Number** | =, !=, >, \<, >=, \<=, exists, not exists | | **Boolean** | =, exists, not exists | | **Datetime** | >, \<, >=, \<=, exists, not exists | | **Semver** (app/OS version) | =, !=, >, \<, >=, \<=, exists, not exists | Multi-value selection is supported for `=` and `!=` on string variables (e.g., country is one of US, CA, GB). #### Example Rules * **US users on iOS 17+**: `locale.currentCountry = US AND deviceInfo.systemVersion >= 17.0` * **Power users**: `custom.days_since_install > 30 AND custom.sessions_count > 50` * **Non-subscribers**: `custom.subscription_tier not exists` *** ### **The "All Users" Audience** Helium has a special system audience called **All Users**. It matches every user unconditionally. * Stored as a real audience record with empty rules `({ operator: "AND", rules: [], isAllUsers: true })`. * Created automatically the first time you scope an experiment to "All Users." * Hidden from the standard audiences list — it only appears when selecting audiences for experiments or workflow targeting. * In analytics queries, it translates to no filtering. You don't need to create it manually. When you select "All Users" during experiment creation, Helium handles it for you. *** ### **Lifecycle of an Audience** Audiences can be created in several ways: * **From the Targeting page** — Use the audience builder with the full rule editor. * **From experiment creation** — The audience selector lets you create a new audience inline while setting up an A/B test. When creating an audience, names are validated for uniqueness (case-insensitive) and rules are stored in both a legacy format and JSON Logic format for compatibility. Once created, audiences are available in two places: * **Workflow targeting criteria** — Map an audience to a paywall, experiment, or "no paywall" action. Rules are evaluated in order; the first matching audience wins. * **Experiment scoping** — Scope an experiment to a specific audience so only matching users are enrolled. An audience can be used across multiple workflows and experiments simultaneously. Each audience shows real-time metrics computed from your analytics data: | Metric | Description | | :--------------------- | :------------------------------------------------------------------------------ | | **Unique users (7d)** | Distinct users matching this audience in the last 7 days. | | **Paywall opens (7d)** | Number of paywall open events from users in this audience over the last 7 days. | These metrics are computed on-demand from ClickHouse — they're not cached or pre-aggregated, so they reflect current data. During experiment creation, Helium shows an "estimated exposed users per day" based on these metrics to help you gauge experiment reach. You can update an audience's **name**, **description**, and **rules** at any time. Changes apply to all workflows and experiments referencing that audience. Keep in mind that changing rules alters who qualifies — if you narrow the rules, some users currently seeing a paywall may stop matching. An audience can only be deleted if it is **not currently referenced by any workflow's targeting criteria**. If it's in use, you'll need to remove it from the workflow first. Deletion is permanent. *** ### **Stripe Targeting Constraints** If a workflow or experiment includes paywalls with Stripe products, the audience must meet specific targeting requirements. "All Users" does **not** qualify for Stripe targeting because Stripe paywalls only work for a subset of users (Apple Pay enabled, US App Store). You'll need to create a more targeted audience that filters for eligible users. Helium validates this automatically and shows a warning if Stripe targeting constraints aren't met. *** ### **Integration with Workflows** Audiences connect to workflows through **targeting criteria** — an ordered list of rules on the workflow: 1. For each rule: "If the user is in **\[audience]**, then **\[show paywall / run experiment / show nothing]**." 2. Rules are evaluated top-to-bottom. The first matching audience determines the outcome. 3. Users who don't match any audience rule see the workflow's **control paywall**. This means audience order matters. A broad audience (like "All Users") placed first would catch everyone before more specific audiences get evaluated. *** ### **Key Rules** * Audience names are **unique per organization** (case-insensitive). * Rules use **AND/OR** logic with system variables and custom user traits. * The **"All Users"** audience is a system audience — it's created automatically and hidden from the standard list. * Audiences **cannot be deleted** while referenced by a workflow. * Metrics are computed **in real-time** from ClickHouse (7-day window). * Changes to audience rules take effect **immediately** across all workflows and experiments using that audience. * Audiences can be **AI-generated** from natural language descriptions. *** ### **Common Patterns** | Pattern | Description | | :---------------------- | :-------------------------------------------------------------------------------------------------------- | | **Country targeting** | locale.currentCountry = US — Show a US-specific paywall with USD pricing. | | **Version gating** | applicationInfo.version >= 3.0 — Only show a new paywall design to users on the latest app version. | | **New user onboarding** | custom.days\_since\_install \<= 3 — Aggressive trial offer for users in their first few days. | | **Power user upsell** | custom.sessions\_count > 50 AND custom.subscription\_tier not exists — Target engaged free users. | | **Platform split** | deviceInfo.osName = iOS vs. deviceInfo.osName = Android — Different paywall designs per platform. | | **All Users fallback** | Use the "All Users" audience as a catch-all at the bottom of targeting criteria for a default experience. | ***