How to Set Up Proactive Messaging Triggers Based on Scroll Depth

A single percentage across all pages is wrong, since seventy percent of a short page is trivial and seventy percent of a long article is substantial reading.

Thinking in content rather than percentage

The useful question is what a visitor has actually read at a given point, which means checking where the threshold lands on each page rather than assuming.

On a long page, fifty percent may already represent several minutes of reading, while on a short one it may be one screen.

Triggering before the end

A trigger firing at the very bottom of a page frequently arrives as the visitor is already leaving, which wastes the signal entirely.

Setting the threshold somewhat before the end catches them while still engaged, which noticeably improves acceptance.

Separate mobile thresholds

The same content occupies far more scroll length on a phone, so a percentage tuned for desktop fires much later in the reading experience on mobile.

Configuring mobile separately, usually with a lower percentage, is one of the most impactful adjustments available.

Accounting for page changes

Adding content to a page changes what a percentage means, which is why thresholds should be reviewed whenever the pages they target are substantially edited.

This is a common source of triggers quietly becoming ineffective without anyone noticing why.

Checking where the threshold lands

Scrolling the page yourself and noting what is on screen at the intended threshold takes a minute and prevents triggers firing at meaningless points.

This is the step most commonly skipped, and it is why so many scroll triggers fire either too early or after the visitor has finished reading.

Scroll depth alone catches fast skimmers, so combining it with a minimum dwell time filters for genuine reading.

Adding a dwell requirement

Requiring both a scroll threshold and a minimum time on the page removes visitors who scrolled straight to the bottom looking for something specific.

A short dwell requirement is usually enough, since the combination rather than either threshold individually does the filtering.

Considering visitor history

A returning visitor reaching the same depth is a stronger signal than a first-time one, and treating them differently is worth configuring where the data exists.

Suppressing the trigger entirely for visitors who dismissed it previously prevents the repeated interruption that produces lasting irritation.

Checking availability

A proactive offer of help outside coverage hours should either not fire or should say plainly what can be handled and when a person will respond.

Firing the standard message when nobody is available is the most avoidable proactive messaging failure.

A scroll trigger has earned a relevant message, since you know what the visitor has been reading and roughly how carefully.

Referencing the content

A message referring to the specific topic of the page substantially outperforms a generic offer of help, because it demonstrates relevance rather than presence.

This is the main advantage of page-specific triggers, and using a generic message discards most of the benefit.

Offering something specific

Naming what the assistant can do on this topic, or offering a concrete next step such as a comparison or an availability check, converts better than an open question.

Two or three tappable options work better than a sentence, particularly on mobile where typing is the main barrier.

Keeping it short

A proactive message interrupting a reader has a very short window to justify itself, and anything longer than two lines is dismissed unread.

Reviewing the message on a phone rather than a desktop is essential, since length looks very different in the two contexts.

A visitor who dismissed the message once should not see it again on the next page, or the trigger becomes an irritation rather than an offer.

Session-level suppression

Suppressing further proactive messages for the rest of a session after a dismissal is the minimum reasonable behaviour and is frequently not configured.

Without it, a visitor reading three pages receives three interruptions, which reliably produces a negative impression of the business.

Longer-term memory

Remembering dismissals across sessions, for a reasonable period, prevents the returning visitor who has already declined being asked repeatedly.

This is a small configuration decision with a disproportionate effect on how the widget is perceived by regular visitors.

Coordinating with other triggers

Scroll triggers should share a frequency cap with every other proactive message, or several individually reasonable rules combine into constant interruption.

Central capping across all proactive behaviour is what keeps the total experience acceptable as more triggers are added.

Judge scroll triggers on acceptance rate, dismissal rate and what the resulting conversations achieved, not on how many they generated.

Acceptance and dismissal together

Acceptance rate shows whether the timing and message are working, while dismissal rate shows what the trigger is costing on the impressions that did not convert.

A trigger with low acceptance and high dismissal is actively damaging engagement elsewhere on the site.

Outcome of the conversations

Conversations from proactive triggers should be assessed on resolution and commercial outcome, since volume alone can be increased by triggering more aggressively.

Comparing these against visitor-initiated conversations shows whether the trigger is producing value or work.

Adjusting one variable at a time

Changing the threshold, the message and the page set together makes the result uninterpretable, which is how trigger tuning becomes guesswork.

Thresholds receive enough impressions that sequential tests conclude quickly even on modest traffic.

Retiring triggers that do not work

A trigger with persistently low acceptance should be removed rather than retuned indefinitely, since every impression costs a small amount of goodwill.

Removing weak triggers usually improves acceptance on the remaining ones, because visitors stop dismissing the widget reflexively.

Chatboq supports combined scroll and dwell conditions per page group, with separate mobile thresholds, dismissal memory and shared frequency capping.

Setting up the first trigger

Choose a page group where reading depth signals intent, set a scroll threshold checked against the actual page, add a dwell requirement and write a message referencing the content.

Configure the mobile threshold separately at this point rather than intending to return to it, since it is the setting most often left at the desktop value.

Suppression handled centrally

Dismissal memory and the shared frequency cap apply across every proactive message, so adding a scroll trigger does not increase total interruption uncontrollably.

Availability awareness is applied automatically, so the message changes rather than misleading visitors outside coverage hours.

Reporting per trigger

Acceptance, dismissal and downstream resolution are reported for each trigger individually, which is what makes retiring the weak ones straightforward.

Removing underperforming triggers usually improves acceptance on the remaining ones, since visitors stop dismissing reflexively.