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.