Как бы мы сделали Яндекс Лавку: Predictive Commerce вместо обычной экспресс-доставки

Быстрая доставка решила вопрос: «Как быстро привезти пользователю то, что он уже захотел?» Следующий вопрос гораздо интереснее: «Можно ли понять, что ему понадобится, ещё до того, как он откроет приложение?»

У Яндекс Лавки уже есть инфраструктура, на которой такой сценарий выглядит логичным направлением развития: сеть дарксторов, собственное производство еды, большой объём транзакционных данных, технологии доставки и роботизации.

В I квартале 2026 года оборот Лавки вырос на 27% год к году. Количество дарксторов с модулями горячей еды выросло на 79%, а готовая еда достигла 21,6% GTV сервиса. Во II квартале рост оборота продолжился — +23% год к году.

Мы бы использовали эту инфраструктуру для следующего шага: не просто Quick Commerce, а Predictive Commerce.

Важно: Яндекс и Яндекс Лавка не являются заказчиками «Продвижение.Тех». Материал подготовлен на основе общедоступной информации и представляет независимую концепцию.

Главный актив q-commerce — не скорость курьера и даже не ассортимент. Это частота взаимодействия.

Покупка продуктов относится к повторяющимся сценариям: молоко, вода, корм, готовая еда и другие категории заканчиваются с определённой периодичностью. Значит, часть спроса потенциально предсказуема.

Гипотеза: если одновременно прогнозировать потребность конкретного пользователя и спрос конкретного микрорайона, можно оптимизировать сразу три экономики — пользователя, даркстора и доставки.

Predictive Commerce Engine объединяет два уровня прогноза: спрос микрорайона и потребность конкретного пользователя.

Первый отвечает на вопрос: «Что понадобится этому району завтра?»

Второй отвечает на вопрос: «Что, вероятно, понадобится конкретному пользователю?»

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

Модель отвечает: «Что понадобится этому району завтра?»

Прогноз строится на уровне: город → зона → даркстор → категория → SKU → час.

• История заказов
• День недели и время
• Погода и сезонность
• Праздники и локальные события
• Акции и остатки
• Категориальный спрос
• Срок годности

Вторая модель отвечает: «Что, вероятно, понадобится конкретному пользователю?»

Она оценивает вероятность следующей потребности, а не просто историю покупок.

Для пользователя рассчитываются P(reorder SKU), P(category need), P(meal order), P(promo sensitivity), P(churn) и expected basket value.

Хорошая персонализация умеет не только показывать, но и молчать при низкой вероятности потребности.

Мы бы развивали не отдельные фичи, а связанные сценарии: от регулярного пополнения до готового решения «что сегодня есть».

• Лавка «На завтра». Вечером пользователь получает предложение собрать привычную корзину из товаров, которые с высокой вероятностью понадобятся завтра. Путь сокращается с «открыть → найти → выбрать → добавить» до «подтвердить».
• Smart Replenishment. Для товаров регулярного потребления рассчитывается Expected Reorder Date. Сначала: prediction → suggestion → confirmation. Только после накопления истории — предложение автопополнения.
• Готовая еда как отдельный продукт. При доле готовой еды 21,6% GTV Лавку можно рассматривать как ответ на вопрос «Что я сегодня буду есть?». Мы бы сделали слой meal solutions: время → количество человек → предпочтение → готовое решение.
• AI-корзина. Пользователь описывает задачу естественным языком, а система превращает её в готовую редактируемую корзину.
• Local Assortment Engine. Для каждого SKU учитываются Expected Demand × Margin × Stockout Cost × Shelf-life Risk × Substitution Probability. Система рекомендует объём, даркстор, время и ассортимент.
• Hyperlocal ассортимент. Даже соседние районы могут иметь разный профиль спроса. Ассортимент должен быть динамически локальным — под реальные сценарии потребления.
• Предиктивная логистика. Прогноз спроса позволяет заранее оценивать нагрузку курьеров, пополнение даркстора и плотность маршрутов. Обычная доставка оптимизирует после заказа; Predictive Commerce — частично до заказа.
• Next Basket Engine. Система рассчитывает вероятность повторной покупки, потребности в категории, заказа еды, чувствительности к промо, оттока и ожидаемой стоимости корзины.

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

• MVP 1 — Replenishment: 20–30 товаров с высокой повторяемостью.
• MVP 2 — Predictive Basket: 3–5 товаров до начала поиска.
• MVP 3 — Meal Solutions: готовые сценарии еды.
• MVP 4 — Local Demand Forecast: связь прогноза с запасами даркстора.
• MVP 5 — Logistics Prediction: управление ресурсами последней мили.

Главная метрика — Incremental Contribution Margin.

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

• Order frequency
• Time-to-basket
• Repeat rate
• Retention
• LTV
• Average basket
• Conversion
• Incremental orders
• Contribution margin
• Stockout rate
• Waste
• Inventory turnover
• Picking efficiency
• Delivery cost per order

При продолжающемся росте Лавки задача может смещаться от «Как открыть ещё больше точек?» к «Как извлекать больше эффективности из каждого даркстора, каждого SKU и каждого пользовательского сценария?»

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

Это и есть Predictive Commerce.

Яндекс и Яндекс Лавка не являются заказчиками «Продвижение.Тех». Материал подготовлен на основе общедоступной информации по состоянию на октябрь 2026 года. Predictive Commerce Engine — независимая концепция «Продвижение.Тех» и не является информацией о внутренних продуктах, архитектуре или планах Яндекса.