Коротко: соберите 3-5 уровней выбора покупателя в своей категории, перенесите ветки в поля ассортиментной матрицы за 6 шагов и задайте приоритет наличия по веткам. Ниже: 3 таблицы, протокол и метрики, которые стоит смотреть после внедрения.
Дерево покупательских решений - это иерархия критериев выбора покупателя внутри товарной категории (свойства, бренд или коллекция, цена, фасовка). BrightBoard - помощник закупок в ритейле - помогает перенести эти уровни в матрицу и нормы запаса по веткам. В ритейле модель также называют CDT, Consumer Decision Tree: порядок отсечения вариантов у полки или в фильтрах e-com. Категорийщику она нужна, чтобы собрать уровни ассортимента под целевого покупателя формата, а не «по ощущениям».
Боль знакома: матрица раздута поставщиками, а покупатель не находит нужную ветку или упирается в пустые полки по приоритетным сегментам. Ниже - практичный вход: зафиксировать дерево решений покупателя под свой формат и регион, перенести уровни в структуру матрицы и связать ветки с наличием.
Что такое дерево покупательских решений (CDT) в коммерческой рознице
CDT (Consumer Decision Tree) - логическая модель выбора целевого покупателя внутри категории: какие критерии он решает раньше, какие позже, и какие варианты (ветки) реально отсекают ассортимент. «Ствол» - сама категория или подкатегория. «Узлы» - критерии выбора. «Ветки» - значения критерия. «Листья» на конце - конкретные SKU, которые закрывают маршрут.
Это не товарное или категорийное дерево учётки (как удобно складу и 1С) и не ML-классификатор. Это зеркало категорийного менеджмента: как покупатель вашего формата собирает решение о покупке. Иерархия уровней зависит от ЦА, региона и роли категории; готовое ДПР поставщика часто отражает его полку, а не вашу.
Делайте: описывайте иерархию с точки зрения покупателя вашего формата. Не делайте: не копируйте ДПР поставщика или чужой сети «как есть».
Зачем категорийщику модель выбора покупателя, а не «дерево решений менеджера»?
Менеджерское «дерево» часто строится от маржи, условий поставщика и удобства учёта. Покупательское дерево решений отвечает на другой вопрос: что реально ветвит выбор у полки. Без этой модели ассортиментная матрица заполняется «удобными» полями, а не теми уровнями, по которым человек ищет товар.
Практика топа ритейл-гайдов совпадает: опираться только на ретроспективу продаж и «опыт катмана» даёт ошибку выжившего. Продажи показывают, что уже купили из того, что лежало. Они плохо показывают, какие ветки покупатель искал и не нашёл. Поэтому сначала фиксируют критерии и иерархию, потом сверяют с продажами и опросами.
Делайте: отделяйте логику покупателя от удобства закупки. Не делайте: не подменяйте CDT внутренним деревом решений «что выгоднее поставить».
Дерево решений покупателя в категории: уровни свойств, бренда, цены и фасовки
Типовой пример уровней (не жёсткий стандарт сети): свойства или применение → бренд или коллекция → ценовой сегмент → фасовка или формат упаковки. В одной категории вкус идёт первым, в другой - размер, в третьей - бренд как свойство. Порядок задаёт целевой покупатель вашего формата, а не учебник.
| Уровень CDT | Типовой вопрос покупателя | Пример значений | Что фиксируем в матрице / классификаторе |
|---|---|---|---|
| 1. Свойство / применение | Для какой задачи беру товар? | вкус, жирность, материал, назначение | поле сегмента / атрибут 1-го уровня |
| 2. Бренд / коллекция | Какому имени доверяю? | бренды A/B/C, СТМ, «без предпочтения» | бренд / линейка в карточке SKU |
| 3. Цена | В каком бюджете выбираю? | эконом / средний / премиум (3-4 корзины) | ценовой сегмент SKU |
| 4. Фасовка / формат | Какой объём или упаковка удобны? | малый / средний / большой; тип упаковки | фасовка / единица измерения |
Держите 3-5 значимых уровней. Близкие варианты объединяйте: вместо 12 граммовок - 3-4 корзины фасовки. То же с ценой: слишком много микросегментов ломает и матрицу, и отчёты.
Делайте: ограничивайте число уровней и групп вариантов данными продаж и опросов. Не делайте: не размножайте десятки микросегментов «на всякий случай».
Как собрать уровни выбора для своей категории по шагам
Ниже протокол, который можно пройти за одну рабочую сессию категорийщика с выгрузкой продаж и коротким полевым чек-листом. Цель - рабочая иерархия уровней выбора покупателя в категории, а не академическая схема на год вперёд.
- Зафиксируйте категорию (или подкатегорию) и целевого покупателя вашего формата и региона.
- Соберите список значимых критериев выбора: что реально ветвит решение у полки или в фильтрах e-com.
- Выстройте иерархию уровней: что покупатель решает раньше, что позже.
- Для каждого уровня перечислите варианты веток и объедините близкие значения в группы.
- Перенесите уровни и ветки в поля или структуру ассортиментной матрицы (вход в матрицу, не полное руководство по ролям).
- Назначьте приоритет наличия и ориентиры норм запаса по веткам, сверьте с продажами и скорректируйте.
Рабочий workflow: категория и ЦА → критерии и иерархия CDT → варианты по веткам → перенос в матрицу → нормы запаса и наличие по веткам → сверка с продажами. Если на шаге 6 приоритетная ветка стабильно в OOS при «среднем» наличии по категории, среднее врёт: эскалируйте ветку, а не весь реестр.
Делайте: проходите шаги по порядку и пишите иерархию явно. Не делайте: не начинайте с выкладки или планограммы до готовых уровней CDT.
Перенесите уровни CDT в структуру ассортиментной матрицы
CDT - вход в матрицу, а не её замена. Уровни и ветки становятся полями классификатора и правилами наполнения: какие комбинации обязательны, какие допустимы, какие не нужны вашему формату. Полное руководство по ролям категорий и ширине/глубине - соседняя задача; здесь важно, чтобы SKU были привязаны к веткам дерева решений покупателя.
Практичный минимум: у каждого SKU категории заполнены атрибуты уровней CDT, отчёты умеют резать продажи и остатки по веткам, а не только по бренду поставщика. Без этой связки матрица остаётся списком позиций, а не моделью выбора.
Когда уровни уже в классификаторе, удобно смотреть продажи и остатки из учётки. Для сетей на МойСклад помогает интеграция BrightBoard с МойСклад: данные по заказам и остаткам подтягиваются для проверки веток и наличия.
Делайте: привязывайте каждый SKU к веткам CDT в классификаторе. Не делайте: не подменяйте CDT полной инструкцией по матрице или списком ролей категорий.
Свяжите ветки с нормами запаса и приоритетом наличия
Иерархия выбора бесполезна, если приоритетные ветки пустые, а хвост затоварен. После переноса уровней в матрицу назначьте приоритет наличия по веткам: какие маршруты покупателя нельзя «ронять», где допустим более мягкий сервис, где достаточно под заказ.
| Ветка CDT | Приоритет наличия | Сигнал для закупки / остатка | Что смотреть в отчётах |
|---|---|---|---|
| Топ-ветка по доле чеков / трафику | Высокий | Жёсткий контроль OOS, выше ориентир нормы | OOS и упущенный спрос по ветке vs среднее по категории |
| Средние ветки стабильного спроса | Средний | Обычные правила пополнения | Оборачиваемость, доля в обороте |
| Узкие / редкие ветки | Низкий | Меньше страховой запас, возможен под заказ | Неликвиды, доля «мёртвых» SKU в ветке |
| Новая / тестовая ветка | Пилот | Ограниченный вход, короткий горизонт оценки | Скорость выбора, отказы, продажи за пилот |
Цифры норм - ваши, из продаж и логистики; чужие проценты роста оборота из чужих кейсов не копируйте как норматив. Выкладка следует логике CDT как следствие: полка должна повторять порядок выбора, но планограмма - не главная тема этой работы.
Связать ветки с остатками и автозаказом удобно в системе управления запасами BrightBoard: ассортиментная матрица, контроль наличия и закупки для перепродажи в одной плоскости.
Делайте: задавайте приоритет наличия по веткам CDT и сверяйте OOS именно там. Не делайте: не обещайте себе чужой процент роста от «правильной выкладки» без своей проверки.
Сравнение: чем CDT отличается от ядра, KVI и ролей категорий
Путаница типична: must-stock, KVI, роли и товарное дерево кладут в одну кучу с CDT. Ниже - развилка без подмены задач.
| Инструмент | На какой вопрос отвечает | Когда использовать | Чем не является |
|---|---|---|---|
| CDT / ДПР | В каком порядке покупатель выбирает внутри категории? | Собрать уровни и ветки для матрицы и полки | Не список never-out SKU |
| Ядро / must-stock | Какие SKU нельзя допускать в OOS? | Приоритет покрытия и автозаказа | Не иерархия критериев выбора |
| KVI | Какие позиции сильнее влияют на восприятие цены? | Ценовой имидж и мониторинг | Не дерево решений покупателя |
| Роли категорий | Какую роль категория играет в формате сети? | Стратегия ширины / глубины / маржи | Не уровни выбора внутри категории |
| Товарное / категорийное дерево | Как удобно учитывать и хранить номенклатуру? | Классификатор учётки, склады | Не модель выбора у полки |
Делайте: держите CDT рядом с ядром и KVI как разные слои. Не делайте: не объявляйте must-stock или роли единственным ответом на запрос про дерево решений покупателя.
Проверьте результат: что замерить после внедрения
После внедрения смотрите не «красивую схему», а операционные сигналы:
- доля SKU с заполненными уровнями и ветками CDT в классификаторе категории;
- OOS и упущенный спрос по приоритетным веткам vs низкоприоритетным;
- оборачиваемость и доля неликвидов после пересборки веток;
- скорость выбора и доля отказов в категории (e-com фильтры или полевые наблюдения).
Пересматривайте иерархию, когда меняется формат, ЦА или состав категории. CDT - живая модель, не разовый слайд.
Делайте: заведите короткий дашборд по веткам на 30-90 дней после внедрения. Не делайте: не закрывайте тему после одного мозгового штурма без сверки с продажами.
BrightBoard - IMS «Помощник закупок в ритейле»: ассортиментная матрица, автозаказ и остатки для перепродажи. Если нужна онлайн-встреча и выгрузка из учётки, свяжитесь с командой BrightBoard.
Частые вопросы
Что понимают под деревом решений покупателя в категории?
Это иерархия критериев выбора целевого покупателя внутри категории: что он решает раньше и позже, какие ветки отсекают ассортимент. На конце маршрута - SKU. Синонимы в практике: ДПР, CDT, покупательское дерево решений.
Нужно ли копировать ДПР от поставщика?
Нет. ДПР поставщика отражает его портфель и полку. Соберите свою иерархию под формат, регион и ЦА, а данные поставщика используйте как гипотезу для проверки, не как готовый классификатор.
Чем CDT отличается от ядра ассортимента и KVI?
CDT описывает логику выбора (уровни и ветки). Ядро отвечает, какие SKU нельзя ронять в OOS. KVI - про ценовой имидж. Это разные слои: можно иметь must-stock внутри приоритетных веток CDT, но нельзя подменять одно другим.
Как нормы запаса связаны с ветками дерева решений?
После переноса уровней в матрицу назначьте приоритет наличия по веткам: высоким - жёсткий контроль OOS и выше ориентир нормы, узким - мягче или под заказ. Сверяйте OOS и неликвиды по веткам, а не только среднее по категории.
Что сделать дальше
Выберите одну категорию, пройдите 6 шагов протокола, заполните атрибуты CDT у SKU и откройте отчёт OOS по 2-3 приоритетным веткам на ближайшие 30 дней. Если нужна помощь с матрицей и остатками в одной системе - начните с главной BrightBoard или заявки в контакты.
