Measure whether eligible users reach the product’s core value, then whether they return when the need recurs. Visits and registrations describe acquisition; they do not establish usefulness. Define activation around a completed task, not a convenient button click.
Define value before choosing events
For an illustrative maintenance-request product, activation might mean submitting a valid request that reaches the responsible team. Opening a dashboard is not equivalent. Write down the qualifying user, successful outcome, evidence source and exclusions, including staff accounts, test traffic and cancelled requests. This is a proposed measurement design, not a report of customer results.
When the outcome is stored on the server, record success from that confirmed outcome. A browser click can help diagnose usability, but must not also count as a completed request. Avoid sending names, free-text messages, payment details or document contents to analytics. Pseudonymous identifiers still need an appropriate privacy policy and access controls.
Use a measurement definition card
| Measure | Operational definition | Decision it supports |
|---|---|---|
| Completion | Valid outcomes divided by eligible attempts | Find a broken journey |
| Activation | First confirmed core-value outcome | Assess the onboarding path |
| Return | Repeat use when the need recurs | Test continued usefulness |
| Failure | Attempts ending in a defined failure state | Prioritize a specific repair |
| Result quality | Outcomes accepted without correction | Check that speed is not hiding rework |
Record the denominator, observation window and exclusions beside every percentage. Ten completions among twelve users can be informative, but not if all twelve are employees testing the system. Show counts alongside rates, and avoid treating a small or unusual week as a reliable trend. A monthly purchasing tool does not need daily return visits to be useful.
Turn one observation into one decision
Suppose users submit requests but repeatedly ask support whether the request arrived. Interview them about what they expected to see. The next change may be a clear receipt and status history, not a new reporting module. Separate a product limitation from confusing language, missing permissions or a slow manual approval process.
For each finding, choose a decision: simplify a step, repair a failure, revise the underlying hypothesis, or keep observing. Record missing measurement periods as unavailable. An analytics outage is not evidence of zero use, and consent choices can affect coverage.
Test measurement before trusting it
Run a successful request, a rejected request and a repeated submission in an isolated environment. Check that success is counted once, failures remain distinct, and staff/test users are excluded as intended. Verify the payload contains no personal form data. Document any difference between consented analytics and operational aggregate counts rather than silently combining them.
Build the measurement definitions into your MVP development scope. Use the project brief checklist to name the decisions, and dashboards owners actually read to keep reporting tied to action.
Sources and editorial status
- Google Analytics: avoid sending personally identifiable information.
- Original contribution: the measurement definition card and acceptance scenarios; no growth forecast is implied.
