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_recordstables 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_plannerschema (especiallyJOURNEY_LOGtables and_plan/_rejectionstables). Hightouch uses these tables during sync and journey execution. Modifying them can cause unexpected behavior. - Depending on internal state tables. Tables prefixed with
IDR_orIDR_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. 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.
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 | JOURNEY_CONTEXT_LOG_<journey_id> (no combined view) | hightouch_planner |
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_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_nodes | text[] | The IDs of every tile this one connects out to. |
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. Used to break ties when multiple Set variable tiles assign the same variable — 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.
Only JOURNEY_LOG and JOURNEY_METADATA have combined views. 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.
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 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_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_nodes | text[] | The IDs of every tile this one connects out to. |
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.