Model-driven segments

A model-driven segment is an audience you describe in plain language that TrailGuide compiles into SQL against your semantic model. If the definition is ambiguous, or would target the wrong or an oversized group, it refuses to run rather than send.

That single idea, say who and let the system write the query, is what makes audiences safe to build quickly. You work in concepts like new members, trial day 5, or power users, and the compiler turns them into a query on your real data.

Describe the audience, get the query

You do not write SQL, and you do not pick tables by hand. You describe the people you mean, and the model-driven evaluator compiles that description against the roles in your semantic model.

Segment: power users who were active in the last 30 days
and started a subscription. Refresh every hour.

Because the evaluator reads your semantic model, active in the last 30 days resolves to the right table and column automatically. Change the source mapping once and every segment that leans on it follows along.

The compile step is deterministic. The same description against the same semantic model produces the same SQL, so a definition you approve today behaves the same way tomorrow. You can read the query it generated, keep it under review, and trust that the audience does not drift unless you change the words. That determinism is also what makes a segment safe for an agent to build, because the outcome is inspectable rather than a surprise.

Fail-closed by design

The evaluators are fail-closed, and that safety property is what lets you move fast without fear. If a definition is ambiguous, references a role your data does not map, or would resolve to an audience far larger than expected, the segment refuses to compile instead of quietly sending to the wrong people. The burden of proof sits with the definition, not with the people who would have received the send.

• Ambiguous definition: it asks for clarification instead of guessing.
• Unmapped role: it stops rather than invent a column.
• Oversized target: it refuses rather than blast an unintended crowd.

A segment that is unsure does not send. Refusing is the safe default, and it is the default here.

Live counts and a refresh cadence you set

Every segment shows a live member count, so you always know how many people a definition currently matches before anything downstream uses it. That number is the fastest sanity check there is.

You also control the refresh cadence, anywhere from every 30 seconds to once a day. A win-back audience that keys off a lapse can refresh often, while a slow-moving VIP list can refresh nightly. You choose the trade-off between freshness and cost, one segment at a time.

The member count is a guardrail, not just a statistic. If a small edit to a definition swings the count from a few thousand to a few hundred thousand, that jump is visible before a single message goes out. Reading the number is often the fastest way to catch a definition that says more than you meant.

Attributes flow to every endpoint

A segment is not a dead end. Its attributes become available to every downstream personalization endpoint, journey, and send. The audience you defined once, power users active in the last 30 days, is now a building block the rest of the harness can call on.

That is what keeps definitions consistent across a team. There is one place an audience is described, and everything else references it rather than redefining it slightly differently each time. When the definition improves, every endpoint and journey that references it improves at the same moment.

Where the data comes from

Segments run on the sources you already connected. Two common shapes are a zero-copy data hub and custom SQL against your warehouse, both mapped through the semantic model so the evaluator can reason about them.

When you need logic beyond a single description, segments compose. You can build precise boolean audiences with ANY, ALL, and NOT, so an audience like power users active in 30 days who are not already in the win-back journey is one clean definition rather than a hand-maintained list.