Как OSA превращает пустые полки в полные корзины?

Меня зовут Анастасия Трапезникова, и я ведущий аналитик данных в Magnit Tech. Вы когда-нибудь сталкивались с разочарованием перед пустой полкой, где должен быть ваш любимый майонез? А что если я вам скажу, что майонез в магазине есть. Помимо разочарования, это приводит еще и к потере выручке магазина.

Понять, почему товар числится в магазине, но не покупается посетителям, практически детективная задача. Так что наша команда занимается настоящими расследованиями: данные – наши улики, с помощью которых необходимо понять, почему вы не можете купить свой любимый майонез в ближайшем магазине. Именно здесь выходит на сцену команда проекта OSA. Присаживайтесь, погружу вас в детали работы нашего детективного бюро.

Итак, начнем с основ. OSA (сокр. On-shelf availability) дословно «Доступность на полке» – показатель, отражающий физическое присутствие товара на полке магазина, при котором потребитель может его взять и купить/пробить через кассу. Общий путь товара от закупа до покупателя длинен и тернист, OSA отвечает за последнюю милю, при котором товар числится на остатках магазина, но по каким-то причинам не продается. OSA напрямую влияет на лояльность клиента: внешний вид пустых полок или отсутствие любимого продукта может оттолкнуть и, в худшем случае, лишить нас  постоянного клиента.

Среди причин недоступности товара для клиента можно отнести:

• Нет на полке. Сотрудники магазина не успели/забыли выложить товар со склада, при этом товарная позиция есть в магазине.

• Виртуальный остаток. На полке и на складе товарной позиции нет, но в базе данных числится на остатках. Приводит к отсутствию срабатывания системы автозаказа, как следствие товар не привозят в магазин.

• В глубине полки. Товара нет в прямой видимости и/или покупатель не может его найти.

• Неправильный ценник/отсутствие ценника. 

• Некорректный штрихкод. Кассир не может пробить товар, и он убирается из корзины клиента.

• Нет возможности выложить. Сотрудники не выкладывают товар из-за ограниченного размера витрины.

Это базовые сценарии статуса товара в магазине, и для каждого случая прописаны инструкции, что необходимо сделать с товаром. Ежедневно сотрудникам магазина на ТСД* приходит задание по проверке доступности, которое содержит несколько товарных позиций (сигналов). Сотруднику необходимо подойти к полке, где должен находится товар и отсканировать его штрихкод. Если с товаром нет проблем, то на этом отработка сигнала завершается. Если есть какая-то из перечисленных выше проблем, то сотрудник может списать товар, распечатать актуальный ценник и так далее, исправив проблему доступности.

ТСД – Android-терминал сбора данных, который позволяет собирать, хранить, обрабатывать и передавать информацию о товарах, имеет множество встроенных функций, например, сканирование штрихкода.

Товарная позиция – единица товарного ассортимента, которая идентифицируется и управляется в рамках бизнес-процессов продаж, учета и хранения товаром. Характеризуется уникальным идентификатором и наименованием в базе данных

Главный челлендж, который стоит перед командой OSA – нам необходимо ежедневно определять проблемный товар в каждом магазине сети «Магнит», доставлять сигналы до сотрудника магазина и получать фидбек с описанием – была ли зафиксирована проблема с товаром, и как она была решена. В «Магните» насчитывается более 27 тысяч торговых точек с актуальным ассортиментом в среднем 6 тысяч позиций на магазин, что приводит к более 160 млн связок магазин-товар для анализа на предмет доступности каждый день. Исходя из накопленных данных, решение проблем с доступностью может принести компании до 1% от выручки магазинов. Чтобы откопать этот клад среди всего многообразия товаров, приходим на помощь мы – команда проекта OSA.

Какие существуют способы проверки товара на полках магазина?

Видеофиксация витрин магазина в реальном времени

Первое решение, которое может прийти на ум – это мониторинг полок магазина в реальном времени с помощью видеонаблюдения, и определение с помощью компьютерного зрения, какие позиции есть на полках, а каких нет. Однако это требует установки специального оборудования в каждый магазин Магнит, а также ресурсы на обработку большого количества данных. Это дорогая реализация проекта, которая ставит под вопрос его окупаемость.

Фотофиксация витрин сотрудниками магазина по требованию

Если отойти от идеи видеонаблюдения, можно с определенной периодичностью запрашивать фотофиксацию полок от сотрудников магазина. Если жестко зафиксировать требования к местоположению товаров (планограмм), можно контролировать состояние полок через фото. При этом необходимо поддерживать актуальным фотобанк, чтобы суметь связать изображение с идентификатором позиции в базе данных. Магазины «Магнит» есть в большинстве регионов России, наличие продукции местного производства приводит к существенным отличиям ассортиментной линейки торговых точек в разных регионах. С учетом этого, а также высокой частоты ротации ассортимента из-за ввода-вывода товара, сезонных позиций и периодической смены упаковки товаров задача актуального фотобанка становится нетривиальной. 

С другой стороны, есть необходимость передавать фото в сервис для распознавания, создается высокая нагрузка при работе на всю торговую сеть, что приводит к ограничениям на количество обрабатываемых фото с магазина в день. Если установить соотношение 1 фото – 1 стеллаж, то за 1 день от магазина можно получить изображения нескольких стеллажей и распознать несколько десятков товарных позиций. Однако вероятность сосредоточения всех недоступных проблемных позиций на двух-трех стеллажах крайне мала, а фотографирование всего магазина трудозатратно для сотрудника и осложнено в обработке. Как итог, результативность метода фотофиксации вызывает сомнения.

Фотобанк — это хранилище изображений товарных позиций, которые предлагаются к продаже

Фиксация в базе данных более детального статуса-местоположения товара, например, склад/витрина

Если мы не хотим получать фото или видео полок магазина, можно фиксировать изменения остатка более детализировано, чем на уровне магазина. Например, при выкладке на витрину фиксировать в базе данных остаток конкретно на витрине. Это может нам дать дополнительное измерение в данных. Очевидный минус, что при фиксации такого статуса товар может оставаться недоступным для клиента из-за проблем с ценником или штрихкодом, как было описано выше. Такой подход может работать в ритейле, когда основной поток выдачи товаров происходит со склада при ограниченной ротации товаров на витрине.

Использовать готовые табличные данные

Допустим, мы не хотим внедрять существенные нововведения в бизнес-процессы магазина. Проблема с доступностью позиции всегда приводит к остановке продаж по ней, что отражается в чеках и собирается в витринах нашего КХД (корпоративного хранилища данных). С учетом повседневного спроса на товары в «Магните», отловить остановку продаж из-за проблем с доступностью должно быть реализуемой идеей. Концепция переиспользования любых доступных данных из КХД с целью определения проблемных связок день – магазин – позиция с точки зрения доступности для клиента и есть базовая идея, которая заложена в реализации проекта OSA.

Остановка продаж по позиции – все ли так просто?

Здесь мы начинаем погружение в проблемы обработки статистики продаж на высоком уровне детализации: товар – магазин – день. В первом приближении временной ряд имеет случайный характер, тем не менее на длинной дистанции мы можем охарактеризовать ряд дискретностью продаж, которая показывает, как часто продается товар в магазине (продажи раз в 7 дней будут иметь дискретность 7 дней, каждый день – дискретность 1 день и т.д). 

Есть товары с коротким сроком годности: например, молочная продукция, яйца, курица и так далее, дискретность продаж которых составляет 1-2 дня. От текущего дня шагнем на 1 месяц назад и рассмотрим продажи позиции по дням в одном магазине (рисунок 1). В статистике могут встречаться дни без продаж, при этом, чем сильнее отличие длительности периода без продаж от дискретности, тем вероятнее наличие проблемы с товаром. Так, для позиции с высокой дискретностью в 1-2 дня выделенный период без продаж 10 дней явно выглядит аномальным.

В то же время в магазине есть категории товаров, которые продаются раз в неделю и реже, например, порошки или дорогой кофе, и тот же период без продаж в 10 дней не выглядит чем-то подозрительным. За последний месяц продажи встречаются редко, и чтобы определить, насколько последний период без продаж является аномальным для данной позиции, приходится собирать данные за более длительное время. Например, за последние 3 месяца.

Мы не можем бесконтрольно увеличивать рассматриваемую статистику продаж в прошлое. Во-первых, это кратно увеличивает временные затраты на обработку данных. Во-вторых, на больших временных отрезках может изменяться спрос, сказаться сезонность продаж категории или всего магазина (пример, магазины на побережье). Выход из этого положения – предварительно разбить магазины на группы аналогов и анализировать объединенную историю продаж, которая увеличится кратно числу магазинов в группе. Если связка позиция-магазин выделяется на фоне всей группы, то это сигнализирует о том, что здесь есть проблема.

Очевидно, что не только недоступность товара на полке может привести к падению в ноль статистики продаж. Вот небольшой круг проблем, который нужно учитывать:

1. Период промо и регулярных продаж

Оттолкнуть от покупки того или иного товара в первую очередь может цена. При выходе из акционного периода могут остановиться продажи по позиции. Так, люди закупаются товарами впрок по сниженным ценам, и после установки регулярной цены продажи на время останавливаются. Для обхода этого явления статистика продаж разделяется на промо период и период регулярной цены, и показатели рассчитываются для них отдельно. Вероятность продажи товара ниже в период регулярной цены. Следовательно, нужно определить была ли акция в момент последнего периода без продаж (выделенный промежуток в 10 дней на рисунке 1). Если акции не было, то брать в расчет дискретность, рассчитанную по статистике продаж только за время действия регулярной цены. Так можно скомпенсировать эффект повышения цены.

2. Каннибализация

Большая ассортиментная линейка в продуктовых магазинах предполагает наличие нескольких аналогов каждого товара на полке. Более привлекательная цена на аналогичный товар способствует снижению спроса на рассматриваемую позицию. Аккуратный подбор магазинов аналогов с похожей ассортиментной линейкой распространяет этот эффект на всю группу, и конкретный магазин не выпадает в качестве проблемы с доступностью.

3. Продаж нет на всех аналогичных магазинах

Если товарная позиция не продается ни в рассматриваемом магазине, ни в группе магазинов-аналогах из-за периода несезона или из-за принадлежности к категории непродовольственных товаров с большим сроком хранения, то данная позиция никогда не станет сигналом вне зависимости от наличия или отсутствия товара на полке.

4. Снижение продаж позиции из-за снижения выручки всего магазина

Дневные продажи торговой точки могут упасть из-за неизвестных заранее причин, например – перекрытие дороги рядом, ремонт магазина без своевременной записи события в базу данных и пр. Мониторинг динамики верхнеуровневых продаж поможет своевременно поднять пороги детекции для отдельных магазинов.

Анализируя всю доступную информацию цен, остатков, приходов, списаний и продаж, есть возможность предсказать, какой ассортимент в магазине не продается из-за проблем с доступностью. Таким образом, часть наших ML – алгоритмов заточена на расчет длительности периода без продаж, при котором на конкретном магазине конкретный товар считается проблемным.

Отдельно стоит отметить, что у нас нет примера готовой разметки на весь магазин, которая показывает какой ассортимент недоступен, а какой лежит на полке. Если вернуться к временным рядам с продажами мы не можем в точности сказать, в какой день позиция стала недоступна, а также нет информации, когда позиция была недоступна в прошлом. При достаточном количестве магазинов в группе аналогов крайне маловероятно, что проблема с доступностью позиции будет одновременно на всех торговых точках. Тем не менее, обучение и валидация ML-алгоритмов без разметки усложняет существующую задачу.

Метрики проекта OSA и принципы работы с обратной связью

Прежде чем перейти к технической реализации проекта, стоит отдельно остановиться на контролируемых метриках проекта, поскольку они обусловливают наличие основных компонентов архитектуры. Итак, вот список основных метрик:

• Точность – доля подтвержденных проблемных позиций от общего числа сигналов с ответом;

• Спасенные продажи – сумма продаж, активированных после исправления проблемы;

• Исполнительность – дисциплина отработки заданий сотрудниками магазинов.

Главное, на что ориентирована вся система OSA – высокая точность определения недоступного ассортимента в магазине. Доля проблемных позиций может варьироваться в зависимости от качества работы сотрудников на разных магазинах. Тем не менее, есть лимит по общему максимальному количеству выдаваемых сигналов в день на один магазин, который составляет в среднем 25 сигналов. Величина лимита может изменяться вплоть до одного конкретного магазина, значение ограничено рабочей нагрузкой сотрудников. Чтобы OSA привносила наибольший эффект в рублях за ограниченное число сигналов, второй метрикой проекта являются спасенные продажи. Благодаря выполнению сотрудником сформированных нами сигналов клиент смог купить недоступную ранее продукцию, и мы восстанавливаем часть выручки, которая без нас была бы утеряна.

Если бы точность зависела только от качества работы нашей системы, это бы значительно облегчило нашу жизнь. Как можно догадаться, на практике ответы зависят от пути отработки сигналов в приложении на ТСД, и насколько сценарии полностью покрывают существующие проблемы с товаром при выкладке, а также от ответственности сотрудников (пример возникновения сложностей при взаимодействии людей и системы можно почитать в другой нашей статье тут). Третья метрика, которая ежедневно контролируется аналитиками проекта – это исполнительность.  Падение исполнительности явно сигнализирует о проблемах либо на технической стороне, либо на стороне мотивации сотрудников.

Для исключения влияния фрода (умышленный обход системы ответа в ТСД без осуществления проверки товаров) и некорректной обработки заданий, команда проекта проводит тестовые походы в магазины для проверки точности сигналов с прода или тестовых сигналов в рамках новых доработок в алгоритмы. Также тестовые походы раскрывают нам пробелы в инструкции по отработке заданий и неочевидные пути развития проблемы при выкладке товара на витрину.

Накапливая статистику ответов от сотрудников магазинов, мы всегда находимся в поиске закономерностей по влиянию отсутствия товара на витрине на показатели в БД (базе данных), и доказанные взаимосвязи внедряются в архитектуру решения, чтобы повысить итоговую точность сигналов OSA. Чтобы понять, как именно можно внедрить инсайты в проект, рассмотрим ключевые блоки архитектурного решения.

Текущая реализация обработки и выдачи сигналов OSA

Не только продажи могут нам указать на проблемы с доступностью. Например, в ходе тестовых походов на магазины, мы заметили, что при приемке товара сотрудники могут не выложить товар на витрину и оставить ее на складе. Кратность остатка товара в магазине размеру минимальной партии привоза товара в течение длительного времени тоже может служить индикацией проблемы. У нас есть несколько работающих подходов, которые в ежедневном порядке выдают списки магазин-позиция, определенные  как проблема OSA. Чтобы не работать с трудно управляемым нагромождённым единым кодом и быть более адаптивными к изменениям, упрощенная схема текущей архитектуры выглядит следующим образом:

Главным источником данных для ML-алгоритмов являются витрины КХД «Магнита». В ежедневном порядке набор алгоритмов анализирует ассортимент всей сети «Магнит» и выдает связки магазин-позиция, которые считает проблемными. Далее сигналы всех алгоритмов проходят индивидуальные фильтры и аккумулируются в одну таблицу. Поскольку алгоритмы могут иметь пересекающиеся сигналы между собой, правило приоритезации присваивает каждому сигналу единственный алгоритм. Далее действует правило ранжирования, в результате которого проставляется приоритет товарной позиции в каждой группе магазин-алгоритм. Для каждого алгоритма есть лимит на количество отправляемых сигналов в день. С учетом приоритета сигналы обрезаются в рамках установленного лимита и отправляются на ТСД по времени, учитывающему часовой пояс магазина. Поскольку мы ориентированы на отправку магазинам в часовом поясе UTC+7 до 12 дня по местному времени, то это накладывает жесткие требования на время сбора и постобработки сигналов. Непосредственная работа ML-алгоритмов обычно откладывается на вечер предыдущего дня. Наличие каждого функционального блока оправдано целью максимизации ключевых метрик, бизнес-требованиями и удобством тестирования. Детальному описанию архитектуры проекта будет посвящена другая статья.

Заключение

На текущем этапе развития проекта мы работаем над улучшением алгоритмов детекции и над оптимизацией всей системы в целом. Начав свой путь с наиболее распространённого формата «Магнит у дома», мы расширились с 12 магазинов до 19 тысяч точек меньше, чем за 4 месяца, и теперь прорабатываем вопросы интеграции с другими форматами. Подводя итог этой статьи, я представила общий обзор проекта OSA и осветила базовые вызовы, с которыми приходится сталкиваться при поиске недоступных товарных позиций. В дальнейшем мы планируем запустить цикл статей по проекту, прежде всего об алгоритмах, в которых сосредоточена ключевая магия выявления недоступного ассортимента в «Магните».

Если возникли вопросы, задавайте их в комментариях, мы с командой постараемся на все ответить!