Привет, Хабр! Я – Александра Быстрова, менеджер продукта 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 лет
Период | Инструменты | Время на одну локацию |
2009-2014 | PowerPoint + ноги | ~3 недели |
2014-2017 | Настольные ГИС | ~1 неделя |
2017-2021 | Геопортал (ArcGIS) | ~5 минут |
2021-настоящее время | Геопортал + GeoML | 1 клик |
От PowerPoint до машинного обучения — путь в 15 лет, десятки тысяч проанализированных локаций и большое приключение. Геомаркетинг в ретейле — это не просто «точки на карте», а полноценная data-driven экосистема, которая влияет на стратегические решения бизнеса.
А как вы видите развитие геомаркетинга с учетом современных технологий?
