Probabilistic Matching

Probabilistic matching extends identity resolution beyond exact-match rules by using fuzzy and statistical signals to link records. Each probabilistic match produces a confidence score between 0.0 and 1.0 that flows through to audiences and syncs, letting you control the precision/recall tradeoff at query time without re-running the identity pipeline.

Graph Types

Identity graphs have a type set at creation time. The graph type determines whether confidence scoring infrastructure is enabled.

Deterministic graphs work exactly as before — no behavior change. Probabilistic graphs add confidence scoring infrastructure throughout the pipeline: edge tables, profile aggregates, golden record columns, and audience query filters.

Scoring Functions

When you add a merge rule with match type probabilistic to a probabilistic graph, you choose a scoring function that determines how candidate record pairs are compared. Each scoring function targets a specific identifier family and uses a method suited to that data type.

Fuzzy Name (fuzzy_name)

Matches records with similar names using phonetic blocking and string similarity scoring.

• How it works: Records that share the same SOUNDEX code are selected as candidates. Confidence is then computed using a per-warehouse similarity algorithm: Jaro-Winkler similarity on Snowflake, Levenshtein distance on Databricks, and SOUNDEX match on BigQuery.
• Requires: name family identifiers — first_name, last_name, or full_name — mapped on participating models.

Configuration:

Example: “Alice Smith” and “Alice M. Smith” share the same SOUNDEX code. Jaro-Winkler similarity scores 0.92, which exceeds the 0.85 threshold, so an edge is created with confidence 0.92.

IP Cluster (ip_cluster)

Links records that share the same IP address within a configurable time window, indicating they may be the same person or household browsing session.

• How it works: Exact IP address match combined with a time proximity constraint. Records whose timestamps fall within the configured window are treated as candidates.
• Requires: ip_address family identifiers and a timestamp column mapped on participating models.

Configuration:

Example: Two records from IP 192.168.1.1 with events 18 hours apart fall within the 24-hour window. An edge is created with the base confidence configured for the rule (default 0.6).

Household (household)

Links records that share a postal code and have sufficiently similar names, indicating they may belong to the same household.

• How it works: Exact postal code match, followed by SOUNDEX name matching. Both conditions must be satisfied to create an edge.
• Requires: Both address family identifiers (postal_code or zip_code) and name family identifiers mapped on participating models.

Configuration:

Example: Two records in postal code 10001 with names “John Smith” and “J. Smith” satisfy the postal code match. SOUNDEX produces a match, and the resulting name similarity score meets the 0.8 threshold, so an edge is created.

Confidence Scores

Every edge in the identity graph carries a confidence score. Deterministic edges always carry 1.0; probabilistic edges carry the computed similarity score from their scoring function.

Propagation

Confidence propagates through the connected-components algorithm. When two records are linked through one or more intermediate edges, the path confidence is the minimum edge confidence along the path from one record to the other. A single weak link therefore lowers the confidence for all records reachable through it.

Each row in _IDENTITY_GRAPH has a min_edge_confidence column — the minimum confidence on the shortest path from that record to the component root.

Profile-level aggregates in _IDENTITY_PROFILES summarize confidence across all members of the resolved cluster:

Confidence Thresholds

Thresholds control which profiles appear in audience queries and syncs. Records whose min_edge_confidence falls below the active threshold are excluded from results. Thresholds are evaluated at query time, not at pipeline time — you can adjust them without re-running resolution.

Three-Level Hierarchy

Thresholds are resolved with this precedence, highest to lowest:

1. Audience sync override — a per-sync threshold set on an individual sync destination, for destination-specific tuning
2. Audience threshold — a per-audience threshold set in the audience builder
3. Graph default — the default threshold configured on the identity graph itself

If none of the three levels has a threshold set, the effective threshold is 0.0, meaning all profiles are included regardless of confidence.

Example Scenario

Impact on Golden Records

When a probabilistic identity graph has a golden record configured, the _GOLDEN_RECORD table includes a _min_confidence column. This column holds the minimum edge confidence across all source records that contributed to that golden record row.

Audience queries using the golden record path (Path B) filter on _min_confidence >= threshold when a confidence threshold is active. This ensures that audience membership derived from golden records reflects the same confidence controls as direct graph queries.

See Golden Records for the full survivorship configuration reference.

Impact on Audiences and Syncs

Audience Queries

When an audience is linked to a probabilistic identity graph and a confidence threshold is set at any level, the audience query applies the threshold automatically:

• Path B (Golden Record): Filters _GOLDEN_RECORD rows where _min_confidence >= threshold.
• Path C (ROW_NUMBER dedup): Adds AND ig.min_edge_confidence >= threshold to the identity graph JOIN clause.

Lower-confidence profiles are excluded from audience membership counts, size estimates, and previews. Threshold changes propagate to estimates on the next audience refresh without requiring a pipeline re-run.

Sync Activation

Each audience sync can specify its own confidence threshold override. This enables destination-specific precision/recall tuning:

• Ad platforms (Google Ads, Meta): Use a looser threshold (e.g., 0.5) to maximize match rate and reach.
• Email and SMS platforms (Braze, Iterable): Use a stricter threshold (e.g., 0.85–0.9) to protect sender reputation and deliverability.
• CRM platforms (Salesforce, HubSpot): Use an intermediate threshold based on your sales team’s tolerance for fuzzy matches.

When a sync override is set, it takes precedence over the audience threshold and graph default for that sync only.

Best Practices

1. Start deterministic, add probabilistic later — Get your deterministic graph working first and validate cluster quality. Once you understand your data’s identity patterns, create a new probabilistic graph to expand reach with fuzzy signals.
2. Use limit rules aggressively — Probabilistic matching increases the risk of super-nodes because weak signals can chain records together through transitive closure. Set tight cardinality limits on weaker identifier families such as IP addresses and household postal codes. See Limit Rules.
3. Review confidence distributions before setting thresholds — After running resolution, query _IDENTITY_PROFILES.min_confidence to understand the distribution of confidence scores in your graph. Set graph-level defaults based on the shape of this distribution, not arbitrary values.
4. Set graph-level defaults conservatively — A default threshold of 0.5 is a reasonable starting point. Loosen it for specific audiences or syncs where recall matters more than precision.
5. Pair with Audience Boost — Probabilistic stitching expands your first-party graph by linking known records across systems. Audience Boost enriches with third-party identifiers at sync time. They address different gaps and are complementary, not alternatives.
6. Monitor avg_confidence over time — As new data is ingested and resolution re-runs, track avg_confidence at the graph level. A declining average can indicate data quality degradation or a misconfigured probabilistic rule that is creating weak edges at scale.

Next Steps

• Merge Rules — Configure deterministic and probabilistic rules and set rule priorities
• Identifier Families — Map name, address, and IP columns to the families that probabilistic scoring functions require
• Golden Records — Unified profiles with confidence metadata and survivorship rules
• Running Resolution — Execute the identity resolution pipeline and review output tables