Entity resolution for customer and company records

Comparing two rows is easy. The difficulty is that matches are transitive and inconsistent: row 1 matches row 2 on email, row 2 matches row 3 on name and company, and row 1 and row 3 look nothing alike.

DataUntangler builds each cluster around one anchor row, the record it proposes to keep, and a row joins only when it matches that anchor by a rule it can name. That is how the CRM, event and billing rows below became one person: two matched the anchor on email and on name and company. It is also why a loose chain (A shares an address with B, B shares a first name with C) never turns a whole file into one group.

When rows merge, something has to be kept. The default here is the most complete row, measured by how many fields are filled, with ties broken by file order. That row is shown as the one to keep and the others are shown as merging into it.

You can reject any cluster, which keeps every row as it was. Nothing is deleted from your original file in any case: you download a new file, and the rows you merged away are listed in the audit log with the row they merged into.

A production entity resolution system is a real project: blocking strategy, model tuning, a golden record store, an operations plan. It is the right answer when resolution has to happen continuously across systems.

It is the wrong amount of work for a one-off file that needs to go into a new CRM on Friday. That is the case this tool is built for. The pairwise scoring underneath it is fuzzy matching, the version aimed at an account and contact export is CRM data cleansing, and the data cleaning tool runs all of it in the browser. A supplier file headed for a new ERP is the same problem on the payables side, covered under vendor master data cleansing.

We merged a CRM export, an event list and a billing file into one eleven row CSV and ran the engine on it. Margaret Chen appeared three times. The CRM row and the event row (Maggie Chen, email in capitals with a trailing space) share an email address. The billing row has a personal Gmail address but the same name and company as the CRM row. No pair of rows explains the whole person, yet the engine returned all three as one cluster.

It also stayed out of three places a careless tool walks into. James Porter at Porter Law Office and James Porter at Summit Financial are two people, so they were not proposed. Sarah and Sara Lindqvist at Pinecrest Medical Group were proposed as a close match and flagged for a look, because the emails differ. Every cluster from that run is in the table below, and the matching rules behind them are on the data deduplication tools page.

Most entity resolution software is sold as part of a master data management program, and it is priced and staffed like one. That is the right purchase when records have to stay resolved across live systems every day. It is a heavy purchase when the job is one file, one migration or one quarterly list. Compare the categories on what you actually need this month.

The people who pay for this are the ones holding the merged file when somebody asks why a customer disappeared: a RevOps lead consolidating two CRMs after an acquisition, a finance analyst joining a billing system to the CRM before a revenue review, or an ops manager loading three event lists into one marketing platform. They need the entities resolved this week and a record of every merge.

The Analyst plan runs unlimited files of up to 25MB each, and Enterprise puts several people on one invoice with a DPA. See pricing, or run the demo above on your own export first. Nothing leaves your browser in the demo.