> ## Documentation Index > Fetch the complete documentation index at: https://docs.hightouch.com/llms.txt > Use this file to discover all available pages before exploring further. # Warehouse schema > How Hightouch structures event data in your warehouse — the tables it creates, how fields become columns, and which timestamps to use. 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 | | `` | The user traits provided in the `identify` request. Each key in the `traits` object is converted into a separate column. | | `context_` | 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_` | 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_` | Additional context about the request. Often automatically collected by the tracking SDKs. | | `` | 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_` | Additional context about the request. Often automatically collected by the tracking SDKs. | | `` | 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_` | Additional context about the request. Often automatically collected by the tracking SDKs. | | `` | 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](https://docs.hightouch.com/events/warehouses/error-handling.md). 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: ```json theme={null} { "company": { "name": "Hightouch", "location": "San Francisco" } } ``` Would get imported into the warehouse as: | company\_name | company\_location | | - | - | | Hightouch | San Francisco |