How a trigger engine is built
A trigger engine is a subscriber to an event stream. Every user action — a page view, an add to
cart, a scroll depth, an inactivity timeout — generates an event the engine receives in real time.
For each event it checks a set of rules: are all the conditions of this rule satisfied for this
person right now?
Event → rule: [conditions] → [action]
Example: add_to_cart → [cart value above threshold] → show a free delivery popup
If the conditions hold, the engine executes the action: shows a popup, swaps a banner, sends a push.
The anatomy of a rule
A typical rule has four components:
| Component | Example |
|---|---|
| Event | exit_intent (an attempt to close the tab) |
| Conditions | There are items in the cart, this is not a first visit |
| Action | Show a you left something behind popup |
| Cooldown | Not more than once every 48 hours |
The richer the supported event set and the more flexible the conditions — segments, history, session
parameters — the more precisely triggers can be configured.
Managing conflicts
In practice an active shopper can satisfy several rules at once. With no conflict management they
receive several popups in a row. The standard solution is numeric rule priority plus a global limit
of one popup per session. A more advanced approach uses machine optimisation to pick the most
relevant action from the person’s interaction history.
Important: aggressive triggers with no cooldown quickly become irritation. Test display
frequency with an A/B test: a rarer but better-targeted trigger often outperforms maximum cadence.