In Hightouch Customer Studio, what does building an audience on a parent model give you?
answer
- Built for marketers, governed by the data team
- One entity row is the starting point
- Events join in for behavioural conditions
- The result becomes just another sync source
- Splits exist for holdouts and tests
basics
~20 sCustomer Studio lets non-engineers assemble audiences visually on top of a governed parent model and its related event models. The resulting audience becomes a sync source, so campaign segments reuse warehouse definitions instead of new hand-written SQL each time.
solid answer
~50 sIn Hightouch, a **parent model** is the governed warehouse entity that audiences are built from — usually one row per user or account, with its primary key. **Related models** attach the events and child records that hang off that entity, such as orders or page views, so an audience condition can combine attributes and behaviour: lifecycle stage is trial *and* fewer than two sessions in the last week. Customer Studio then lets a marketer compose those conditions visually and activate the result as a sync to any destination, and it supports splitting an audience into groups for experiments. The engineering value is governance: the entity, its keys and its event joins are defined once in the warehouse and reviewed like any other model, while the per-campaign segment stops being a one-off SQL query that nobody can reproduce later.
code
sql · 7 lines-- Parent model: one row per user, keyed by user_id
select user_id, email, country, lifecycle_stage, signup_at
from analytics.dim_user;
-- Related model: events joined to the parent on user_id
select user_id, event_name, occurred_at, revenue_usd
from analytics.fct_product_event;go deeper
Know that an audience is built on a parent model representing one row per user or account, and that the resulting audience is synced like any other model.
Explain how related models turn events into behavioural conditions, and why declaring the joins once keeps two campaigns from disagreeing about the same definition.
Show where the split of ownership breaks: stale parent models, expensive unaggregated event models, and self-serve audiences quietly consuming a destination's API quota.
Own the governance design — entity grain, who may create destinations, how experiment splits stay analysable in the warehouse, and when the layer is simply not worth adding.
## The problem it addresses Without an audience layer, every campaign segment is a bespoke SQL query. A marketer asks for "trial users in EMEA who viewed pricing but never started a workspace", an analyst writes it, it runs once, and it is never reviewed again. Multiply that by a busy quarter and you have dozens of segment definitions with subtly different notions of "trial" and "active", none of them tested, all of them competing for analyst time. Hightouch's Customer Studio exists to move that composition step to the people who need it, without letting them redefine the underlying entities. ## The parent model The **parent model** is the entity audiences are built on: typically one row per user, customer or account, keyed by the same kind of stable primary key any Hightouch model needs. It is defined once, in the warehouse, by whoever owns the data model. Everything an audience can filter on starts from this row — its columns are the attributes, and its key is what joins to everything else. Choosing the grain here is the load-bearing engineering decision. A user-grain parent model and an account-grain parent model produce very different audiences, and a business that sells to accounts but messages individuals usually needs both, with an explicit relationship between them. ## Related models and behavioural conditions Attributes alone are not enough for real segmentation; the interesting conditions are behavioural. **Related models** are the child datasets joined to the parent — orders, sessions, feature events, support tickets — declared once with their join keys. Once related, they become available as conditions with counts and time windows: performed this event at least N times in the last N days, has never performed it, has an order over some value. Because the joins are declared by the data team rather than re-derived per campaign, two marketers asking for "purchased in the last 30 days" get the same answer. That consistency is the point of the layer. ## Audiences as sync sources An audience is not a report; it is a rowset, and it behaves like any other Hightouch model. It gets synced to destinations with the same machinery — field mappings, sync modes, schedules, run-level diffing — so the same audience can drive an email tool, an ad platform's customer list and a CRM field simultaneously. That is the practical argument for building audiences here rather than inside each marketing tool: define once, activate everywhere, instead of re-creating the same segment in three vendor UIs where it will inevitably drift. Membership is dynamic. When a user stops satisfying the audience's conditions, the row leaves the result — and what happens downstream then depends on the sync mode you chose, exactly as for any other model. If the destination must forget the user, the sync needs removal behaviour or a status field carrying the exit. ## Splits and experimentation Customer Studio supports splitting an audience into groups so a campaign can be tested against a holdout or run as an A/B. The split assignment matters to the data team, because measuring the experiment means joining the assignment back to outcomes in the warehouse; an assignment that is not durable or not queryable makes the experiment unanalysable after the fact. ## What the data engineer owns The division of labour is the answer interviewers are usually probing for. The data team owns: the parent model's grain and key, the correctness and freshness of related models, the join definitions, the destination connections, and the operational health of the syncs. The business team owns: which conditions to combine for a given campaign, and where to send the result. That split fails in predictable ways. If the parent model is stale, every audience is stale and no marketer can tell. If related event models are enormous and unaggregated, condition previews get slow and expensive to compute in the warehouse. If nobody constrains destination volume, a self-serve audience builder is also a self-serve way to exhaust a destination's API quota. Cost is a real consideration too — audience conditions run as warehouse queries, so a heavily used builder shows up on the warehouse bill. ## When it is not worth it If your segments are few, stable and already expressed as dbt models, an audience builder adds a layer for little benefit — sync the models directly. The layer earns its place when segment churn is high and the bottleneck is analyst availability rather than data modelling.
- Who should own the parent model, and why does its grain matter so much?The data team owns it, because its grain and primary key decide what every audience can express. A user-grain parent model cannot cleanly express account-level conditions, and switching grain later invalidates existing audiences and their downstream syncs. Pick the grain the business actually messages, and relate the other entity explicitly.
- A user stops matching an audience's conditions. What happens in the destination?The row leaves the audience result, which the sync sees as a removal — and only a removal-capable sync mode acts on it. With a create-or-update mode the downstream record keeps its last synced values, so if the destination must stop targeting the user you need either removal behaviour or a status column that carries the exit.
The parent model and its related models are the vocabulary; the audience builder lets the business write its own sentences without inventing new words.
saying these in an interview costs you the question
- Thinks audiences query the destination rather than the warehouse
- Says marketers redefine the underlying entity in the builder
- Assumes audience membership is static once computed
- Ignores that audience conditions run as warehouse queries and cost money
- Believes an audience sync escapes destination rate limits