On-Site Popup and Banner CRO Automation: The Right Prompt, at the Right Moment, Not Every Moment

A popup that fires the instant a page loads, regardless of what the visitor is actually doing, teaches people to close it reflexively before reading it — the exact opposite of the outcome it was built for. The difference between an interruption that converts and one that gets dismissed on reflex usually comes down to timing: whether it appears after genuine engagement (real scroll depth, a real second page view) or the moment the visitor has shown zero signal of interest yet.

A popup on a fixed timer is the easy version — the harder, more useful version reacts to what a specific visitor is actually doing: how far they have scrolled, how many pages they have viewed this session, or whether their cursor just moved toward the browser's close button. Each of those signals needs its own real detection logic running in the visitor's browser, not a single generic timer standing in for all of them. And once a widget can fire on real behavior, it also needs real frequency control — without it, a visitor who already dismissed an offer once would see the exact same interruption on every subsequent page view, which erodes trust faster than showing nothing at all.

A team configures a widget in one of six formats — popup, full-screen takeover, slide-in, top banner, bottom banner, or a persistent bar — along with a trigger: a fixed time delay (three seconds by default), a minimum page-view count in the session (two by default), a scroll-depth percentage (50% by default), exit intent (detected the instant the cursor crosses toward the top of the browser window, the real signal a visitor is about to leave), or a specific URL match. Targeting narrows who ever sees it: by device (mobile or desktop, detected by real screen width) and by URL include/exclude patterns.

Once a widget qualifies to fire for a given visitor, a frequency cap decides whether it actually shows: once per browser session, once per calendar day (a real 24-hour check, not just "once per session" renamed), or every time the trigger condition is met. Every meaningful moment — the widget being shown, a click inside it, a specific conversion action, or the visitor dismissing it — is recorded through a single atomic counter increment, so two visitors triggering the same widget in the same instant are both counted correctly rather than one silently overwriting the other. The account a widget belongs to is always resolved server-side from a tracking key embedded in the site's script — a request can never claim to belong to a different account than the one that key actually maps to.

A team configures a slide-in offer set to trigger on exit intent, targeted to desktop visitors on the pricing page only, capped at once per day. A visitor browses the pricing page, and the moment their cursor moves toward the browser's tab bar — the real signal they are about to leave — the slide-in appears with a discount offer. They dismiss it. The next time they visit the same page later that same day, nothing appears, because the daily cap already recorded a dismissal; the following day, the offer is eligible to show again if they trigger the same exit-intent behavior.

A popup or banner starts appearing when a visitor's actual behavior suggests the moment is right, rather than on a schedule that ignores what they are doing. Frequency capping means the same visitor is not shown an identical interruption on every page load, and because every event type is tracked separately and atomically, a team can tell the difference between "widely seen but rarely clicked" and "rarely triggered at all" instead of guessing from a single combined number.

A team that needs a widget to appear based on a visitor's identity or CRM history (not just their on-page behavior in the current session) will find targeting here is scoped to device and URL, not contact-level personalization. A team expecting real-time visual A/B testing of widget copy inside this same tool should look at Flow's dedicated A/B testing mechanism, which is a separate, statistically-driven feature for testing page-block variants, not widget copy specifically.

A popup on a flat timer treats every visitor identically regardless of what they are actually doing on the page, which is exactly what trains people to close it without reading. Centriu Flow's widgets react to five different kinds of real, detected behavior — scroll depth, exit intent, page-view count, elapsed time, or URL — and respect a frequency cap so the same visitor is not shown the same interruption over and over, keeping the moment relevant rather than routine.