Understanding Selection Rules and Audiences

Overview

This document explains how Selection Rules and Audiences work in Redpoint Interaction (RPI) and their role in Segmentation and Activation to identify, refine, and operationalize audiences. It covers the logical model, core components, execution behavior, and integration from data to activation.

At a high level, Redpoint audience selection follows a layered, composable model:

1. Data Foundation: Unified customer data (Golden Record) and related entity data

2. Selection Rules: Atomic logic that defines who qualifies

3. Audience Definitions: Combinations of selection rules and set logic

4. Execution Context: When, how, and against which population logic is evaluated

5. Activation: Use of audiences in workflows, exports, personalization, and orchestration

Each layer builds on the previous one, allowing audience logic to remain modular, explainable, and reusable.

Data foundation (what selection operates on)

Selection rules always evaluate persisted data available to Redpoint at runtime. This typically includes:

• Customer / person Golden Record

• Household, account, or other identity levels

• Transactional / behavioral tables (orders, web events, responses)

• Derived attributes (scores, flags, aggregates)

• Reference / lookup data

Key principles:

• Selection logic does not manipulate data — it filters and qualifies existing records

• All rules execute against a defined primary entity (usually Customer)

• Cross-entity logic is resolved through joins and relationship paths

Selection Rules (atomic qualification logic)

What a Selection Rule is

A Selection Rule is a named definition that answers the question: Does this entity meet a specific business condition?

Selection rules are the smallest logical building blocks used for segmentation.

Selection Rules come in two forms, and the distinction matters for how they behave as described later in this document:

• Reusable rules: Built and saved once as an independent, named object, then referenced from any number of Audiences or other rules. This is the form most of this document describes.

• Inline rules: A one-off condition built directly into a single rule or audience, not saved as its own reusable object, and not available anywhere else.

If you need a condition to be shared and centrally maintained across multiple audiences, build it as a reusable rule. If it's a one-time, single-use condition, inline is fine — just know it won't propagate anywhere (refer to Governance, below).

Characteristics

• Evaluates to TRUE / FALSE for each entity

• Can reference:

  • Attributes (demographics, flags, scores)

  • Events or transactions (exists, counts, sums, dates)

  • Related entities (orders, households, devices, etc.)

• Can be parameterized (dates, thresholds, lookback windows)

Common rule types

• Attribute-based (e.g., age ≥ 30)

• Behavioral (e.g., purchased in last 90 days)

• Aggregated (e.g., lifetime spend > $500)

• Relational (e.g., any household member is VIP)

• Exclusionary (e.g., has NOT opted out)

Execution behavior

• Rules are evaluated dynamically at runtime

• Results are not persisted unless explicitly materialized via a workflow, a validation export, or a backfill export (refer to Performance Considerations, below)

• Rule logic is independent of activation context

Audiences (composed logic)

What an Audience is

An Audience is a logical container that combines one or more Selection Rules using Boolean logic to define a population. Selection Rules define conditions → Audiences define sets of people.

Logical composition

Audiences support:

• AND / OR logic

• Nested groupings

• Exclusions (NOT logic)

Example:

(Age ≥ 30 AND Purchased in last 90 days)
AND NOT (Opted Out)

Audience scope

Each audience is evaluated at a specific level: which table is the driving population and which key identifies a record at that level (e.g., an environment might define levels such as individual/customer, household, or account). These levels aren't fixed, built-in options; each environment's administrators define the specific levels available and what they map to, so the exact choices vary by client.

The scope determines:

• Which table is the driving population

• How joins and aggregations are resolved

Segmentation vs. activation context

Segmentation (who qualifies)

Segmentation answers: Who meets these conditions right now?

• Uses selection rules and audience definitions

• Focused on logical qualification

• Can be executed ad hoc or scheduled

• May produce:

  • Preview counts (via a bounded-time "test" run of the audience)

  • Sample records

  • Materialized segment outputs (e.g., a validation export for reviewing output before it's used, or a backfill export for filling in historical/missed deliveries)

Activation (how audiences are used)

Activation answers: What do we do with the people who qualify?

Audiences are used downstream in:

• Campaign workflows

• Channel execution (email, push, paid media, etc.)

• Exports and data shares

• Personalization and decisioning

The same audience can be reused across multiple activations without redefining logic.

Execution model

Runtime evaluation

When an audience is used:

1. Redpoint resolves the base population

2. Each selection rule is evaluated

3. Boolean logic is applied

4. Final qualifying set is produced

Key points:

• The audience and its selection rules are reloaded to their latest saved version and evaluated fresh at execution time; there's no stale, pinned-at-save-time copy used.

• Results reflect the current state of data.

• This "always fresh" guarantee is about the audience/rule logic itself. The supporting configuration an audience depends on (audience definitions, levels, attribute definitions, channel/integration setup) is refreshed on a short background interval rather than instantaneously: typically low single-digit seconds up to a couple of minutes, occasionally longer for a full rebuild. In practice this is not noticeable for normal use, but it means "no caching, ever, anywhere" isn't quite accurate; it's "no caching you need to configure or manage," which was the original intent of this section.

Performance considerations

• Rule selectivity matters (broad → narrow is optimal)

• Aggregations and lookbacks drive cost

• Materialization may be used for:

  • High reuse

  • Large volumes

  • Downstream latency requirements

• Concretely, RPI offers two admin-enabled materialization mechanisms per audience:

  • A validation export, for reviewing what an audience would produce before it's relied on.

  • A backfill export, for producing historical/catch-up output outside the normal run schedule.

Reuse, governance, and maintainability

Reusability

• Reusable selection rules are designed to be:

  • Business-readable

  • Shared across teams

  • Used in many audiences

Governance

• Naming standards clarify intent

• Central rule libraries reduce duplication

• Changes to a reusable rule automatically propagate to every audience that references it; you don't need to re-save or republish the dependent audiences, the next run simply picks up the latest saved version of the rule. This does not apply to an inline rule built directly into a single audience — that kind of condition only changes where it lives, because nothing else references it.

Explainability

• Audiences are explainable because:

  • Logic is explicit

  • Rules are discrete and named

  • Execution is deterministic

Putting it all together

Selection Rules define conditions → Audiences define populations → Segmentation determines who qualifies → Activation determines what happens next.

This separation of concerns allows RPI to support:

• Scalable audience management

• Consistent activation across channels

• Clear governance and reuse

• Real-time and batch execution models

Summary

• Selection rules are atomic logic units, either reusable (shared, centrally maintained) or inline (single-use)

• Audiences compose rules into meaningful populations

• Segmentation evaluates qualification

• Activation operationalizes the result

• All logic executes dynamically against unified data — the audience/rule logic is always fresh; supporting configuration refreshes on a short interval rather than instantly

• Editing a reusable rule automatically updates every audience that references it; an inline rule only changes where it lives

This model enables flexible, enterprise-grade audience strategy without sacrificing clarity or control.

Additional resources

• Standard Selection Rules

• Basic Selection Rules

• Audience Designer

• Offer Designer