Three systems, one customer, three different Daves
Salesforce has Dave Menzies, VP of Operations at Northline Supply, last touched by a rep in March. Shopify has an order from d.menzies@northlinesupply.com with no company name attached, shipping to a warehouse in Reno. Klaviyo has "Dave M." on a gmail address, subscribed in 2021, opens everything, never clicks.
Same person. Three records. Zero connections between them. So your rep doesn't know Dave buys consumables online every six weeks, your email team treats him like a cold subscriber, and your revenue reporting counts him twice.
Multiply that by 50,000 records and you have the problem that vendors call identity resolution. Then they tell you the answer is a customer data platform, a six-figure contract, and a four-month implementation with a partner agency.
For a company with thirty source systems, event streams, and real-time personalization needs, that might be true. For a company with a store, a CRM, and an email platform, b2b identity resolution is a matching exercise. You need match keys, a hierarchy, survivorship rules, and a place to put the result. All four fit on one page.
Decide what you're resolving: person, account, or buying group
Before you match anything, decide what a "customer" is. Your three systems already disagree, which is half the reason your data looks broken.
Shopify thinks in orders attached to email addresses. Your CRM thinks in accounts with contacts hanging off them. Your email platform thinks in subscribers, one row each, no hierarchy at all. Each is right inside its own walls and wrong the moment you combine them.
In B2B you usually need two levels, sometimes three. Resolve people first, then roll them up to accounts. The third level, what consumer data people call a household, is the buying group: several people at the same company who order on the same card, ship to the same dock, or share a procurement login.
Write the definitions down before you write any rules. A one-paragraph definition of "person" and "account" will settle more arguments than any matching tool.
- Person: a single human being, identified across systems. Dave Menzies is one person even with three email addresses.
- Account: the company that pays. Northline Supply is one account even if three people order separately.
- Buying group: people inside one account who behave as a single purchasing unit. Worth separating when ship-to addresses or payment methods are shared.
Choosing match keys, and knowing exactly where they break
A match key is the field you compare to decide whether two records are the same thing. Most teams reach for email, get burned, and conclude matching is impossible. Email is a good key. It is not a reliable one on its own.
Pick two or three keys and understand their failure modes before you trust them. Here is how the usual candidates behave in B2B data.
Standardize before you compare. Lowercase every email, strip whitespace, normalize phone numbers to digits, and reduce domains to their root. AutoFormat handles this during the cleaning step so you're matching on comparable values instead of on formatting noise. "Northline Supply, Inc." and "northline supply inc" are the same company, but only one of them matches.
The strongest approach is layered. Match on email first, because it is precise when it hits. Fall back to name plus domain. Fall back again to phone plus last name. Each layer catches records the previous one missed, and each layer gets a little less certain, which matters for the next step.
- Email: precise when it matches, but people have work addresses, personal addresses, aliases, and plus-addressing. One person, four keys. Leavers keep their records and their addresses get recycled to someone new.
- Company domain: excellent for rolling contacts up to accounts. Fails on gmail and other free providers, on parent companies that share a domain across subsidiaries, and on franchises that each have their own.
- Phone: surprisingly good for B2B because direct lines change less than you'd think. Fails on shared switchboards, where fifty contacts collapse into one.
- Name: never a key on its own. There are two Dave Menzies in a 50,000 record file and at least one of them spells it Menzes.
- Billing or shipping address: strong for buying groups and accounts, weak for people. Useful as a tiebreaker, rarely as a primary key.
Deterministic matching first, probabilistic matching for the rest
Deterministic matching means the values are identical after standardizing: same email, same normalized phone, same domain plus same last name. It's a yes or no answer, and it's right nearly all the time. For a clean-ish B2B file, deterministic rules will resolve 60 to 80 percent of your duplicates without you looking at a single one.
Probabilistic matching handles the rest. It scores similarity across several fields at once and produces a confidence number instead of a verdict. "Dave Menzies, Northline Supply, Reno NV" against "David Menzies, Northline Supply Inc, Reno" isn't an exact match on anything, but it's obviously the same person, and a scored comparison says so with 94 percent confidence.
The trick is not to treat probabilistic results as decisions. Treat them as a queue. SmartMatch runs both passes, merges the high-confidence matches automatically, and holds the ambiguous ones for a human in the review step. You're not reviewing 50,000 records. You're reviewing the few hundred where the rules genuinely can't tell.
Set your thresholds deliberately. A common starting split: auto-merge above 90 percent confidence, review between 70 and 90, ignore below 70. Run it, check a sample of the auto-merges, and move the thresholds once you've seen how your own data behaves. Nobody gets this right on the first pass, and nothing bad happens, because you review before you export.
LogicGuard sits alongside this and flags the records that don't make sense regardless of matching: an account with a 1908 created date, a contact whose order total is forty times the median, a domain that appears on 3,000 records when the next biggest has eleven. Those are usually test data, imports gone wrong, or a shared switchboard masquerading as a person.
Survivorship: deciding which record wins, field by field
Once two records are a confirmed match, something has to decide what the merged record says. This is survivorship, and it's where most do-it-yourself projects fall apart, because teams make it a record-level decision. They pick a "master system" and let it overwrite everything.
That's wrong, and you already know why. Your CRM has the best job title and the worst email deliverability. Shopify has the most accurate shipping address and no idea what industry anyone is in. Your email platform knows exactly which address a human actually opens and nothing else about them.
Survivorship is a field-level decision. For each field, you name a winning source and a rule. Write it as a table and keep it somewhere everyone can see, because this document is the real asset. The matching is mechanical; the rules encode what your business actually knows.
Here's a starting table for a Shopify plus CRM plus email platform stack. Adjust the sources to yours, but keep the shape.
- Email address | Wins: email platform | Rule: most recently engaged address beats most recently created. An address someone opens is more true than one someone typed.
- First and last name | Wins: CRM | Rule: longest non-null value, then most recent. Catches "Dave" losing to "David Menzies".
- Job title | Wins: CRM | Rule: most recent non-null. Nobody updates titles anywhere else.
- Company name | Wins: CRM | Rule: most recent, standardized. Strip the Inc, Ltd, and LLC suffixes before comparing, keep one canonical form.
- Phone | Wins: CRM, then store | Rule: prefer direct lines over switchboards, most recent non-null wins ties.
- Shipping address | Wins: store | Rule: address on the most recent completed order. Billing and shipping stay separate fields.
- Billing address | Wins: store | Rule: most recent completed order.
- Lifetime value and order count | Wins: store | Rule: recalculate from order records, never copy. Summed fields go stale the day you merge them.
- Lead source and first touch | Wins: oldest record across all systems | Rule: earliest non-null wins. Original attribution survives the merge.
- Subscription and consent status | Wins: email platform | Rule: most restrictive value wins, always. If any system says unsubscribed, the golden record says unsubscribed.
- Account owner | Wins: CRM | Rule: most recent non-null. Never filled from another source.
- Created date | Wins: oldest across all systems | Rule: earliest date. Your customer relationship started when it started.
Building the golden record
The golden record is the single resolved version of a person or account, assembled from the winning value of each field. It isn't a new system. It's a file, and then a habit.
Give every resolved person a stable identifier of your own, something like PER-000148, and every account an equivalent, ACC-00032. Then keep the source IDs alongside it: the Shopify customer ID, the CRM record ID, the email platform profile ID. That cross-reference is the quiet backbone of the whole exercise. Without it, next month's run starts from scratch. With it, you match new records against identities you already resolved.
Fill the gaps while you're in there. SmartFill completes missing fields from the other systems that already have the answer, so the person who exists as an email address in Klaviyo picks up a company, a domain, and a region from the CRM record they just merged with. Fields nobody has stay empty, which is the honest outcome.
In CleanSmart the shape of this is straightforward. DataBridge reads records from Mailchimp, Shopify, Klaviyo, HubSpot, and Salesforce. SmartMatch resolves the identities, AutoFormat standardizes values, SmartFill closes gaps, and LogicGuard flags what looks wrong. You review the matches you asked to review. Then you export the golden records as CSV or JSON, along with a change log of every merge and every field decision, and you import that back into your own platforms on your own schedule. CleanSmart reads from your systems and hands you the results; it doesn't make changes inside them for you.
After each run, a Clarity Score is recalculated across your file. It weights Completeness, Consistency, Uniqueness, and Validity, plus the results of contact verification. Uniqueness is the number that moves most on a first identity resolution pass, often dramatically, because duplicates are exactly what you just resolved. A run takes a few minutes, so you can rerun after adjusting thresholds and see where you landed.
If you want the field-by-field mechanics for a specific stack, our walkthrough of unifying Shopify, Salesforce, and HubSpot works through the mapping in detail. This article is the method; that one is a worked example.
When you genuinely do need a CDP
This isn't a case for never buying one. There are real conditions where a platform is the right call, and it's worth checking whether you meet them before you spend the money or after you've spent three months building something that doesn't scale.
You probably need a CDP if you have more than ten meaningful source systems, if you need resolved identities available to other systems within seconds rather than after a batch run, if you're building audience segments that push into ad platforms continuously, or if you're handling tens of millions of records with behavioral event streams attached. Real-time personalization on a high-traffic site is the clearest case of all. Batch matching can't serve a decision that has to happen while the page loads.
You probably don't need one if you have three to five systems, under a few hundred thousand records, and a weekly or monthly cadence for unification. That describes most B2B companies under 200 employees, and it describes a lot of companies currently sitting in a CDP evaluation because identity resolution got filed under "platform problem" by default.
The honest test: write down the question you can't answer today. If it's "which of these records are the same person," that's matching, and you can solve it this quarter. If it's "what did this person do in the last four seconds and what should the site show them," that's a platform, and you should go buy one.
Start with the matching, not the purchase order
Identity resolution feels enterprise because the vendors who sell it are. The underlying work isn't. Choose your match keys, layer them from precise to probabilistic, write survivorship rules field by field, assign stable IDs, and keep a cross-reference. That's the whole method, and it holds at 50,000 records as well as it holds at 50 million.
The practical move is to run it once on real data and see what comes back. Connect your store, your CRM, and your email platform, let SmartMatch do the deterministic pass and score the rest, then look at the review queue. The ambiguous matches will teach you more about your own data in twenty minutes than a vendor evaluation will in six weeks.
Build your golden record with SmartMatch. Try the self-serve product demo and run a matching pass against your own file before you decide you need anything bigger.
Frequently Asked Questions
How many records can you resolve without a CDP?
Most teams handle a few hundred thousand records across three to five systems with batch matching and clear survivorship rules. The constraint is usually the number of sources and how fast you need results, not raw record count.
What's the difference between deduplication and b2b identity resolution?
Deduplication removes repeated records inside one system. Identity resolution connects records that describe the same person or account across different systems, then decides which values win. Deduplication is one step inside the larger job.
Does CleanSmart update the records in my CRM or store?
No. DataBridge reads records from connected platforms, and CleanSmart delivers resolved golden records as a CSV or JSON export plus a change log. You import that back into your own systems, so you stay in control of what changes and when.