There is a version of a nudge that feels like a helping hand. There is another version that feels like a popup you dismiss before you've even read it. The content can be identical. The only variable is when it fires.
We've been thinking carefully about trigger timing since we started building Onboardvue's nudge layer. This post is an attempt to put our mental model into words, because we've found most onboarding teams are either firing too early (before the user has context) or too late (after the frustration has already set in). Both feel bad to the user, and neither converts.
The three timing failure modes
Before we get into what good timing looks like, it helps to name the patterns we see going wrong:
Premature triggers
This is the most common. A user signs up, lands on a dashboard, and immediately gets a tooltip saying "click here to create your first flow." They've been in the product for 11 seconds. They don't know what a "flow" is yet. The nudge is technically correct but experientially nonsensical, because the user has zero frame of reference for what they're being asked to do.
Premature triggers usually come from well-intentioned product decisions made in a vacuum. A PM sees that step 2 of onboarding has 60% drop-off, so they add a nudge at step 2. But the nudge fires the moment the user reaches step 2, before they've had any time to even attempt it. The signal they needed wasn't "user reached step 2." It was "user has been on step 2 for 90 seconds without progressing."
Stale triggers
The inverse problem. A user struggled, figured it out on their own, and then two days later your drip email arrives explaining the thing they already solved. Stale nudges erode trust faster than no nudge at all. They signal that you're not actually watching; you're running a script.
Context-blind triggers
This is subtler. The timing is technically correct, but the trigger fires without respect for what else is happening in the user's session. We've seen products fire a "complete your profile" banner immediately after a user just failed to perform an import. The banner isn't wrong. But the user is in a recovery mindset, not an optimization mindset. That's not a moment for feature nudging.
What good trigger timing actually requires
Good timing requires three things happening simultaneously: the user is in a state of readiness, the relevant event has occurred, and a minimum friction threshold has been crossed. Let us unpack each.
Readiness state
Readiness isn't a boolean. It's a combination of signals. Has the user completed enough prior steps to have context for what the nudge is about? Are they in an active session (not just an idle tab)? Have they previously dismissed this type of nudge, which suggests they're not ready even if the event has triggered?
In Onboardvue, we track a lightweight readiness score on each session using session depth (number of meaningful events in the current session), recency of engagement (was the last event less than 5 minutes ago?), and prior dismissal history. A nudge only fires if the readiness score clears a configurable threshold. By default, that threshold is conservative.
Event relevance window
Behavioral events have a half-life. The "user viewed the integration setup page" event is most actionable in the 30-60 seconds after it fires, moderately actionable over the next few minutes, and essentially stale after 10 minutes. If your trigger system can't differentiate between firing at 30 seconds and firing at 12 minutes, you're going to get very different user experiences from the same rule.
We've implemented event TTLs (time-to-live values) per event type in Onboardvue's trigger engine. Integration-related events have a short TTL. Account setup events have a longer one. Error events are handled separately because they have their own urgency window.
Friction threshold
Some nudges should fire proactively, before the user is stuck. Others should wait for a signal that the user needs help. The distinction matters because proactive nudges feel like guidance, while reactive ones feel like a rescue. Both are useful, but they require different copy, different visual weight, and different placement.
For friction detection, we look at: time-on-step above a percentile benchmark (e.g., user has spent 2x longer than the median user on this step), repeated visits to the same step within a session, and failed form submissions or error states. Any one of these in isolation might not be significant. Two or more in the same session is a reliable signal of genuine friction.
A concrete example: the import screen problem
One of our early customers (a growing B2B data tool with around 2,000 MAU) had a painful drop-off at their CSV import step during onboarding. They'd tried adding a tooltip that said "need help with your CSV format?" but completion rates barely moved.
When we looked at the event data, the tooltip was firing on page load, 1-2 seconds after the user landed on the import screen. The user hadn't tried anything yet. The tooltip was pre-emptive sympathy for a problem that hadn't happened.
We moved the trigger: the nudge now fires only after a failed import attempt, AND only if the user remains on the page for more than 45 seconds after the failure. Same message, same design. Completion rate on the import step increased by around 28% over the following two weeks. The change was entirely in the timing logic.
Trigger windows vs. trigger conditions
Most documentation on behavioral triggers focuses on conditions: what event must occur, what properties must match, what user segment the rule applies to. This is necessary, but it misses the temporal dimension.
We've found it useful to think separately about trigger conditions (the what) and trigger windows (the when). A trigger window is a time-bounded context in which a trigger condition is allowed to fire. Outside the window, even a matching condition is suppressed.
Some windows are session-scoped: the nudge can only fire once per session, and only if the session is at least 3 minutes old. Some are day-scoped: the nudge can fire at most once in a 24-hour period. Some are lifecycle-scoped: the nudge can only fire during the user's first 7 days in the product.
Lifecycle-scoped windows are particularly important for activation flows. A nudge that makes sense on day 2 is often wrong on day 14. Users who've been in the product for two weeks have different mental models and different needs than brand-new users. Sending the same "getting started" flow to both is a timing error even if the trigger condition matches.
What we're not saying
We're not saying nudges should be rare or minimal. There's a school of thought in PLG that says "less onboarding is better, let users discover." That may be true for certain products and certain user types, but it's not a universal principle. High-complexity B2B tools often benefit from active guidance, especially during the first week.
The point isn't frequency. It's fit. A nudge that fires at exactly the right moment can be one of several nudges in a session and still feel natural. A nudge that fires at the wrong moment is annoying even if it's the only one the user saw all day.
Building timing rules that survive
The last thing worth saying: trigger timing logic degrades over time if you don't maintain it. User behavior patterns shift as the product matures. The friction points that existed at launch are not the same friction points that exist six months later, once you've improved the UI and added documentation. If you set trigger windows in January and never revisit them in August, you're delivering nudges calibrated to a product that no longer exists.
In Onboardvue, we surface per-trigger performance metrics (delivery rate, engagement rate, dismissal rate, downstream activation rate) so teams can see when a trigger's effectiveness is decaying. A dismissal rate above 60% usually means the timing is off, the message is wrong, or the audience is too broad. It's rarely just content. Timing is the first thing to examine.
The investment in getting trigger windows right isn't glamorous, but it's where the conversion delta actually lives.