Build Event-Triggered Emails and Alerts from User Behavior

A known contact looks at your pricing page twice in a week. What should happen next? Our answer is an alert to the person who owns the account, not an email to the contact. A pricing view is a weak signal, and an automated email in response can feel like being watched. A salesperson who has read the context can write something welcome.

That choice is the center of a behavior trigger: something a person did starts an action, and the calendar does not. The build is small. You need an event source (your product or website), an automation layer that holds the rules, and a way to send email or notify your team. Product names change, so check each vendor's current documentation.

Pick three to five behaviors worth acting on#

Start from outcomes. What do you want people to do next, and which behavior shows that they are on track or stuck? Good first triggers fall into three groups: activation (signed up, key first action not done yet), intent (a known contact looked at pricing or a booking page) and risk (a trial is ending, or a user dropped a feature they relied on).

For each trigger, write one sentence: "When X happens, we send Y to Z, so that W." If you cannot write the last part, skip the trigger.

Decide early whether each message is a service message or a marketing message. A receipt is transactional. A tip, an offer or a sales follow-up is generally marketing, and consent and unsubscribe rules apply. The FTC's CAN-SPAM guide ↗ says the law views transactional and relationship categories narrowly. Read the compliance automation guide before you send marketing messages from behavior.

Name events once and know who did them#

Keep a tracking plan: a plain table of event names, when each fires, its properties and its owner. Use one pattern, such as "Object Action" in past tense. Segment's Track documentation ↗ recommends human-readable names, and its examples such as "Order Completed" follow it. Fire events from your server where you can, because browser events are lost to ad blockers and closed tabs.

A trigger also needs to know who. Link anonymous visitors to known users with an identify step, or pre-signup behavior is lost. Segment's Identify documentation ↗ says the call "lets you tie a user to their actions and record traits about them", and recommends database IDs over email addresses, which can change. For B2B, add an account ID to every event. Tracking people before signup may need consent under cookie rules in some places, so check what applies to your site.

Test the route before you build any rule. Fire a test event and check that it arrives tied to the right person with the right properties, and that a repeat does not create a duplicate. Most trigger failures are data failures: a missing user ID, a misspelled event name or an absent property.

Write each rule with six parts#

A condition alone is not a rule. Add a delay (an hour for a tip, none for a demo request), an exit condition that cancels the message if the person completes the next step, a frequency cap across all triggers, quiet hours in the recipient's time zone, and a suppression check against your suppression table.

Write the rule in plain words first:

Trigger:   Pricing Page Viewed (known contact, 2 or more views in 7 days)
Delay:     30 minutes
Exit if:   Demo Booked, or reply received, or contact is already a customer
Action:    Notify the account owner in Slack; do not email the contact
Cap:       One alert per account per week

Be careful with noisy signals. A single page view, or a link click from a security scanner, can look like intent and mean nothing. Prefer actions that need a deliberate step, and combine several weak signals before you act. To rank people by accumulated behavior instead of reacting to single events, see the lead scoring pipeline.

An internal alert needs who did what, the relevant history, a suggested action and a link to the record. Send it to the person who owns the account, and track whether alerts get acted on. When a trigger does send email, keep it short, refer to what the person did and offer a next step. Set a fallback for every merge field, or the message will say "Hi ,". Do not reveal more tracking than the person expects, such as "I saw you spent four minutes on page X".

Test, then compare against a holdout#

Test every path with a test account: the send after the delay, the exit that cancels it, the cap on a repeat, and an opted-out user who gets nothing. Authenticate and warm up your sending domain first, as the email warmup system describes.

To judge whether a trigger works, hold out a random group that gets nothing and compare their next action with the group that gets the message. Open rates mislead, because mail privacy features can load messages automatically. Measure the behavior you wanted, such as the second project or the booked call.

Review each trigger every quarter. When the product changes, an event can stop firing silently, so alert on any event whose volume drops to zero. Keep one list of active triggers and what each sends, and retire first any trigger whose purpose you can no longer state in one sentence.