Conjoint в RevOps: как Aviasales снизил риск ошибочного ценообразования и выбора пакета услуг

Conjoint в RevOps: как Aviasales снизил риск ошибочного ценообразования и выбора пакета услуг

Когда в B2B и e-com лидогенерация MQL/SQL «проседает», компании чаще отвечают за выручку всем фронтом: маркетинг, продажи и customer success (удержание, расширение). На этом фоне особенно болезненны решения «в одну кнопку»: поменять тарифную сетку или добавить пакетные услуги. Если сделать это без данных, можно получить падение конверсии в покупку и рост нагрузки на поддержку.

Задача
Aviasales (сервис планирования поездок) нужно было пересобрать предложение для разных сценариев путешествий: подобрать состав услуг и определить, какие комбинации действительно ценит пользователь. Важно было не просто узнать «какие услуги нравятся», а измерить компромиссы — сколько люди готовы «отдать» за конкретные элементы пакета.

Решение
Команда построила conjoint-подход (сопряженный анализ предпочтений):
— выделили атрибуты предложения (например, состав включенных сервисов и условия предоставления)
— задали пользователям серии профилей с разными сочетаниями атрибутов
— оценили, какие параметры вносят наибольший вклад в выбор и как меняется предпочтение при смене цены/условий
— по итогам сформировали ранжирование атрибутов и сценарии «оптимальных» пакетов под разные сегменты по поведению/потребности

Конкретный результат
По данным кейса, результаты помогли сузить список гипотез до комбинаций, где вклад атрибутов статистически устойчив и экономически логичен: решение стало более предсказуемым, потому что опиралось на полезность (часть варианта, которая объясняет выбор), а не на прямые суждения «что лучше».
Важно: в источнике не указаны точные цифры по приросту выручки/конверсии, поэтому корректно отметить эффект иначе: снизили долю рискованных решений за счет квантификации компромиссов между атрибутами предложения.

Урок для читателя
1) Conjoint выигрывает там, где есть «торговля компромиссами»: пакет — это не список опций, а математика выбора.
2) Для RevOps особенно полезна связка: результаты опроса переводятся в дизайн предложения (что менять), а дальше в план тестов и ответственность по цепочке (marketing → sales → customer success).
3) Если в данных нет метрик по выручке — все равно можно измерять качество решения: устойчивость вкладов атрибутов, объясняемость предпочтений и сегментные различия, которые потом проще проверить performance-экспериментом.

Если хотите, опишу шаблон построения conjoint-опроса под тарифные пакеты (какие атрибуты брать, как избежать «усталости» респондента и как потом интерпретировать utility-значения для продуктовой команды).

— @QuantResearchRuPro