Match rules and match order across tables

What it does

The match step links records for the same customer across tables. You order the tables, then define rules for each table pair saying which columns must agree and how closely. Records that match are consolidated into one unified record carrying columns from every table involved.

Key facts

Only appears when two or more tables were selected in the Customer data step. Single-table unifications go straight from dedupe to the unified data view.
The first table in the list is the primary table and forms the basis of the unified profiles. It should be your most complete and most reliable customer source, with the widest overlap of common columns.
Matching is strictly downward through the order: Table 2 matches against Table 1, Table 3 matches against Table 2 or Table 1. A table never matches against something below it.
Reorder with the up/down arrows or drag and drop. Ordering is a design decision, not cosmetics.
Include all records on a table brings unmatched rows through as their own singleton profiles. Leave it off and those customers simply don't exist in the unified profile.
A rule is a set of conditions combined with AND. Multiple rules per table pair are allowed and are evaluated in sequence, so rule order within a pair matters too.
Precision per condition: Low (30%), Medium (60%), High (80%), Exact (100%), or a Custom percentage.
The same normalisation set as deduplication applies — phone, name, address and organisation types, case, symbols, whitespace, Unicode to ASCII, plus preview Alias mapping and Custom bypass.
Exceptions stop a match that the rule would otherwise make. The documented example is a rule on last name, city and date of birth catching twins, blocked by an exception on first name.
Custom match conditions override the algorithm using an ingested override table: Always match, Never match, Bypass and Alias mapping. You download a template, fill in Table1/Table1Key and Table2/Table2Key pairs, rename it without spaces, ingest it as a data source, then select it. Table names in the template are case-sensitive.
Once match conditions are created you can't remove tables or columns from that screen — you go Back to the earlier step to revise.
Alternate (non-winner) rows from deduplication are considered during matching, but records match to winner rows.
Enriched tables can be selected as match inputs, in preview.

When to use / skip

If you have more than one customer source, you have to do this, and it's where most of the real work in a Customer Insights build lives. The question is not whether but how hard: a two-source build with a shared email column takes an afternoon; a five-source build spanning loyalty, e-commerce, CRM and a legacy billing system takes weeks and several rounds of review with people who know the data.

Where you can consciously go light is when one source dominates. If 90% of profiles come from CRM and the other sources only add a handful of columns to a small population, a single Exact rule on email each way is often enough, and the effort is better spent elsewhere.

Custom match conditions are the exception to "configure it properly". They're for genuine, known, unfixable cases — a merged company where two IDs are the same person and no rule will ever see it. Using them as a general correction mechanism means you're maintaining a hand-curated identity map forever.

Configuration decisions

Table order, and specifically which source is primary. This drives which profiles exist and, later, the default merge importance ranking.
Include all records per table — effectively deciding whether that source's non-matching customers are in scope for marketing at all.
One rule per pair or several. Several tighter rules (exact email, then exact phone plus surname) usually beat one loose rule and are far easier to explain.
Precision and normalisation per condition, with a documented rationale for anything below High.
Whether exceptions are needed for known collision patterns — households, twins, shared corporate email addresses, generic info@ addresses.
Whether custom match overrides are in scope, who maintains the override table, and how it gets refreshed.

Gotchas

Getting the table order wrong is expensive to fix later, because match rules, merge importance and profile population all follow from it. Decide it with the client's data owners, not on your own.
Tables can't be added or removed from the matching screen once conditions exist. It isn't a one-way door, but it does mean stepping back through the wizard.
Duplicates surviving in the primary table stay as separate profiles unless they match a secondary table. Match rules don't rescue a weak dedupe configuration.
Rules within a pair evaluate in sequence, so a loose rule placed first can consume records you wanted a tighter rule to catch.
The custom override template is case-sensitive on table names and rejects spaces in the file name. Both fail quietly enough to waste an afternoon.
Generic email addresses (info@, sales@, noreply@) are the most reliable way to merge dozens of unrelated people into one profile. Bypass them explicitly.
Turning Include all records off on a source silently shrinks the profile count. People notice weeks later when a segment comes back short.

Consultant notes

Use Run matching conditions only to iterate. It updates the deduplication and ConflationMatchPair tables without touching the unified profile or dependencies, so you can test rule quality without a full run.
Show the client match scores on real records, including a few near misses. Abstract precision percentages mean nothing; two records side by side mean everything.
Agree an acceptable false-positive rate in writing. Someone will eventually find two people merged into one profile, and you want that conversation to have happened already.
Push back on match rules built purely on name and address for consumer data. They look impressive in a demo and cause complaints in production.
Before go-live, check the profile count against what the business expects per source, and confirm the Include all records setting matches that expectation on each table.

Worth another look if the client adds a source system, or when Alias mapping and enriched table matching leave preview.