Analytics wants an ad slot counted as viewed only after at least 50% of it has been continuously on screen for one second. IntersectionObserver reports crossings, not durations — how would you build that on top of it, and when do you stop observing the slot?

## Why the API alone does not answer the question The requirement has three parts — an area fraction, a duration, and a once-only guarantee. `IntersectionObserver` answers exactly one of them. It tells you when the target's visible fraction crosses a threshold you nominated, in either direction. It has no concept of "for how long", and no concept of "already counted". Both are yours to add, and an interviewer asking this is checking whether you know where the API's responsibility ends. ## The shape of the solution Threshold 0.5 gives you a pair of events per exposure: a rising crossing and a falling one. A dwell requirement is a timer that must survive from one to the other. ```js const pending = new Map(); // Element -> timeout id const io = new IntersectionObserver((entries, obs) => { for (const entry of entries) { const el = entry.target; if (entry.isIntersecting) { if (pending.has(el)) continue; // already ticking pending.set(el, setTimeout(() => { pending.delete(el); obs.unobserve(el); // count once, then retire recordImpression(el.dataset.slotId); }, 1000)); } else { clearTimeout(pending.get(el)); pending.delete(el); // scrolled past: no impression } } }, { threshold: 0.5 }); document.querySelectorAll('.ad-slot').forEach((el) => io.observe(el)); ``` Four details in that snippet are the actual answer: 1. **Keyed per target.** One observer watches every slot and delivers a batch of entries, so a single module-level timer is wrong the moment there are two slots. `entry.target` is the key. 2. **Cleared on the way out.** Without the `else` branch, a flick-scroll past the slot still counts a second later, and the numbers inflate exactly where advertisers care. 3. **`unobserve` after counting.** It makes the once-only guarantee structural rather than a flag someone can forget to check, and it stops the browser evaluating a slot whose answer is now irrelevant. 4. **The re-entrancy guard.** The initial observation, plus repeated crossings around the tripwire during slow scrolling, can deliver several intersecting entries; without `if (pending.has(el)) continue` you leak overlapping timers. ## Measuring real dwell instead of a fixed threshold If the metric is "total seconds visible" rather than "was it visible for a second", stop using timers for measurement and use the entries' own clock. `entry.time` is a `DOMHighResTimeStamp` on the same time origin as `performance.now()`, so accumulating `time` deltas between rising and falling crossings gives you dwell without a single `setTimeout`. That is also more robust: timers can be delayed by long tasks, while the timestamps record when the geometry actually changed. ```js // on the rising edge start.set(el, entry.time); // on the falling edge total.set(el, (total.get(el) ?? 0) + (entry.time - start.get(el))); ``` ## What the geometry does not know A senior answer volunteers the honest limits of "viewed": - **Occlusion.** A slot under a cookie banner or a modal still intersects. IntersectionObserver v2 adds `trackVisibility` with a required `delay` and reports `entry.isVisible`, but it is Chromium-only, so a cross-browser tracker cannot depend on it. - **Tab and window state.** Intersection is measured against the viewport box, not against whether the tab is foregrounded. A slot that was intersecting when the user switched away stays in that state, and a naive `setTimeout` still fires, so background tabs quietly accrue impressions. Reading `document.visibilityState` — and abandoning the pending timer when the page is not visible — is what makes the metric defensible. - **The unload boundary.** A partial exposure that is still ticking when the user navigates away is simply lost unless you flush what you have on the way out, which is a transport decision rather than an observer one. ## Teardown Every pending timeout is a live reference to your callback and its closure. When the view is destroyed, `observer.disconnect()` plus clearing every entry in the `Map` is the sweep; doing only one of the two leaves either timers firing into a dead view or an observer still evaluating detached elements. In a single-page app that mounts and unmounts feeds repeatedly, that pair is the difference between a stable memory profile and a slow climb. ## How to present it Lead with "the observer gives me edges; the duration is a timer between them". Then name the four details — per-target keying, clearing on exit, `unobserve` after counting, and the guard against duplicate rising entries. Finish with the honesty about occlusion and hidden tabs. That is a complete senior answer in under two minutes.