Hightouch automatically creates and manages tables for all event types. New tracked fields are automatically imported into the warehouse without additional data engineering work.
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 autocollected 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 autocollected 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 autocollected 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 autocollected 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 autocollected 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 |