Warehouse tables reference

As you use Hightouch, it writes tables back to your data warehouse. These tables record sync activity, audience changes, journey progress, resolved identities, and event data. This page is the single reference for all of them. Each section below explains what each table is, how it’s used, and which shouldn’t be queried or modified.

Usage guidance

Hightouch writes these tables to your warehouse for observability, debugging, and lightweight reporting. Before building on top of them, keep the following in mind.

Recommended uses

Ad-hoc debugging and auditing. Query sync logs to investigate failed rows, inspect audience membership changes, or trace a user’s journey path.
Lightweight reporting. Build dashboards on top of sync run metadata, audience snapshots, or identity resolution outputs to monitor Hightouch activity.
Analytics and activation with Identity Resolution outputs. The _resolved, _resolved_identifiers, and _golden_records tables are built for your use. You can query them, register them as dbt sources, or sync from them.

Not recommended

Wiring tables into production workflows. Don’t build business-critical pipelines that depend on these tables without . Table schemas may change as Hightouch evolves, and we don’t guarantee schema stability for all tables.
Writing to Hightouch-managed tables. Never insert, update, or delete rows in the hightouch_planner schema (especially JOURNEY_LOG tables and _plan/_rejections tables). Hightouch uses these tables during sync and journey execution. Modifying them can cause unexpected behavior.
Depending on internal state tables. Tables prefixed with IDR_ or IDR_BACKUP_ are internal to Identity Resolution. Don’t query or reference them in pipelines. Their schemas can change without notice.

Documenting a table here doesn’t mean Hightouch is committing to a stable schema contract. If you want to build durable integrations on top of these tables, so we can help you find the right approach.

Schemas overview

Hightouch uses up to three schemas in your warehouse, depending on which features you enable:

Schema	Purpose	Created when
`hightouch_planner`	Change data capture, audience snapshots, journey logs, Identity Resolution outputs, AI Decisioning tables	Lightning sync engine is enabled
`hightouch_audit`	Warehouse Sync Logs, holdout group logs, journey views, data extraction reports	Lightning sync engine is enabled; individual features populate specific tables
Custom (per Events source)	Event data (Hightouch Events); schema name is configurable	An Events source writes to a warehouse destination

hightouch_planner schema

Lightning sync engine (CDC)

These tables are created automatically when the Lightning sync engine is enabled. They’re required for syncs using the Lightning engine. Change data capture (CDC) is how Hightouch figures out what changed between sync runs. These tables hold the working state Hightouch needs to make that comparison: a snapshot of the model’s rows from the previous run, and a record of rows dropped during the current one. You’ll rarely query them directly. The occasional exception is *_rejections, which you can inspect to see rows Hightouch dropped during a specific run and why.

Table	Key columns	Description
`*_plan`	—	Stores a model’s query results for a sync run. Hightouch compares this against the previous run to identify added, changed, and removed rows. Table names change with every run.
`*_rejections`	—	Stores rows rejected during a sync run. Table names change with every run.

Hightouch only keeps the two most recent pairs of _plan and _rejections tables per sync. Because table names change with every run, Hightouch requires write access to the entire schema.

Don’t delete tables from hightouch_planner. Removing CDC tables breaks change data capture and requires a full resync to recover.

For full details, see Lightning sync engine — Warehouse schemas.

Audience snapshots

Optional — must be enabled on the source’s Sync Logs tab. See Audience snapshots. Use this table to see how an audience’s membership changed over time — for example, who entered or left a segment between two dates.

Table	Key columns	Description
`audience_membership`	`ht_row_id`, `ht_audience_id`, `ht_timestamp`, `ht_event_type`, `ht_split_group`	Tracks audience membership changes over time. Each row records an `enter` or `exit` event for a member.

Journey tables

Created automatically when a journey is active. See Journeys — Journey logs. Use these tables when you’re analyzing a single journey — for example, tracing where members drop off or auditing the path a specific member took. Each journey gets its own set of tables, and each row in these tables represents one visit by one member (the primary key from the journey’s parent model). To report across all journeys at once, use the combined journey views in the hightouch_audit schema instead. JOURNEY_LOG and JOURNEY_METADATA views are created automatically; a JOURNEY_CONTEXT_LOG view is also available but must be enabled by Hightouch. Until then, query the per-journey context tables directly when you need journey variable values across journeys.

In these tables, a node is what you configure as a tile on the journey canvas. The column names use node because that’s the underlying data model; the UI calls them tiles.

Pick the right table for your goal:

Goal	Query	Schema
Debug or audit a single journey	`JOURNEY_LOG_<journey_id>`, `JOURNEY_METADATA_<journey_id>`	`hightouch_planner`
Report across all journeys at once	`JOURNEY_LOG_VIEW_<workspace_slug>`, `JOURNEY_METADATA_VIEW_<workspace_slug>`	`hightouch_audit`
Read journey variable values for a single journey	`JOURNEY_CONTEXT_LOG_<journey_id>`	`hightouch_planner`
Read journey variable values across all journeys	`JOURNEY_CONTEXT_LOG_VIEW_<workspace_slug>` (opt-in)	`hightouch_audit`

Don’t write to JOURNEY_LOG tables. Hightouch reads and writes them during journey execution, so inserting, updating, or deleting rows can cause the journey to behave unexpectedly.

The journey_id in table names is the journey’s UUID with dashes removed.

JOURNEY_LOG

JOURNEY_LOG_<journey_id> logs the progress of all rows through a given journey. Each time a row enters the journey, moves from one node to another, or exits the journey, Hightouch creates an entry in this table. Since a row can enter a journey more than once, the row_instance_id column uniquely identifies each entry instance as it moves through the journey. Resetting a journey clears its log table.

Column	Type	Description
`row_id`	string	The primary key from the journey’s parent model that this row represents.
`row_instance_id`	string	A UUID to uniquely identify a `row_id` each time it enters the journey.
`run_id`	string	The ID of the journey run that executed this operation. Internal detail.
`from_node_id`	string	The node this action originates from. For moves or exits, it’s the node the row moved or exited from. For entries, it’s `NULL`.
`to_node_id`	string	The node this action targets. For moves and entries, it’s the node the row moved into. For exits, it’s `NULL`.
`timestamp`	timestamp	The effective timestamp of this operation. This doesn’t always represent the actual time the operation occurred — for example, if a row moved due to an event, this is the event timestamp rather than when the warehouse query ran.
`event_type`	string	The type of event: `moved-to-node`, `entered-journey`, `exited-journey-by-criteria`, or `exited-journey`.
`journey_version_id`	string	The ID of the journey version this row belongs to. Only present when your workspace uses versioned journey metadata. Used to join log rows to the matching `JOURNEY_METADATA` snapshot.

JOURNEY_METADATA

JOURNEY_METADATA_<journey_id> describes the shape of the journey: which tiles exist, what they’re called, and how they connect. Hightouch writes this table during journey execution, not on save. The exact write behavior depends on your workspace: the table is either replaced on each run, or updated once per journey version with an appended snapshot.

Column	Type	Description
`journey_id`	text	The ID of the journey.
`journey_name`	text	The name you gave the journey.
`node_name`	text	The name you gave the tile.
`node_type`	text	The tile type: `entry-cohort`, `entry-event`, `sync`, `segments`, `segment-branch`, `time-delay`, `splits`, `split-branch`, `wait-until-event`, `wait-until-event-branch`, `context` (Set variable), `coupon-assignment`, and `message` (Send email, Send SMS, or Send push).
`node_id`	text	The ID of the tile.
`to_node_id`	text[]	The IDs of every tile this one connects out to.
`journey_version_id`	text	The ID of the journey version this snapshot belongs to. Only present when your workspace uses versioned journey metadata (the appended-snapshot behavior described above). Used to join metadata to the matching `JOURNEY_LOG` rows.
`created_at`	timestamp	When Hightouch wrote this snapshot. Only present with versioned journey metadata.

JOURNEY_CONTEXT_LOG

JOURNEY_CONTEXT_LOG_<journey_id> records the value of each journey variable as members pass through Set variable tiles. Filter it to build audiences of members who reached a specific branch — for example, everyone whose vip_user variable was set to true.

Column	Type	Description
`row_id`	string	The primary key from the journey’s parent model that this row represents.
`row_instance_id`	string	A unique ID assigned each time this member enters the journey.
`run_id`	string	The ID of the journey run that recorded this value. Internal detail.
`node_id`	string	The ID of the Set variable tile that recorded this value.
`entered_at`	timestamp	When the member reached the Set variable tile.
`inserted_at`	timestamp	When Hightouch wrote the row. If multiple Set variable tiles assign the same variable, the row with the latest value wins.
`[variable_name]`	dynamic	One column per journey variable. The column’s type matches the variable’s type.

Identity Resolution outputs

Created automatically when an identity graph runs. See Identity Resolution for details. By default, these tables are written to hightouch_planner. If you configure an output schema for the identity graph, Hightouch writes them to that schema instead. Use these tables to power analytics and activation on resolved identities. They’re the recommended starting point for anything you build on top of Identity Resolution: query them directly, register them as dbt sources, or sync from them.

Table	Key columns	Description
`<output_prefix>_resolved`	`ht_id`, `source`, `primary_key`, `latest_timestamp`	Maps every input row to a resolved identity.
`<output_prefix>_resolved_identifiers`	`ht_id`, `identifier`, `value`, `first_timestamp`, `last_timestamp`, `count`	All identifier values associated with each resolved identity.
`<output_prefix>_unresolved`	—	Input rows that couldn’t be processed, typically due to duplicate primary keys.
`<output_prefix>_golden_records`	`ht_id`, plus one column per configured field	One row per identity with canonical field values. Only created when Golden Record is enabled.

These four output tables are designed for your use. You can safely query them, reference them in dbt, or build views on top of them. For long-term stability, we recommend creating a view or derived table rather than transforming them in place.

Identity Resolution internal state

Created automatically as part of identity graph processing. These tables support incremental resolution and graph consistency behind the scenes. They aren’t meant for your use.

Table	Description
`IDR_` / `IDR_BACKUP_`	Internal tables for incremental processing and graph consistency.

Don’t query or modify these tables. They’re internal implementation details and can change without notice.

AI Decisioning

Created automatically per agent when using Hightouch-assigned groups. See AI Decisioning — Group assignment. Use this table to analyze experiment results: compare how the treatment, holdout, and customer_managed groups performed to measure AI Decisioning’s impact.

Table	Key columns	Description
`de_user_experiment_groups_<agent_id>`	`user_id`, `user_hash`, `experiment`, `first_seen_at`, `last_seen_at`	Tracks which experiment bucket (`treatment`, `holdout`, `customer_managed`) each user belongs to over time.

hightouch_audit schema

Warehouse Sync Logs

Optional — must be enabled per source or per sync. See Warehouse Sync Logs. Use these to audit sync outcomes: investigate why specific rows failed (sync_changelog), check the latest status of each row (sync_snapshot), or report on run-level metrics like planned, succeeded, and failed counts (sync_runs).

Table	Key columns	Description
`sync_changelog`	`sync_id`, `row_id`, `op_type`, `status`, `failure_reason`, `fields`	A log of every operation across all sync runs. Each synced row gets one entry per run.
`sync_snapshot`	`sync_id`, `row_id`, `op_type`, `status`, `failure_reason`, `fields`	The latest status of each row across all syncs. Replaced after each run.
`sync_runs`	`sync_id`, `sync_run_id`, `model_name`, `started_at`, `finished_at`, `status`	Metadata for each sync run, including row counts for planned, attempted, succeeded, and failed operations.

Holdout group logs

Optional — requires a feature flag and must be enabled on the source’s Sync Logs tab. See Experiments — Holdout group logs. Use this table after a campaign to measure holdout performance: compare outcomes for held-out members against those who received the campaign.

Table	Key columns	Description
`audience_holdout`	`sync_id`, `sync_run_id`, `model_id`, `row_id`, `fields`, `split_group`	Logs rows excluded from a sync due to holdout group membership, for post-campaign analysis.

Journey views

Created automatically when journeys are active. These are read-only views that stitch every journey’s per-journey tables together, so you can report across all journeys at once without querying and joining each one manually. JOURNEY_LOG and JOURNEY_METADATA views are created automatically for every workspace. A combined JOURNEY_CONTEXT_LOG view is also available but is off by default.

Find your workspace slug under Settings → Workspace → Workspace slug. Lowercase the slug and replace any non-alphanumeric character (such as a dash) with an underscore when querying (for example, My-Workspace becomes my_workspace).

JOURNEY_LOG_VIEW

JOURNEY_LOG_VIEW_<workspace_slug> combines all JOURNEY_LOG tables into a workspace-level view of row movement across all journeys. Hightouch rebuilds the view during journey runs on an as-needed basis: when a new log table is added, when schema or version columns require it, or when the view is marked stale. Journey removal also triggers a rebuild.

Column	Type	Description
`source_table`	string	The name of the table this row came from: `journey_log_<journey_id>`.
`row_id`	string	The primary key from the journey’s parent model that this row represents.
`row_instance_id`	string	A UUID to uniquely identify a `row_id` each time it enters the journey.
`run_id`	string	The ID of the journey run that executed this operation. Internal detail.
`from_node_id`	string	The node this action originates from. For moves or exits, it’s the node the row moved or exited from. For entries, it’s `NULL`.
`to_node_id`	string	The node this action targets. For moves and entries, it’s the node the row moved into. For exits, it’s `NULL`.
`timestamp`	timestamp	The effective timestamp of this operation. This doesn’t always represent the actual time the operation occurred — for example, if a row moved due to an event, this is the event timestamp rather than when the warehouse query ran.
`event_type`	string	The type of event: `moved-to-node`, `entered-journey`, `exited-journey-by-criteria`, or `exited-journey`.
`journey_id`	text	The ID of the journey.
`journey_version_id`	string	The ID of the journey version this row belongs to. Only present when your workspace uses versioned journey metadata.

JOURNEY_METADATA_VIEW

JOURNEY_METADATA_VIEW_<workspace_slug> combines every journey’s JOURNEY_METADATA table so you can see the shape of every journey in the workspace at once. Hightouch rebuilds the view during journey runs on an as-needed basis: when a new metadata table is added, when an existing one is converted, or when the view falls out of sync with the underlying tables.

Column	Type	Description
`source_table`	string	The name of the table this row came from: `journey_metadata_<journey_id>`.
`journey_id`	text	The ID of the journey.
`journey_name`	text	The name you gave the journey.
`node_name`	text	The name you gave the tile.
`node_type`	text	The tile type: `entry-cohort`, `entry-event`, `sync`, `segments`, `segment-branch`, `time-delay`, `splits`, `split-branch`, `wait-until-event`, `wait-until-event-branch`, `context` (Set variable), `coupon-assignment`, and `message` (Send email, Send SMS, or Send push).
`node_id`	text	The ID of the tile.
`to_node_id`	text[]	The IDs of every tile this one connects out to.
`journey_version_id`	text	The ID of the journey version this snapshot belongs to. Only present when your workspace uses versioned journey metadata.
`created_at`	timestamp	When Hightouch wrote this snapshot. Only present with versioned journey metadata.

JOURNEY_CONTEXT_LOG_VIEW

Global journey context log view must be enabled by Hightouch. to turn it on.

JOURNEY_CONTEXT_LOG_VIEW_<workspace_slug> combines every journey’s JOURNEY_CONTEXT_LOG table so you can query journey variable values across all journeys in the workspace at once. Hightouch rebuilds the view when a new context log table is added or when a journey adds a new variable. Columns for renamed or removed variables are kept in the view so historical values remain queryable.

Column	Type	Description
`row_id`	string	The primary key from the journey’s parent model that this row represents.
`row_instance_id`	string	A unique ID assigned each time this member enters the journey.
`run_id`	string	The ID of the journey run that recorded this value. Internal detail.
`node_id`	string	The ID of the Set variable tile that recorded this value.
`entered_at`	timestamp	When the member reached the Set variable tile.
`inserted_at`	timestamp	When Hightouch wrote the row. If multiple Set variable tiles assign the same variable, the row with the latest value wins.
`journey_id`	text	The ID of the journey.
`source_table`	string	The name of the table this row came from: `journey_context_log_<journey_id>`.
`[variable_name]`	string	One column per journey variable across all journeys. Unlike the per-journey table, the view casts every variable to string so the combined columns align across journeys.

Data extraction

Created automatically when data extraction is enabled for a destination. See Data extraction. Use these to see the audiences Hightouch maintains in each ad platform. Query the combined external_audiences_metadata_v1 view to report on audience sizes and refresh times across destinations.

Table	Key columns	Description
`{destination-type}_{destination-id}_audiences`	Varies by ad platform	One table per enabled destination. Schema mirrors the ad platform’s API response.
`external_audiences_metadata_v1` (view)	`ad_account_id`, `audience_id`, `audience_name`, `audience_size`, `ht_fetched_at`	A combined, standardized view across all destination tables.

Events schema

Hightouch Events writes event data into a configurable schema — not hightouch_planner or hightouch_audit. The schema name defaults to an auto-generated value based on the event source but can be configured in destination settings. Tables are created automatically when an Events source writes to a warehouse destination. Use these tables to analyze collected behavioral data directly in your warehouse — for example, build models on tracks events or join identifies traits into your audiences.

Table	Key columns	Description
`identifies`	`id`, `anonymous_id`, `user_id`, `<traits>`, `timestamp`	All `identify` events. Trait keys become separate columns.
`tracks`	`id`, `anonymous_id`, `user_id`, `event`, `event_text`, `timestamp`	All `track` events.
Per-event tables	Varies	A separate table for each track event type, with event properties as columns. Can be disabled.
`pages`	`id`, `anonymous_id`, `user_id`, `<properties>`, `timestamp`	All `page` events.
`screens`	`id`, `anonymous_id`, `user_id`, `<properties>`, `timestamp`	All `screen` events.
`groups`	`id`, `anonymous_id`, `user_id`, `group_id`, `<traits>`, `timestamp`	All `group` events.

For the full column-level schema, see Events warehouse schema.

Get started

Marketing

Data platform

Manage

Resources

API reference

Warehouse tables reference

Usage guidance

Recommended uses

Not recommended

Schemas overview

hightouch_planner schema

Lightning sync engine (CDC)

Audience snapshots

Journey tables

JOURNEY_LOG

JOURNEY_METADATA

JOURNEY_CONTEXT_LOG

Identity Resolution outputs

Identity Resolution internal state

AI Decisioning

hightouch_audit schema

Warehouse Sync Logs

Holdout group logs

Journey views

JOURNEY_LOG_VIEW

JOURNEY_METADATA_VIEW

JOURNEY_CONTEXT_LOG_VIEW

Data extraction

Events schema

​Usage guidance

​Recommended uses

​Not recommended

​Schemas overview

​hightouch_planner schema

​Lightning sync engine (CDC)

​Audience snapshots

​Journey tables

​JOURNEY_LOG

​JOURNEY_METADATA

​JOURNEY_CONTEXT_LOG

​Identity Resolution outputs

​Identity Resolution internal state

​AI Decisioning

​hightouch_audit schema

​Warehouse Sync Logs

​Holdout group logs

​Journey views

​JOURNEY_LOG_VIEW

​JOURNEY_METADATA_VIEW

​JOURNEY_CONTEXT_LOG_VIEW

​Data extraction

​Events schema

Usage guidance

Recommended uses

Not recommended

Schemas overview

hightouch_planner schema

Lightning sync engine (CDC)

Audience snapshots

Journey tables

JOURNEY_LOG

JOURNEY_METADATA

JOURNEY_CONTEXT_LOG

Identity Resolution outputs

Identity Resolution internal state

AI Decisioning

hightouch_audit schema

Warehouse Sync Logs

Holdout group logs

Journey views

JOURNEY_LOG_VIEW

JOURNEY_METADATA_VIEW

JOURNEY_CONTEXT_LOG_VIEW

Data extraction

Events schema