Use a small set of meaningful email segments, keep their data current, and distinguish audience rules from event payload filters.
A segment earns its place when it changes what you would say. "Has completed setup" is useful if it stops you sending a setup reminder. A complicated score nobody can explain usually is not.
Start with a few differences that matter to the recipient. Add complexity only when you can name the decision it improves.
Most segments draw on one of a few kinds of data. The examples below are illustrations. Swap in the fields and time windows your own data supports.
| Type | What it uses | Example segment |
|---|---|---|
| Demographic or firmographic | Facts about the person or company, such as location, role, industry, or company size | Contacts in Europe, for a webinar scheduled in European working hours |
| Behavioral | Actions in your product, on your site, or in your email | People who viewed the pricing page this week but have not started a trial |
| Lifecycle stage | Where the person is in the relationship, such as subscriber, trial, customer, or former customer | Trial accounts that have not completed setup |
| Engagement | Recent clicks, replies, logins, or site visits | Subscribers with no clicks or logins in the past six months |
| Purchase history | Orders, plans, renewals, and what was bought | Customers who bought once and have not ordered since |
| Psychographic or preference | Interests and choices the person told you about, such as topics or email frequency | Subscribers who chose product updates only in the preference center |
Treat opens with care in engagement segments. Apple's Mail Privacy Protection can download an email's images when it arrives, whether or not anyone reads it, so an open is weak evidence of attention. Clicks, replies, and product activity are stronger signals. The guide to email metrics that matter covers this in more detail.
Most useful segments combine types. "Trial accounts that have not completed setup" mixes a lifecycle stage with a missing behavior. The label matters less than whether the data behind the rule is current.
Current state answers questions such as whether an account is on a paid plan or which product it uses. Event history records what happened, such as an import completing or a subscription renewing. Both are useful, but they are not interchangeable.
A signup event from last week does not tell you whether the person upgraded this morning. Give current fields a clear owner and an update path. Keep event timestamps and identifiers so you can reason about order and retries.
For a first lifecycle program, consider new users who have not completed a meaningful task, active customers who can use a new feature, and customers who have become inactive. Define inactivity around the product's normal usage cycle, not an arbitrary number of days.
Suppose two segments receive the same subject, offer, and next step. They may not need to be separate campaigns. Conversely, customers on different plans may need different instructions even if their engagement looks similar.
For each proposed segment, write down the inclusion rule, the exclusions, the data source, and the message it makes possible. Include unsubscribes and suppressions in the audience review. A segment match does not override marketing permission.
Use welcome sequences for the next product milestone and win-back emails for a credible reason to return. Avoid sending both to the same person because two independent rules happened to match.
The tables below follow that format: a rule and the message it makes possible. They are starting points to adapt. The time windows are placeholders, so set them from how often your customers buy or use the product.
| Segment | Rule | Message it makes possible |
|---|---|---|
| Browsers without a cart | Viewed products in the past week, no cart, no order | Help choosing, such as a size guide or a comparison of similar items |
| Cart abandoners | Added items to the cart, no order after a few hours | A reminder of the items with shipping and returns details, as in the abandoned cart guide |
| First-time buyers | Exactly one order | Setup or care instructions for what they bought, then related products |
| Repeat customers | Several orders over time | Restock notices and new items in the categories they buy |
| Lapsed customers | No order for longer than their usual gap between orders | A reason to return, such as a new range, if there is one |
| Segment | Rule | Message it makes possible |
|---|---|---|
| Trial, not activated | In a trial, the key setup event has not happened | The one step that gets them to a first result |
| Trial, activated | In a trial, setup complete | What to try next and how the paid plans differ |
| Active paid customers | Paid plan, regular product use | A new feature that relates to what they already use |
| Declining use | Paid plan, activity well below the account's own recent level | An offer of help from support, sent before renewal |
| Cancelled | Subscription ended | What has changed since they left, when something relevant has |
| Segment | Rule | Message it makes possible |
|---|---|---|
| New leads | Downloaded a guide or joined the newsletter, no sales conversation yet | More on the topic they chose |
| Engaged leads | Repeated visits to pricing or product pages, or a reply to an email | An offer to talk to someone, or a product walkthrough |
| Open opportunities | A deal in progress in the CRM | Material the buying group needs, such as security documentation |
| New customers | Contract signed recently | Onboarding for each role on the account |
| Established customers | Active account for several months | Feature updates and training for the roles they have |
Agree with sales on which of these segments marketing should email at all. A generic nurture email that arrives in the middle of an active deal can confuse a careful conversation. The B2B email marketing guide covers the handoff.
In a Brew event-triggered automation, a condition on payload.activated still reads the signup event after a wait. A condition on contact.activated reads the current Brew contact field when that node executes. Declare the field and keep it synchronized; the condition does not fetch your application database.
For a reminder several days later, place the contact condition after the wait. If eligibility depends on state you have not synced to Brew, have your application check it when due and fire a fresh event only for people who qualify. The trial conversion walkthrough shows both options.
That distinction prevents a common mistake: sending "Finish setup" after someone has already finished it.
Before publishing, inspect a handful of included and excluded contacts. Test missing values, an unsubscribed contact, a recently changed account, and an event delivered twice.
After sending, measure the outcome the segment was meant to improve. More segments are not evidence of a better program. A rule that saves someone an irrelevant email is.
