Journal · 28 Feb 2026
Instrumenting first-use without drowning in noise
First-use is the most over-instrumented moment in mobile analytics. Teams log view, tap, permission prompt, permission result, camera open, camera cancel, crop, confirm, upload start, upload fail, upload retry, and success. Then nobody can remember which of those meant “the user completed the job.”
In Event Taxonomy for Mobile Teams, and in week three of Adoption Signals, we ask for three events only at the start: feature_exposed, feature_trial_succeeded, and feature_trial_failed with a small, stable reason code. Everything else is optional until those three are trustworthy.
What “succeeded” has to mean
Succeeded is a persisted outcome, not a UI state. A crop screen is not success. A 200 from an upload API is not success if the ledger row never appears. If your backend can roll back, your trial event should fire after the rollback window, or you will teach the council a lie.
Failures worth keeping
Keep reason codes short: permission_denied, network, validation, payment_incomplete, unknown. If unknown stays above a fifth of failures, your instrumentation is still guessing. Do not add a new event name for each reason; you will never join them later.
Deep links from LINE deserve a property on exposure, not a parallel event family. Otherwise first-use from a campaign and first-use from in-app navigation become two sciences.
Resist the urge to log every micro-interaction “in case we need it.” You will need a clean trial more than you will need the tap map. Add density only after the three events survive a redesign without renaming.