Data Subject Request API Version 1 and 2
Data Subject Request API Version 3
Key Management
Platform API Overview
Accounts
Apps
Audiences
Calculated Attributes
Data Points
Feeds
Field Transformations
Services
Users
Workspaces
Warehouse Sync API Overview
Warehouse Sync API Tutorial
Warehouse Sync API Reference
Data Mapping
Warehouse Sync SQL Reference
Warehouse Sync Troubleshooting Guide
ComposeID
Warehouse Sync API v2 Migration
Audit Logs API
Bulk Profile Deletion API Reference
Calculated Attributes Seeding API
Custom Access Roles API
Pixel Service
Profile API
Data Planning API
Group Identity API Reference
Events API
mParticle JSON Schema Reference
IDSync
AMP SDK
Initialization
Configuration
Network Security Configuration
Event Tracking
User Attributes
IDSync
Screen Events
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Push Notifications
WebView Integration
Logger
Preventing Blocked HTTP Traffic with CNAME
Workspace Switching
Linting Data Plans
Troubleshooting the Android SDK
API Reference
Upgrade to Version 5
Direct URL Routing FAQ
Web
Android
iOS
Cordova Plugin
Identity
Workspace Switching
Initialization
Configuration
Event Tracking
User Attributes
IDSync
Screen Tracking
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Push Notifications
Webview Integration
Upload Frequency
App Extensions
Preventing Blocked HTTP Traffic with CNAME
Linting Data Plans
Troubleshooting iOS SDK
Social Networks
iOS 14 Guide
iOS 15 FAQ
iOS 16 FAQ
iOS 17 FAQ
iOS 18 FAQ
API Reference
Upgrade to Version 7
Getting Started
Identity
Upload Frequency
Getting Started
Opt Out
Initialize the SDK
Event Tracking
Commerce Tracking
Error Tracking
Screen Tracking
Identity
Location Tracking
Session Management
Getting Started
Identity
Initialization
Configuration
Content Security Policy
Event Tracking
User Attributes
IDSync
Page View Tracking
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Custom Logger
Persistence
Native Web Views
Self-Hosting
Multiple Instances
Web SDK via Google Tag Manager
Preventing Blocked HTTP Traffic with CNAME
Facebook Instant Articles
Troubleshooting the Web SDK
Browser Compatibility
Linting Data Plans
API Reference
Upgrade to Version 2 of the SDK
Alexa
Overview
Step 1. Create an input
Step 2. Verify your input
Step 3. Set up your output
Step 4. Create a connection
Step 5. Verify your connection
Step 6. Track events
Step 7. Track user data
Step 8. Create a data plan
Step 9. Test your local app
Overview
Step 1. Create an input
Step 2. Verify your input
Step 3. Set up your output
Step 4. Create a connection
Step 5. Verify your connection
Step 6. Track events
Step 7. Track user data
Step 8. Create a data plan
Step 1. Create an input
Step 2. Create an output
Step 3. Verify output
Node SDK
Go SDK
Python SDK
Ruby SDK
Java SDK
Introduction
Outbound Integrations
Firehose Java SDK
Inbound Integrations
Compose ID
Glossary
Migrate from Segment to mParticle
Migrate from Segment to Client-side mParticle
Migrate from Segment to Server-side mParticle
Segment-to-mParticle Migration Reference
Data Hosting Locations
Rules Developer Guide
API Credential Management
The Developer's Guided Journey to mParticle
Composable Audiences Overview
User Guide Overview
Warehouse Setup Overview
Audience Setup
Frequently Asked Questions
Overview
Overview
User Profiles
Overview
Create and Manage Group Definitions
Calculated Attributes Overview
Using Calculated Attributes
Create with AI Assistance
Calculated Attributes Reference
Predictions Overview
View and Manage Predictions
What's Changed in the New Predictions UI
View and Manage Predictions
Future Behavior Predictions Overview
Create Future Behavior Prediction
Manage Future Behavior Predictions
Create an Audience with Future Behavior Predictions
Identity Dashboard (Early Access)
Create an Input
Start capturing data
Connect an Event Output
Create an Audience
Connect an Audience Output
Transform and Enhance Your Data
Usage and Billing Report
The new mParticle Experience
The Overview Map
Observability Overview
Observability User Guide
Observability Troubleshooting Examples
Observability Span Glossary
Audit Logs
Platform Configuration
Key Management
Event Forwarding
Event Match Quality Dashboard
Trends
System Alerts
Notifications
Introduction
Data Retention
Data Catalog
Connections
Activity
Data Plans
Live Stream
Filters
Rules
Blocked Data Backfill Guide
Tiered Events
mParticle Users and Roles
Analytics Free Trial
Troubleshooting mParticle
Usage metering for value-based pricing (VBP)
IDSync Overview
Use Cases for IDSync
Components of IDSync
Store and Organize User Data
Identify Users
Default IDSync Configuration
Profile Conversion Strategy
Profile Link Strategy
Profile Isolation Strategy
Best Match Strategy
Aliasing
Audiences Overview
Create an Audience
Connect an Audience
Manage Audiences
Audience Sharing
Audience Expansion
Inclusive & Exclusive Audiences Overview
Using Logic Blocks in Audiences
Combining Inclusive and Exclusive Audiences
Inclusive & Exclusive Audiences FAQ
Match Boost
FAQ
Standard Audiences (Legacy)
Predictive Audiences Overview
Using Predictive Audiences
New vs. Classic Experience Comparison
Introduction
Core Analytics (Beta)
Sync and Activate Analytics User Segments in mParticle
User Segment Activation
Welcome Page Announcements
Project Settings
Roles and Teammates
Organization Settings
Global Project Filters
Portfolio Analytics
Analytics Data Manager Overview
Events
Event Properties
User Properties
Revenue Mapping
Export Data
UTM Guide
Analyses Introduction
Getting Started
Visualization Options
For Clauses
Date Range and Time Settings
Calculator
Numerical Settings
Assisted Analysis
Properties Explorer
Frequency in Segmentation
Trends in Segmentation
Did [not] Perform Clauses
Cumulative vs. Non-Cumulative Analysis in Segmentation
Total Count of vs. Users Who Performed
Save Your Segmentation Analysis
Export Results in Segmentation
Explore Users from Segmentation
Getting Started with Funnels
Group By Settings
Conversion Window
Tracking Properties
Date Range and Time Settings
Visualization Options
Interpreting a Funnel Analysis
Group By
Filters
Conversion over Time
Conversion Order
Trends
Funnel Direction
Multi-path Funnels
Analyze as Cohort from Funnel
Save a Funnel Analysis
Export Results from a Funnel
Explore Users from a Funnel
Saved Analyses
Manage Analyses in Dashboards
Data Dictionary
Query Builder Overview
Modify Filters With And/Or Clauses
Query-time Sampling
Query Notes
Filter Where Clauses
Event vs. User Properties
Group By Clauses
Annotations
Cross-tool Compatibility
Apply All for Filter Where Clauses
Date Range and Time Settings Overview
User Attributes at Event Time
Understanding the Screen View Event
User Aliasing
Dashboards––Getting Started
Manage Dashboards
Organize Dashboards
Dashboard Filters
Scheduled Reports
Favorites
Time and Interval Settings in Dashboards
Query Notes in Dashboards
The Demo Environment
Keyboard Shortcuts
User Segments
Data Privacy Controls
Data Subject Requests
Default Service Limits
Feeds
Cross-Account Audience Sharing
Import Data with CSV Files
CSV File Reference
Glossary
Video Index
Single Sign-On (SSO)
Setup Examples
Introduction
Introduction
Introduction
Rudderstack
Google Tag Manager
Segment
Advanced Data Warehouse Settings
AWS Kinesis (Snowplow)
AWS Redshift (Define Your Own Schema)
AWS S3 Integration (Define Your Own Schema)
AWS S3 (Snowplow Schema)
BigQuery (Snowplow Schema)
BigQuery Firebase Schema
BigQuery (Define Your Own Schema)
GCP BigQuery Export
Snowflake (Snowplow Schema)
Snowplow Schema Overview
Snowflake (Define Your Own Schema)
Aliasing
Audience
Audience
Feed
Event
Event
Audience
Cookie Sync
Server-to-Server Events
Platform SDK Events
Audience
Audience
Audience
Feed
Event
Event
Event
Data Warehouse
Event
Audience
Event
Event
Audience
Event
Feed
Event
Event
Event
Event
Event
Audience
Event
Feed
Event
Event
Event
Audience
Feed
Event
Event
Event
Custom Feed
Data Warehouse
Event
Event
Audience
Audience
Audience
Event
Audience
Event
Event
Event
Event
Event
Audience
Event
Audience
Event
Event
Audience
Data Warehouse
Event
Audience
Cookie Sync
Event
Event
Event
Event
Event
Feed
Feed
Event
Event
Kit
Event
Event
Event
Audience
Event
Event
Event
Audience
Feed
Event
Audience
Audience
Event
Audience
Event
Audience
Audience
Event
Audience
Microsoft Ads Audience Integration
Event
Audience
Event
Event
Event
Event
Feed
Event
Event
Event
Event
Event
Feed
Audience
Event
Event
Event
Event
Event
Event
Event
Feed
Event
Event
Feed
Custom Pixel
Event
Event
Event
Event
Audience
Event
Event
Data Warehouse
Event
Event
Audience
Audience
Loyalty Feed
Event
Feed
Audience
Audience
Event
Audience
Audience
Cookie Sync
Event
Audience
Feed
Audience
Event
Event
Audience
Audience
Event
Event
Event
Event
Cookie Sync
Audience
Cookie Sync
Audience
Feed
Audience
Event
Inclusive & Exclusive Audiences adds support for both inclusive and exclusive audience membership. In the current version of Audiences, all audiences are exclusive by default, meaning users can belong to only one audience within a group. The Early Access release adds the option to make audiences inclusive within a single logic block, allowing users to belong to multiple audiences at the same time if they meet the criteria for each.
This update also introduces logic blocks, which give you the ability to control when audiences should be inclusive and when they should remain exclusive. The addition of logic blocks makes audiences more flexible and allows you to mirror real marketing and lifecycle strategies more closely within mParticle.
Inclusive audiences let users be added to more than one audience within the same logic block. This approach is useful when you want to target overlapping behaviors or attributes, such as reaching users who have both viewed a product and made a purchase. By using inclusivity, you can combine multiple behavioral or contextual audiences without worrying about them canceling each other out.
Inclusive audiences help you deliver more personalized messaging and run cross-channel or cross-offer campaigns efficiently. For example, if a user qualifies for both “High Intent” and “Email Engaged” audiences within the same logic block, they will appear in both. This ensures that they can receive communications tied to both engagement patterns.
Logic blocks are containers that control how audiences relate to one another inside an audience group. They do not change who qualifies for an audience. Instead, they control which audiences a user is added to when they qualify for more than one.
Within a single logic block, audiences are inclusive. If a user qualifies for several audiences in the same block, the user is added to all of them. This is useful when you want overlapping audiences, such as multiple behavior-based segments that can all apply at once.
Logic blocks are exclusive relative to other logic blocks that share the same parent audience. If a user qualifies for audiences in more than one of these sibling blocks, they are only added to audiences from the highest priority block. Logic blocks under different parent audiences do not compete with each other, so a user can still belong to audiences in logic blocks under multiple parents.
You can also nest logic blocks to apply this pattern at more than one level. For example, you might use top-level blocks to keep lifecycle stages exclusive, then use nested blocks inside each stage to manage overlapping offer or behavior audiences.
Exclusivity applies across logic blocks that are children of the same parent audience.
A group of sibling logic blocks under one parent represents a mutually exclusive set of audiences. When a user qualifies for audiences in more than one of these blocks, they are added only to audiences in the highest priority block according to the block order you define.
This setup helps you maintain clean audience boundaries. It is particularly useful for lifecycle, funnel, or testing workflows where users should only belong to one stage or group at a time. For example, if you have blocks for “New Users,” “Active Users,” and “Lapsed Users,” exclusivity ensures that no user appears in more than one at once.
Logic blocks provide more flexibility and better reflect how teams manage audiences in real-world scenarios. Many use cases require some audiences to overlap, such as when running multi-offer or cross-sell campaigns, while others require strict exclusivity, such as A/B testing or funnel progression.
By introducing logic blocks and supporting both inclusive and exclusive audiences, mParticle allows you to control both types of behavior within the same framework. This approach simplifies configuration, reduces errors, and improves your ability to manage complex audiences at scale.
Yes. The generally available version of Audiences continues to function as it always has. Only a limited set of customers have access to Inclusive & Exclusive Audiences. If an mParticle workspace does not include logic blocks, audiences remain exclusive by default.
If you’re part of the Early Access program, your feedback helps shape the final release of Inclusive & Exclusive Audiences. To share comments, suggestions, or issues, contact your mParticle account representative or customer success manager. You can also submit feedback directly through your mParticle workspace if that option has been enabled for your account.
Logic blocks are created automatically when you add a second sibling audience using the Add path button. To create additional logic blocks and separate audiences, use the Move action on an audience and select Create New Logic Block.
For detailed instructions, see Creating and Managing Logic Blocks.
Yes. Logic block priority determines which block users are added to when they qualify for audiences in multiple sibling blocks. To change block priority, click the action menu on a logic block and select Edit Logic & Priority. You can then drag blocks to reorder them or use the arrow icon to increase a block’s priority.
For detailed instructions, see Change a Logic Block’s Name and Priority.
If a user qualifies for audiences in multiple sibling logic blocks under the same parent, they are added only to audiences in the highest priority block. Logic blocks are evaluated in priority order (highest to lowest, displayed left to right in the Audience Group Editor), and the user is added to the first block where they meet the criteria.
Yes. Logic blocks are only exclusive relative to other sibling logic blocks under the same immediate parent. If logic blocks are under different parent audiences, they can share users.
For example, if you have “Comedy: Basic Subscribers” under “Comedy Viewers” and “Drama: Basic Subscribers” under “Drama Viewers,” the same user can appear in both audiences because the logic blocks have different parents.
A remaining users logic block is a special block that automatically collects all users who do not meet the criteria for any other block. This ensures that all users in your dataset are accounted for, even if they do not currently qualify for any explicitly defined audiences.
To create a remaining users logic block, click the path icon and select Add Remaining Users Split. The remaining users block always has the lowest priority and cannot be reprioritized.
You cannot directly delete a logic block. However, if you move or delete all audiences within a logic block, the block is automatically deleted. Logic blocks only exist as containers for audiences—when they’re empty, they are removed.
No. Connecting audiences to outputs works the same way regardless of logic blocks. You still:
Logic blocks only control which users are added to which audiences. Once an audience is populated, forwarding to outputs is unchanged.
For more information, see Connect an Audience.
Was this page helpful?