11 March 2026 · Telemetry

Reading event noise without drowning


A busy stream flatters the team that instrumented it. In Product Signal Mapping we treat most of that busyness as weather you walk through, not climate you report.

People working at laptops in a classroom-style room

Open a raw live view on a consumer app at lunchtime and you will see a river: screen_view, button_tap, video_quartile, experiment_exposure, a heart-beat from a forgotten debug flag. New analysts often try to graph the river. The graph looks important because it moves.

Volume is a property of instrumentation, marketing spend, and how chatty the SDK was configured to be. It is not, by itself, a product fact. In the atelier we ask a colder question: which names would you still defend if the river halved tomorrow?

Three sieves

First, jobs not screens. If an event cannot be paired with a sentence a user would recognise — started a trial, attached a card, finished a workout — it stays in the noise pile. Screen_view of “HomeV3” is a breadcrumb for debugging, not a claim for Monday.

Second, cardinality. A property that mints a new value for every session is a novel, not a dimension. We freeze it or we hash it out of the dictionary. Third, ownership. An event nobody will update after the next navigation rewrite is already dead; it just has not stopped firing.

A practical hour

Take one day’s export. Strike every event that fired more than once a minute per active user unless you can name the job. You will feel unfaithful to the engineers who added those taps. Thank them later with a freeze list, not with a dashboard that pretends every tap was a decision.

What remains is small enough to put on a readout. The rest can live in a debug view. App Analytics becomes quieter, which is usually the point.

Back to the journal · Product Signal Mapping