Audience Builder Reference Beta

This page covers the Audience Builder’s condition types, operators, and system limits.

For a step-by-step walkthrough on creating an audience, see How to Create an Audience from a Data Graph.

Condition types

The Audience Builder supports four condition types. You can combine any of them freely using AND/OR logic.

Properties (attribute conditions)

Use the Properties tab to filter on columns of the base entity directly.

Example: “Customers with lifetime_value >= 5000.”

The operators available depend on the column’s data type. See the Operator reference below.

Relations (related-entity conditions)

Use the Relations tab to filter the base entity by the existence or aggregate of its related records.

Examples:

• “Customers belonging to a Corporate account.” (single-hop, many:1)
• “Customers who placed at least 3 orders in the last 90 days.” (single-hop, 1:many, count aggregate + time window)
• “Customers whose total spend at Flagship stores in the last 90 days is over $1,000.” (two-hop: Customers → Sales → Stores, with sum aggregate and a condition on the final node)

Relationship conditions combine:

• A path of one or two relationship hops
• An optional condition on the final entity (for example, store_type = "Flagship")
• Either a quantifier (any / all / none) or an aggregate (count, sum, avg, min, max), or both
• An optional time window (applies when the related entity is an event model)

Events (behavioral conditions)

Use the Events tab to filter on timestamped event tables, for example, Customer Interactions, Purchase, or Loyalty Points. Events use the same structure as relationships but also let you set a time window.

Example: “Customers who had 3 or more Add to Cart interactions in the last 7 days that were not converted to a purchase.”

The following time-window modes are supported:

Audiences (composition and exclusion)

Use the Audiences tab to reference saved audiences that share the same base entity. This is useful for:

• Reusable building blocks: Create a “VIP Members” audience once and reuse it across many audiences.
• Exclusion lists: Prevent over-messaging with not in "Recently Contacted".

Example: “High-LTV customers who are not in the New Customer Welcome audience.”

Combine conditions with AND / OR

• By default, conditions inside a group are joined with AND
• Toggle a group to OR to match any condition instead of all
• Nest one group inside another for expressions, for example, (A AND B) OR (C AND D)

Operator reference

Audience expressions use a fixed set of operators. The operators available in each dropdown depend on the selected column’s data type.

inlast takes an interval and unit, for example “in the last 30 days” or “in the last 6 months”.

Aggregate comparison operators: You can compare COUNT, SUM, AVG, MIN, and MAX with eq, neq, gt, gte, lt, and lte.

Preview and size estimation

• Automatic preview: When you open a saved audience, RudderStack runs a preview automatically. It re-runs after every save.
• Manual preview: Use the Calculate size button to preview unsaved changes in the builder.
• Sampling: If your data team has enabled sampling in the Data Graph, the preview runs against a sample of the warehouse data for speed. The reported size is an estimate — RudderStack computes the exact membership at sync time.
• Sample members: Alongside the size, the preview also shows a sample of matching record IDs so you can sanity-check the definition.

Examples

The following examples are drawn from a typical ecommerce Data Graph where Customers is the base entity and is related to Accounts, Sales, Purchase, Customer Interactions, Products, and Stores.

High value customers

Customers with a lifetime value of 5,000 or more.

• Tab: Properties
• Condition: LIFETIME_VALUE >= 5000

Big spenders (last year)

Customers whose total sales exceeded $3,000 in the last year.

• Tab: Events (or Relations if Sales is modeled as an entity)
• Relationship: Customers → Sales
• Aggregate: SUM(TOTAL_AMOUNT) >= 3000
• Time window: In the last 365 days

Frequent buyers (last 90 days)

Customers who made 10 or more purchases in the last 90 days.

• Tab: Events
• Relationship: Customers → Sales
• Aggregate: COUNT(Sales) >= 10
• Time window: In the last 90 days

Churn risk: High value but lapsed

High-value customers who have not made a purchase in the last 90 days.

• Group 1 (Properties): LIFETIME_VALUE >= 500
• Group 2 (Events): Customers → Sales, quantifier none, time window in the last 90 days
• Combine with: AND

Engaged non-buyers, excluding win-back

Customers who are highly engaged but haven’t purchased and aren’t already being targeted by the win-back campaign.

• Events: Customer Interactions count >= 5 in the last 14 days
• Events: Loyalty Points count >= 1 in the last 30 days
• Events: Sales quantifier = none in the last 30 days
• Audiences: not in Win-Back Lapsed High-Value
• Combine with: AND

Current limitations

• Relationship hops: A relationship path can currently traverse up to 2 hops. Deeper traversal will be supported in a future release.
• Logical nesting: Expressions can nest AND/OR groups up to 2 levels deep.
• Predicates per audience: A single audience can contain up to 100 predicates (configurable per workspace).
• Audience reference depth: An audience can reference other audiences up to 2 levels deep.
• Time windows: Time windows apply only to event models. Entity relationships query across all time by default.
• Aggregates on multi-hop paths: Aggregates on a multi-hop relationship are flattened across the full path and are allowed only when the path contains a single 1:many edge.

FAQ

What’s the difference between a quantifier and an aggregate?

A quantifier answers a Yes/No question. For example, “do any matching related records exist?” (any, all, none).

An aggregate answers a numeric question. For example, “what’s the count/sum/avg/min/max across related records?”. Use a quantifier for existence, an aggregate for counting or summing.

Why is the size in the preview an estimate?

If your Data Graph has sampling enabled, the preview runs against a sample of the warehouse rather than the full table to keep response times fast. RudderStack computes the exact membership at sync time.