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
Rokt mParticle’s Inclusive/Exclusive Audiences allows you to create both overlapping and mutually exclusive audiences within the same audience group.
Currently, Audiences are exclusive by default. This means that within an audience group, users are only added to one audience at a time, even if they qualify for more than one audience in the group.
However, with Inclusive/Exclusive Audiences, you can use logic blocks to combine overlapping audiences into inclusive groups. By separating audiences into different logic blocks, you can enforce exclusivity. This allows you to build more complex audience groups that more accurately reflect your users and their behaviors.
For example, you might want users to belong to a single lifecycle audience such as New Customers, Active Customers, or Lapsed Customers, so your lifecycle messaging is based on one stage at a time. However, within each lifecycle stage, users might be added to multiple behavior based audiences such as High Value Purchasers or Sports Fans.
Inclusive/Exclusive Audiences would allow you to keep your lifecycle audiences mutually exclusive while still allowing users in each stage to join multiple behavior based audiences.
Logic blocks are the foundation of Inclusive/Exclusive Audiences. They act as containers that determine how audiences relate to one another within an audience group. Logic blocks are tools you use when building audiences. They are not unique entities, like a user profile or an audience, that can be managed outside the audience group.
All audiences within the same logic block are treated as inclusive. If a user qualifies for multiple audiences in the block, they are added to all of them.
For example, if you place two audiences called High Intent Users and Recent Purchasers in the same logic block, a user who meets both sets of criteria will appear in both audiences.
It’s important to note that logic blocks are only exclusive relative to other logic blocks that are children of the same immediate parent.
For example, if two logic blocks sit under the same parent audience, a user can only be added to audiences in one of those blocks at a time, but logic blocks under different parent audiences can share users.
When more than one logic block shares the same parent audience, you use block priority to control which block “wins.”
In the Audience Group Editor, blocks are ordered from highest to lowest priority. If a user qualifies for audiences in more than one of these sibling logic blocks, the blocks are evaluated in priority order and the user is added only to audiences in the first block that matches.
Logic blocks can only be created, renamed, reprioritized, and deleted within the Audience Group Editor.
If you place two audiences inside the same logic block and a user qualifies for both audiences, the user is added to both audiences. This reflects scenarios in which a single user matches several defined behaviors, interests, or attributes that you want to recognize and act on.
Keeping our example from above, a user may qualify for the New Customers audience as well as the Sports Fans and High Value Purchasers audiences. By placing the Sports Fans and High Value Purchasers audiences within the same logic block under the New Customers parent audience, you can ensure that the user receives relevant messaging for both sports and higher value products.
Inclusive audiences are useful when:
Inclusive audiences help you reach the full set of users who meet your criteria, without forcing a choice about which behavior should win.
If you place two audiences inside separate logic blocks and a user qualifies for both audiences, the user is only added to the audience in the block with the highest priority. This reflects scenarios in which you need to enforce non-overlapping audiences for things like A/B tests or lifecycle stages where it doesn’t make sense for a user to belong to more than one audience.
For example, the New Customers, Active Customers, and Lapsed Customers audiences should never overlap. By separating these into three logic blocks, you can ensure that each user is added to only one of the three audiences at a time. Even if a user qualifies for more than one lifecycle audience, they are only assigned to the audience in the highest priority block.
Exclusive audiences are useful when:
Exclusive audiences help you assign users based on your strategic priorities and avoid conflicting messaging, double counting, or ambiguity.
While Inclusive/Exclusive Audiences adds new options for structuring your audiences, it does not change the core Audiences workflows you already use. You still:
To learn more about these unchanged audience workflows, see:
Was this page helpful?