Простой

8 мин

14

Привет, Хабр! Я – Александра Быстрова, менеджер продукта Lenta Tech («Группа Лента»). Эта статья — рассказ о том, как внутри крупного продуктового ретейлера зарождался, развивался и трансформировался геомаркетинг. Мы начинали с PowerPoint и полевых выездов, а пришли к собственному геопорталу с ML-моделями прогнозирования. По дороге набили немало шишек, о некоторых из них тоже расскажу.

С чего всё начиналось

В конце 2009 — начале 2010 годов рынок продуктового ритейла в России только набирал обороты. В компанию пришла новая команда управленцев, которая привезла с собой понятие «геомаркетинг» — подхода к экспансии, при котором новые магазины открываются не «где попало», а в объективно доходных локациях. А решения принимаются на основе актуальных данных о продуктовом рынке города и конкретного района.

Эпоха City Walk: анализ «ногами»

В то время не было картографических онлайн-сервисов, подходящих под наши задачи. Весь анализ проводился «в полях». Исследование называлось «City Walk» — буквально «прогулка по городу» — и включало:

Сроки: 4 дня в полях + 2 недели на отчет = ~3 недели на одну локацию.

Все картографические материалы мы готовили в PowerPoint. Да, POI, зоны доступности, конкуренты — всё заносилось прямо в PP. И самое болезненное: при повторном анализе той же или соседней локации всё приходилось переделывать практически с нуля.

Для сравнения: сегодня наше решение позволяет получить основную картографическую информацию за пять минут в онлайн-режиме — с готовым отчетом в PowerPoint, PDF или Excel.

2014–2017: настольные ГИС и первый скачок

В том же 2014 году мы начали активно использовать настольные геоинформационные системы для подготовки отчетов. Это стало серьезным шагом вперед, так как в ГИСах уже можно было сохранять основную картографическую информацию и переиспользовать ее для других локаций одного города. Но проблемы масштабирования никуда не делись.

2017: «бутылочное горлышко» и рождение геопортала

К 2017 году объем работы вырос лавинообразно. Нужно было оценивать не только новые локации, но и анализировать действующие магазины. Наш отдел превратился в «бутылочное горлышко»: очередь на оценку локаций выросла до двух месяцев, а заказчикам результат нужен был «вчера».

Мы провели анализ рынка ГИС-платформ и вместе с коллегами из ИТ выбрали текущее энтерпрайз-решение — веб-портал со всей необходимой картографической и аналитической информацией. Теперь у любого сотрудника компании появился прямой доступ к инструментам для решения задач экспансии, анализу эффективности действующих магазинов и для взвешенной локальной маркетинговой поддержки магазинов.

Две системы (геопортал и GEO ML) — одна экосистема

Концептуально в экосистему гео входят следующие сервисы: анализ локаций, прогнозы продаж по клику, анализ каннибализации от открытия локаций на действующие магазины, геоанализ действующих магазинов (клиенты, их продажи в привязке к карте).

Геопортал: что под капотом

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

Система базируется на ArcGIS — закрытом лицензионном ПО от компании ESRI, которая была и остается флагманским решением для геоаналитики в мире.

Выбор платформы происходил в отличных от текущих внешних рыночных и социально-экономических условиях. На тот момент это была единственная коробочная платформа, которая предлагала полный набор необходимых инструментов: фронтенд, бэкенд, сервера, коннекты к базам данных, сервисы для администраторов и рабочие места операторов данных.

Платформа имеет удобное API для автоматизации процессов, доступна для кастомизации, но при этом для закрытия базовых потребностей требует минимум разработки.

Другие важные факторы при выборе:

●      наличие у вендора опыта внедрения похожих систем в нашей сфере;

●      готовая квалифицированная и доступная техническая поддержка;

●      наличие обкатанных курсов и программ обучения для наших специалистов.

Рабочий процесс: от данных до пользователя

Пространственные данные

    ↓ обработка специалистами

Загрузка в БД

    ↓ настройка визуализации

Публикация картографического сервиса

    ↓ конструктор портала

Веб-карты и веб-приложения

    ↓

Пользователь

Главный плюс — минимум разработки. Изначально при выборе платформы это и был основной аргумент: мы можем быстро дать доступ к данным без традиционной разработки. Собрать рабочее приложение реально в течение одного дня. Это не требует специфических навыков — только знание системы.

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

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

Сейчас в стеке у нас следующие технологии:

• SQL\PLSQL. В качестве основного хранилища у нас используется Oracle и разработки на SQL у нас много. Это и подготовка витрин данных и написание процедур, функций, тригеров.

• Python. Платформа имеет хорошо задокументированное Python API для взаимодействия с компонентами и реализации различных задач геообработки. Сейчас мы пишем много на питоне. Реализуем различные хотелки наших пользователей по инструментам выгрузки данных, геоаналитики, автоматизации отчетов и т.д.

• JavaScript – наше самое слабое место сейчас и зона для развития. Гепортал это веб-приложение, поэтому вопрос разработки удобных интерфейсов для взаимодействия пользователей с системой появляется постоянно. У нас уже есть кейс захода на эту территорию, но пока основные работы выполняет подрядчик.

• Powershell – задачи администрирования системы возникают постоянно. Система развернута на Windows. Поэтому часть скриптов автоматизации мы пишем на powershell.

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

Возникновение GeoML

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

Команда Big Data разработала собственную ML-модель. Принципиальное решение — делать in-house:

●      данные не уходят за периметр компании;

●      дешевле в эксплуатации;

●      проще поддерживать и развивать.

В 2021 году, в связи с активной экспансией новых форматов, мы разработали облачный сервис прогнозирования, интегрированный с геопорталом. Теперь пользователь по клику на карте мгновенно получает прогноз товарооборота с учетом всех вводных для конкретной локации.

Как это работает:

Алгоритм: модель GeoML – модель градиентного бустинга на дереве решений (lightGBM).

Градиентный бустинг — продвинутый алгоритм машинного обучения для задач регрессии.

Идея: последовательно применяются модели-предикторы, где каждая следующая модель минимизирует ошибку предыдущей. Из множества «слабых» моделей собирается одна эффективная.

GeoML развернута в Яндекс.Облаке и взаимодействует с геопорталом через REST API и шины интеграции. Верхнеуровнево GeoML состоит из следующих компонентов:

●      приложения на FastAPI, предоставляющее эндпойнты для обработки запросов;

●      бэкенд на python, содержащий ядро модели прогнозирования;

●      БД PostgreSQL для хранения и обработки данных;

●      системы мониторинга на графане;

●      Airflow для управления задачами обработки данных;

●      гитлаба для хранения кода и обеспечения процессов развертывания модели.

Цифры:

Факторов в модели на продуктиве ~50;

Фичей на этапе обучения ~1 000;

Текущая точность – 75-90% в зависимости от формата магазина.

Типы данных, участвующие в обучении, представлены агрегированными статистическими показателями, рассчитанными в рамках зон доступности локации.

В системе используются как предварительно рассчитанные данные, хранящиеся в БД, так и вычисления, выполняемые в режиме реального времени с применением специализированных пространственных инструментов – PostGis и Geopandas.

Как обучаем, валидируем и мониторим модель прогнозирования выручки новых магазинов

Цикл переобучения

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

Почему нет отложенной выборки

Классический train/test split здесь не работает так, как хотелось бы. Нам важно, чтобы в обучении были представлены недавно открытые магазины — именно они несут актуальные тренды. Если “отрезать” их в тест, модель рискует не увидеть то, что происходит прямо сейчас. Поэтому используем кросс-валидацию — она дает надежную оценку качества без потери свежих данных.

Метрики на кросс-валидации:

• MAPE, WAPE — стандартные метрики точности прогноза выручки;

• Квантили по выручке — смотрим не только на среднее, но и на “хвосты” распределения.

Мониторинг в продакшне

Мониторинг реализован просто: отчет по точности, в котором прогноз сравнивается с фактическими продажами.

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

Как отбираем финальную модель

Хорошая метрика на кросс-валидации — необходимое, но не достаточное условие. Перед релизом гоняем модель по срезам:

• Регионы — как модель отработала на старых регионах, где нас давно знают и как на рынках, куда мы только-только вышли.

• Форматы магазинов — модель должна одинаково хорошо отработать, как для магазина больше 5 000 квадратных метров, так и для 2 500.

• Годы открытия — точность должна быть высокой, как для магазинов, открытых в нулевых, так и в двадцатых годах.

Бизнес-метрики: самое сложное

Технические метрики — это хорошо, но бизнес хочет ответа на конкретный вопрос: порекомендует ли модель открыть магазин, который реально “выстрелит”, и отсеет ли заведомо провальный?

Проблема в том, что для такой оценки нам нужен эталон — профиль «образцового успешного магазина». И это уже не задача ML-команды: это совместная работа с бизнесом, который помогает нам формализовать, что именно считается успехом. Без этого любая оценка по бизнес-метрикам будет субъективной.

Зоны для развития модели:

●      Мультитаргетное моделирование — прогнозирование нескольких метрик одновременно.

●      Новые фичи — расширение набора признаков;

●      Новые алгоритмы подготовки фичей;

●      AutoML — автоматический подбор моделей;

●      Бизнес-метрики — фокус на практически значимых показателях;

●      Региональные модели — учёт локальной специфики территории;

●      Обеспечение преемственности модели от релиза к релизу.

Масштабирование опыта

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

Итого: эволюция за 15 лет

От PowerPoint до машинного обучения — путь в 15 лет, десятки тысяч проанализированных локаций и большое приключение. Геомаркетинг в ретейле — это не просто «точки на карте», а полноценная data-driven экосистема, которая влияет на стратегические решения бизнеса.

 А как вы видите развитие геомаркетинга с учетом современных технологий?