Как посчитать Downgrade Rate в SQL

Зачем Downgrade Rate

Downgrade — это мягкий отток (soft churn): пользователь не ушёл совсем, но стал платить меньше. Если каждый квартал тариф понижают 10% пользователей, это сигнал, что премиум-план не оправдывает для них цену. Возможно, он переоценён или недодаёт ценности.

Формула

Downgrade Rate = customers_downgraded / total_customers × 100%
Contraction MRR = SUM(old_plan - new_plan) для downgraded

Базовый расчёт

WITH stats AS (
    SELECT
        user_id,
        new_plan_value < old_plan_value AS downgraded
    FROM plan_changes
    WHERE change_at >= CURRENT_DATE - INTERVAL '90 days'
)
SELECT
    COUNT(*) AS users_with_changes,
    COUNT(*) FILTER (WHERE downgraded) AS downgraded,
    COUNT(*) FILTER (WHERE downgraded)::NUMERIC * 100 / NULLIF(COUNT(*), 0) AS downgrade_rate_pct
FROM stats;

Contraction MRR

SELECT
    DATE_TRUNC('month', change_at) AS month,
    COUNT(*) FILTER (WHERE new_plan_value < old_plan_value) AS downgrade_events,
    SUM(old_plan_value - new_plan_value) FILTER (WHERE new_plan_value < old_plan_value) AS contraction_mrr,
    SUM(new_plan_value - old_plan_value) FILTER (WHERE new_plan_value > old_plan_value) AS expansion_mrr
FROM plan_changes
WHERE change_at >= '2026-01-01'
GROUP BY 1
ORDER BY 1;

Net Expansion = Expansion - Contraction.

Причины

SELECT
    downgrade_reason,
    COUNT(*) AS events,
    SUM(old_plan_value - new_plan_value) AS contraction_mrr
FROM plan_changes
WHERE new_plan_value < old_plan_value
  AND change_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY downgrade_reason
ORDER BY events DESC;

Самые частые причины понижения тарифа: «слишком дорого», «не пользуемся функциями», «урезали бюджет».

Частые ошибки

Ошибка 1. Годовая подписка против месячной. Годовой контракт можно понизить только в момент продления, а месячный — в любой момент. Смешивать их в одном расчёте некорректно.

Ошибка 2. Считать «паузу» даунгрейдом. Пауза и понижение тарифа — разные вещи: пауза это временный $0, а понижение — переход на более дешёвый тариф. Складывать их в одну метрику не стоит.

Ошибка 3. Переход из триала в бесплатный тариф. Если у вас есть бесплатный тариф, заранее решите: считать ли переход «закончился триал → free» понижением. От этого зависит, что именно попадёт в метрику.

Ошибка 4. Изменение цен. Компания снизила цены и перевела текущих клиентов на новый, более низкий прайс. Это не понижение тарифа: план у них тот же, изменилась только цена, — в downgrade rate такое попадать не должно.

Ошибка 5. Сокращение числа мест (seats). Enterprise-клиент урезал число мест со 100 до 50 — это понижение тарифа или contraction? Часто такое считают по количеству мест, а не по смене плана, и это правило стоит зафиксировать заранее.

Связанные темы

• Как посчитать upgrade rate в SQL
• Как посчитать MRR Churn в SQL
• Как посчитать NRR в SQL
• Как посчитать MRR в SQL

FAQ

Какой Downgrade Rate нормальный?

Менее 5% в квартал — это норма. Выше 10% — уже повод беспокоиться и разбираться в причинах.

Downgrade vs Churn?

При понижении тарифа клиент остаётся с вами, при оттоке (churn) — уходит совсем. При этом downgrade часто работает как опережающий индикатор оттока: сначала человек снижает тариф, а через какое-то время уходит вовсе.

Как уменьшить?

Во-первых, заранее находите пользователей, которые близки к понижению тарифа: обычно у них падает активность. Во-вторых, проактивно подключайте команду по работе с клиентами (CSM), пока человек ещё не ушёл. В-третьих, лучше доносите ценность продукта, чтобы тариф не воспринимался как переплата.

Downgrade → Re-upgrade?

Это хороший знак: клиент снова вовлёкся и вернулся на более высокий тариф. Чаще всего повторный апгрейд случается после работы CSM или выхода новой функции.

Auto-downgrade?

Так бывает, когда у клиента не проходит оплата картой и аккаунт автоматически переводят на бесплатный тариф. Формально это считается понижением, но причина у него другая — технический сбой оплаты, а не осознанное решение. Такие случаи лучше выделять отдельно.