Designing match rules and choosing their order

What it does

Match rules decide which rows from different source tables become the same unified profile. You set an order for the tables, then define one or more rules per table pair, each rule being conditions on columns with normalisation and a precision threshold. Get the order and the first two rules right and the rest is tuning; get them wrong and you spend the project explaining why two people are one profile.

Key facts

The first table in the match order is the primary table and forms the basis of unified profiles. Tables only match upwards: table 3 can match against table 2 or table 1, never downwards.
Rules within a match pair run in sequence. The algorithm moves to the next rule only when the current one finds no match, so rule order is precedence, not preference.
Conditions inside a single rule are joined with AND. All of them must hold.
Deduplication rules behave as OR conditions across the table, grouping rows into match groups before cross-table matching starts.
Precision is Low (30%), Medium (60%), High (80%), Exact (100%), or a custom percentage.
Normalisation options include Numerals, Symbols, Text to lower case, Unicode to ASCII, Whitespace, and typed normalisation for Phone, Name (500+ variations and titles), Address and Organization (around 50 company noise words), plus alias mapping and custom bypass values.
Exceptions run after the rule matches and stop false positives — the classic case being twins sharing surname, city and date of birth.
Custom match conditions come in four kinds: Always match, Never match, Bypass and Alias mapping. You download a template, fill in Table1/Table1Key/Table2/Table2Key (table names are case sensitive), then ingest the file as a data source before selecting it.
Alternate rows from deduplication are considered during matching. A hit on an alternate row attaches the record to the winner row.
Select Include all records on a table to treat unmatched rows as unique customers — singletons.
Once you move past the match conditions with Next, you can't remove a selected table or column. Use Back first.

When to use / skip

Start narrow. Compare every secondary table to the primary table only, and resist the urge to define every pair. Comparing everything to everything buys you a handful of extra matches and a unification run that takes hours, and you'll be looking at that runtime every day for the rest of the project.

My standard opening set is two rules per pair: an exact match on a shared strong identifier if one exists (customer number, loyalty ID, verified email), then a composite rule of normalised email or phone plus surname. Add fuzzy conditions afterwards, and always pair a fuzzy condition with at least one exact condition so the fuzzy comparison runs against a small candidate set rather than the whole table.

Don't use fuzzy matching for name variants. That's what Type: Name normalisation and alias mapping are for — fuzzy matching on names produces exactly the false positives that destroy client trust in the first demo.

Where I'd do the opposite: a B2C retail client with no shared identifier, dirty typed-in addresses and a genuine business need to collapse households. There, fuzzy on normalised address with an exception on first name earns its keep. Accept a slower run and budget for a review cycle where someone from the business looks at a sample of matches. Precision above 80% on messy consumer data mostly just under-matches quietly, which is harder to spot than over-matching.

Configuration decisions

Which table is primary — the one with the most complete and reliable profile data and the most columns in common with the others, not necessarily the biggest.
The full table order, since it determines which pairs are even possible.
Which columns are exact-match candidates, and whether their uniqueness holds in production rather than in the extract you were given.
Precision level per condition, and whether a custom percentage is justified over the four preset levels.
Which normalisation types apply per column, and whether you need alias mapping or bypass lists for known junk values like [email protected].
Whether unmatched rows in each table become singletons via Include all records, or are dropped.

Gotchas

Duplicates left in the primary table are not consolidated when it's matched against a secondary table. Deduplicate the primary table properly first or you carry the duplicates all the way through.
A warning icon next to a table name means no rule is defined for that match pair. It's easy to miss and the table then contributes nothing.
Custom match files are ordinary data sources. Someone deleting or failing to refresh them changes matching behaviour with no obvious cause.
Rule order changes shift which rule wins, which can split or merge profiles and reassign CustomerId values downstream.
Not being able to remove a table or column after moving on with Next catches everyone once. Check the selection before you proceed.
Matching on a column that looks unique but isn't — a purchase or transaction ID, or a form default like "Firstname" — creates enormous match groups and a run that never finishes.

Consultant notes

Add rules one at a time and record the Unique records count after each. If a rule doesn't move the number, take it out; you're paying for it on every refresh.
Watch unification runtime under Settings > System > Status > Match from day one. Clients notice a four-hour job long before they notice a slightly better match rate.
Get a business person to eyeball 50 matched pairs before go-live. It's the cheapest quality gate available and it turns matching from your risk into a shared decision.
Tell the client plainly that matching is never finished. Budget a tuning session a month after go-live, when real data has exposed the rules that were tuned on an extract.

Worth revisiting if the normalisation library or the precision options change, or if a rule-level match preview ever ships.