Warehouse schema

Hightouch automatically creates and manages tables for all event types. New tracked fields are automatically imported into the warehouse without additional data engineering work. Use this page to understand which tables Hightouch creates, how event fields become columns, and which timestamps to use for analysis. All the tables for an event source are written into the same schema in the warehouse. By default, this schema name is autogenerated based on the event source. However, the destination schema can be configured in the destination settings.

Tables

Identifies

All identify events are written into the warehouse in the identifies table.

Column	Description
`id`	The `messageId` from the event
`anonymous_id`	The anonymous ID from the event
`user_id`	The user ID from the event
`<traits>`	The user traits provided in the `identify` request. Each key in the `traits` object is converted into a separate column.
`context_<key>`	Additional context about the request. Often automatically collected by the tracking SDKs.
`timestamp`	The clock-skew adjusted timestamp this event occurred. In most cases, this column should be used for timestamp analysis.
`received_at`	When Hightouch received the event. Used for calculating `timestamp`.
`sent_at`	When the tracking SDK sent the event. Used for calculating `timestamp`.
`original_timestamp`	The client-side timestamp for when the tracking SDK sent the event. Used for calculating `timestamp`.

Tracks

All track events are written into the warehouse in the tracks table.

Column	Description
`id`	The `messageId` from the event
`anonymous_id`	The anonymous ID from the event
`user_id`	The user ID from the event
`context_<key>`	Additional context about the request. Often automatically collected by the tracking SDKs.
`event_text`	The event name.
`event`	The snake-cased version of the event name. This matches the table name autocreated by Hightouch.
`timestamp`	The clock-skew adjusted timestamp this event occurred. In most cases, this column should be used for timestamp analysis.
`received_at`	When Hightouch received the event. Used for calculating `timestamp`.
`sent_at`	When the tracking SDK sent the event. Used for calculating `timestamp`.
`original_timestamp`	The client-side timestamp for when the tracking SDK sent the event. Used for calculating `timestamp`.

Per-event tables

By default, Hightouch creates a separate table for each Track event type. When these per-event tables are enabled, the event properties are written as separate columns within the table. When per-event tables are turned off, the events properties column is added to the tracks table so that custom properties are still accessible.

Pages

All page events are written into the warehouse in the pages table.

Column	Description
`id`	The `messageId` from the event
`anonymous_id`	The anonymous ID from the event
`user_id`	The user ID from the event
`context_<key>`	Additional context about the request. Often automatically collected by the tracking SDKs.
`<properties>`	The page properties provided in the `page` request. Each key in the `properties` object is converted into a separate column.
`timestamp`	The clock-skew adjusted timestamp this event occurred. In most cases, this column should be used for timestamp analysis.
`received_at`	When Hightouch received the event. Used for calculating `timestamp`.
`sent_at`	When the tracking SDK sent the event. Used for calculating `timestamp`.
`original_timestamp`	The client-side timestamp for when the tracking SDK sent the event. Used for calculating `timestamp`.

Screens

All screen events are written into the warehouse in the screens table.

Column	Description
`id`	The `messageId` from the event
`anonymous_id`	The anonymous ID from the event
`user_id`	The user ID from the event
`context_<key>`	Additional context about the request. Often automatically collected by the tracking SDKs.
`<properties>`	The screen properties provided in the `screen` request. Each key in the `properties` object is converted into a separate column.
`timestamp`	The clock-skew adjusted timestamp this event occurred. In most cases, this column should be used for timestamp analysis.
`received_at`	When Hightouch received the event. Used for calculating `timestamp`.
`sent_at`	When the tracking SDK sent the event. Used for calculating `timestamp`.
`original_timestamp`	The client-side timestamp for when the tracking SDK sent the event. Used for calculating `timestamp`.

Groups

All group events are written into the warehouse in the groups table.

Column	Description
`id`	The `messageId` from the event
`anonymous_id`	The anonymous ID from the event
`user_id`	The user ID from the event
`group_id`	The group ID from the event
`context_<key>`	Additional context about the request. Often automatically collected by the tracking SDKs.
`<traits>`	The group traits provided in the `group` request. Each key in the `traits` object is converted into a separate column.
`timestamp`	The clock-skew adjusted timestamp this event occurred. In most cases, this column should be used for timestamp analysis.
`received_at`	When Hightouch received the event. Used for calculating `timestamp`.
`sent_at`	When the tracking SDK sent the event. Used for calculating `timestamp`.
`original_timestamp`	The client-side timestamp for when the tracking SDK sent the event. Used for calculating `timestamp`.

FAQ

How are the warehouse column types determined?

Hightouch determines what types to use for new columns based on the event values. Event values are categorized into one of the following types:

String
Integer
Float
Timestamp
Boolean

Timestamps must be sent as ISO-8601 string.

What happens if my event types change?

When possible, Hightouch attempts to convert the values in the event payload into the existing types in the warehouse. For example, if an event contains a Integer value for a field, but the current type in the warehouse is a String, the Integer is automatically converted. If a conversion can’t be safely done without losing data, Hightouch doesn’t upload the event, and retries it for 48 hours. This way, if you fix the type in the warehouse, Hightouch will automatically sync the event.

How are complex objects handled?

When tracking events with Objects as custom properties, Hightouch flattens nested columns into a flat schema. For example, the following properties:

{
  "company": {
    "name": "Hightouch",
    "location": "San Francisco"
  }
}

Would get imported into the warehouse as:

company_name	company_location
Hightouch	San Francisco

Get started

Marketing

Data platform

Manage

Resources

API reference

Tables

Identifies

Tracks

Per-event tables

Pages

Screens

Groups

FAQ

How are the warehouse column types determined?

What happens if my event types change?

How are complex objects handled?

​Tables

​Identifies

​Tracks

​Per-event tables

​Pages

​Screens

​Groups

​FAQ

​How are the warehouse column types determined?

​What happens if my event types change?

​How are complex objects handled?

Tables

Identifies

Tracks

Per-event tables

Pages

Screens

Groups

FAQ

How are the warehouse column types determined?

What happens if my event types change?

How are complex objects handled?