Overview
Redpoint Interaction (RPI) Selection Rules determine how audience data is filtered and selected for various marketing efforts, including campaigns, segments, and downstream activities. Understanding selection rules helps you to effectively target audiences and optimize outreach strategies.
There are two types of selection rules available within RPI, each tailored to meet different needs in terms of complexity and reusability, and both are created and edited in the Selection Rule designer.
-
Basic Selection Rules (BSR): These rules are designed to be lightweight and reusable, making them ideal for simpler audience filtering tasks. BSRs allow you to quickly define criteria for audience selection without the need for extensive configuration. This simplicity enables rapid deployment and adjustments, ensuring that campaigns can be launched in a timely manner while still maintaining a level of precision in targeting.
-
Standard Selection Rules (SSR): In contrast, SSRs offer a more advanced approach to audience definitions. These rules are optimized for complex filtering scenarios and provide greater flexibility in how audience data is accessed and utilized. SSRs enable you to create sophisticated audience segments that can be fine-tuned to meet specific campaign objectives, thereby enhancing the overall effectiveness of marketing efforts.
While both BSRs and SSRs serve the fundamental purpose of audience filtering, they differ significantly in terms of flexibility, data access, and functional capabilities. BSRs are best suited for straightforward tasks where speed and efficiency are the priority, while SSRs are ideal for campaigns that require a deeper level of analysis and customization.
Basic Selection Rules (BSR)
Basic Selection Rules are designed for simple, reusable filtering logic. They typically represent stable, business-defined subsets of your audience that can be leveraged across multiple campaigns or workflows.
Key characteristics
|
Feature |
Description |
|---|---|
|
Complexity |
Simple and reusable; optimized for fast evaluation. |
|
Attribute Access |
Attribute choices are constrained to what's modeled in the connected database definition's catalog. |
|
Embedding |
Can embed other BSRs that have been built on the same database definition. |
|
Conversion |
Can be converted to a SSR if additional complexity or flexibility is required. This conversion is one-way; SSRs cannot be converted back to BSRs. |
|
AI Integration |
Supports GenAI for rule generation and refinement, enabling automated creation of logical conditions. This is currently a BSR–only capability. |
|
Contact Rules |
Supports per-rule Contact Rules to control eligibility or frequency. There is also a separate, database-definition-level contact rule that is automatically applied to every BSR built on that definition (this could result in a segment that looks smaller than the rule's visible criteria would suggest). |
|
Include/Exclude Logic |
Implements Include/Exclude via operators (e.g., "is not equal to," "does not contain") rather than explicit record lists. |
|
Logic Construction |
Supports AND/OR logic, applied per rule level; combining AND and OR in the same rule requires nested sub-groups rather than toggling per condition. |
|
Execution Context |
Can run in Realtime Mode, ideal for immediate lookups or triggered interactions. This is currently a BSR–only capability. |
Use cases
-
Define reusable filters such as "Active Subscribers", "Opted-In Contacts", or "Customers with Email Addresses."
-
Provide a foundational data subset for campaign-level targeting.
-
Apply simple, reusable business rules across multiple programs.
Example
Basic Selection Rule: Customers who are active, have provided an email address, and have not opted out.
WHERE CustomerStatus = 'Active'
AND EmailAddress IS NOT NULL
AND OptOutFlag = 0
Standard Selection Rules (SSR)
SSRs are the advanced, flexible variant. They enable data engineers and campaign users to define complex, multi-source audience criteria, leveraging advanced logic, joins, and SQL expressions.
Key characteristics
|
Feature |
Description |
|---|---|
|
Complexity |
Advanced — allows multiple joins, nested logic, and user-defined SQL. |
|
Attribute Access |
Full access to the underlying database schema, not limited to a curated attribute catalog the way Basic Selection Rules are. |
|
Embedding |
Can embed any Selection Rule, including BSRs. |
|
Custom SQL |
Supports Custom SQL blocks for direct query manipulation or advanced logic injection. BSRs have no equivalent. |
|
Include/Exclude Logic |
Supports explicit Include/Exclude of specific records or lists, a more granular mechanism than the operator-based approach in BSRs. |
|
Custom Resolution |
Can override the default resolution table/key used to identify or de-duplicate records for this rule. BSRs have no equivalent. |
|
Grouping Logic |
Enables grouped AND/OR condition logic for complex nested criteria, more granular than the single AND/OR mode used per level in BSRs. |
|
Traceability |
General query trace/debug tooling is available in the product for reviewing selection logic. |
Use cases
-
Multi-table joins across customer, transaction, and behavioral data.
-
Complex segment creation requiring dynamic expressions or data-driven inclusion/exclusion.
-
Advanced campaign entry logic that blends multiple BSRs with event or transactional data.
Example
Standard Selection Rule: Customers who purchased in the last 90 days and engaged with the "Spring Promo" campaign.
SELECT DISTINCT c.CustomerKey
FROM Customer c
JOIN Transaction t ON c.CustomerKey = t.CustomerKey
JOIN Event e ON c.CustomerKey = e.CustomerKey
WHERE t.TransactionDate >= DATEADD(DAY, -90, GETDATE())
AND e.CampaignName = 'Spring Promo'
Comparative summary
|
Feature |
Basic Selection Rule (BSR) |
Standard Selection Rule (SSR) |
|---|---|---|
|
Complexity |
Simple |
Advanced |
|
Attribute Access |
Limited to the database definition's modeled attribute catalog |
Full access to the underlying database schema |
|
Embedding |
Embed BSR (same database definition only) |
Embed any Selection Rule (including BSR) |
|
Custom SQL |
Not supported |
Supported |
|
Trace / Debug |
Standard preview only |
General query trace/debug tooling available |
|
Include/Exclude |
Via operators |
Explicit include/exclude of records or lists |
|
Custom Resolution / Key |
Not supported |
Custom Resolution Table/Key override |
|
Logic Control |
One AND/OR mode per rule level; nested sub-groups for mixed logic |
Grouped AND/OR per criterion |
|
AI / GenAI Support |
Supported for rule generation/refinement |
Not supported |
|
Realtime Mode |
Supported |
Not applicable |
|
Convertibility |
Can be converted to SSR (one-way) |
N/A |
|
Typical Use Case |
Reusable audience filters |
Advanced, campaign-specific audience logic |
Best practices
-
Leverage BSRs for stability and reusability: Use BSRs as the foundation for stable, reusable logic that applies broadly across multiple campaigns and audiences. Parameterize your BSRs whenever possible to maximize reusability and streamline operational efficiency.
-
Apply SSRs for advanced customization: Use SSRs when you require advanced SQL joins, custom logic, or explicit control over inclusion/exclusion and resolution logic. SSRs are preferable for scenarios where campaign requirements exceed the capabilities of BSRs, such as when integrating multi-dimensional data inputs (behavioral, demographic, transactional, contextual) or when highly granular audience targeting is needed. Limit unnecessary joins or data expansions to optimize performance, and leverage pre-aggregated tables where possible.
-
Combine Basic and Standard Selection Rules for precision: Adopt a layered approach by applying a BSR as your foundational eligibility filter, then refining your audience with a SSR for campaign-specific logic. This method ensures that broad eligibility criteria are enforced consistently, while allowing for campaign-specific refinements and exclusions. This combination supports both operational efficiency and campaign precision.
-
Document rule logic and maintain transparency: For every Basic and Standard Selection Rule, add clear descriptions and version comments within each rule. Maintain comprehensive documentation and audit trails for all segments and selection rules.
-
Validate and iterate on segments: Before launching campaigns, validate your segments using audience snapshots and seeds to ensure alignment with intended demographics. Regularly iterate and refresh your segments as new data becomes available to keep targeting relevant and effective.
-
Optimize for performance and scalability: Limit complex joins and data expansions in SSRs to avoid performance bottlenecks. Where possible, use pre-aggregated or indexed tables to accelerate rule execution. Monitor campaign performance metrics and adjust rules as needed to improve results.
-
Ensure compliance and data privacy: Ensure your audience rules and campaign logic comply with relevant data privacy regulations (e.g., GDPR, CCPA). Obtain explicit consent where required, provide easy opt-out options, and handle personal data responsibly and transparently.
-
Align with business and marketing objectives: Customize your rule logic to align with specific business goals, marketing strategies, and compliance mandates. Whether focusing on individual records or households, ensure your unification and segmentation strategies support broader organizational aims.
Example workflow
|
Step |
Rule type |
Description |
|---|---|---|
|
Eligibility definition |
BSR |
Defines "Active Customers" across all brands. |
|
Campaign targeting |
SSR |
Refines to customers who made a purchase in the last 90 days. |
|
Channel filtering |
Contact Rules (within BSR) |
Ensures compliance with contact frequency limits. |
Summary
BSRs are designed to be reusable and efficient, operating under the governance of the connected database's modeled attribute catalog. They can be consistently applied across various marketing scenarios, streamlining processes and enhancing performance. BSRs also uniquely support GenAI-assisted rule generation and Realtime Mode evaluation.
SSRs offer a more advanced and flexible approach. They are specifically crafted to accommodate deep, campaign-specific logic, including custom SQL, explicit include/exclude lists, and custom resolution overrides, allowing you to tailor your strategies to meet campaign objectives.
Together, these two types of selection rules allow you to strike a balance between performance, reusability, and data flexibility.