Tells relatives apart
A father and son with the same name at the same address are separated by their birth dates.
Customer data is rarely clean. People use nicknames, mistype their address, change their last name, move, and fill out forms from work. Instead of requiring a perfect text match, the engine looks for agreement across every detail you send, using three approaches in order.
Each step runs only for records that earlier steps have not yet matched to a specific person.
Deterministic matching finds an exact, verified connection in the graph. It’s fast and very precise, and it handles the everyday differences that defeat simple text comparison:
How: Bill is a recognized nickname for William, and the address agrees exactly.
How: The email is connected to a Michael Chen in the graph, so no postal address is needed.
How: Name, ZIP code, and date of birth together identify one person, even without a street.
How: First name, date of birth, and address all agree. The different last name doesn't block the match.
When there is no exact connection, probabilistic matching weighs every detail together. Strong agreement on some details can outweigh small differences in others, such as a typo, a road alias, a different unit format, or a neighboring ZIP code.
Some differences are never outweighed. A candidate is ruled out if the house numbers differ, the unit numbers conflict, the first names cannot be the same person, or the birth dates are more than 18 years apart.
How: State route and highway names are treated as the same road when the house number, ZIP code, and name agree.
How: House number, street, and ZIP code agree exactly. Mikey is a nickname for Michael, and Jehnson is a single-letter phonetic variation. Together the details clearly point to one person.
How: Unit labels such as Apt, Suite, Unit, and # are normalized, so both records point to unit 4B. The hyphenated last name contains the graph surname.
How: Same name, house number, and street in a neighboring ZIP code in the same area. This is common when a ZIP code is mistyped or an address sits near a ZIP boundary.
If neither approach can place a record and you sent a first and last name, the spatial engine looks at where the address actually is. It evaluates physical proximity and density to locate the same person within a realistic distance. This is how it finds someone who moved between buildings in an apartment community or who submitted an office address.
Explore the spatial engine, its modes, and examples →
Date of birth is optional, but when you have it, it strengthens matching in every approach:
A father and son with the same name at the same address are separated by their birth dates.
Name + ZIP + date of birth needs no street. First name + date of birth + address works after a last-name change.
An exact birth date raises confidence. Birth dates more than 18 years apart are never accepted as the same person.
If you don’t collect date of birth, nothing is held against the record. The engine matches on your other signals.
Every match reports a match_level. Choose which levels you accept for each request or file; all five are included by default.
| Level | What it confirms | Typical uses |
|---|---|---|
| I · Individual | The specific person, confirmed by name plus address, email, phone, or date of birth. | Personalized outreach, direct mail, CRM cleanup and deduplication. |
| H · Household | The home and family, confirmed by last name plus address. | Household offers, direct mail, home services. |
| D · Digital | A known email or phone, without a confirmed name. | Digital advertising audiences, newsletter and web enrichment. |
| S · Spatial | The person, placed by the spatial engine near the address you sent. | Workplace leads, recent local movers, apartment communities. |
| A · Address | The physical address only. | Property and neighborhood insight, territory planning. |
If a record qualifies at more than one level, the most specific result wins: an Infinite Audience Graph Person ID you sent, then I, D, H, S, and A. A spatial match can replace an address-only match because it identifies a person, not just a place.
How: Last name and address agree, but no Linda lives there in the graph, so the result is the household rather than an individual person.
How: The email is connected to one person in the graph. No name was sent to confirm, so the match is Digital.
How: With no name, email, or phone, the result describes the place, not a particular resident.
While match_level gives the category (I, H, D, S, or A), every returned match also includes a specific match_type. This records the exact combination of signals that resolved the record:
| Level | match_type |
What made the match |
|---|---|---|
| Prior level or empty | graph_iag_person_id_match |
Recognized Person ID sent directly; preserves prior match provenance without establishing a new Individual match. Person IDs → |
| I · Individual | graph_name_address_match |
First name + last name + street address + zip |
| I · Individual | graph_name_email_match |
First name + last name + email |
| I · Individual | graph_name_phone_match |
First name + last name + phone |
| I · Individual | graph_name_zip_dob_match |
First name + last name + zip + date of birth (no street needed) |
| I · Individual | graph_first_dob_address_match |
First name + date of birth + address (resolves across last-name changes) |
| I · Individual | graph_fuzzy_street_match |
Name + street with highway/route alias or minor spelling difference |
| I · Individual | probabilistic_name_address_match |
Weighted agreement across name, address, unit, or neighboring zip |
| H · Household | graph_last_name_address_match |
Last name + street address + zip (different first name or family unit) |
| D · Digital | graph_email_match |
Email alone |
| D · Digital | graph_phone_match |
Phone number alone |
| S · Spatial | spatial_match |
Name + physical coordinate proximity within residential or commuter radius |
| A · Address | graph_address_match |
Street address + zip alone (property and neighborhood profile) |
Every match includes a match_confidence score between 0 and 1. Matches confirmed by several agreeing details score near 1.00. Matches with less corroboration score lower.
By default, a match must score at least 0.80 to be returned. Below that, the record is left unmatched rather than guessed. Unmatched rows stay in your results so nothing disappears.