The problem appears at the third rule
One invitation rule is simple. Two are usually fine. By the third, you have almost certainly written rules that overlap: a site-wide dwell rule, a pricing-page rule and an exit-intent rule will all match the same visitor on your pricing page after ninety seconds. Something has to decide which one the visitor actually sees, and if you do not decide it deliberately, the tool will decide it for you.
This is the part of proactive chat that most setups get wrong quietly. Nothing breaks. The visitor simply gets the blandest of your three messages, because the general rule happened to be evaluated first.
Only one invitation fires
The first thing to understand is that overlapping matches do not produce overlapping invitations. A sensible engine fires at most one invitation per page view, and MyLiveChat's proactive invitation rules work this way: two matching rules do not stack into two prompts.
That single design decision removes the worst failure mode, but it creates the question this guide is about. If only one can fire, which one? The answer should never be luck.
Precedence is the answer
Rules carry a priority, and the highest-priority matching rule wins. Where two rules share the same priority, the tie is broken by their order in the list. So the mental model is simple: priority first, position second, and only one survives.
Be careful with the direction, because the number runs the opposite way to the word. On the smart trigger editor the field is a plain number that defaults to 100, and the help text under it is explicit: lower fires first. So the highest-priority rule is the one with the smallest number, and giving your most specific rule a big number does precisely the wrong thing. Set your checkout rule to 20 and your site-wide fallback to 200, not the other way round.
The practical rule that follows is the one worth writing on the wall: the more specific a rule is, the higher its priority should be. A checkout-page rule should outrank a pricing-page rule, which should outrank a site-wide rule. If you invert that, the general rule wins every contest and your carefully written specific messages never appear — which is exactly the symptom described above.
A worked ordering
A setup with four rules, ordered from most specific to least:
- Highest. Checkout page, exit intent. Narrow page, narrow signal, highest commercial stake.
- High. Pricing page, forty-five seconds dwell. Still narrow, still high intent.
- Medium. Documentation pages, ninety seconds plus deep scroll. Signals a visitor who is not finding the answer.
- Lowest. Everything else, three minutes. The catch-all, deliberately last and deliberately slow.
Read that list downward and you can predict what any visitor sees. That predictability is the point — it is what lets you change one rule later without wondering what else you disturbed.
Cooldowns stop the rule repeating
Precedence decides which rule wins now. A cooldown decides how long that rule stays quiet afterwards. The two solve different problems and you need both.
Without a cooldown, a visitor who dismisses an invitation and moves to the next page can meet the same rule again immediately, which is the pestering pattern that gets widgets closed for good. A cooldown measured in hours, not minutes, is usually right for a rule that fires on a common page. Remember also that dismissal is itself an answer: a visitor who has said not now should not be asked again in that session regardless of which rule is next in line.
Two conditions in one rule
Precedence resolves competition between rules. Within a single rule, multiple conditions combine, and you choose how: either every condition must be true, or any one of them is enough.
Nearly always you want every. A rule that fires when the visitor is on the pricing page and has been there forty-five seconds is a real signal. The same two conditions joined by any fire on every pricing-page view and on every page after forty-five seconds, which is a site-wide rule wearing a disguise. If a rule seems to be firing far more than you expected, this is the first thing to check.
Which conditions you have to choose from, and the way each one is counted, is a subject of its own: see what your chat triggers can actually measure. Several of the measurements behave in ways that quietly change who a rule matches.
The safe defaults worth knowing
Two behaviours protect you from your own configuration, and both fail in the cautious direction.
- An unfinished rule does not fire. A rule with no conditions filled in matches nothing rather than matching everyone. This is the difference between a forgotten draft being harmless and it inviting your entire audience.
- An unrecognised condition does not fire. If a rule contains a condition the visitor-side engine does not understand, that condition evaluates as false rather than true, so a narrow rule can never silently widen into a broad one.
Both are worth knowing because they explain a rule that is not firing. Before assuming a bug, check that every condition in the rule is complete.
When a rule is not firing
Work down this list in order; it is roughly the frequency order of real causes.
- A higher-priority rule is matching first. The most common cause by far.
- The rule is still in its cooldown window from an earlier firing.
- The visitor already dismissed an invitation, or is already in a conversation — both correctly suppress it.
- A condition is incomplete, so the rule matches nothing.
- The conditions are joined by every and one of them is never true on that page — a scroll-depth condition on a page shorter than the viewport, for instance.
- You are testing on a phone and the rule depends on a desktop-only signal.
Test with a fresh browser profile. Cooldowns and dismissal state persist in the browser, so the second and third attempts on your own machine will not behave like a first-time visitor's.
What to measure
- Firings per rule. The single most useful number here. A rule with zero firings over a busy week is being outranked, not ignored by visitors.
- Acceptance rate per rule. Your specific rules should beat your catch-all. If the catch-all wins, your specific messages are not specific enough.
- Dismissals per rule. Rising dismissals on one rule usually means its scope is too wide.
- Share of firings from the catch-all. If the general rule accounts for most invitations, your precedence is inverted.
Review the ordering whenever you add a rule. Adding a fourth rule changes the behaviour of the three you already had, and that is easy to forget — it is one of the setup mistakes that only shows up weeks later in the numbers.