Google HEART Framework: Happiness, Engagement, Adoption, Retention, Task Success

By Harry Nguyen · Updated Oct 11, 2026

The HEART framework is a set of five categories for measuring user experience at scale: Happiness, Engagement, Adoption, Retention, and Task success. Google researchers published it in 2010 as a user-centered complement to traffic and revenue counts. Teams pick the categories that fit their goals, then turn each into a specific, trackable metric.

That's the short version. The longer version matters because most teams that adopt HEART skip the part that makes it work. The five letters are a menu, not a scorecard. The real value sits in the process that comes with them, called Goals, Signals, Metrics, which forces a team to say what success looks like before anyone builds a dashboard.

Key Facts: Google HEART Framework

• HEART was introduced in a 2010 paper by Kerry Rodden, Hilary Hutchinson, and Xin Fu of Google, presented at CHI 2010. (Google Research)
• The five categories are Happiness, Engagement, Adoption, Retention, and Task success. (Rodden, Hutchinson, and Fu, CHI 2010)
• The authors say they applied the framework and the Goals-Signals-Metrics process to more than 20 different products and projects within Google. (Rodden, Hutchinson, and Fu, CHI 2010)
• HEART was designed to sit beside PULSE metrics (Page views, Uptime, Latency, Seven-day active users, Earnings), not replace them. (Rodden, Hutchinson, and Fu, CHI 2010)
• The paper says it is not always appropriate to use metrics from every category, and that the framework helps teams make an explicit decision to include or exclude one. (Rodden, Hutchinson, and Fu, CHI 2010)

Where HEART Came From and What It Fixes

Before HEART, the large-scale numbers most teams watched were business or technical ones. The authors grouped them under the name PULSE: page views, uptime, latency, seven-day active users, and earnings. These matter, but the paper calls them either very low-level or indirect measures of user experience, and says they can be ambiguous. A rise in page views might mean a feature is popular. It might also mean a confusing interface is sending people clicking around looking for the exit. (Source: CHI 2010 paper.)

Seven-day active users has a subtler problem. It counts how many people showed up, but not whether they're new or returning. In theory, the paper notes, that count could rise even if the entire user base turned over from one week to the next.

HEART was the answer: categories that describe what users feel and do, from which a team defines its own metrics. Two of them, Happiness and Task success, were generalized from existing UX measures. The other three, Engagement, Adoption, and Retention, became possible because products could now log behavior at scale.

If you already track a growth metrics hierarchy, think of HEART as the experience layer that explains why the top-line numbers move.

The Five HEART Categories

All five definitions and examples above come from the CHI 2010 paper. A few details are worth pulling out.

Happiness

Happiness is the attitudinal category. It's the only one that needs you to ask people, so it usually means a short in-product survey run on a steady cadence. The paper describes the iGoogle team tracking satisfaction through a weekly in-product survey. After a major redesign, satisfaction dipped, then recovered over time. The team read that as change aversion rather than a bad design, which gave them the confidence to keep it. A single reading would have told them the opposite.

Engagement

The paper defines engagement through behavioral proxies such as frequency, intensity, or depth of interaction. It also gives a useful reporting rule: show engagement as an average per user rather than a total, because a total can rise just because you have more users. For Gmail, the team chose the percentage of active users who visited on five or more days in the last week, and found it strongly predicted longer-term retention.

Adoption and Retention

These two are a pair. Adoption counts new users in a window; retention asks how many of an earlier group are still around later. What counts as "using" the product is your call. The paper suggests that for some products, just visiting counts, while for others you may only count someone as adopted after they complete a key task such as creating an account. Retention windows also vary: week to week for some products, monthly or 90 days for others. For depth on that side, see churn rate and churn analysis.

Task success

This is the old usability trio at scale: efficiency, effectiveness, and error rate. The paper's example is Google Maps testing a single search box against a dual "what" and "where" box. By comparing error rates in an A/B test, the team learned users adapted fine to the single box, which let them retire the dual one.

Goals, Signals, Metrics: The Process That Makes HEART Work

The paper is blunt that a user-centered metric is unlikely to be useful unless it explicitly relates to a goal. So HEART comes with a three-step process, described in the same paper.

1. Goals. What is the product or feature trying to achieve for users? HEART prompts the conversation: is it more important to attract new users or to deepen use by existing ones?
2. Signals. How would success or failure show up in behavior or attitude? Which actions would tell you the goal was met, and where will that data come from (logs, surveys, or something else)?
3. Metrics. How do those signals become numbers you can track over time on a dashboard?

The paper adds practical tips at each step. Different team members often disagree about goals, and the exercise is a chance to reach consensus and get buy-in for the metrics. Signals should be sensitive and specific to the goal, moving only when the experience gets better or worse. Sometimes failure is easier to spot than success, such as task abandonment. And raw counts rise as your user base grows, so normalize them into ratios, percentages, or per-user averages.

HEART vs AARRR, North Star Metric, and NPS

HEART gets compared to other metric systems constantly, and it's the wrong comparison if you treat them as rivals. They answer different questions.

In practice they stack. A North Star metric gives the company a direction. AARRR shows where in the funnel to look. HEART tells a feature team how to judge whether a change helped the users it was built for. NPS can feed the Happiness slot. For the funnel side, see product analytics metrics and the user activation framework.

How to Apply the HEART Framework, Step by Step

1. Pick one product or feature. HEART works best with a narrow scope. The paper notes that goals for a single feature may differ from goals for the whole product.
2. Write the goals in plain language. One sentence each. If two teammates would write different sentences, you've found the real work.
3. Choose the relevant HEART categories. Skip the rest on purpose. An enterprise tool that people must use daily may have little to say about Engagement at the product level, though it may still matter for a specific feature.
4. List signals for each chosen category. Note the data source. If the action isn't logged today, someone needs to add the instrumentation before launch, not after.
5. Turn signals into metrics. Normalize them. Pick the time window. Define exactly who counts as a user.
6. Set a baseline and a target. Measure before you change anything. Without a baseline, "improved" means nothing.
7. Add the metrics to a dashboard and a review cadence. Weekly for fast-moving features, monthly for slower ones.
8. Pair the numbers with qualitative research. The paper stresses that metrics should be triangulated with usability and field studies, and are mainly useful for launched products rather than early discovery research.
9. Act on the result, then revise. If a metric moves and nobody changes a decision, drop it. Test changes through your growth experimentation framework so the lift is attributable.

HEART Framework Template (Copy and Paste)

Fill in one row per goal. Delete any category you've decided not to use, and write down why.

Here's what a filled-in row can look like. This is an illustration for a hypothetical feature, not a real result:

HEART Examples by Business Function

These are illustrative scenarios, not case studies. They show how the same five categories translate once you leave the product team.

Notice that Engagement is the weak spot for internal tools, just as the paper warns for enterprise contexts where use is required. A team in that spot might lean on Happiness and Task success instead, and track Engagement only for specific features. If your motive is habit formation rather than usability, the Hook Model is a better lens for the engagement question.

HEART Do's and Don'ts

Do

• Start from goals, not categories. The paper's process puts goals first for a reason. Metrics without a goal are decoration.
• Use only the categories that fit. The authors say explicitly that you needn't use all five. Choosing to leave one out is a legitimate outcome.
• Normalize your numbers. Per-user averages and percentages survive growth. Raw totals don't.
• Mix attitude and behavior. Happiness tells you how people feel; the other four tell you what they do. When they disagree, investigate.
• Look past the first dip. The iGoogle satisfaction recovery is the standing reminder that a drop right after a redesign can be change aversion.
• Keep PULSE metrics too. Uptime and latency still matter. HEART complements them.

Don't

• Don't treat HEART as a dashboard template. Five categories times many metrics each is a wall of charts. Choose a few that match your goals.
• Don't replace research with metrics. Numbers show what happened. Usability and field studies show why.
• Don't define "active" loosely. If one team counts a page visit and another counts a completed task, your Adoption and Retention numbers won't compare.
• Don't skip instrumentation. A signal you can't log is a signal you can't use. Check what's captured before you commit to a metric.
• Don't chase one metric. Pushing Engagement alone can drive annoying notifications that hurt Happiness. Track a counterweight.
• Don't copy someone else's targets. Retention and engagement norms vary by product type. Build your own baseline.

Common Mistakes When Adopting HEART

Teams stumble in predictable places. The first is picking metrics before agreeing on goals, which the paper flags as a known difficulty: teams haven't always agreed on or clearly articulated their goals, and that makes metrics hard to define. The second is using HEART only after launch. Metrics are most useful for judging launched products, so set them up before launch to capture a baseline.

The third is over-reading a single number. A spike in visits may mean enthusiasm or confusion. That's why the paper pairs behavioral metrics with attitudinal ones and with qualitative research. If you're running HEART inside a product-led growth motion, the same caution applies: usage numbers need a reason attached.