Event triggers that fire on the moment

An event trigger is a rule that watches for a specific moment in your data and fires a set amount of time later. It turns the pattern behind every reactive campaign, watch event E and fire at offset O, into a piece of configuration instead of a piece of code.

The moments that drive good lifecycle marketing are small and specific: a value crossed a line, a user did the same thing three times in an hour, someone just entered an audience you care about. Event triggers exist to catch those moments precisely and act on them at exactly the right delay, without anyone watching a dashboard for them.

Four kinds of moment

A trigger can watch for any of four kinds of event, which between them cover most of what a meaningful moment looks like in real data:

• Row change: a record in your data appears or changes, like a new signup row or an updated order status.
• Threshold crossing: a metric crosses a line you set, such as sessions passing a count or a balance dropping below a floor.
• Event burst: the same event happens several times in a short window, a strong signal of intent or of trouble.
• Segment join: a user newly enters a model-driven segment, which is often the cleanest way to say that a person just became interesting.

Some of these are single facts and some are patterns that only appear across several events, but they share one interface. You describe the event once and the trigger watches for it, whether it is a lone row or a burst that builds over a minute. This is what makes triggers general rather than a fixed menu of prebuilt events.

Set the cadence per trigger

Not every moment deserves the same urgency, so polling cadence is set per trigger, anywhere from every 30 seconds to once a day. A high-intent moment, like someone abandoning a checkout or a burst of activity worth riding, gets a tight loop that reacts in seconds. A slower signal, like a weekly usage threshold, can poll once a day and cost almost nothing to keep watching.

Tuning the loop per trigger is how you keep reaction time where it matters without watching everything at full speed. You spend the tight, frequent loops on the moments that are worth them, and let the rest tick along slowly.

Fire at an offset

When a trigger detects its event, it does not have to fire immediately. Each trigger carries an offset: act now, in fifteen minutes, or in three days. The offset is what lets you respond relative to a moment, an hour after the burst or two days after the join, rather than only at the instant it happens.

That small delay is often where the value is. The right message an hour after an abandoned checkout lands very differently from the same message fired the same second, and the offset makes that timing part of the configuration rather than something you engineer by hand. You are not choosing between fast and thoughtful; the offset gives you both.

Coalesced events into journeys and webhooks

Detected events are coalesced so a single meaningful moment does not fire a dozen times, and then handed straight to the things that act on them: a multi-step journey that enrolls the user, or a webhook that carries the event out to another system. The trigger is the sensor, and the journey or webhook is the response.

The result is that a whole class of reactive campaigns becomes configuration. You describe the moment and the delay, wire it to a journey, and the loop runs itself, with no new code required to start watching a new signal.

It also means the same trigger can feed more than one destination. The moment that enrolls a user in a journey can, at the same time, notify an external system through a webhook, so your reactive logic and your integrations stay in step without duplicated watching.

Watch for a checkout-started event with no purchase that follows it.
Poll every 30 seconds. Fire 1 hour later.
Enroll the user in the abandoned-checkout journey.