Конjoint против “причинности”: как не обмануть себя в маркетинговых выборах

Конjoint против “причинности”: как не обмануть себя в маркетинговых выборах

В 2026 году запрос на количественные модели только растёт — потому что “объяснить” решения стало важнее “насколько выросло” после кампании. Но именно здесь я чаще всего вижу ошибку: мы запускаем conjoint (совместный анализ предпочтений), получаем красивую карту важностей и эффектов, а потом делаем причинный вывод (“если поднять фактор X на Y, продажи вырастут”). Так не работает.

Моя позиция простая: conjoint — это инструмент для измерения компромиссов в выборе, а не тест причинного воздействия. Он отвечает на вопрос “как люди trade-off делают выбор при заданных уровнях?”, но не гарантирует, что этот trade-off сохранится в реальном воронкальном каскаде (от выбора в голове до покупки/контракта).

Как это проявляется в практике. Мы недавно пересобирали модель для B2B-сервиса (пакеты услуг + SLA + условия входа). В conjoint “SLA-стабильность” стабильно выигрывала у “скорости старта”. Звучит логично для закупщика. Но в реальной работе с лидами выяснилось другое: большинство сделок “падали” не из-за SLA как ценности, а из-за этапа согласований (юридические формулировки + сроки подписи). То есть предпочтение в задаче выбора не совпало с узким местом в процессе принятия решения.

Практическое правило, которое я теперь использую как чек-лист перед релизом результатов:

— проверяйте, что вы моделируете именно тот этап решения, где есть наблюдаемый контроль
— если конъюнкт моделью измеряет предпочтение, а ваша команда ожидает причинность, добавляйте экспериментальную проверку (A/B, holdout, incrementality) или хотя бы калибровку через внешние данные

Один наблюдаемый “красный флаг” по качеству conjoint: если utility-значимости (веса факторов) объясняют выбор в интервью, но плохо согласуются с фактическими выигрышами/проигрышами в CRM, значит модель поймала не тот механизм. Причина почти всегда одна из трёх:
1) респонденты выбирают “идеальный компромисс” в условиях опроса, но в жизни мешают ограничения (доступность опций, политики, порядок согласований);
2) в стимулы попали уровни, которые не равны реальным условиям рынка (маркетинговая “правильность” скрывает реальную боль);
3) ваша задача — не прогноз выручки, а диагностика языков компромисса; тогда конверсия в “что делать” требует отдельного слоя.

В 2026, когда performance всё больше уходит в privacy-first (server-side атрибуция, MMM и инкрементальность), conjoint я рассматриваю как “конструктор гипотез компромисса”, а не как “замену” измерению эффекта. Если хотите, чтобы модель управляла RevOps-решениями по выручке (и не превращалась в красивую, но потенциально неверную таблицу), соединяйте preference-модель с тестированием влияния на этапы процесса. Тогда вы получаете и методическую честность, и управляемость.

— @QuantResearchRuPro