Segments Instead of SQL

If you've spent years writing SELECT statements against data extensions, segments feel slower at first and then faster. Slower because you're clicking; faster because you are not rebuilding the same join for the fortieth time.

The mental shift

A query in Engagement answers a question about one or two tables you chose. A segment in Data 360 answers a question about a unified person — one whose records may have arrived from CRM, from Engagement, from a web source — after identity resolution has decided those records are the same human.

So the quality of your audience is mostly decided before you open the segment builder. If identity resolution is loose, your segment is loose, and no amount of criteria fixes it.

What you can filter on

• Profile attributes from any ingested source.
• Behavioural and engagement data, including Engagement activity when the accounts are connected.
• Related object data, so "bought twice in six months" is a criterion rather than a pre-built flag.

Fictional example for shape only: a segment of people with an email consent of opted-in, a last purchase within 90 days, and no open in 60 days — a re-engagement audience assembled without a single line of SQL.

Where I still miss SQL

Debugging. A query tells you exactly why a row qualified. A segment tells you a count. Build audiences narrow first, check the number is plausible, then widen — rather than building the full thing and trusting it.