Implementation worksheet · 5 min read
An In-App Component Exposure Deduplication Checklist
Deduplicate exposure events on a key of user, component, and a defined window — then test six cases that produce duplicates: a component re-rendering on state change, a user navigating back to the same screen, a modal reopening after dismissal, the same component mounting twice in different layouts, a page refresh, and a session resuming on another device. Decide the window deliberately: per session for most in-app components, per day for recurring prompts, per lifetime for one-time announcements. Duplicate exposures are worse than merely noisy — they inflate reach and deflate conversion rate simultaneously, so a component looks both more seen and less effective than it is.
Exposure is the denominator of every in-app conversion metric. Getting it wrong does not add noise symmetrically; it biases every rate in the same direction, which is how a well-performing prompt gets cut.
Put it into practice
1. Fire exposure on visible, not on mount
A component mounted off-screen or behind a collapsed section is not an impression. Use an intersection check so the event means what the metric assumes it means.
2. Define the dedupe key and window per component type
user + component + window. Session for standard prompts, day for recurring ones, lifetime for one-time announcements. Write the window into the component's spec, not into the analytics query.
3. Test the re-render case first
React-style re-renders on state change are the most common duplicate source. If the event fires in a render path rather than an effect with a guard, one prompt can log dozens of impressions.
4. Test navigation and resume
Back navigation to the same screen, refresh, and a session resumed on another device. Each should respect the window rather than starting a new one.
5. Reconcile against a known case
Take one user, walk through the flow manually, and compare what you did with what was logged. This five-minute check catches more than a week of query auditing.
Exposure dedupe cases
Copy this structure into your review document and record your observed result for each row.
| Case | Should log | Common bug | Verified |
|---|---|---|---|
| First visible render | 1 exposure | — | |
| Re-render on state change | 0 additional | fires per render | |
| Back navigation in-session | 0 additional | new exposure | |
| Modal reopened after dismiss | per policy | always counted | |
| Page refresh | 0 additional (same session) | new session assumed | |
| Resume on another device | per policy | duplicate user key |
A failure worth checking
The re-render triple-count: an exposure event sits in a render path, the component re-renders on every keystroke in a nearby field, and one prompt logs thirty impressions. Reach looks excellent, conversion rate looks terrible, and the prompt gets cut for underperforming when it was converting at three times the reported rate.
Common questions
Should a dismissed component log exposure again if it reappears?
Only if your policy intends it to reappear — and if it does, the exposures are separate by design and should be counted. The rule to avoid is silent re-exposure that neither the policy nor the metric acknowledges.
Where should deduplication happen?
At the point of emission, so every consumer sees the same numbers. Deduplicating in the analysis query means each new report has to re-implement the rule, and eventually one of them will not.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.