A/B-тест цены продукта: как сделать правильно

Зачем тестировать цену

Цена — рычаг с самым большим влиянием на прибыль. Подняли на 10%, удержали половину юзеров — выиграли. Но «выиграли или нет» нельзя угадать на глазок: эластичность спроса нелинейна, а реакция юзеров на цену зависит от позиционирования, момента и формата подачи.

Поэтому pricing проверяют экспериментом. A/B-тест цены — обычный A/B-тест с одним важным нюансом: основная метрика — не конверсия, а доход на юзера. Можно поднять цену, потерять конверсию и всё равно выиграть в выручке.

Отдельно про этику: тестировать одну и ту же цену для одинаковых юзеров — норм. Показывать разную цену одинаковым юзерам, не предупреждая, — серая зона, которая может ударить по репутации.

Что именно тестируем

Не всегда тестируется именно «цена в цифрах». Часто эффект сильнее на других элементах:

• Цена сама (10$ vs 12$ vs 15$).
• Структура тарифов (3 тарифа vs 2).
• Период (месяц vs год по умолчанию).
• Якорь (показ перечёркнутой «старой» цены).
• Подача (доллары vs «менее $1 в день»).
• Формат биллинга (раз в год со скидкой vs ежемесячно).
• Платёжные методы (только карта vs +Apple Pay +YooKassa).

Часто тест «механики», а не цены даёт больший прирост, потому что юзеры покупают не цифру, а её восприятие.

Дизайн эксперимента

Стандартный A/B на новых юзерах. Существующих обычно не трогают, чтобы не ломать доверие.

Шаги:

1. Гипотеза. Например: «увеличение цены с 10$ до 12$ увеличит ARPU без значимой потери конверсии».
2. Метрики. Главная — выручка на нового юзера. Вторичные — конверсия, retention первого месяца, refund rate.
3. Размер выборки. Считаем под главную метрику. Pricing-тесты часто требуют выборки в разы больше, чем тесты UI, потому что variance дохода высокий.
4. Длительность. Минимум 2 недели плюс цикл оплаты, чтобы оценить рефанды и churn первого месяца.
5. Распределение трафика. 50/50 для классического теста. Если рисково — 90/10 на старте.
6. Стат-критерий. Для бинарной конверсии — z-test. Для дохода на юзера — t-test или bootstrap (распределение неровное, много нулей).

Нюанс выборки: доход на юзера — это smushed-распределение с большим хвостом. Если опираться на нормальный t-test, можно получить ложный positive. Bootstrap безопаснее.

Какие метрики смотреть

Главная — ARPU (revenue per user) на новых юзерах за период.

Вторичные:

• Conversion rate (visitor → paid).
• Refund rate в первые 30 дней.
• Churn в M1.
• Retention в M1.
• LTV (если есть данные за прошлые когорты для extrapolation).
• NPS / поддержка (качественно).

Особенность: иногда конверсия падает, ARPU растёт, и кажется, что выиграли. Но если падает retention — новые подписчики дороже уходят, и через 3 месяца LTV проигрывает контролю. Поэтому смотрите когортно, а не одной цифрой за неделю.

Простая агрегация для ARPU:

SELECT
  variant,
  COUNT(DISTINCT user_id) AS users,
  SUM(revenue)::NUMERIC / NULLIF(COUNT(DISTINCT user_id), 0) AS arpu
FROM experiment_users eu
LEFT JOIN payments p USING (user_id)
WHERE eu.experiment = 'pricing_v3'
  AND p.created_at < eu.assigned_at + INTERVAL '30 days'
GROUP BY variant;

Этические и юридические нюансы

Сразу плохие новости: показывать разную цену юзерам без предупреждения — путь к скандалу. Когда Amazon в начале 2000-х так сделал, пресса разнесла историю в клочки.

Что обычно делают, чтобы не подставиться:

• Тестируют цены только для новых юзеров.
• Не двигают цену внутри одной сессии.
• Каждый юзер видит одну цену стабильно (закрепление в куках/учётке).
• Если эксперимент «проиграл» — обновляют контрольную цену, а не делают вид, что новый сегмент платит дороже навсегда.
• В тестах со скидками — фиксируют итоговые правила в публичной оферте.

Юридический момент: в РФ дискриминация по цене на одинаковых условиях для одинаковых юзеров может быть оспорена. Лучше консультироваться с юристом до запуска.

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

• Тестировать на действующих юзерах. Их доверие важнее эксперимента.
• Опираться на конверсию, забывая про ARPU и LTV. Конверсия может вырасти, а деньги упасть.
• Слишком короткий тест. Без полного цикла оплаты не видно refunds и churn.
• Маленькая выручка на юзера → огромная выборка нужна. Часто люди недосчитывают и принимают шум за сигнал.
• Не использовать bootstrap для ARPU. Распределение перекошенное, t-test может врать.
• Не трекать платёжки. Эффекты часто связаны с тем, что добавили или убрали платёжный метод, а не с самой ценой.
• Запускать без peer-review. Pricing-тесты — самый политически нагруженный класс экспериментов в продуктах.

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

• Pricing-стратегия продукта
• Как повысить цену без потери юзеров
• Value-based pricing
• Что такое A/B-тест
• Что такое t-test

FAQ

Можно ли тестировать цену на текущих платящих юзерах?

Лучше нет. Это бьёт по доверию и ломает retention.

Какая длительность нормальна для pricing-теста?

Минимум 2 недели плюс полный цикл оплаты. Для месячных подписок — 30+ дней.

Что использовать вместо t-test для ARPU?

Bootstrap или Welch's t-test с большим запасом по выборке, потому что распределение дохода перекошено.

Можно ли тестировать одновременно цену и pricing-page?

Можно, если это считается одним «оффером». Главное — не запутать атрибуцию между несколькими тестами.

Как поступать с проигравшим вариантом?

Откатить и оставить контроль. Не оставлять в проде «дорогой» вариант для группы юзеров — это ловушка с точки зрения честности.

Как считать stat. significance, если ARPU имеет много нулей?

Bootstrap по среднему даёт честный доверительный интервал. Можно дополнительно разложить ARPU на conversion × ARPPU и тестировать обе компоненты отдельно.

---

Готовитесь к собесу аналитика — откройте тренажёр Карьерника с задачами по A/B-тестам и продуктовой аналитике.