testing · signals
Signals — what to measure and why
Analytics events are the raw material. Signals are what the team reads to understand whether the work is succeeding. Not every signal is equally useful at every moment. The taxonomy matters because a team that watches the wrong signal at the wrong time either panics over noise or misses a real problem.
Leading signals — predict the outcome before it happens
- Feature adoption — are people using the new flow at all? If Gal opens the grading view and immediately switches back to the spreadsheet, the flow has a barrier the brief didn't anticipate.
- Task completion — of the people who start the flow, how many finish? A 90% start rate and a 40% completion rate means something breaks midway.
- Error encounter rate — how often do users hit error states? A rate that climbs in the first week signals a gap the scenarios missed.
Lagging signals — confirm the outcome after it happened
- The prediction metric — grading time from 47 to under 15 minutes. The brief's promise, checked on the named date. The most important signal; arrives last.
- Support ticket volume — a feature that generates tickets has a gap between design and experience large enough for users to complain about.
- Retention / renewal — for subscription products, whether users keep paying after the feature ships. The slowest signal, the most consequential.
Leading signals are what the team watches in the first weeks. Lagging signals are what the prediction check measures. Both categories are defined before the release gate — not invented after the feature ships.