How does exit intent actually work?
The original 2012-era implementation hooks mouseout on the document and checks two conditions:
- The cursor crossed the top edge of the viewport (
event.clientY <= 0) - The cursor's vertical velocity over the last few hundred milliseconds was upward and fast
If both fire, the script assumes the user is reaching for the back button, the tab close x, or the URL bar, and triggers an event — usually a popup with a discount or an email capture.
A minimal version looks like this:
document.addEventListener('mouseout', (e) => {
if (!e.relatedTarget && e.clientY <= 0) {
triggerExitIntent();
}
});
Production implementations layer in velocity smoothing, a debounce so it only fires once per session, and a session-storage flag so the popup does not re-trigger on every page.
Why is exit intent broken on mobile?
Mobile browsers have no cursor. There is no mouseout event because there is no mouse. The only signals available to detect a likely exit are:
visibilitychangefiring withdocument.hidden = true(user switched apps or tabs)pagehidefiring (user navigated away)bluron the window- Aggressive scroll velocity in the upward direction (rare and unreliable)
None of these give you the predictive moment that mouse-based exit intent gives on desktop. By the time visibilitychange fires, the user is already gone — you can show a popup, but they will see it next time they open the tab, if at all. That latency is why mobile exit-intent popups have collapsed in effectiveness.
The honest framing: "exit intent on mobile" is exit detection, not exit prediction.
Has exit intent decayed on desktop too?
Yes, for several converging reasons:
- Smaller cursor travel: laptop trackpads encourage shorter mouse movements; users often abandon by hitting Cmd+W instead of mousing to the close button.
- Tab-close shortcuts: power users never trigger a
mouseoutto the top edge. - PWAs and full-screen apps: there is no top edge to cross.
- Multi-monitor setups: mousing off the top of one viewport into another monitor is not an exit, but the script treats it as one.
- Popup fatigue: even when the trigger fires correctly, conversion on the resulting modal has fallen as users learn to dismiss reflexively.
Vendor data from the late 2010s claimed exit-intent popups recovered 5–15% of abandoners. By 2024 most teams report low-single-digit recovery on desktop and barely measurable on mobile.
What are the modern alternatives?
Instead of trying to predict the moment of exit, modern teams instrument the causes of exit and intervene earlier in the session:
| Signal | What it tells you | When to act |
|---|---|---|
| Form abandonment | User filled some fields, then stopped | Save partial data, send recovery email |
| Scroll velocity spike | User is skimming or frustrated | Adjust copy density, shorten the page |
| Dwell time on a single section | User is stuck on a confusing element | Surface inline help or a chat prompt |
| Rage click on a non-button | Users expect something to be interactive | Make the element clickable |
| Repeated dead clicks | Users are lost | Improve affordance |
These signals fire earlier, are measurable on mobile, and feed back into the product itself rather than into a popup that interrupts whatever attention is left.
Is exit intent dead?
Not entirely. Exit intent is still a useful additive trigger on desktop landing pages with high anonymous traffic and a low-friction offer (newsletter, lead magnet). It is no longer a credible primary recovery mechanism and it should never be the only thing standing between a session and a lost lead. The marketing teams getting the most lift in 2026 treat exit intent as one tile in a recovery dashboard that also includes form abandonment, drop-off replays, and partial-submission webhooks.
How it relates to CloseTrace
CloseTrace captures exit-intent moments alongside form abandonment, rage events, and scroll velocity, and lets you replay the session leading up to each exit so you can see whether the popup fired too late, too early, or against the wrong audience. The recovery workflow does not depend on cursor-based prediction.