Warehouse tables reference

Hightouch creates and manages tables in your data warehouse to power change data capture, sync logging, audience snapshots, journeys, identity resolution, and more. This page is a single reference for all of these tables: which schema they belong to, which feature creates them, and how you should (and shouldn't) use them.

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 explicitly designed for downstream use. You can query them directly, 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). These tables are actively used 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 — they 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.

These are internal change data capture working tables, so you'll rarely query them directly. The occasional exception is *_rejections, which you can inspect to see rows Hightouch dropped during a specific run.

Table	Key columns	Description
`*_plan`	—	Stores a model's query results for a sync run, used to compute row-level diffs. 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 users drop off or auditing the path a specific user took. Each journey gets its own set of tables. To report across all journeys at once, use the combined journey views in the hightouch_audit schema instead. Those views cover JOURNEY_LOG and JOURNEY_METADATA; there's no combined view for JOURNEY_CONTEXT_LOG, so query the per-journey context tables directly when you need journey variable values across journeys.

Use this table to decide which object to query:

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	`JOURNEY_CONTEXT_LOG_<journey_id>` (no combined view)	`hightouch_planner`

Don't write to JOURNEY_LOG tables. They're actively used during journey execution — 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_METADATA

JOURNEY_METADATA_<journey_id> contains the journey's graph structure and customer-defined node names. Updated each time a change is saved to the journey.

Column	Type	Description
`journey_id`	text	The ID of the journey.
`journey_name`	text	The customer-defined name of the journey.
`node_name`	text	The customer-defined name of the node.
`node_type`	text	The node type: `entry-cohort`, `entry-event`, `sync`, `segments`, `segment-branch`, `time-delay`, `splits`, `split-branch`, `wait-until-event`, `wait-until-event-branch`.
`node_id`	text	The ID of the journey node.
`to_nodes`	text[]	An array of the outbound node IDs from the given node.

JOURNEY_CONTEXT_LOG

JOURNEY_CONTEXT_LOG_<journey_id> logs the result of journey context variables for each row.

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.
`node_id`	string	The ID of the journey node.
`entered_at`	timestamp	When the row entered the "set a variable" node.
`inserted_at`	timestamp	Used for prioritizing when multiple context nodes assign the same variable. The most recent value is used.
`[variable_name]`	dynamic	One dynamic column per context variable. The type depends on 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 downstream 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 combine every journey's per-journey tables into a single workspace-level view. Use them for reporting across all journeys at once, rather than querying and joining individual JOURNEY_LOG and JOURNEY_METADATA tables. Only those two tables have combined views — for journey variable values, query the per-journey JOURNEY_CONTEXT_LOG tables directly.

Find your workspace slug under Settings → Workspace → Workspace slug. Replace dashes with underscores in the slug when querying (for example, my-workspace becomes my_workspace).

JOURNEY_LOG_VIEW

JOURNEY_LOG_VIEW_<workspace_slug> combines all JOURNEY_LOG tables into a single view of row movement across all journeys. Updated each time a journey is added or removed from the workspace.

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_METADATA_VIEW

JOURNEY_METADATA_VIEW_<workspace_slug> combines all JOURNEY_METADATA tables into a single view of node structures across all journeys. Updated each time a journey runs.

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 customer-defined name of the journey.
`node_name`	text	The customer-defined name of the node.
`node_type`	text	The node type: `entry-cohort`, `entry-event`, `sync`, `segments`, `segment-branch`, `time-delay`, `splits`, `split-branch`, `wait-until-event`, `wait-until-event-branch`.
`node_id`	text	The ID of the journey node.
`to_nodes`	text[]	An array of the outbound node IDs from the given node.

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.