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

• Email address — is exactly, starts with, ends with, or contains text you type. "Everyone at acme.com" is an ends-with rule.
• Fields — any custom field you've defined, compared however you like.
• Tags — has, or doesn't have.
• Suppression — whether they're suppressed: unsubscribed, hard-bounced, or complained, so Mimeo will never email them.
• Subscribed on — the day they joined the list, before or after a date you pick. Everyone has one, including people carried over from another tool, so this is one rule and not two.
• Money — bought a product, has an active subscription to one, or total lifetime spend.
• Engagement — received, opened or clicked a specific email — or any email at all — optionally within the last N days. "Hasn't opened anything in 90 days" is an engagement rule with no email picked, set to doesn't match.
• 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 every rule can be negated on its own row — each one reads matches or doesn't match. It's the same vocabulary flows and guards use, so a rule means exactly the same thing wherever you write it.

"Can still be emailed" is a doesn't match. The "Is suppressed" rule asks whether someone is suppressed, so the audience you usually want — everyone who isn't — is that rule set to doesn't match. Writing it by hand, that's { "type": "not", "condition": { "type": "suppressed" } }. Putting a value on the suppression rule does not invert it, and a segment written that way describes the suppressed people — see the schema reference.

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.

Suppressed people are included

Segments see everyone, suppressed or not. That's deliberate: it's what lets a segment ask "is anything queued for someone who's suppressed?".

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 alert and emails you once. The alert sits in the dashboard's bell and stays until the segment empties or you dismiss it; 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 alert 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.