Lookup table usage

Overview

After an identity graph runs, Identity Resolution writes a set of output tables to your data warehouse. These tables represent the current state of your identity graph and are designed for downstream use across analytics, activation, and Customer Studio.

Your marketing team can use these tables for paid campaigns, your sales team for deduplicating outreach efforts, and your data science team for fraud detection.

Where identity outputs live

Identity Resolution writes output tables to your warehouse, typically in the hightouch_planner schema (or a schema override configured for your source).

These tables act as stable integration points. You can use them to:

• Query them directly in SQL
• Register them as dbt sources
• Use them to build analytics models or views
• Use them as the foundation for Customer Studio schemas
• Sync from them to downstream tools

Core output tables

Each identity graph produces the following output tables.

Resolved table

<output_prefix>_resolved

This table maps every input row used in Identity Resolution to a resolved identity.

Each row represents a single input record and includes:

• ht_id: the resolved identity ID
• source: the originating model
• primary_key: the primary key value of the input record
• latest_timestamp: the most recent timestamp for that record

Use this table when you need to:

• Join raw source data to resolved identities
• Aggregate metrics at the identity level
• Trace how specific records were grouped into profiles

Example output

Resolved identifiers table

<output_prefix>_resolved_identifiers

This table contains all identifier values associated with each resolved identity.

Each row represents a single identifier value observed for that identity, along with when and where it appeared.

Each row includes:

• ht_id: the resolved identity ID
• identifier: the identifier type (for example, email or user_id)
• value: the identifier value
• first_timestamp and last_timestamp: when the value was first and last seen
• count: how many times the value appeared across input records
• Lineage fields identifying the originating record and model (initial_row_pk, initial_row_source)

Use this table when you need to:

• Retrieve the full set of identifiers associated with an identity
• Sync multiple identifiers per identity to downstream destinations
• Inspect how specific identifiers contributed to identity resolution

Example output

Unresolved table

<output_prefix>_unresolved

This table contains input rows that could not be processed, most commonly because primary key values were not unique within the originating model.

Use this table to:

• Debug data quality issues
• Identify records excluded from identity resolution

Golden Record table

<output_prefix>_golden_records

If you enable Golden Record, Identity Resolution produces a flattened table with one row per resolved identity. This table selects a single, trusted value for each field based on the survivorship rules you configure, creating a marketer-friendly profile representation for downstream use.

Each row includes:

• ht_id, which uniquely identifies the resolved identity
• One column per field configured in Golden Record
• Values selected using survivorship rules such as recency, frequency, source priority, or array

Golden Record is the most common starting point for analytics and activation because it provides a clean, one-row-per-identity view with canonical fields.

Example row

Each row corresponds to a single HT_ID (one identity). For example, a row might look like:

{
  "ht_id": "ht1",
  "most_recent_email": "user@example.com",                -- using most recent survivorship
  "all_phone_numbers": ["123-456-7890", "098-765-4321"],  -- using array survivorship
  "primary_user_id": "user_123"                           -- using source priority survivorship
}

For configuration and survivorship rules, see Golden Record.

State tables

Identity Resolution also creates internal state tables—typically prefixed with IDR_... or IDR_BACKUP_...—to support incremental processing and maintain graph consistency in the same schema.

These tables are managed by Hightouch and should not be queried or modified directly.

Common usage patterns

Analyze data at the identity level

A common pattern is to aggregate activity or metrics by ht_id rather than by raw records.

You can do this by joining source tables (such as events or transactions) to the resolved table and grouping by ht_id. This lets you analyze behavior, engagement, or revenue at the resolved identity level instead of the raw‑record level.

Use Golden Record for analytics and reporting

Golden Record is typically used as the primary table for analytics and Customer 360‑style views.

Patterns include:

• Starting from <output_prefix>_golden_records as the base table
• Joining transactional data (such as orders or subscriptions) using ht_id
• Aggregating metrics like lifetime value per resolved identity
• Using Golden Record fields (such as primary email) as trusted attributes

Retrieve identifiers for activation

When syncing to destinations that support multiple identifiers per user (such as ad platforms), you may want access to all identifier values for each resolved identity.

Use <output_prefix>_resolved_identifiers to retrieve and group identifier values by ht_id. This supports sending multiple emails, phone numbers, or other identifiers per identity when required by the destination.

Using identity data in Customer Studio

If you use Customer Studio, identity outputs are typically used in one of two ways:

• Golden Record as the parent model
  A unified, one‑row‑per‑identity table that marketers can build audiences and traits from directly.

• Resolved records as related models
  Events or transactions roll up to identities using ht_id.

This structure lets you build audiences, traits, and insights on unified customer data without writing SQL.

Sync and activation guidance

When syncing identity data to downstream tools:

• Prefer syncing from Golden Record when the destination expects one record per person.
• Use resolved identifiers when a destination supports multiple identifiers.
• Treat ht_id as an internal reference, not a customer‑facing identifier; it has no inherent meaning beyond grouping records into an identity.

Always structure syncs based on the destination’s data model and requirements.