Supercluster detection

Supercluster detection flags over-merged identity clusters, quarantines the identifier values that caused them, and lets you decide whether to keep or block each value while your graph keeps running.

What you'll learn

After reading this article, you'll know how to:

1. Identify when IDR flags potential superclusters
2. Understand how quarantining keeps your graph updating
3. Locate quarantined values in the UI
4. Understand which identifiers are causing over-merging
5. Decide whether to keep or block flagged identifiers
6. Confirm that reprocessing resolved the issue

Overview

Supercluster detection helps you detect and resolve over-merged identity clusters caused by high-cardinality or low-quality identifiers, such as shared emails or placeholder IDs.

When IDR detects potential over-merging, it quarantines the identifier values involved and finishes the run without them. The rest of your data keeps flowing into the graph, and you can review the quarantined values whenever you're ready.

This feature lets you:

• Identify identifiers causing excessive merging
• Keep your graph updating while flagged values wait for review
• Allow valid high-volume identifiers
• Block problematic identifiers and reprocess affected clusters

What is a supercluster?

A supercluster is an identity cluster that grows unusually large and oftentimes merges different identities together.

This can be caused by:

• Shared or default identifier values
• Corrupted or reused IDs
• Unexpected upstream data issues

How IDR detects potential superclusters

During each graph run, IDR monitors how identifier values contribute to cluster growth.

If a single identifier value links together an unusually large number of source rows within the same cluster, IDR flags that cluster as a potential supercluster. This helps surface cases where shared, default, or corrupted identifiers may be causing accidental over-merging.

Example

Let's say the threshold for detecting a supercluster was 3 source rows per identifier value.

1. Ingest source rows

The graph ingests rows containing the identifiers email and user_id:

2. Build identity clusters

During resolution, rows are grouped into clusters based on shared identifiers.

All rows containing fake@email.com are merged into the same cluster.

IDR then counts how many source rows each identifier value appears in within that cluster:

3. Flag and quarantine the value

Because the identifier value fake@email.com appears in 3 source rows, it exceeds the example threshold used here.

As a result:

• The cluster containing that identifier is flagged as a potential supercluster
• IDR quarantines fake@email.com and re-runs without it, so rows 4, 5, and 6 resolve on their remaining identifiers
• The run completes, and fake@email.com waits for you to Keep (allow) or Block it

Quarantining

Quarantining is a safety mechanism that keeps potential superclusters out of your identity graph without stopping graph updates.

When IDR detects a potential supercluster, it quarantines the identifier values that caused it, rewinds to the last stable state, and re-runs without those values. The run completes, and every row that doesn't depend on a quarantined value updates the graph as normal. Quarantined values stay out of new merges until you review them.

While a value is quarantined:

• Existing rows and clusters are unchanged
• New rows that carry the value are ingested, but the flagged value is ignored, so the cluster can't grow
• The value will not be flagged again on future runs

If IDR still detects a supercluster after re-running a limited number of times, the run fails with a Quarantined: superclusters detected status, and the graph remains in its previous state.

Resolve superclusters

The following steps walk through how to review and resolve quarantined values.

Step 1: Run your identity graph

Supercluster detection runs automatically as part of each identity graph run.

If potential superclusters are detected, the run completes with a Completed: superclusters quarantined status.

Step 2: Open the supercluster review flow

You can access quarantined values from several places:

• Graphs list view — Shows Completed: superclusters quarantined in the Last run column, with a Review and verify button, while any values are waiting for review.

  

• Graph summary tab — Displays a warning banner with the number of quarantined identifier values.

  

• Graph runs — Labels the run that flagged the values, and keeps the label after you've made your decisions.

  

• Identifier settings — Each identifier's blocked values drawer has a Quarantined tab listing its flagged values, with a Review cluster link for each one.

From any of these views, select Review and verify to open the superclusters drawer. From a run, the drawer is titled Superclusters flagged on followed by the run's start time. From the graph list or summary tab, it's titled Superclusters quarantined for review.

Step 3: Review flagged clusters

In the superclusters drawer, the Flagged clusters impact chart and the cluster list show:

• Each flagged cluster
• The total number of source rows in each cluster
• Which identifiers caused the cluster to be flagged

This helps you identify which clusters have the highest impact.

Step 4: Review flagged identifiers

Expand a cluster to review its flagged identifiers.

For each identifier, IDR shows:

• Identifier type and value
• Source row count — how many rows include the identifier
• Percentage of the cluster linked by that identifier

High row counts and high percentages often indicate accidental over-merging.

Step 5: Inspect identifier details (recommended)

In the superclusters drawer, select an identifier value to open Identifier details.

This view helps you understand why the identifier was flagged by showing:

• How many unique values of other identifiers are linked
• Which source models the rows come from
• A random sample of linked source records

High diversity (for example, many distinct user_id values tied to one email) is a strong signal of over-merging.

IDR captures this evidence when it flags the value, so it stays available after later runs.

Step 6: Decide how to handle each identifier

For every flagged identifier, choose one of the following actions. You can decide on values one at a time. Values you haven't decided on stay quarantined.

Keep (allowlist)

Choose Keep if the identifier is expected and valid at scale.

• The identifier is added to the graph's allowlist
• It won't be flagged in future runs
• On the next run, IDR re-ingests the rows that carry this value and merges on it

Block (blocklist)

Choose Block if the identifier is causing accidental over-merging.

• The identifier is added to the graph's blocklist
• It's ignored in future resolution
• On the next run, IDR removes the value from rows that already carry it and breaks the cluster apart

Step 7: Submit your decisions

Select Submit actions to save your decisions. You don't have to decide on every value before submitting. The footer counts how many values still need action.

On the next run:

• Clusters containing blocked identifiers are split
• Rows that carry a kept identifier are merged back into the graph
• Identity resolution is recalculated using the remaining identifiers

Step 8: Verify results

After the next run completes:

• Review updated cluster sizes
• Confirm that over-merging has been resolved
• Verify downstream systems receive corrected identities