HEART:
как UX-метрики ложатся
на продуктовые

HEART — фреймворк UX-метрик, который в 2010 году придумали Керри Родден и команда Google UX. Идея простая: UX-исследование отвечает на вопрос «нравится ли продукт юзеру», а аналитика — на вопрос «что юзер делает в продукте». Между ними был разрыв: дизайнеры замеряли удовлетворённость через опросы, аналитики — DAU и retention, и эти две картины редко стыковались.

HEART сводит обе стороны в пять категорий, по которым можно собрать метрики из любого источника — продуктовые ивенты, опросы, оценки в сторе, поведенческие записи. Главная польза для продуктового аналитика — это мост: ты больше не выбираешь между «опросный CSAT» и «SQL-овый DAU», а раскладываешь продукт по HEART и видишь, где какая дыра.

Чем HEART отличается от AARRR: AARRR — это воронка жизни юзера (как привлекли → активировали → удержали → монетизировали). HEART — это срез качества опыта, который применим к каждому шагу AARRR-воронки. Они не конкуренты, а дополнения. К сравнению вернёмся в конце карточки.

-- CSAT по типу события
SELECT event_type,
       AVG(rating)::numeric(3,2) AS csat,
       COUNT(*) FILTER (WHERE rating >= 4) * 100.0 / COUNT(*) AS top2_pct
FROM feedback
GROUP BY event_type;

-- NPS = % промоутеров − % детракторов
SELECT
  100.0 * COUNT(*) FILTER (WHERE score >= 9) / COUNT(*) -
  100.0 * COUNT(*) FILTER (WHERE score <= 6) / COUNT(*) AS nps
FROM nps_surveys
WHERE survey_date >= CURRENT_DATE - INTERVAL '90 days';

SELECT
  COUNT(DISTINCT user_id) FILTER (WHERE event_date >= CURRENT_DATE - 1)::float
  /
  COUNT(DISTINCT user_id) FILTER (WHERE event_date >= CURRENT_DATE - 30)
  AS stickiness,
  AVG(events_per_day) AS avg_events_per_user
FROM events_summary
WHERE event_date >= CURRENT_DATE - 30;

-- % активных юзеров, использовавших фичу feature_X за месяц после релиза
WITH active_users AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_date BETWEEN '2026-04-01' AND '2026-04-30'
),
adopters AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_type = 'feature_X_used'
    AND event_date BETWEEN '2026-04-01' AND '2026-04-30'
)
SELECT
  COUNT(DISTINCT a.user_id) * 100.0
  / COUNT(DISTINCT u.user_id) AS adoption_pct
FROM active_users u
LEFT JOIN adopters a USING (user_id);

WITH cohort AS (
  SELECT user_id, MIN(event_date) AS first_dt
  FROM events GROUP BY user_id
),
retained AS (
  SELECT c.user_id, c.first_dt
  FROM cohort c
  WHERE EXISTS (
    SELECT 1 FROM events e
    WHERE e.user_id = c.user_id
      AND e.event_date = c.first_dt + INTERVAL '7 days'
  )
)
SELECT
  DATE_TRUNC('week', c.first_dt) AS cohort_week,
  COUNT(DISTINCT r.user_id) * 100.0
  / COUNT(DISTINCT c.user_id) AS d7_retention
FROM cohort c
LEFT JOIN retained r USING (user_id)
GROUP BY cohort_week
ORDER BY cohort_week;

SELECT
  SUM(CASE WHEN status = 'completed' THEN 1 ELSE 0 END) * 100.0
    / COUNT(*) AS completion_pct,

  SUM(CASE WHEN error_count > 0 THEN 1 ELSE 0 END) * 100.0
    / COUNT(*) AS error_pct,

  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY duration_sec)
    FILTER (WHERE status = 'completed') AS median_time_sec

FROM task_attempts
WHERE task_type = 'checkout'
  AND started_at >= CURRENT_DATE - INTERVAL '30 days';

Чтобы превратить HEART-категорию в конкретную метрику, в той же статье Родден предложила вспомогательный фреймворк — GSM. Алгоритм такой: для каждой категории формулируешь цель (Goal), потом сигнал (Signal) — то, что говорит о её достижении, и только потом метрику (Metric) — конкретное число с формулой.

Без GSM команда тонет в дискуссии «какая метрика правильная для Happiness». С GSM сначала договариваются о цели и сигнале на простом языке, а потом инженер аналитики предлагает формулу. Это разводит роли — продакт отвечает за goal, аналитик за metric — и устраняет 90% переписки на тему «но эта метрика не то измеряет».

У продуктовых аналитиков часто возникает путаница: AARRR — это «5 стадий» и HEART — тоже «5 категорий», обе кажутся универсальными. Они про разное и должны использоваться вместе, а не вместо друг друга.

Практическая рекомендация: сначала AARRR, потом HEART. Сначала пойми, где течёт воронка количественно (низкая Activation, низкий free-to-paid). Потом на каждой проблемной стадии собери HEART-срез — это даст контекст «почему течёт». Например: Activation 35% (AARRR ставит проблему) + Time-on-task до aha-момента 22 мин (HEART даёт причину).