mParticle built its reputation on the piece of the customer data problem that web-first competitors handled least well, which is mobile. The difference is not cosmetic. Collecting behavioural data on the web is comparatively forgiving: the page loads, the script runs, the network is usually available, and if something fails you lose an event. On mobile, you are dealing with applications that run offline for extended periods, with an operating system that may terminate your process without warning, with app store release cycles that mean an instrumentation change can take weeks to reach most users and may never reach some of them, with battery and data constraints that make naive event-by-event transmission unacceptable, and with two entirely different platforms and their respective privacy frameworks.
A CDP SDK that handles batching, offline queueing, retry, and graceful behaviour under memory pressure is doing real engineering work, and mParticle's documentation on this is thorough and written by people who evidently hit these problems in production. If mobile is a significant part of your product, this is the strongest documentation in the category on that specific axis. The kit architecture is the other technically interesting idea. Rather than every partner SDK being separately integrated into your app, each adding binary size, each with its own initialisation and its own potential to misbehave, mParticle wraps them as kits managed through a single integration point.
The practical benefit is that a marketing team wanting to add an attribution partner does not require an app release and a fresh integration review, and the practical cost is a layer of indirection between your app and the partner code. The documentation explains both sides, which is more than I expected. Data quality and privacy get more attention than is typical, with the consent and data subject request material being reasonably practical rather than the usual gesture toward compliance. What does not exist is any teaching.
There is no academy, no course catalogue, no learning path and no certification. This is pure technical reference aimed at engineers who already know what a CDP is, and a marketer or analyst arriving here will find nothing pitched at them, which is a notable gap for a product category that explicitly sells to both audiences. The ownership question is the thing a prospective buyer should think hardest about, and it deserves to be stated factually rather than dramatically. Rokt acquired mParticle in January 2025 for around $300 million.
mParticle had raised approximately $272 million in total funding. An exit barely above the capital invested is not a disaster and it is not a success; it is the market saying that the standalone CDP business was worth roughly what was put into it, which is consistent with the broader consolidation this category has been going through. Michael Katz stayed on as CEO of mParticle and the product continues to operate. So far, so ordinary.
The part that requires actual thought is who Rokt is. Rokt is an ecommerce technology company whose business is relevance and advertising in the transaction moment, which is to say it monetises knowing things about shoppers. A customer data platform, by contrast, sells itself on being neutral infrastructure: you put your customer data in, it goes where you direct it, and the vendor has no interest of its own in that data. Those two positions are not automatically in conflict, and I want to be careful not to allege anything about Rokt's conduct, which I have no basis to do.
But the structural question is legitimate and any serious procurement process should ask it directly: what are the contractual guarantees about the use of customer data flowing through this platform, do they survive the change of ownership, and what changes if Rokt's commercial priorities evolve. The documentation does not address this, cannot address it, and it would be naive to expect it to. Ask the account team and get the answer in writing. The exit question carries more weight than usual for the same reason.
CDPs are sticky by construction, mobile CDPs especially so because your integration is compiled into an application that users must update, which means migrating is not a server-side change you can make over a weekend but a multi-release programme. Under ordinary circumstances that is a manageable risk. Under an ownership situation with an open strategic question attached, it is worth knowing in advance what your exit would look like. Three point two.
Strong mobile engineering documentation that remains the best reason to use the product, with no teaching layer, unpublished pricing, and an ownership change that raises a neutrality question a buyer should resolve with a contract rather than with a docs site.