I85PREP
⌘ K
mParticle Practitioner study materials
mParticle Practitioner study resources

mParticle Practitioner practice questions

One question at a time. Build your mParticle Practitioner understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Hybrid Architecture

In a hybrid mParticle deployment, what is the primary role of the mParticle SDK embedded in a native mobile app?

  1. It replaces the need for any data plan configuration in the dashboard
  2. It hosts the server-side firewall rules that block unwanted event names
  3. It stores the full customer profile database on the device permanently
  4. It collects events locally and forwards them to the mParticle platform for forwarding to connected outputs Correct answer.

Explanation

The embedded SDK is the client-side collection point in a hybrid architecture: it captures events, identities, and attributes on the device and transmits them to the mParticle platform, which then fans them out to configured outputs. It does not host firewall rules or maintain a permanent on-device profile database.

Question 2Hybrid Architecture

A team wants server-side event forwarding so that sensitive identifiers never pass through the client SDK. Which mParticle capability should they use?

  1. The server-to-server Events API Correct answer.
  2. The on-device identity sync
  3. The client-side integration with each output partner
  4. The kit-based partner SDK wrapper

Explanation

The Events API accepts server-originated events and forwards them through the same platform and outputs, so sensitive identifiers can stay on the backend. Client-side integrations and kits run in the app and would expose those values on the device.

Question 3Hybrid Architecture

Which statement best describes the difference between an mParticle input and an output in a hybrid setup?

  1. An input is a source that feeds data into mParticle; an output is a destination mParticle forwards data to Correct answer.
  2. Inputs and outputs are interchangeable terms for the same connection
  3. Inputs are only for mobile apps, while outputs are only for web browsers
  4. An input stores data permanently, while an output deletes it after forwarding

Explanation

Inputs are the data sources (such as SDKs, feeds, or APIs) that send data into mParticle, and outputs are the downstream destinations (such as analytics or marketing tools) that receive forwarded data. The distinction is about direction of data flow, not device type or retention.

Question 4Hybrid Architecture

What does an mParticle data plan primarily provide in a hybrid architecture?

  1. A billing schedule for each connected output
  2. A network proxy that caches events offline
  3. A schema and validation contract defining expected events, attributes, and identities Correct answer.
  4. A compiled binary that replaces the SDK in the app

Explanation

A data plan defines the expected event names, attributes, and identities and lets the platform validate incoming data against that contract. It is a governance and schema mechanism, not billing, a binary, or a proxy.

Question 5Hybrid Architecture

Why is consistent identity management especially important in a hybrid architecture that combines app, web, and server data?

  1. Because outputs refuse to receive data without a device ID
  2. Because identity resolution only works when a single channel is used
  3. Because server data cannot contain user identifiers
  4. Because each channel otherwise creates disconnected profiles that cannot be stitched together Correct answer.

Explanation

When multiple channels send data, mParticle relies on shared identifiers to resolve events to the same user profile. Without consistent identity, the same person appears as separate profiles and cross-channel attribution breaks down.

Question 6Hybrid Architecture

A developer needs to send a custom event from a backend service into mParticle without using a mobile SDK. Which approach fits the hybrid model?

  1. Embed the mobile SDK inside the backend service
  2. Configure a kit in the web app
  3. Call the mParticle Events API from the backend Correct answer.
  4. Enable the on-device identity sync

Explanation

The Events API is the server-side ingestion path that lets backend services submit events directly to mParticle. Embedding a mobile SDK in a backend or relying on client-side kits does not match server-originated data.

Question 7Hybrid Architecture

What is the purpose of the mParticle ID (MPID) in a hybrid deployment?

  1. It is the API key used to authenticate server requests
  2. It is a platform-generated identifier that ties events and identities to a single user profile Correct answer.
  3. It is the name of the output configuration
  4. It is the device's advertising identifier

Explanation

The MPID is mParticle's internal identifier for a resolved user profile, allowing events from different channels and identifiers to be associated with the same person. It is distinct from API credentials, device advertising IDs, and output names.

Question 8Hybrid Architecture

Which scenario best illustrates a hybrid architecture pattern in mParticle?

  1. A firewall rule blocking a single event name
  2. Only a single iOS app sending events to one analytics output
  3. A dashboard report generated without any data collection
  4. A web SDK collecting browsing events while a backend service sends purchase events to the same outputs Correct answer.

Explanation

A hybrid pattern combines multiple collection paths, such as a client SDK plus a server-side service, feeding a shared platform and outputs. A single app to a single output is not hybrid, and reports or firewall rules are not collection architectures.

Question 9Hybrid Architecture

A mobile app and a backend service both send events for the same user, but the backend uses a different customer ID than the app. What is the most reliable way to ensure the events resolve to one profile?

  1. Send the backend events through the mobile SDK
  2. Log the same identity value (such as a known customer ID) on both paths so mParticle can resolve them Correct answer.
  3. Disable identity resolution for the backend
  4. Rely on the device ID, which the backend will inherit automatically

Explanation

Identity resolution depends on shared identifiers. When both the app and the backend log the same known identifier, mParticle can associate the events with a single profile. Device IDs from the app are not automatically inherited by server-originated events.

Question 10Hybrid Architecture

An event sent through the Events API fails data plan validation because it uses an attribute not defined in the plan. What is the most appropriate fix?

  1. Remove the Events API integration entirely
  2. Add the attribute to the data plan so it is recognized as expected Correct answer.
  3. Disable validation for all inputs
  4. Duplicate the event under a new name

Explanation

Data plan validation compares incoming data against the defined schema, so an unrecognized attribute means the contract does not cover it. Updating the data plan to include the attribute aligns the schema with the actual data. Disabling validation or removing the integration are disproportionate and weaken governance.

Question 11Hybrid Architecture

Which consideration most strongly favors server-side forwarding over client-side kits for a particular output?

  1. The team wants to use the SDK's offline queue
  2. The app needs to render the output's UI
  3. The output requires the lowest possible mobile binary size
  4. The data must not be exposed to the client device Correct answer.

Explanation

Server-side forwarding keeps sensitive data on the backend, so it never reaches the device. Binary size and offline queuing are client concerns, and rendering a partner's UI is unrelated to forwarding architecture.

Question 12Hybrid Architecture

A team notices duplicate purchase events in an output after enabling both client-side and server-side purchase tracking. What is the most likely cause?

  1. The same purchase is being logged from two collection paths Correct answer.
  2. The MPID is missing from the profile
  3. The output is configured to double every event
  4. The data plan automatically duplicates events

Explanation

When two collection paths both log the same purchase, the platform forwards both, producing duplicates downstream. The fix is to designate a single source of truth for that event rather than relying on automatic deduplication. Data plans and outputs do not inherently duplicate events, and a missing MPID does not cause duplication.

Question 13Hybrid Architecture

What is the effect of configuring an output to receive only a subset of event types in a hybrid deployment?

  1. The data plan is automatically deleted
  2. All events are still forwarded, but hidden in reports
  3. Only events matching the configured criteria are forwarded to that output Correct answer.
  4. The SDK stops collecting events entirely

Explanation

Output-level filtering controls which events reach a given destination, so partners receive only the data they need. It does not stop collection at the source, hide events in reports, or affect the data plan.

Question 14Hybrid Architecture

A backend service needs to send events on behalf of users whose identity is known only by an internal account number. What should the team do to make those events resolvable?

  1. Rely on the app's device ID to identify the user
  2. Convert the account number into an event attribute only
  3. Send the events without any identity and expect automatic resolution
  4. Log the internal account number as a known identity in mParticle and use it consistently Correct answer.

Explanation

For server-originated events to resolve to a profile, the identifier must be logged as an identity that mParticle recognizes. Using the internal account number consistently as a known identity allows resolution; treating it only as an attribute does not create identity linkage.

Question 15Hybrid Architecture

Which situation best justifies using the mParticle web SDK alongside a native app SDK in the same deployment?

  1. Users interact with the brand on both a website and a mobile app and events should flow to shared outputs Correct answer.
  2. The team wants to avoid defining a data plan
  3. The team wants to eliminate all identity resolution
  4. The backend cannot reach the Events API

Explanation

Using web and app SDKs together is appropriate when users engage across channels and the organization wants unified collection into shared outputs. It does not remove the need for a data plan, and it is unrelated to backend API reachability or disabling identity.

Question 16Hybrid Architecture

What happens to events collected by the SDK while a device is offline?

  1. They are discarded immediately
  2. They are queued and sent when connectivity returns Correct answer.
  3. They are forwarded directly to outputs without the platform
  4. They are converted into firewall rules

Explanation

The SDK queues events locally when the device lacks connectivity and uploads them once a connection is restored. Events still pass through the mParticle platform before reaching outputs, and they are not converted into firewall rules.

Question 17Hybrid Architecture

A team wants to validate that server-originated events conform to the same schema as app events. Which mechanism supports this?

  1. Applying the same data plan to the server input Correct answer.
  2. Disabling the data plan for the server input
  3. Creating a separate output for server events
  4. Using a kit on the backend

Explanation

A data plan can govern multiple inputs, so applying the same plan to the server input validates server events against the shared schema. Disabling the plan, isolating outputs, or using kits does not provide schema validation for server data.

Question 18Hybrid Architecture

Why might an organization route the same event to different outputs with different filters in a hybrid architecture?

  1. Because identity resolution fails without multiple outputs
  2. Because filters are the only way to create a data plan
  3. Because each output has different data needs and privacy constraints Correct answer.
  4. Because the platform requires at least two outputs per event

Explanation

Different destinations often need different subsets of data, and privacy or contractual constraints may limit what each partner receives. Output-level filtering lets one event stream serve multiple destinations appropriately. The platform does not require multiple outputs, and filters are unrelated to creating data plans or identity resolution.

Question 19Hybrid Architecture

A company wants a single source of truth for order events while still tracking browsing behavior in the app. Which hybrid design is most sound?

  1. Send browsing events from the backend only
  2. Send order events only from the backend and browsing events from the app SDK Correct answer.
  3. Send order events from both the app and the backend
  4. Disable the app SDK entirely

Explanation

Designating the backend as the sole source for order events prevents duplicates and keeps authoritative transaction data server-side, while the app SDK handles behavioral browsing events. Sending orders from both paths reintroduces duplication, and removing the app SDK loses valuable behavioral data.

Question 20Hybrid Architecture

An analyst reports that server-originated events appear under separate profiles from app events for the same customer. Which root cause is most consistent with this symptom?

  1. The server events lack a shared identity value that the app logs Correct answer.
  2. The SDK offline queue is disabled
  3. The data plan does not include browsing events
  4. The outputs are misconfigured to drop server events

Explanation

Fragmented profiles across channels typically indicate that the server events do not carry an identifier the platform can match to the app's profile. Ensuring a shared identity is logged on both paths resolves the split. Output configuration, data plan scope, and offline queuing would not produce this cross-channel split.

Question 21Hybrid Architecture

A team wants strong governance over a hybrid pipeline where app and server events must conform to the same definitions. Which combination best achieves this?

  1. Disabling identity resolution to simplify the pipeline
  2. Client-only validation with no server checks
  3. A shared data plan applied across inputs plus output-level filtering for each destination Correct answer.
  4. A separate undocumented schema per channel with no validation

Explanation

A shared data plan enforces consistent event and attribute definitions across all inputs, while output-level filtering tailors what each destination receives. Separate undocumented schemas, client-only validation, and disabling identity all undermine governance and consistency.

Question 22Hybrid Architecture

Which statement accurately distinguishes when to use the client SDK versus the Events API for a given event in a hybrid deployment?

  1. Use the SDK for backend events because it handles authentication
  2. Use the Events API only for events that must render UI on the device
  3. Use the SDK when the event originates from user interaction in the app; use the Events API when it originates from a trusted backend system Correct answer.
  4. Use the Events API for all events to avoid maintaining the SDK

Explanation

The SDK is the natural collection path for in-app user interactions, while the Events API is intended for events generated by trusted backend systems. Routing everything through one path ignores the strengths of each, and backend events do not originate in the app SDK.

Question 23Hybrid Architecture

A privacy requirement states that a specific sensitive attribute must never reach the client device but must still be forwarded to a marketing output. Which architecture satisfies this?

  1. Send the attribute via the Events API from the backend to the output Correct answer.
  2. Log the attribute only as a device identifier
  3. Store the attribute in the SDK's offline queue
  4. Collect the attribute with the app SDK and filter it at the output

Explanation

Sending the sensitive attribute from the backend through the Events API keeps it off the device while still allowing it to reach the output. Collecting it in the app SDK exposes it on the device, and the offline queue or device identifiers do not satisfy the constraint.

Question 24Hybrid Architecture

Which outcome indicates that output-level filtering is working as intended in a hybrid deployment?

  1. A partner output receives only the event types configured for it while others continue to flow elsewhere Correct answer.
  2. The data plan rejects all events
  3. Every output receives every event regardless of type
  4. The SDK stops collecting events for filtered types

Explanation

Output-level filtering restricts what a specific destination receives without affecting collection or other outputs. Observing that one partner gets only its configured event types while other destinations continue receiving their data confirms the filter is applied correctly.

Question 25Hybrid Architecture

What is the main benefit of centralizing multiple collection paths through the mParticle platform before reaching outputs?

  1. Identity resolution becomes unnecessary
  2. Each output must build its own integration with every source
  3. The SDK is no longer needed for any channel
  4. Each output receives data in a consistent, governed form regardless of source Correct answer.

Explanation

Routing multiple sources through the platform lets mParticle apply consistent validation, identity resolution, and filtering before forwarding, so outputs receive governed data. It removes the need for per-source integrations at each destination rather than creating them, and identity resolution remains essential.

Question 26Hybrid Architecture

In a hybrid mParticle deployment, which credential does a backend service use to authenticate calls to the Events API?

  1. An output partner's OAuth token for a downstream destination
  2. A user's MPID combined with a device advertising identifier
  3. A mobile SDK API key copied from the app's initialization code
  4. A workspace API key and secret issued in the mParticle platform Correct answer.

Explanation

Server-side ingestion through the Events API is authenticated with platform-issued workspace credentials (an API key and secret) rather than client keys. Those credentials identify the account and workspace authorized to submit events, and they should be stored securely on the server, never embedded in a client app.

Question 27Hybrid Architecture

A team wants the app SDK to capture screen views while a server process enriches the same user's purchase data with internal order metadata. Where should the enrichment logic live?

  1. In the output configuration, using a transformation applied after delivery
  2. In the identity settings, by mapping the order number to the MPID
  3. In the server process, before the enriched event is submitted through the Events API Correct answer.
  4. In the app SDK, using a custom kit that calls the internal order database

Explanation

Enrichment that depends on internal systems belongs on the server, where the data already lives, and the enriched event is then submitted via the Events API. The client should stay focused on capturing user interaction, and output transformations run after ingestion rather than adding source-of-truth metadata.

Question 28Hybrid Architecture

A hybrid pipeline sends app events and server events that share the same event name but carry different attribute sets. Which practice keeps downstream consumers consistent?

  1. Disable data plan validation for the server path to avoid rejection of extra attributes
  2. Define one data plan for that event name and enforce it across both collection paths Correct answer.
  3. Let each output apply its own schema independently of the collection path
  4. Register the server path under a separate event name so the schemas never overlap

Explanation

A data plan is tied to event definitions rather than to the collection path, so one plan can govern both app and server submissions of the same event name. Enforcing it on both paths catches drift early and gives downstream consumers a predictable payload.

Question 29Hybrid Architecture

Which event is best captured client-side rather than through the Events API in a hybrid deployment?

  1. A nightly reconciliation record generated from a finance system
  2. A button tap that reflects immediate in-session user interaction Correct answer.
  3. A refund issued by a customer service representative
  4. A warehouse inventory adjustment produced by an internal service

Explanation

Events that originate from user interaction inside the app are naturally captured by the SDK, which has direct access to session and device context. Back-office records such as reconciliations, refunds, and inventory changes originate in server systems and belong on the Events API path.

Question 30Hybrid Architecture

A company wants server-originated events to carry the same device context (such as platform and app version) as SDK events. What is the practical approach?

  1. Enable a setting that copies context from the last client event automatically
  2. Rely on mParticle to infer device context from the user's most recent app session
  3. Include the relevant context fields explicitly in the Events API payload from the server Correct answer.
  4. Configure the output to backfill context from the identity profile

Explanation

The Events API does not observe a device, so any device or app context that matters downstream must be supplied in the payload by the server. mParticle does not silently inherit context from a prior session, and outputs do not backfill missing collection-time fields.

Question 31Hybrid Architecture

An engineer asks why a hybrid deployment often sends the same business event through both the app SDK and the Events API during a migration period. What is the main risk of this overlap?

  1. The app SDK will stop forwarding events to client-side kits
  2. Identity resolution will permanently merge unrelated users
  3. The Events API will reject all subsequent events from that user
  4. Downstream outputs may count the same business event twice unless deduplication is handled Correct answer.

Explanation

When both paths report the same real-world event, each submission is a separate record, so outputs can double-count unless the team deduplicates by a shared transaction identifier or filters one path. The overlap does not block future ingestion or disable kits, and it does not merge unrelated identities.

Question 32Hybrid Architecture

Which identity value should a server include so that Events API submissions attach to the same profile the app SDK already created?

  1. A freshly generated random identifier unique to the server request
  2. The device's advertising ID only, with no other identifier
  3. The output partner's internal account number
  4. A customer ID or MPID that the SDK has already associated with that user Correct answer.

Explanation

Profile stitching depends on a shared identifier, so the server should send a customer ID already known to the SDK or the MPID itself. Sending only a novel or partner-specific value leaves the event unattached to the existing profile.

Question 33Hybrid Architecture

A team needs server events to be held until a user's app identity is known, so the events land on the correct profile. Which approach best fits mParticle's model?

  1. Send the event with the strongest available identifier and associate the remaining identifiers when the app logs in Correct answer.
  2. Buffer events indefinitely on the server until an MPID is manually assigned
  3. Send events with no identifiers and rely on later manual profile merges
  4. Route server events to a separate workspace that never resolves identity

Explanation

mParticle resolves identity from the identifiers present on each request, so sending the best available identifier and then associating additional identifiers at login lets the profile converge. Indefinite buffering, identifier-free events, and isolated workspaces all prevent proper resolution.

Question 34Hybrid Architecture

Which statement correctly describes how output filters interact with events arriving from different collection paths?

  1. Filters apply only to SDK events and ignore Events API submissions
  2. Filters are evaluated at collection time on the device before forwarding
  3. Filters can only match on the event name, not on custom attributes
  4. Filters evaluate event properties regardless of whether the event came from the SDK or the Events API Correct answer.

Explanation

Output filtering is applied to the event data in the platform, so it can match on event type and attributes whether the record originated on the client or the server. Filtering is not limited to client events, is not performed on the device, and can use custom attributes.

Question 35Hybrid Architecture

A privacy officer requires that a sensitive field be removed before data reaches any downstream output while remaining available for internal analysis. Which hybrid design satisfies this?

  1. Collect the field server-side and strip it in the output configuration before forwarding Correct answer.
  2. Include the field only in the app's local logs and never send it
  3. Store the field in the event name so filters can exclude it
  4. Send the field from the app SDK and ask each output to ignore it

Explanation

Keeping the sensitive attribute on the server path and removing it via output configuration lets the platform retain it for internal use while preventing it from reaching destinations. Relying on each output to ignore a field, encoding it in the event name, or never sending it does not meet both requirements.

Question 36Hybrid Architecture

Which mParticle capability lets a team confirm that a server-submitted event was accepted and forwarded as expected?

  1. The activity and event views in the platform that show ingestion and forwarding results Correct answer.
  2. The output partner's billing dashboard
  3. The workspace's user role settings
  4. The app's local debug console on the device

Explanation

Platform activity views show what was ingested and how it was forwarded, which is how teams verify server submissions. Device consoles only reflect client activity, and partner dashboards or role settings do not show mParticle ingestion outcomes.

Question 37Hybrid Architecture

A team plans to use the Events API for order events but wants client-side kits to keep receiving app events. What must they consider about kit forwarding?

  1. Server events automatically invoke every client kit configured in the workspace
  2. Enabling the Events API disables client-side kit forwarding
  3. Kits are triggered by client-side SDK forwarding, so server events reach outputs only through configured output integrations Correct answer.
  4. Kits must be re-registered on the server before Events API data can flow

Explanation

Client kits operate inside the app and forward data collected by the SDK; server-submitted events do not pass through them. Server events reach destinations through the output integrations configured in the platform, so the two forwarding mechanisms are independent.

Question 38Hybrid Architecture

Which identifier type is most appropriate for correlating a server event with an app session when the business uses a stable internal account number?

  1. The app's bundle identifier
  2. A customer ID set to the internal account number and also set by the app at login Correct answer.
  3. A new identifier generated for each server request
  4. The output's endpoint URL

Explanation

A stable customer ID that both the app and the server set creates a shared key for the same user across paths. Per-request identifiers, bundle identifiers, and endpoint URLs do not identify a person and cannot correlate sessions.

Question 39Hybrid Architecture

A team observes that server events appear in outputs but never trigger the app's client-side kit for a messaging destination. What is the most likely explanation?

  1. The Events API strips all event names before forwarding
  2. The data plan rejected the server events silently
  3. The messaging destination is configured as a client-side kit, which only receives SDK-collected events Correct answer.
  4. The server events were sent with the wrong HTTP method

Explanation

Client kits live in the app and only see events the SDK collects, so server-only events will not reach them. To deliver server events to that destination, the team needs an appropriate output integration rather than relying on the client kit.

Question 40Hybrid Architecture

Which benefit most directly results from enforcing consistent event definitions across app and server collection paths in a hybrid deployment?

  1. Identity resolution becomes unnecessary
  2. Client kits no longer need configuration
  3. Downstream tools receive comparable records regardless of which path produced them Correct answer.
  4. The Events API gains higher throughput than the SDK

Explanation

Shared definitions mean an event means the same thing whether it came from the app or a backend service, so downstream tools can combine and compare records safely. Consistent definitions do not change throughput, eliminate kit setup, or remove the need for identity resolution.

Question 41Audiences and Segmentation

In mParticle, what is the fundamental difference between an audience and a segment?

  1. Segments are always connected to destinations, while audiences are only visible inside the dashboard
  2. A segment is a reusable definition of users, while an audience is a calculated snapshot of membership at a point in time
  3. An audience is a reusable definition of users, while a segment is a calculated snapshot of membership at a point in time Correct answer.
  4. Audiences can only be built from event data, while segments can only be built from user attributes

Explanation

The audience is the saved, editable definition (criteria such as attributes, events, and lookback windows). The segment is the resulting computed population produced when that definition is evaluated, and it can be recalculated or synced onward. Keeping the two concepts separate is what lets you edit criteria without losing the identity of the audience.

Question 42Audiences and Segmentation

Which set of criteria types can be combined when defining an mParticle audience?

  1. User attributes, event activity with lookback windows, and audience membership Correct answer.
  2. Only event names with a fixed one-day lookback
  3. Only user attributes imported from a data warehouse
  4. Only calculated metrics such as lifetime value

Explanation

Audience criteria can reference user attributes, event-based behavior within a defined lookback window, and membership in other audiences. Combining these lets you build layered definitions such as 'made a purchase in 30 days but is not in the lapsed buyers audience'. Calculated metrics are not a native criterion type.

Question 43Audiences and Segmentation

A marketer wants a daily refreshed population of users who opened the app in the last 14 days. Which configuration expresses this correctly?

  1. An audience with an attribute criterion for app open and no lookback window
  2. A segment with a 14-day lookback window and no audience definition
  3. An audience with a 14-day lookback window and a connection to a warehouse only
  4. An audience with an event criterion for app open and a 14-day lookback window Correct answer.

Explanation

Recency-based behavior is expressed as an event criterion paired with a lookback window, which defines the rolling period mParticle evaluates against. The resulting segment is recalculated on the audience's refresh cadence. Attributes describe state, not recency of an event.

Question 44Audiences and Segmentation

What does a real-time audience in mParticle do differently from a standard audience?

  1. It recalculates only once every 24 hours
  2. It stores membership only in the data warehouse
  3. It evaluates membership as qualifying events arrive rather than on a batch refresh cycle Correct answer.
  4. It ignores user attributes and uses events exclusively

Explanation

Real-time audiences are evaluated as events stream in, so a user can enter or exit shortly after the triggering activity. Standard audiences are recalculated on a scheduled cadence instead. This distinction matters when a downstream journey or message depends on immediacy.

Question 45Audiences and Segmentation

Which statement best describes how audience membership is typically used once a segment is calculated?

  1. Membership is written back as a user attribute and can be forwarded to connected destinations and journeys Correct answer.
  2. Membership replaces the need for any event data collection
  3. Membership is only visible in the mParticle dashboard and cannot leave the platform
  4. Membership is deleted automatically after each calculation

Explanation

Calculated membership is exposed as an audience attribute on the user profile, which can then be activated through connections and used in journeys or downstream tools. This is the mechanism that turns segmentation into activation. Membership persists and updates rather than being discarded.

Question 46Audiences and Segmentation

Two audiences exist: Audience A contains all users who added an item to cart in 7 days, and Audience B contains all users who completed a purchase in 7 days. Which configuration produces users who added to cart but did not purchase?

  1. Audience A combined with Audience B using an exclusion of B Correct answer.
  2. Audience A combined with Audience B using a union
  3. Audience A and Audience B each connected to the same destination
  4. Audience B combined with Audience A using an exclusion of A

Explanation

Exclusion subtracts one audience's members from another, so A excluding B yields cart-adders who are not purchasers. Union would produce anyone who did either action, which is the opposite of what is needed. Order matters in exclusion, so the base audience must be A.

Question 47Audiences and Segmentation

A user made a purchase 45 days ago and the purchase event criterion uses a 30-day lookback. What is the user's membership status for that criterion?

  1. The user does not qualify, because the event falls outside the 30-day window Correct answer.
  2. The user qualifies, because the event is stored permanently on the profile
  3. The user qualifies only if a real-time audience is used
  4. The user qualifies, because lookback windows are ignored for purchase events

Explanation

A lookback window limits evaluation to events that occurred within the specified number of days from the evaluation time. A 45-day-old purchase is outside a 30-day window and therefore does not satisfy the criterion. Historical storage of the event does not override the window.

Question 48Audiences and Segmentation

Which scenario most clearly calls for a real-time audience rather than a scheduled one?

  1. An in-session offer triggered immediately after a user abandons a cart Correct answer.
  2. A quarterly re-evaluation of a suppression list
  3. A monthly newsletter list built from users active in the last 90 days
  4. A nightly export of high-value customers to a warehouse

Explanation

Real-time audiences suit cases where the downstream action must follow the triggering event closely, such as an immediate in-session message. Monthly, nightly, and quarterly use cases tolerate scheduled recalculation. Latency requirements, not data volume, drive the choice.

Question 49Audiences and Segmentation

An audience is defined with two criteria: 'attribute plan_type equals premium' and 'event purchase in 30 days'. How are these criteria combined by default in an audience definition?

  1. Criteria are combined by priority order, with the first criterion taking precedence
  2. Criteria are combined with AND, so a user must satisfy every criterion to be a member Correct answer.
  3. Criteria are combined with OR, so satisfying any one criterion is enough
  4. Criteria are evaluated independently and produce separate audiences

Explanation

Within a single audience definition, criteria are treated as conditions that must all hold, which is equivalent to a logical AND. A premium user who has not purchased in 30 days therefore falls outside the audience. To express OR logic, you build separate audiences and combine them with a union.

Question 50Audiences and Segmentation

What is the effect of connecting an audience to a destination in mParticle?

  1. It converts the audience into a new event type
  2. It forwards audience membership or qualifying events to the integrated partner Correct answer.
  3. It permanently locks the audience criteria from further edits
  4. It recalculates the audience every time the destination is opened

Explanation

A connection determines where audience data flows, typically forwarding membership updates or the underlying events to a partner integration. Connections are configuration for delivery, not a change to the audience definition itself. Criteria remain editable after connecting.