Get Started

OverviewCreate a sourceCreate a modelCreate a destinationCreate a sync

Hightouch Audiences

OverviewUsageVisual Audience BuilderSchemaSync Templates
Documentation/Hightouch audiences/Schema


Table of Contents
An Example Schema
The root users table, related objects, and events, are configured in the schema tab. The schemas tab is divided into objects and events.

An Example Schema

For example, Amazon might map the following schema from their warehouse to Hightouch:
  • A root users object (which you build audiences off of). With columns for:
    • user_id — a unique identifier for the user. Used as a foreign key for other tables.
    • name — the user's name
    • age — the user's age
  • A "purchases" object, with columns for:
    • user_id — A reference to the user that made the purchase
    • total — The total cost of the purchase
    • used_coupon — Whether the user used a coupon when checking out
  • A "viewed page" event, with columns for:
    • user_id — A reference to the user that viewed the page
    • page_path — The url path for the page (e.g. /promo)
    • timestamp — When the user viewed the page


The root users table

The root users table is defined under the "objects" section. You can create these queries just like any other query in Hightouch. The object must have a primary key so that it can be synced to a destination.

Other Objects

Other objects are defined under the "objects" section as well. These objects can be referenced in the "related object" filter, but cannot be directly synced.For example, you may create a second object for "organizations", so that users that are a part of an organization can be filtered based on properties of the organization.


Under the hood, Hightouch generates SQL JOINs between your various models to power the related object and event conditions. To facilitate this, you need to configure the foreign keys between your models.

Direct relationships

In the majority of cases, you will just need to setup "direct relationships", which relate models directly to each other. I.e. the users foreign key is directly referenced by the other model.For example, for the schema above, you need a relationship between "users" and "purchases":

Many to many relationships (i.e. through relationships) [Advanced]

Hightouch supports objects that are related through an intermediary table.For example, a user might belong to multiple organizations. Imagine you have:
  • A users table, with columns for:
    • user_id — a unique identifier for the user
  • A organizations table, with columns for:
    • organization_id — a unique identifier for the organization
  • A memberships table (where a user is "part of" a organization" if they have an entry with a matching user_id and organization_id), with columns for:
    • user_id — A reference to the user
    • organization_id — A reference to the organization
In this example, you could say "users are related to organizations through the memberships table". And create the following relationships to allowing filtering users based on organization properties:
  • A direct relationship from users to memberships on user_id
  • A direct relationship from memberships to organizations on organization_id
  • A through relationship from users to memberships via the above two direct relationships.
In general, you should just create direct relationships, and only use through relationships if you have to.


Events are very similar to related objects — you just have to specify the name of the timestamp column.Each event should have its own query, as well as a relationship from the users model to the event.