Skip to main content
Graph Studio is the platform’s identity graph building tool. Its Edge Builder and Graph Builder work together to transform your raw data into a connected identity graph, and its Addressable Graph Builder turns a finished graph into something activation platforms can match against.

​
How it works

Building an identity graph is a two-step process:
  1. Define edges — Tell the platform which identifiers in your data should be used to connect records. Two records that share the same identifier value (like the same email address) are linked together.
  2. Build the graph — The platform runs a connected components algorithm over your edges to discover which records belong to the same person or household, resolving transitive connections across multiple hops.

​
Edges

An edge connects a source record to a target identifier. The Edge Builder creates an edges dataset by combining your data sources with the identity attributes you choose as connection points.

​
Key concepts

Each source record produces one edge per target ID group. When two records from any source share the same target ID value, the graph recognizes them as connected.

​
Target ID groups

Target IDs are organized into groups. Each group defines one type of connection, and the two levels combine differently:
  • Within a group, attributes combine with AND. A group can contain a single attribute or multiple attributes — when a group has multiple attributes, all values in the group must match for two records to be connected. Adding attributes to a group makes that connection stricter.
  • Across groups, connections combine with OR. Each group is an independent way for records to connect — two records are linked if they match on any one group. Adding more groups gives the graph more ways to find connections.
For example:
  • A group with just normalized email connects any two records sharing the same email — high confidence, since email is typically unique to a person
  • A group with phone number + first name requires both values to match, which is more precise than phone alone — useful when a phone number might be shared across a household
If both groups are defined, two records connect when they share the same email or the same phone-plus-first-name combination.
A single group is a complete, valid configuration. If you only want to match on one identifier — say, a hashed email — define one group containing just that attribute. You only need additional groups when you want the graph to have additional, independent ways to connect records; you are never required to include every identity attribute mapped on your dataset.

​
Data sources

The Edge Builder accepts two types of sources:
  • Datasets (first-party) — Your own data, mapped to Rosetta Stone attributes
  • Access rules (third-party) — Data shared with you by other companies. Third-party sources introduce connections that your first-party data cannot see on its own.

​
Graph

The Graph Builder takes one or more edges datasets and runs a Label Connected Components algorithm. It follows connections between records — including transitive chains — and groups every connected record into a single identity.

​
Identifier types in the build

Every target ID type on the selected edges enters the graph by default. The Input Configuration step also lists the identifier types it found on those edges — one entry per target ID group that produced edges — and you can uncheck any the graph should not be built on. An unchecked type’s edges never reach the graph, and the source datasets’ own Rosetta Stone mappings are left alone, so every other consumer of those datasets still sees that identifier. Leaving every type checked is the same as making no choice at all: the build is identical to one made before the selector existed. Include all returns to that state, and so does unchecking the last remaining type — narrowing the list can never produce a graph with no edges.
The list is drawn from the identifier types observed on the selected first-party edges datasets. Third-party access-rule sources are narrowed by the same list, but their own identifier types are not in it — so once you narrow the selection, an identifier type that only a third-party source contributes is excluded along with everything else you unchecked.

​
Algorithm parameters

The defaults work well for most use cases.

​
Output

The graph produces a dataset where each record is assigned a component ID — all records with the same component ID belong to the same resolved identity. You can join this back to your original data for analytics, segmentation, and activation.

​
Automation

You can run the graph build once or set a refresh schedule to keep it current as source data changes. You can also optionally encode identifiers in the output using your company’s encryption material.

​
Addressable graphs

A resolved graph tells you which records belong to the same person. It does not tell you how to reach that person on an ad platform, because each platform accepts only certain identifier types. The Addressable Graph Builder closes that gap: it takes a graph you have already built and produces a table pairing each resolved identity with the identifiers the platforms you selected can actually match on. This is addressability expansion applied to your own graph rather than to a third-party append. The builder works through seven steps:

​
Platforms and identifier types

Each supported platform accepts its own identifier types, and that is what makes a property worth encoding:

​
Targeting properties, and why identifiers are flagged

The Targeting properties step sorts what it found into three groups: recommended attributes, other properties, and identifiers, which are marked as not recommended. The distinction is deliberate — an identifier makes a person reachable but makes a poor targeting dimension, and selecting one as a targeting property widens the audience table without improving how you can segment it.

​
Output

The builder produces the addressable table and a companion audience table beside it, both materialized in the selected data plane and tagged with their lineage and the platforms they were built for. Before generating anything you can review the NQL and the workflow specification the builder assembled, so the query that will run is visible rather than implied.

​
Source eligibility

Not every dataset or access rule appears in the Graph Studio source pickers. Each builder only lists sources that have been prepared for the step you’re on — the Edge Builder lists sources that are ready to become edges, and the Graph Builder lists the edges datasets that are ready to be resolved into a graph. If a source you expect is missing, it hasn’t met the requirement for that list. Under the hood, eligibility is driven by dataset and access-rule tags and Rosetta Stone attribute mappings:
The _nio_ci_* tags are managed on the dataset or access rule itself. First-party data becomes edge-eligible when it’s tagged _nio_ci_components; the Edge Builder’s output edges datasets are mapped to graph_edge, which is what makes them appear in the Graph Builder. If a source is missing from a picker, check that it carries the tag or mapping listed above.

​
Data plane support

Graph Studio runs on both Snowflake and AWS data planes. Both the Edge Builder and the Graph Builder are available in either environment — the Graph Builder uses the platform’s LabelConnectedComponents workflow task for step 2, which is cross-platform.

​
Related content

Identity Graphs

How connected components and graph structure unify identifiers

Building an Identity Graph

Step-by-step guide to creating your first graph

Graph Enrichment

Strengthen graph structure with third-party linkage data

Mapping Schemas

Map your data to Rosetta Stone attributes