Источником проблем в анализируемых данных могут быть не только случайные ошибки, но и фейки. Это информация, которая выглядит как достоверная, хотя таковой не является. Не делая различия между реальными и фиктивными данными, можно прийти к сравнению теплого с мягким, а высокого с зеленым.
Казалось бы, о чем речь? Анализируются продажи одной компании, торгующей канцтоварами. В данных не смешиваются несовместимые позиции, типа квартир и детского питания. Следовательно, показатели можно агрегировать, и они должны корректно сравниваться.
Однако в деятельности компании могут сосуществовать несколько процессов продаж, данные которых сравнивать некорректно. Или бизнес-процессы построены неверно, так что сотрудники вынуждены вносить данные до того, как получена достоверная информация. В конце концов, могут быть сознательные искажения с целью мошенничества. Подобное встречается намного чаще, чем может показаться с первого взгляда.
Важно! Если вы не сделали практику в теме «Двое из ларца. Причины и способы устранения дублей», то предварительно требуется открыть решение задания предыдущего дня, скачав его ниже.
lgpРешение практического задания. День 7.lgp
При анализе транзакций легко заметить, что 95% продаж приходится на покупателя Частное лицо. Такая ситуация возникает, когда продажи через контрольно-кассовую технику привязываются к виртуальному клиенту, олицетворяющему всех клиентов-физлиц.
Трюк с виртуальной компанией используется очень часто. Например, так могут оформляться перемещения товаров между подразделениями, отгрузка рекламной или акционной продукции, списание брака и прочее.
Однако сквозная задача марафона посвящена анализу клиентской базы по оптовым продажам. Поэтому наличие подобного виртуального покупателя в отчете Портрет клиента искажает статистику.
По объемам продажи Частное лицо попадает в категорию VIP-клиентов. Более того — его можно считать чуть ли не единственным VIP-клиентом. Он перетягивает на себя почти всю выручку, завышает средний чек и пессимизирует вклад в продажи других покупателей.
Если строить финансовую модель, опираясь на такую структуру VIP-клиентов, то будут сделаны неверные выводы: фиктивный клиент объединен с реальными, а продажи в розницу с оптовыми. Полагаться на такие цифры нельзя.
В широком смысле фиктивные данные — это информация, которая не подходит для выбранного сценария обработки. При анализе в других разрезах фейковые данные могут не представлять проблемы.
Например, при фокусе на товарах, а не клиентах, можно игнорировать информацию о покупателе. Не важно, продан товар частному лицу или организации, следовательно, не принципиально – указан реальный или фиктивный покупатель.
Ценность данных определяется тем бизнес-процессом, который их породил. Например, информация о продажах частным и юридическим лицам существенно не отличается — она одинаковая. Но анализировать ее с целью улучшения процесса можно, только разделяя продажи по направлениям.
Однако помимо «естественных» бизнес-процессов в компаниях существуют технические, искажающие наборы данных. Например, бесплатная выдача продукции по промо-акциям проводится как продажа с нулевой суммой.
Логика простая: товар отгружен, и его количество на складе уменьшилось, при этом оплата не предполагается, поэтому сумма продажи равна нулю. Все корректно как с точки зрения логистики, так и финансов. Однако такие отгрузки в отчетах будут фигурировать как обычные продажи и, как следствие, снизят сумму среднего чека.
Если взглянуть на наименования клиентов, то тоже можно обнаружить интересные экземпляры, вроде _#Необходима перерегистрация. Что это такое? Имя клиента заменено на нечто техническое? Баг в учетной системе? Загружено не то поле из источника?
В реальности причины могут быть разными и до истины придется докапываться. В нашем примере условимся, что это некие неопределенные клиенты и другой информации о них получить невозможно.
Еще один источник фиктивных данных о продажах — внутренние перемещения, которые отражают товарооборот между подразделениями.
В отчетах по товародвижению такие данные имели бы смысл, но в анализе продаж они явно лишние. Дело в том, что эти записи не отражают сути взаимоотношений с реальными клиентами.
Нередко такие особенности можно обнаружить только погрузившись в данные. Поэтому надо активно использовать визуализацию и элементы разведочного анализа:
По большому счету, сценариев работы с фиктивными данными два:
Исключение при помощи фильтрации нужно, когда фиктивные данные не должны учитываться, т.к. искажают вычисления. Например, в нашем случае не нужны продажи частным лицам. Транзакции с нулевой суммой тоже можно убрать. Так же как и перемещения между подразделениями, которые по сути не являются продажами.
С другой стороны, в данных есть некие неопределенные клиенты, «требующие перерегистрации». Такой метод таск-менеджмента использовала бухгалтерия, чтобы не забыть выполнить необходимые проверки по клиенту.
Это не самый лучший способ отметки записей, чтобы не забыть внести правки, но, возможно, остальные варианты были менее удобными. Желательно иметь возможность мониторить наличие таких клиентов, быстро включать/исключать их из отчета. Поэтому лучше всего их не убирать из данных, а создать дополнительный признак в виде поля, которое будет фильтром в отчете.
Задание №1. С помощью узла Фильтр, исключите из транзакций значения, в которых сумма продажи равна 0 или в поле Покупатель содержится фраза 0_Администратор или поле Покупатель содержит Частное лицо.
Рекомендуемое расположение фильтра — перед выходом из подмодели Продажи.
Добавление узла фильтрации
Обратите внимание, что используется не первый выход фильтра, а второй, куда попали записи, не удовлетворяющие условию.
Чаще всего проще прописать условие в утвердительном варианте Найди строки где сумма = 0, а покупатель содержит 0_Администратор или Частное лицо, а на выходе из узла взять те строки, которые не удовлетворяют этим условиям.
Должно получиться 98 893 строки. Количество записей сократилось с 2.5 миллионов более, чем в 25 раз.
Задание №2. Введите дополнительный аналитический признак для фильтрации в отчете клиентов, которым «необходима перерегистрация». Это будет удобно сделать в узле Калькулятор, в котором можно сформировать дополнительные признаки клиентской базы.
Дополнительный признак клиента
Для замены понадобится проверить, есть ли в названии клиента подстрока Перерегистрация. Это можно сделать функцией Find. Она возвращает номер символа строки, с которого начинается искомое слово. Таким образом, если Find выдаст значение больше 0 — значит слово было найдено.
Обратите внимание, что поле Pokupatel обрабатывается функцией Lower, чтобы проверяемая строка содержала только строчные буквы.
Полученное поле нужно добавить как фильтр в визуализаторы внутри Калькулятора. Теперь можно оценить, какой процент продаж приходится на подобных клиентов.
Куб с показателями продаж
В конце можно оценить, как повлияла работа с фиктивными данными на итоговые отчеты.
Отчет Клиентская матрица затронут несильно, т.к. в основном расcчитывает количество покупателей. Поэтому изменения небольшие: исчез клиент Частное лицо и пара внутренних подразделений.
А вот в Портрете клиента все намного интереснее. Вот что было до работы с фиктивными данными.
До исключения фейковых данных
А вот что стало после.
После исключения фейковых данных
Оказывается, VIP-клиенты приносят не 81.73% выручки, а 23.61%. И средний чек у них не 137 330, а 23 024 рубля. Теперь финансовая значимость этого сегмента выглядит иначе, поэтому приоритеты работы могут серьезно измениться.
Кейс с разделением продаж на опт и розницу простой, но это хороший повод задать вопрос: достаточно ли одноуровневого разбиения на 3 сегмента? Может быть стоит разбить на подсегменты, требующие отдельного изучения?
Оптовые продажи могут включать в себя совершенно разные категории клиентов. Например, государственные закупки, розничные сети, малый опт и т.д. Скорее всего объединение их в одну группу — не лучшая идея.
Не всегда эти разделения доступны в виде готовых справочных данных. Только опыт экспертов позволит все разложить по полочкам. А если своих знаний особенностей бизнеса недостаточно, лучше всего обратиться к опытному сотруднику и оцифровать его экспертизу в Loginom.
Сергей Кравченко является владельцем продукта «Визуализация отчетности блока риски» СБЕР. Весь его карьерный путь связан с работой с данными, отчетностью, автоматизацией и оптимизацией операционного и управленческого учёта. В выступлении рассказываем о self-service — что это такое и зачем нужно? А также рассуждаем, что делать, если попали в ловушку и как их избегать.
