Measure active engagement time accurately
accurate engagement and efficient telemetry.
accumulate time only while the tab is visible and the user active, via Page Visibility and activity events; flush with sendBeacon on unload.
What's really being asked
It checks whether you understand why naive time-on-page is wrong and which browser APIs fix both the measurement and the delivery problems at scale.
The full answer
Define active engagement time as time the user is plausibly attending. Maintain an accumulating timer that increments only when two conditions hold: the page is visible, detected via the Page Visibility API and visibilitychange events, and the user is active, inferred from recent interaction events such as scroll, mousemove, keydown, and touch within a short idle timeout of a few seconds; if no interaction occurs, pause the timer. This excludes backgrounded tabs and idle reading-abandoned sessions. For delivery, do not POST continuously. Accumulate locally and flush at sensible moments, but the unload moment is unreliable for a normal XHR, so use navigator.sendBeacon, which queues a small payload the browser sends asynchronously even as the page unloads, fired on visibilitychange to hidden or on pagehide.
The mistakes people make
Counting wall-clock time from load to unload as engagement, which inflates idle tabs left open for hours. Polling the server every second, which hammers it under load. Using a synchronous XHR on unload, which browsers may drop or block. Ignoring the visibility state entirely so backgrounded tabs still accrue time.
What usually comes next
Why is sendBeacon better than a synchronous XHR on unload. What idle timeout is reasonable for reading. How do you handle the back-forward cache and the pagehide event correctly. How do you aggregate noisy client-reported times robustly on the server side.
A concrete example
A reader opens an article, reads for forty seconds, switches tabs for five minutes, then returns and skims for ten seconds. The engagement timer records about fifty active seconds, not six minutes, because it paused entirely while the tab was hidden. On pagehide a single sendBeacon ships the fifty-second total in one compact, non-blocking request without delaying the user's navigation away from the page.
Interview question
Why is navigator.sendBeacon preferred over a synchronous XHR for sending engagement data as the page unloads?
- a.It retries failed requests indefinitely
- b.It queues a non-blocking request the browser delivers even during unloadCorrect
- c.It compresses the data better than XHR
- d.It encrypts the payload automatically
Why? this is the answer
sendBeacon hands the request to the browser to send asynchronously without blocking navigation, so unload-time data is not dropped. It offers no special encryption, retries, or compression over a normal request.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #web-analytics
- #page-visibility
- #sendbeacon
- #engagement
- #telemetry
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles