mParticle Practitioner key terms

A deployment pattern where mParticle SDKs collect data on-device while server-side APIs send events directly from backend systems, with both streams joined under one workspace and account.

An HTTP endpoint that accepts batched event payloads from a backend, letting you log conversions and user attributes without an app or browser SDK present.

A single JSON payload containing multiple events and their user identities, submitted to the server-side API in one request to reduce network overhead and improve throughput.

The top-level organizational container in mParticle holding inputs, outputs, audiences, and user data; separate workspaces are fully isolated from one another.

A configured data source, such as an SDK platform, a server-side feed, or a partner integration, that is authorized to send events into a workspace.

A configured destination, such as an analytics tool, marketing platform, or data warehouse, that receives filtered events and audience membership from mParticle.

The link between an input and an output that defines which event types flow through, plus any filters or transformations applied along that path.

A schema of approved event names, attribute names, and types that incoming data is validated against, surfacing violations so teams can keep data consistent.

A rule that drops or allows events and attributes before they reach an output or the warehouse, used to reduce volume and protect sensitive fields.

Personally identifiable information such as email, phone, or government ID; mParticle can hash or suppress these fields before they leave the platform toward downstream tools.

The mechanism that relays a captured event to one or more outputs in real time, applying each connection's filters and any configured transformations on the way out.

The process of linking identifiers such as email, phone, customer ID, and device ID to a single user profile so activity from multiple sources merges into one record.

mParticle's internal, stable user identifier assigned to a resolved profile; it stays constant even as new identifiers are added or devices change.

An ordered list of identifiers that determines which value mParticle prefers when merging profiles; the highest-ranked available identifier anchors the resolved user.

A workspace setting that controls how aggressively identifiers are matched and merged, trading stricter privacy for broader cross-device stitching.

A call that updates a profile's known identifiers, such as adding a logged-in customer ID or email, triggering a merge with any existing matching profile.

A user record created before any strong identifier is known, typically keyed by a device or cookie ID, which can later merge into an identified profile.

A named group of users defined by criteria such as event behavior, attributes, or membership in other audiences, which mParticle recalculates and forwards to outputs.

The rules, such as event occurrence, attribute conditions, or lookback windows, that determine whether a user qualifies for an audience.

The state of a user being inside an audience, recorded as a subscribe or unsubscribe event that is sent to connected outputs when it changes.

A full re-evaluation of an audience against its criteria, used to correct drift, backfill members, or refresh membership after criteria changes.

The time range of historical events an audience criterion considers, such as events in the last 30 days, controlling how far back behavior is evaluated.

An audience whose membership is evaluated and updated as events arrive, rather than on a scheduled batch cycle, enabling immediate activation.

A derived user property computed from event history, such as lifetime order count or last purchase date, usable in audience criteria and as an output field.

A group used to exclude users from campaigns or from another audience, commonly built from opt-outs, recent purchasers, or complaint lists.

A machine-learned model trained on a workspace's historical events to score users on a defined outcome, such as likelihood to purchase or churn.

An audience populated by users whose prediction score crosses a threshold, so membership refreshes automatically as scores are recalculated.

The offline process of fitting a prediction to historical labeled events; it requires sufficient positive and negative examples to produce a usable model.

An input variable, such as recency, frequency, or monetary value, that a prediction model uses to estimate a user's likelihood of the target outcome.

The cutoff value on a prediction score above which a user is included in a predictive audience, tuned to balance reach against precision.

A measure of how well a trained prediction separates likely from unlikely users, reported through metrics such as lift or AUC and used to judge readiness.

Delivering audience membership and user attributes to a destination, such as an ad platform or messaging tool, so campaigns can target the right users.

A destination integration that accepts audience membership updates, translating mParticle subscribe and unsubscribe events into the partner's native list or segment format.

A destination integration that forwards individual events, such as purchases or screen views, to a partner rather than audience membership changes.

A packaged client-side integration bundled into the SDK that forwards events to a partner directly from the device, complementing server-side forwarding.

A generic output that posts event or audience data to a URL you control, useful when no dedicated partner integration exists.

An output that writes raw events and audience membership to a warehouse such as Snowflake or BigQuery for analysis and downstream modeling.

A one-time or scheduled snapshot of an audience's members delivered to a destination, distinct from continuous membership streaming.