Goals–Signals–Metrics Process

What this topic is for

A common failure mode when choosing product metrics is starting with whatever is easy to measure — page views, time on site, click counts — and then working backward to justify them as meaningful. The result is a dashboard that looks busy but doesn't tell the team whether the product is actually getting better or worse for users.

The Goals–Signals–Metrics (GSM) process prevents this by forcing teams to start with what success looks like before choosing how to measure it. Goals come first; metrics are derived. The process works well alongside the HEART framework, which defines what dimensions of user experience to care about. GSM provides the method for turning each HEART dimension into specific, defensible metrics.

This topic covers the three levels of GSM, how to fill out a HEART × GSM matrix, and what separates a well-specified metric from a bad one.

The three levels

Goals

A goal states what success looks like for a given HEART dimension. It's not a measurement — it's an outcome the team cares about. Goals are written in plain terms, not metric terms: "users can find what they're looking for," "users keep coming back," "users feel confident after completing the task."

Goals are intentionally abstract at this stage. The point is to get explicit about what matters before getting concrete about how to measure it. Teams that skip goals and go straight to metrics often end up measuring things that are easy to count but don't connect to whether the product is working.

One HEART dimension can have multiple goals, but one or two per dimension is usually enough. More goals mean more metrics; keep the set manageable.

Signals

A signal is observable evidence that a goal is being met or not. It's a behavior or event you could imagine seeing in data — not a measurement yet, but a description of what you'd be looking for.

Good signals are:

• Specific enough to be observable. You can imagine seeing it in a log or a survey response.
• Connected to the goal. If you saw more of this, you'd believe the goal was closer to being met.
• Not already a metric. Signals describe what to look for; metrics describe how to count it.

For the goal "users can find what they're looking for," signals might include: a user clicking on a result and not returning to the search page; a user completing a search with a single query without reformulating. For "users feel confident after completing the task," a signal might be: the user does not immediately undo the action; the user gives a positive response to a post-task satisfaction prompt.

Each goal usually yields one to three signals. Choosing signals is the hardest part of the GSM process — it requires thinking carefully about what would actually constitute evidence of success, not just a correlation with success.

Metrics

A metric is a quantification of a signal — the specific number you'll track to operationalize what the signal is telling you. Metrics have denominators, time windows, and clear operational definitions.

For the signal "user clicks a result and doesn't return to search," the metric might be: fraction of searches that result in at least one click with no return to the search results page within 30 seconds (a form of search success rate). For "user completes a search with a single query," the metric might be: fraction of search sessions containing exactly one query.

Good metrics are:

• Specific. Clear enough to implement unambiguously. Two engineers should produce the same number from the same definition.
• Sensitive. Small improvements in the product should produce detectable changes in the metric.
• Resistant to gaming. The metric shouldn't be easy to inflate without actually improving the experience.
• Directional. It should be clear which direction is better.

The HEART × GSM matrix

The HEART × GSM matrix puts the two frameworks together. Rows are HEART dimensions (or a subset); columns are Goals, Signals, and Metrics. Each cell answers: for this HEART dimension, what are the goals? What signals would indicate them? What metrics would be tracked?

A partial example for a document editor:

Dimension	Goals	Signals	Metrics
Happiness	Users feel satisfied with editing	Users give high ratings after editing	Mean satisfaction score (1–5); NPS
Engagement	Users edit regularly	Users open documents multiple times per week	Mean edit sessions per user per week
Adoption	New users discover core features	First-time use of formatting tools	% of new users who use 3+ formatting features in week 1
Retention	Users return after first session	Users return within 7 days of first use	7-day retention rate
Task success	Users complete formatting tasks	Users complete operations without errors	Error rate on formatting operations

Not every cell needs to be filled. If the team is focused on Adoption right now, the Retention row can be left sparse. The matrix is a planning tool, not a compliance checklist.

Filling the matrix well

Start with goals, not metrics. The most common mistake is to fill the Metrics column first and then reverse-engineer goals. This produces metrics that are easy to measure but not meaningful.

Be honest about what signals are really capturing. A signal should provide real evidence for the goal, not just correlate with it. "User spends a long time on the page" might seem like a signal of engagement, but it could also be a signal of confusion. Be skeptical of signals before turning them into metrics.

Choose a small number of primary metrics. The matrix can accommodate dozens of metrics across five dimensions, but a dashboard with dozens of metrics is unusable. Identify the two or three metrics that matter most and make those the primary ones. The rest can exist as diagnostics, consulted when investigating a change.

Distinguish between metrics and goals. If the Goals column contains things like "increase DAU by 10%," you've skipped the goal and gone straight to the metric. Goals should be stated in terms of user outcomes, not numbers.

Use the matrix to make trade-offs visible. A product team optimizing for Engagement at the expense of Happiness isn't necessarily making the wrong call — but they should be doing it knowingly. Filling out the full matrix makes those choices explicit and keeps them honest.

Further reading

• Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications — Kerry Rodden, Hilary Hutchinson, and Xin Fu (Google), CHI 2010. The original paper introducing HEART and the GSM process.
• HEART Metrics: The five dimensions — Happiness, Engagement, Adoption, Retention, and Task Success — with detail on what each measures and how to measure it.