Segments
A segment is a question about your list, written once and answered whenever anything asks. It's not a saved list of people.
Membership is always worked out fresh. This page, a flow's "is in segment" branch, and a broadcast about to send all ask the same question at the moment they need the answer. So a count can change without anyone touching the segment — somebody buys something, opens an email, or unsubscribes, and they're in or out from that moment. That's the intended behaviour, not drift.
They live under People → Segments. Each one has a name, a
stable key (engaged_customers) that flows and files reference it
by, and a set of rules.
What you can ask about
- Fields — any custom field you've defined, compared however you like.
- Tags — has, or doesn't have.
- Suppression — whether they've unsubscribed.
- Money — bought a product, has an active subscription to one, or total lifetime spend.
- Engagement — received, opened or clicked a specific email, optionally within the last N days.
- Run history — started or finished a sequence, completed a flow.
- Another segment — membership of one segment as a rule inside another.
- A code predicate — the escape hatch, for anything the list above can't express.
Rules combine with all of these and any of these, and any rule can be negated. It's the same vocabulary flows and guards use, so a rule means exactly the same thing wherever you write it.
Tags are allowed here. Elsewhere the rule is that tags describe and never decide — a flow has to branch on real state. Segments are the sanctioned exception, because describing a set of people is what a tag is for.
Unsubscribed people are included
Segments see everyone, subscribed or not. That's deliberate: it's what lets a segment ask "is anything queued for someone who unsubscribed?".
Nothing will actually be sent to them. The standing suppression check sits in front of every send and no segment can get past it, and a broadcast's recipient count excludes them so the number you see is the number who'll receive it.
The count, while you're still editing
The editor answers as you type: how many people match, out of how many, and a few examples. That's the point of building rules in a UI rather than a file — a rule you can't see the effect of is a rule you're guessing at.
The trend line
Once a night every segment's count is recorded, and the chart on a segment's page is those snapshots. It's the only thing about a segment that isn't live, and nothing depends on it — a missed night costs a point on a graph.
A new segment has no line until it's been counted twice. An unknown trend is left blank rather than drawn flat, because flat is a claim.
Watchdogs: segments that should be empty
Mark a segment should be empty and it becomes an alarm. The useful ones describe states that shouldn't be reachable:
- People stuck in a track for longer than it takes to finish it.
- Mail queued to someone who has unsubscribed.
- Churned customers still receiving the newsletter.
Writing the impossible state down as rules means Mimeo can keep asking whether it happened, which is strictly better than remembering to check.
A trip raises a dashboard banner and emails you once. The banner stays until the segment empties; the email doesn't repeat, because a repeated alert about a problem you already know about is how people learn to ignore alerts. It's checked hourly. When the segment empties the banner goes and the alarm resets, so if it ever happens again you hear about it again.
Alert email goes out through Settings → Application email, which is deliberately separate from the provider your audience receives mail through.
Rules checked person by person
Most rules become a single database query however large your list is. Two can't: a code predicate is arbitrary Ruby, and an event matched on its details has to read each event. Those are worked out one person at a time over a set narrowed as far as the other rules allow.
The answer is identical either way — it just takes longer to count. Segments that work this way say so on their own page.
Where segments get used
- Broadcasts — pick one as the audience; membership resolves at send time.
- Flows and guards — "is in segment X" as a condition.
- Previewing an email — roll a random person from a segment, so you're previewing as somebody who'd actually receive it.
- CSV export — the current members, as a file.
A segment that something still points at refuses to be deleted, and says what would break.
Segments referring to segments
One segment can use another as a rule, which is how you build "engaged customers, but not the ones in the workshop" without repeating yourself. A loop — A refers to B refers to A — is rejected when you save it, because it could never be evaluated.