Idle and active state signals
Idle and active signals separate time a user is actually interacting from time the page is merely open. Analytics derives an active state from recent interaction (clicks, keypresses, scroll) and treats prolonged silence as idle, so engagement time does not inflate. This is a derived concept built from input events and visibility, not a single named GA4 event. It keeps engagement-based metrics meaningful.
How active state is derived
The common rule is: the user is 'active' if any qualifying interaction (pointer, key, scroll, or focus) occurred within a recent window; otherwise 'idle'. The window length is a convention you choose. Browsers also expose an Idle Detection API for OS-level idle, but most analytics derive activity from input events plus the Page Visibility state. The formula is: active = (now − last_interaction) < window AND visible.
Why it matters for metrics
Engagement time, engaged sessions, and bounce-like signals all degrade if idle time is counted as engagement. By accruing time only while active and visible, you keep these metrics representative of attention rather than of an open tab. Choose the idle window deliberately — too short under-counts genuine reading; too long over-counts abandonment — and document it so reports are interpretable.
- active = recent interaction within a window AND visible
- Idle window is a chosen convention
- Prevents engagement inflation from open-but-ignored tabs
How it appears in analytics and logs
Implausibly long engagement times often mean idle periods are being counted as active; tightening the active-window definition usually corrects them.
Diagnostic use case
Keep engagement time honest by counting it only while the user is active — recent interaction within a window — and pausing during idle stretches.
What WebmasterID can help detect
WebmasterID can bound engagement using an active-state rule plus visibility, so engagement figures reflect real attention without capturing input content.
Common mistakes
- Counting idle, backgrounded time as engagement.
- Recording the content of interactions, not just their presence.
- Leaving the idle window undocumented, making metrics opaque.
Privacy and accuracy notes
Active/idle state is derived from the presence of interaction, not its content. Record only that interaction occurred, never keystrokes or pointer paths that could identify someone.
Related pages
- Engagement time and the user_engagement event
Engagement time measures how long a page was actually in the foreground and active, recorded through GA4's user_engagement event. It replaces the old, unreliable time-on-page that could not measure the last page of a visit. By only counting time when the tab is visible and focused, engagement time is a more honest attention signal — though still not a guarantee that anyone read anything.
- Page visibility change events
A page-visibility event comes from the Page Visibility API's visibilitychange event, which fires when a tab becomes hidden or visible. Analytics uses it two ways: to pause engagement timing when a tab is backgrounded, and as the safest moment to flush pending events before a user leaves. It is a browser primitive that underpins reliable measurement, not a GA4 event you name yourself.
- The user_engagement event
user_engagement is the GA4 event that carries active engagement time. The SDK and tag send it periodically — and when the page or app goes to the background — to report how long the user was actively engaged via the engagement_time_msec parameter. It underpins engaged sessions, engagement rate, and average engagement time. It measures attention duration, never who the user is.
- Website observability
Measure attention, not open tabs.
Sources and verification notes
- MDN — Idle Detection APIOS-level idle; active-window threshold for analytics is a convention.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.