Ну что, выкладываю обещанный пост про выбор неправильных пороговых значений!

Часто при проведении аналитики нам приходится задавать некоторые «критерии» вручную. Это довольно субъективная штука, так что ошибиться очень легко. И в то же время цена ошибки может быть очень большой, потому что именно от этого зависят конечные управленческие выводы.

Несколько примеров таких «критериев»:

— Как выбрать пороговые значения для групп А/B/C в ABC-анализе ассортимента (взять стандартные 80/15/5 или сделать как-то иначе?)
— Как выбрать пороговые значения для групп X/Y/Z в XYZ-анализе стабильности спроса (взять стандартные <10/<25/25+ или сделать как-то иначе?)
— Какие значения считать большими, какие средними, а какими маленькими в каждой из групп по Recency, Frequency и Monetary в RFM-анализе клиентской базы (здесь вообще нет стандарта — придется выдумывать самому)

Буквально недавно я и сам столкнулся с проблемой, что несколько раз подряд был вынужден корректировать «критерии», потому что промахивался с выбором. Так и родился этот пост — поделюсь, на что я опирался, когда принимал решение, что все-таки ошибся)

В моем случае задача была настроить сегментацию клиентов (что это такое, писал тут) для нового проекта. То есть в отдел продаж попадают заявки и нужно прописать критерии квалификации — кого мы считаем квалифицированным, а кого нет.

По мере накопления данных я менял и количество критериев, и сами критерии, и распределение значений внутри конкретного критерия. Например:

— Изначально одним из критериев была «Осведомленность о компании», потом я этот критерий убрал.
— Внутри критерия «Предпочитаемый формат» опция «Рассматривает только офлайн» сначала относилась к С-сегменту (квалифицированный, но слабо нам подходит), а затем я перенес это значение в D-сегмент (это уже неквалифицированная сделка и мы ее закрываем).

На что я опирался при принятии решений (вы можете делать также в своих задачах):

1. Соблюдение принципа «пирамиды»

Почти во всех подобных задачах объекты в группах должны быть распределены по принципу пирамиды.

Например, в случае моей задачи А-лидов (то есть супер горячих) должно быть прям немного, B-лидов (достаточно горячих) должно быть побольше, а С-лидов (квалифицированных, но есть к ним вопросики) — существенно больше. Если у вас получилось, что Ашек прям много, Bшек почти нет, а Cшек сопоставимо с Ашками — вы явно сделали что-то не так.

Тоже самое в АБС-анализе — группа ААА априори не может быть больше группы BBB или даже ABC. Если вы провели анализ и весь ваш ассортимент супер топовый — вы просто недостаточно жесткие требования к нему предъявили)

2. Имеется адекватный минимум

Этот пункт как бы продолжает предыдущий с одной стороны, но и противопоставляется ему одновременно. Идея в том, что при выполнении принципа пирамиды надо не пережать — в каждой группе должны быть объекты и их должно быть достаточно.

Условно, если у вас 300 лидов и из них одна Ашка или их нет вообще — это странно. Если у вас 1000 товаров и в группе ААА всего один товар — это странно. Если в RFM анализе у вас VIP-клиентов один человек из 5000 клиентов — это странно.

В таком случае, скорее всего, это повод немного «разжать тиски» и сделать критерии более мягкими. Например, в случае с сегментацией клиентов я могу ослабить критерий «готовность платить» с «готов платить в течение суток» до «готов платить в рамках недели». Какой смысл иметь красивый критерий, если под него никто не подходит)

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

3. Что происходит после работы с этой группой объектов

Когда мы разбиваем объекты на такие группы, это всегда делается для того, чтобы потом с ними как-то поработать. Например, заявкам мы присваиваем сегменты, чтобы понять, как им потом продавать. А клиентскую базу делим на RFM-группы, чтобы понять, что им предлагать, чтобы их реактивировать и увеличить выручку с одного клиента.

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

Пример: я на опыте знаю, что С-сегмент лидов — это квалифицированные лиды, которые так или иначе закрываются в продажу. Да, это занимает больше времени. Да, с ними нужно по-особому работать. Но конверсия там ненулевая. Так вот когда я увидел, что у нас уже несколько сотен С-лидов, прошло достаточно времени и работаем мы с ними адекватно, но там даже намека на сделку нет — я понял, что проблема не в нас, а в слишком позитивной расстановке сегментов.

Именно так критерий «рассматривает офлайн» и перекочевал из С в D сегмент (писал выше) — в результате просмотра сделок «глазами» я понял, что именно эта штука создает нам ложную картинку.

4. Обязательное наличие дисперсии у каждого критерия

Тут все просто — если у какого-то критерия одинаковые значения по всем объектам, то нафиг такой критерий нужен) Ну условно, если на вопрос «Знаете ли вы нашу компанию» 99% заявок отвечают «нет» — убери этот критерий, не усложняй жизнь менеджерам и клиентам и поработай над своей репутацией и брендом))

Заключение

Это не все приемы — есть еще несколько, но они уже не влезут в пост) Кроме того, помимо самих приемов, есть еще масса методов борьбы с этим — например, делать ABC-анализ не вручную, а через кластеризацию.

Если эта тема вам интересна — накиньте реакций!) Как соберем 50 реакций, продолжу серию постов на эту тему!)