A media company computes a daily unique-viewer rate from a play log. The same viewer is written twice whenever a player retries, so the rate treats one person as two viewers. What must happen before that rate is computed?
Select an answer to reveal the explanation.
Short Explanation
Two ticket stubs from the same person should not make you count two guests. The player retry writes the viewer again, and the rate believes it. Collapse those repeats into one viewer before you compute the rate, or the extra stub becomes an extra person.
Full Explanation
A unique-viewer rate is a rate of distinct people, not a count of log lines. When a retry writes the same viewer twice, the raw log contains two rows for one entity. Deduplication collapses those rows into one viewer before the rate is computed, so the person is counted once. Computing the rate on the raw log and deleting duplicates afterward leaves the published rate based on the double count; the cleanup comes too late to change the figure. Averaging timestamps while keeping both rows may tidy the clock but still presents two entities to the rate. Assigning a new identifier to each retry does the reverse of a unique count: it turns one viewer into several people and inflates the rate with every restart. Exam caveat: deduplication has to use the identity the metric means, such as a viewer key, because collapsing only exact full-row copies can miss retries that differ by a timestamp. Operational check: pick one viewer with a known retry, collapse that identity, and confirm the rate counts that person once.