A product can exist in a collection response without ever appearing on a shopper’s screen. If your analytics counts every returned item as an impression, products near the bottom of a long list acquire exposure they did not receive. Click-through rates then punish position and loading behaviour as though they were evidence of weak merchandising.
Our editorial recommendation is to define a measurable exposure opportunity before judging a product’s response. This guide explains an IntersectionObserver approach for collection pages and recommendation rails. The thresholds and numbers below are illustrative measurement policies, not an industry viewability standard or evidence that a person looked at a product.
Table of Contents
- Choose the impression you mean
- Separate loading from measurement
- Design a small observation state machine
- Handle repeat cards and changing lists
- Work through a merchandising example
- Keep measurement within a performance budget
- Validate the awkward journeys
- The EcomToolkit view
Choose the impression you mean
Start with a written unit: one eligible product-card exposure within one list instance. A list instance might represent the initial collection, a filtered result or a recommendation placement. Decide whether sorting starts a new instance and whether returning from a product page preserves the old one. Without these rules, two technically correct implementations can produce incompatible reports.
A useful distinction is between delivered, rendered and exposure-qualified products. Delivered means the response included the item. Rendered means a card entered the document. Exposure-qualified means your chosen geometry and timing conditions were met. Keep these as separate stages; do not silently rename one as another during a tracking migration.
The W3C Intersection Observer draft describes asynchronous reporting of a target’s intersection with a root. That root can be the viewport or an appropriate containing element. Intersection is geometric information. It does not establish attention, reading, or freedom from every possible visual obstruction.
| Stage | Suggested event meaning | What it cannot establish |
|---|---|---|
| Delivered | Product included in the list response | A card was rendered |
| Rendered | Product card entered the document | Card reached the viewport |
| Exposure-qualified | Card met the defined eligibility rule | Shopper noticed or understood it |
| Selected | Shopper activated a product link | Purchase intent or a completed order |
Separate loading from measurement
An image loader benefits from starting before a card enters view. An exposure metric usually should not count that early. If the same observer configuration serves both purposes, a generous preload margin can turn products below the fold into measured impressions.
Use separate policies even if the implementation shares utilities. The loading observer can look ahead; the measurement observer should use the actual measurement boundary. Record a policy version alongside aggregates so a future margin change does not masquerade as a merchandising improvement.
For a horizontally scrolling recommendation rail, test the clipping container as well as the page viewport. A card can sit inside a rail’s scrollable content while being outside its visible area. A product with a tall card can also struggle to satisfy a high area threshold on a short screen. Choose a rule that works for the real card sizes, not just a desktop mock-up.
Design a small observation state machine
Consider an example rule requiring at least half the card’s area for one continuous second while the page is visible. Crossing the area threshold begins a candidate interval. Falling below it cancels the interval. Completing the interval emits one qualified impression and marks that card identity as counted for the list instance.
A callback alone is not a dwell timer. If geometry does not cross another threshold, there may be no later callback just because a second passed. Maintain a timer or scheduled check, and cancel it when eligibility changes. Use monotonic timestamps within the document rather than calendar time for interval arithmetic.
Tab state needs its own treatment. MDN’s visibility-timing example combines intersection information with page visibility because intersection alone does not resolve background tabs. Decide whether a tab switch cancels a continuous interval or pauses an accumulated one. Those are different measures; label them accordingly.
For ordinary storefront reporting, a simple continuous rule is often easier to explain and test. It also reduces the temptation to interpret a collection of fleeting exposures as sustained engagement. Preserve raw eligibility counts during rollout so you can explain the difference between old and new reports.
Handle repeat cards and changing lists
Deduplicate on the business unit you selected. A product identifier alone may be insufficient when the same item appears in both the main grid and a recommendations rail. A DOM element alone is also insufficient when a virtualised list reuses that element for another product.
A practical key includes list instance, placement and product identifier. Add position if the question concerns placement exposure, but recognise that this can count the same product again after a sort. Keep the rule stable across devices before comparing mobile and desktop rates.
When filters replace the list, cancel outstanding timers and remove obsolete targets. When a component is destroyed, disconnect observers or unobserve its cards. Retaining stale state can leak memory and send events for products that are no longer part of the shopper’s current results.
Treat back navigation deliberately. A restored list may deserve continuity rather than a fresh exposure for every card. The existing bfcache guide explains why returning to a page is not always a new document load. Test that journey before declaring your deduplication complete.
Work through a merchandising example
Suppose an illustrative collection response contains 24 products. Twelve cards render immediately, six meet the exposure rule, and two receive clicks. A response-based denominator produces a selection rate of 2 divided by 24, or 8.3%. An exposure-qualified denominator produces 2 divided by 6, or 33.3%.
Neither figure should be presented without its definition. The first describes selection relative to the returned assortment; the second describes selection relative to measured exposure. The difference does not prove that a new tracking system increased engagement. It changed the question.
| Illustrative measure | Calculation | Result |
|---|---|---|
| Render coverage | 12 rendered / 24 delivered | 50% |
| Exposure coverage of rendered cards | 6 qualified / 12 rendered | 50% |
| Selection per delivered product | 2 selected / 24 delivered | 8.3% |
| Selection per qualified exposure | 2 selected / 6 qualified | 33.3% |
For a product-level analysis, also align the selected products with the eligible exposure population. A very fast click could occur before the dwell rule completes. Decide whether that click creates a separate interaction-qualified exposure or is reported outside the dwell-based rate. Otherwise the numerator can contain events that are impossible under the denominator’s definition.
Keep measurement within a performance budget
An asynchronous browser API does not make callback work free. A callback that builds large payloads, traverses the document, updates application state and sends a request for each card can still interfere with shopping.
Share an observer across targets using the same configuration. Record minimal eligibility changes, batch telemetry where appropriate and avoid repeated layout reads inside the callback. MDN’s API guide describes threshold-driven entries and callback behaviour; profile your own implementation rather than assuming the interface guarantees a fast page.
Measure callback duration, event volume and payload size on a realistic mobile collection. Compare a long scroll before and after instrumentation. Use the interaction attribution guide if filter or cart responsiveness deteriorates after release. The purpose of analytics is to understand shopping, not to make scrolling harder.
Validate the awkward journeys
Test rapid scrolling, slow image loading, browser zoom, orientation changes and a sticky header covering the first row. Also test an empty result, repeated products, a horizontal rail, sorting and leaving the tab during the candidate interval. These cases expose definitions that a straight scroll through a desktop page will miss.
Inspect the outgoing events against a small manual record. Check that each qualified product has the expected list instance and that unqualified cards remain absent. Compare event totals with rendered-card totals; an unexpected excess should trigger investigation before the data reaches a merchandising dashboard.
Deploy the new measure beside the previous one for a limited validation period. Annotate the switch date, retain the policy definition and warn report users against comparing the two series as if nothing changed. The strongest implementation includes an owner who can explain its denominator months later.
The EcomToolkit view
Product impressions are useful when they describe a consistent opportunity to engage. Start with that contract, then choose the browser mechanism. A smaller, defensible exposure dataset is more valuable than a large impression count whose meaning changes with page length.
If product-list reporting and storefront behaviour disagree, request an EcomToolkit audit to connect measurement rules with the actual shopping journey.
