You spend a week defining an audience in your CDP. Lapsed high-value customers, the ones actually worth winning back. You push the segment to Meta feeling good about it. Then the matched figure comes back at around sixty percent of what you sent, and the rest just isn't there. The platform couldn't recognise four in ten of your own customers.

Anyone who has run paid media knows that feeling. It's the match rate gap, and it has a few causes. People sign up with one email and log into Meta with another. Phones get replaced every couple of years. And the work address someone handed you is almost never the login their personal Meta account runs on. The audience is real. The platform just can't see all of it.

Over the past six months, a handful of CDPs have started selling a fix for exactly this. Hightouch calls it Match Booster. mParticle, now part of Rokt, calls it Match Boost and shipped it in February before opening it to everyone in March. Zeotap, the European option, calls it Audience Boost. Same capability, three brand names, no agreed category term yet. I'll call it in-flight enrichment, because that's what it does.

What does it actually do?

Here's the mechanic, without the usual marketing gloss.

You send your first-party audience toward an ad platform. Before it arrives, the CDP appends extra identifiers to each record from a third-party identity graph. Additional emails, phone numbers, device IDs, sometimes household data. A record that left your warehouse with one email lands at Meta carrying three identifiers, which gives the platform more chances to recognise the person. More matches, which means a bigger addressable audience and less wasted spend.

What is it that really matters? The enrichment happens in transit. The extra identifiers get added as the audience syncs, and then they're gone. They don't write back into your CDP. Hightouch, mParticle and the others all stress this, and they're right to. It's meaningfully better for your data hygiene than the old approach of bulk-uploading your whole list to a third party and letting them keep a copy.

Think of it like posting a letter with a name and a street but no postal code. The sorting office looks up the rest against its directory and completes the address before delivery. Your letter leaves your hands incomplete and arrives deliverable. The part worth holding onto is that the extra detail on the envelope came from the directory, not from the person who wrote to you.

The figures vendors quote are plausible, for what it's worth. mParticle reports customers seeing match rate improvements from 30% to over 100%. Hightouch claims it beats LiveRamp in head-to-head tests on several platforms. I haven't run those tests myself, so take the comparative claims with the usual pinch of salt, but the underlying gain is consistent across vendors and it lines up with how the mechanic works.

Who's shipping it?

LiveRamp has done a version of this for years through its identity graph, so the approach has a track record. What's different now is that it lives as a toggle inside the CDP you already own, rather than a separate onboarding contract. Hightouch even uses some of the same aggregated third-party datasets LiveRamp does, a family resemblance nobody mentions a lot.

Zeotap is worth pausing on, because it comes at this from a different starting point. It's European, built with GDPR at the core, and it markets the capability through a deterministic identity graph with custom match logic and match-rate reporting rather than raw reach figures. For anyone operating under European rules, that framing matters more than another percentage point, which is why I'd think twice before lumping it in with the US players by default.

So the cast is Hightouch, Zeotap and mParticle, with LiveRamp as the elder statesman. Expect more to follow. When three vendors ship near-identical features in one quarter, the category has decided something.

Before you switch it on

None of this should put you off the feature. Give it an afternoon of understanding first and you can use it with confidence. A few things are worth checking.

The first is what that in-flight enrichment means for how you think about your own data. What you activate on Meta is now a richer profile than the one you hold internally. That's fine, as long as you can explain it when your data protection officer asks why a customer who gave you a work email is being matched on a personal mobile. You want that answer to hand before an audit, rather than discovering the question during one.

The second is consent, and this is the one I'd genuinely slow down for. These platforms let you configure opt-out rules and suppression. The real question is whether your consent signals are actually wired into those rules. If your consent management platform and your CDP aren't talking properly, you can enrich and activate someone who opted out of advertising, and the enrichment layer won't know any better. The gap is easy to fix. It just has to be fixed before you flip the switch.

The third is picking sensible first use cases. Suppression and retargeting of people who are already your customers is the lowest-risk, highest-value place to begin. Enriching a cold prospecting audience is a different conversation, especially in Europe and especially in regulated sectors. One practical detail for global campaigns: mParticle's enrichment is currently US-only. If your audiences are European, check the data residency story before you assume parity.

So, is match boosting worth it?

I'll be honest, I came at this expecting to dislike it more than I do. The performance case is sound, and the in-flight design is a real improvement on the bad old days of handing your entire customer list to a broker and hoping. The technology is the easy part. What needs your attention is the half-hour of consent and use-case housekeeping that should happen before the toggle goes green.

That's the part that tends to get skipped, because the feature is built to be effortless, and effortless things invite a certain carelessness. A one-click setup doesn't mean a one-click decision.

Martech Stack Builder — Plan, Evaluate & Govern Your Stack

Map your vendor landscape, run AI-powered evaluations, manage procurement, and track costs — on one canvas. The planning tool for martech architects.

Martech Stack BuilderMartech Stack Builder

If you want to pressure-test how identity matching and enrichment would behave against your own data model, that's the kind of thing the Martech Stack Builder is built for. Worth a look before a vendor demo, not after.

I'm curious whether anyone has switched one of these on in a GDPR-first setup yet. I'd like to know how the consent inheritance held up once it met a real preference centre.