mParticle

mParticle grew up in mobile — its SDKs, kit architecture, and offline batching were built for apps before the web — and that heritage still shows in how it models data: everything hangs off a persistent user profile keyed by an internal mParticle ID (MPID), with events, user attributes, and consent state attached. The company was acquired by Rokt in January 2025 and now brands itself “mParticle by Rokt.”

Identity is the core of the product. IDSync resolves every incoming batch to a profile through an Identity API (identify, login, logout, search calls) plus an identity strategy you pick up front: profile conversion (merge anonymous history into the known profile at login), profile link, profile isolation (keep anonymous data off known profiles — the privacy-conservative choice), best match (for products without a login flow), or the simplified default keyed on customer ID. You also rank an identity priority list — the order in which identifiers (customer ID, email, device IDs) are matched against existing profiles. Get the strategy and priority wrong at the start and fixing it later is painful, because they shape how every profile in the system was stitched together. Treat that decision as the real implementation work, not the SDK install.

Implementation notes. The web SDK loads via an async snippet (under 30KB depending on configuration, per the docs) or can be self-hosted/installed from npm. Integrations run two ways: server-side, where mParticle receives the data and forwards it, and client-side “kits” that bundle a partner’s code into the SDK and send data directly from the browser or app. Kits are how tools that require their own client code (attribution, some ad SDKs) get data, but each one you enable adds third-party code back to the page — partly undoing the “one SDK” pitch, so audit which connections actually need a kit.

Governance is genuinely strong. Data Plans act as an allowlist: unplanned events and attributes can be blocked from processing entirely. Two real gotchas from the vendor’s own docs: blocking can cause outright data loss, and blocked data cannot be replayed through the UI — you need a quarantine connection set up in advance plus backfill scripts to recover it. Per-output data filters and consent forwarding are core product rather than add-ons, which is a real differentiator versus lighter CDPs.

Audiences builds segments on profiles for activation into ad platforms and messaging tools. Note the platform is mid-transition: the classic experience with separate Real-Time Audiences and Journeys was deprecated in August 2025 in favor of a unified Audiences product, with legacy standard audiences read-only until August 2026 — factor that churn into training and migration plans. Real-time segments compute on recent data (about the last 30 days for most customers, per the docs), while retention-based audiences reach across stored history.

Use it when you run large consumer apps across platforms, need strict schema and consent governance, and have the budget and team for an enterprise CDP. Look past it when you want self-serve pricing, a warehouse-first architecture, or a lightweight pipeline a small team can own end to end — pricing is sales-quoted with no published floor, and post-acquisition roadmap direction is worth probing during evaluation.