Launch changes the source of truth. Before launch, product decisions rely heavily on market knowledge, direct evidence, and explicit assumptions. After launch, the operating system begins producing behavioral and commercial signals of its own.

The danger is not having too little data. It is treating every available number as equally meaningful.

Activity is not an outcome

A click proves that an interaction happened. It does not prove that the person understood it, received value, or would pay for the result.

A visit proves that a surface was reached. It does not prove that the intended audience arrived or that the visit created a viable customer relationship.

A user count proves that identities or devices were recorded under some definition. It does not prove continued use.

Revenue proves that money changed hands. It may still conceal churn, support cost, refunds, concentration, or an operating process that cannot scale responsibly.

Each signal is useful when its limitation is understood.

Start with the operating outcome

Measurement should begin with the change the product exists to create.

For a workflow product, that may be a completed and accepted operation. For a consumer application, it may be a repeated useful session. For an internal system, it may be fewer manual exceptions or a shorter cycle from request to decision.

Write the outcome in plain language, then identify the events that show progress toward it.

A useful sequence is:

The user reaches the relevant condition.
The user attempts the core action.
The system completes the action correctly.
The resulting state creates value.
The user or operator returns when the need appears again.

This produces a decision model rather than a collection of dashboard widgets.

Clicks explain interaction behavior

Clicks, taps, field changes, and navigation events are useful for understanding where people act or stop acting.

They can answer:

Is the intended action discoverable?
Does a control invite repeated attempts?
Where does a workflow lose people?
Which recovery path is being used?

They cannot answer why the behavior occurred without supporting context. A heavily clicked control may be valuable, confusing, or broken.

Instrument meaningful actions and failure conditions. Avoid recording every movement simply because the analytics tool permits it.

Visits explain acquisition and return

Visits become useful when they are connected to source, audience, and intent.

A product team should be able to distinguish:

a new person evaluating the product;
an existing user returning to work;
an operator administering the system;
automated or irrelevant traffic;
a person arriving through a specific market channel.

Aggregate traffic without these distinctions can encourage work that increases attention without improving the product.

Users need a precise definition

“Active user” should describe product value, not merely a login or application open.

The right definition depends on the product. It might require completing a report, publishing an item, resolving an operational task, finishing a guided session, or returning to a saved workflow.

Write the definition next to the number. If the definition changes, preserve that history so the trend remains interpretable.

Revenue needs operating context

Revenue is a strong commercial signal, but it still needs decomposition.

Useful questions include:

Is revenue new, recurring, expanded, refunded, or at risk?
Which product behavior preceded the purchase?
How much manual work is required to deliver it?
Is it concentrated in one customer or segment?
Does the product remain valuable after the first payment?

A revenue increase can justify investment. It can also expose an operational bottleneck that needs to be fixed before more demand arrives.

Include system health

Customer and commercial measures do not reveal whether the software is becoming harder to operate.

The operating view should include signals such as:

failed or delayed core workflows;
repeated requests and reconciliation work;
support interventions;
background-job backlog;
release failures and recovery time;
external-service errors;
data corrections performed by operators.

These are product signals because they describe whether the promised outcome remains dependable.

Every measure should have a response

A metric earns its place when the team can state:

what decision it informs;
what change would be meaningful;
what other evidence is needed;
who reviews it;
what action becomes possible.

If a number changes and nobody knows what decision follows, it is reporting rather than operation.

The goal after launch is not a perfect dashboard. It is a short feedback loop in which real use changes the next product decision while the system remains understandable and accountable.

What to measure after launch