mParticle Practitioner cheat sheet

Hybrid architecture = mParticle SDK (client-side) plus server-side Events API/HTTP API feeds into the same workspace; both paths converge on the same event pipeline and identity model.

Client SDKs batch events and flush on a time/size threshold; server integrations post directly to the Events API endpoint, so latency and dedupe behavior differ between the two paths.

The platform assigns an mParticle ID (MPID) to each user profile; client-side MPIDs and server-side MPIDs merge only when a shared identity key (email, customer ID) is present on both.

Kit integrations run client-side inside the app; server-side output integrations are configured per output and receive events after the platform's identity, filtering, and audience enrichment.

Data planning: event names, attribute names, and data types are defined in the platform and enforced; undeclared events can be blocked or flagged depending on workspace data-plan settings.

Forwarders and feeds: an input feed (SDK or API) is separate from output feeds; a single input can fan out to many outputs, and each output can have its own filters and transformations.

Server-side events should carry the same identity keys as the SDK events; if only one path sends an email, the profiles will not merge and audiences will split.

Workspace environments (development vs production) use separate API keys and separate data; test keys must not be used for production traffic because data is isolated per environment.

Audience = a named set of users defined by real-time rules over events, attributes, and calculated values; membership is evaluated as events arrive, not on a nightly batch.

Rule types: event-based (did event X with attribute Y), attribute-based (user attribute equals/contains), and audience-based (member of another audience) for nested composition.

Time-window operators such as 'in the last N days' create recency conditions; a user leaves the audience when the window expires if no qualifying event refreshes membership.

Calculated attributes aggregate event data (counts, sums, first/last value) and can be used as audience criteria; they update as new events arrive, so rules should reference them after they are defined.

AND across rules narrows membership; OR widens it; mixing AND/OR in one audience requires care because grouping changes the result set materially.

Audience membership is written back to the user profile and can be forwarded to outputs as an audience membership event, enabling downstream activation.

Audiences can be connected to outputs (e.g., ad platforms, email) for activation; connection settings determine whether membership changes are sent in real time or on a schedule.

Test an audience against a known user or sample before activating; a rule that references an attribute never populated will silently produce an empty audience.

Predictive audiences are built from a trained model that scores each user with a probability; a threshold converts the score into audience membership.

Model inputs are historical events and attributes; the outcome (target) event must have enough historical occurrences to train, so sparse outcomes produce weak models.

Training requires a lookback window for features and a separate label window; leakage occurs if features include data from after the outcome event.

Model quality is assessed with holdout/AUC-style metrics; a model near random (AUC ~0.5) should not be activated regardless of threshold.

Predictive audience membership changes as scores are recomputed; users can enter and exit without any new event, unlike rule-based audiences.

Threshold choice trades precision against reach: a high threshold yields a smaller, higher-confidence audience; a low threshold yields larger but noisier membership.

Predictions depend on the identity graph; users with fragmented profiles (client and server events not merged) receive scores based on partial history.

Predictive audiences can be used as criteria in other audiences and connected to outputs the same way as rule-based audiences, subject to refresh cadence.

Identity priority: the platform resolves a user by matching known identities (email, customer ID, device ID) in a defined priority order; the highest-priority matched identity anchors the profile.

MPID is the platform's canonical user key; identities are linked to an MPID, and linking two previously separate MPIDs merges their histories and audience memberships.

Identify calls add or update identities on the current user; login switches the current user to a known identity, and logout reverts to an anonymous state.

Identity strategy matters: logging in a user mid-session can merge an anonymous profile into a known profile, so order of identify/login calls changes the resulting data.

Server-side events must include identity keys to attach to the correct MPID; without them, the event creates or attaches to an anonymous profile.

Identity changes propagate to audiences in real time; a merge can cause a user to instantly gain or lose audience membership based on the combined history.

Device IDs and advertising IDs are platform-specific; cross-device identity requires a durable key such as email or a first-party customer ID.

When identity conflicts occur (same email on different MPIDs), the platform resolves per its identity priority; conflicting keys should be corrected at the source rather than patched downstream.

Output integrations receive events and audience membership after platform processing; each output has its own configuration, credentials, and event filters.

Kit integrations are embedded in the client SDK and forward events from the device; server-side integrations forward from the platform, so the same event can reach a partner twice if both are enabled.

Event filtering per output controls which events are forwarded; forwarding all events to every output increases cost and noise and can break partner schemas.

Audience connections activate membership to destinations such as ad platforms and email tools; the connection defines which audience and which destination account.

Identity mapping: each output maps platform identities (email, device ID) to the partner's expected identifiers; missing mappings cause dropped or unmatched users.

Activation latency depends on the destination: real-time outputs forward on event receipt, while some partners ingest on a scheduled sync.

Data quality checks before activation: verify event names, required attributes, and identity keys are populated, because partners reject malformed payloads silently or with delayed reporting.

Consent and suppression: users who opt out should be excluded via audience rules or output filters so activation does not send data for non-consented users.