Предпосылки идеи

В 2015 году рынок продуктового ритейла переходит в стадию зрелости — открывать экономически выгодные объекты становится сложнее. Некоторые продуктовые сети закрываются, компании несут убытки. Начинается гонка игроков, и выигрывает тот, кто начинает использовать технологии при открытии торговых точек. Появляются и развиваются сети новых форматов (ВкусВилл и Азбука Вкуса).

Потребность в сервисах прогнозирования выручки растёт с количеством ошибок при открытии, которые допускает компания — чем больше объектов закрылось, тем больше компания несёт убытков. Поняв потребности бизнеса, мы решили создать собственный сервис.

В основу сервиса встала геоинформационная платформа, однако только с помощью ГИС невозможно посчитать выручку, поэтому мы соединили геоаналитические и математические функции моделирования. Так появился «Арендоход». Сервис реализован как закрытая система, доступная только для подтверждённых пользователей.

Суть сервиса — карта

«Арендоход» — это ГИС, поэтому основным рабочим пространством является карта.

Создание расчётного проекта:

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

Геомаркетинг — расчет выручки сервиса на основании вычисленных коэффициентов для отрасли, например, процент конверсии потенциальных покупателей (кто является потенциальной целевой аудиторией).

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

Первый прототип

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

Плохими оказались новости о качестве данных: существующие на рынке источники данных не всегда точные, их нужно обрабатывать. Например, если в адресе небольшая ошибка и множество таких адресов с ошибками автоматически привязывать к карте — геокодировать, их координаты будут отличаться от фактического положения объекта. Нам пришлось стать создателями данных.

Удачным решением было использовать Bootstrap — это заметно сократило затраты на frontend-разработку и позволило быстрее внедрить сервис на первом этапе. Мы получили фидбек от пользователей о том, что удобно, а что нет. Приступили ко второй итерации.

Вторая итерация

Мы показали MVP опытным аналитикам рынка ритейла, рассказали о результатах использования сервиса и доработали сервис до 85-90% точности прогноза. И всё — мы уперлись в эту точность.

Оказалось, что проблема не в данных или программе. Мы пришли к выводу, что эти 10-15% погрешности связаны с человеческим фактором — работа директора магазина и всего персонала, в общем — клиентского сервиса.А это — то, за что наш сервис отвечать не может.

Фичи сервиса

1. Поиск места с потенциальным максимальным товарооборотом.
2. CRM — учёт всех объектов компании и отправка оповещении при действиях пользователей.
3. Прогноз не только потенциала, но и отображение выручки помесячно с учётом сезонности и закрытия/открытия конкурентов.
4. Прогнозирование выручки двумя методами: машинное обучение и геомаркетинг.
5. Отображение зон охвата конкурентов.

Каждый объект торговли имеет локацию, выраженную географическими координатами. На выручку объекта влияет группа факторов в зависимости от локации и формата магазина.

Технологический стек и рабочее окружение

Для кода проекта был создан репозиторий на GitHub и выданы доступы всем разработчикам. Тестовая версия развернута на сервере DigitalOcean, настроено Conitnuous Integration и Continuous Deployment.

При каждом изменении в проекте автоматически происходила сборка, выполнялись автоматические тесты и статический анализ кода. Настроена отправка статусов в GitHub таким образом, чтобы изменения кода можно было принять только в случае успешной сборки. Для CI/CD использовался сервис TeamCity.

Сценарии автоматического развертывания проекта написаны с использованием Fabric. Для развертывания в окружении разработчика использовался Vagrant и Packer для сборки базовых образов системы. Production-сервер настроили с помощью автоматических сценариев, написанных на Fabric. Автоматическое развёртывание новых версий настраивали с помощью TeamCity.

Кроме этого, мы писали функциональные тесты для автоматической проверки работы в реальных сценариях применения. Для написания функциональных тестов использовали Selenium и Python 3.

Команда проекта

Над проектом работали 6 разработчиков, 1 QA специалист, 1 менеджер проекта и 2 аналитика.

Результаты работы

Сейчас нашим сервисом пользуются крупные сетевые ритейлеры. Узнайте, сколько стоит разработка сервиса Арендоход в WB—Tech.