Узнайте, как платформы наподобие Uber уравновешивают спрос и предложение с помощью ликвидности, динамического ценообразования и координации диспетчеризации, чтобы городская мобильность ощущалась программируемой.
Город — это не софт, но части того, как он движется, можно воспринимать как программируемые, если платформа умеет чувствовать происходящее, применять правила и учиться на результатах.
В этом смысле «программируемый» не значит контролируемый город. Речь о том, чтобы запускать постоянно обновляющийся уровень координации поверх городской инфраструктуры.
Программируемая сеть — это система, где:
Uber — яркий пример: он непрерывно переводит грязную городскую реальность в машиночитаемые сигналы, принимает тысячи мелких решений и обновляет их по мере поступления новых сигналов.
Координация тяжела, потому что «входы» нестабильны и частично зависят от людей.
Трафик может превратиться из свободного в пробки за считанные минуты. Погода меняет спрос и скорость движения. Концерты, матчи, сбои в метро и перекрытия дорог создают внезапные всплески. И люди — не датчики: они реагируют на цены, времена ожидания, стимулы и привычки.
Поэтому задача — не только предсказать, что произойдёт; важно успеть отреагировать так, чтобы сама реакция не породила новых проблем.
Когда говорят, что Uber «программирует» город, обычно имеют в виду три рычага, которые поддерживают работу маркетплейса:
Вместе они превращают разрозненные индивидуальные выборы в скоординированный поток.
Эта статья сосредоточена на концептах и механизмах: базовой логике ликвидности, динамического ценообразования, сопоставления и обратных связей.
Здесь нет описания проприетарного кода, точных формул или внутренних реализаций. Рассматривайте материал как повторяемую модель для понимания того, как платформы координируют реальные сервисы в масштабе города.
Uber — это не просто «приложение для такси», а двусторонний маркетплейс, координирующий две группы с разными целями: пассажиров, которым нужен поездка сейчас, и водителей, которым важно заработать стабильно и предсказуемо. Задача платформы — перевести тысячи отдельных решений (вызов, принятие, ожидание, отмена) в равномерный поток завершённых поездок.
Для большинства пассажиров опыт определяется не машиной, а тем, насколько быстро их сопоставили и насколько надёжно произойдёт посадка. Время до подачи и надёжность (не получить отмену, не видеть скачки ETA) — практический «продукт».
Именно поэтому ликвидность важна: при достаточном количестве доступных водителей рядом система может быстро матчить, держать ETA стабильными и снижать количество отмен.
Каждый матч — это баланс между противоречивыми целями:
Чтобы управлять этими компромиссами, платформы следят за несколькими индикаторами, которые сигнализируют о состоянии:
Когда эти индикаторы двигаются, обычно это цепная реакция на обеих сторонах маркетплейса.
Ликвидность в маркетплейсе вроде Uber просто определяется как: достаточно близкое предложение для спроса — в большинстве случаев. Не «много водителей где-то в городе», а водители рядом настолько, чтобы пассажир получил быстрый и надёжный матч.
Когда ликвидность падает, симптомы проявляются сразу:
Это не отдельные проблемы — разные проявления одной и той же нехватки: недостаточно машин в радиусе, который имеет значение.
Город может иметь большое число водителей в целом и всё равно ощущаться «сухим», если они распределены по всему пространству. Ликвидность гиперлокальна: меняется по кварталам и по минутам.
Стадион, выпуская зрителей в 22:17, — это другой рынок, чем соседний район в 22:19. Мокрый перекрёсток отличается от сухого. Даже одно дорожное перекрытие может сместить точку концентрации предложения.
Каждая лишняя миля между пассажиром и водителем добавляет время ожидания, неопределённость и шанс отмены.
Когда пассажиры доверяют, что «машина приедет», они заказывают чаще и в более разное время суток. Стабильный спрос делает доходы водителей предсказуемыми, и они остаются онлайн. Больше стабильного предложения снова улучшает надёжность.
Ликвидность — не просто результат; это сигнал, который формирует поведение и удерживает обе стороны на платформе.
Всё, что делает Uber дальше — ценообразование, сопоставление, ETA — опирается на постоянно обновляемую картину происходящего. Это «реальное состояние» города: живой снимок, который превращает уличный шум в входы, на которые система может реагировать.
На практике это множество мелких сигналов:
Реакция проста: всплеск запросов в зоне — система отвечает.
Но более ценна способность предсказывать — прогнозировать, где спрос или предложение появятся до того, как они слишком разойдутся. Это помогает не «гнаться за прошлой проблемой», когда водители приезжают только после окончания пика.
Несмотря на ярлык «в реальном времени», решения обычно принимаются в батчах:
Реальные улицы дают грязные данные. GPS дрейфует в «городских каньонах», обновления приходят с задержкой, некоторые сигналы пропадают при потере связи. Важная часть слоя данных — обнаружение и исправление таких проблем, чтобы дальнейшие решения не опирались на призраков, устаревшие местоположения или вводящие в заблуждение скорости.
Если хотите посмотреть, как эти сигналы влияют на последующие шаги, продолжите по /blog/dynamic-pricing-balancing-supply-and-demand.
Динамическое ценообразование (часто называемое surge) — это инструмент балансировки. Это не в первую очередь «способ брать больше», это регулятор, которым платформа может поворачивать, когда рынок уходит из баланса.
У маркетплейса простая проблема: люди делают запросы всплесками, а доступные водители разбросаны и ограничены в каждый момент. Цель системы — уменьшить избыточный спрос и привлечь/удержать достаточное предложение в нужных местах.
Быстрая корректировка цен влияет на два решения одновременно:
Думайте так:
Это работает по минутам, потому что условия меняются по минутам: завершается концерт, начинается дождь, сбой в поездах, район внезапно опустел.
Поскольку цены непосредственно влияют на людей, динамическое ценообразование обычно требует ограждений. Это может включать:
Важная мысль: динамическое ценообразование — сигнал для поведения. Это механизм, который сохраняет работоспособность рынка, не давая временам ожидания вырасти неконтролируемо.
Ценообразование на платформе — это не просто «дороже при загруженности, дешевле в покое». Алгоритм старается поддерживать рабочий рынок: достаточный поток запросов, достаточное число принятий водителями и выполнение поездок с предсказуемыми временами ожидания.
Точность важна, потому что ошибки имеют асимметричные последствия. Если система перебарщивает с ценой, пассажиры откажутся и будут считать платформу алчной. Если недооценивает пик, запросы накапливаются быстрее, чем водители могут обслуживать — ETA растут, отмены увеличиваются, водители демотивируются.
Большинство систем ценообразования объединяют несколько сигналов, чтобы оценить ближайшее будущее:
Цель — не точное предсказание будущего, а формирование поведения сейчас — подтолкнуть достаточно водителей и отсеять низкоприоритетные запросы, когда сервис не может быть доставлен.
Даже при быстрой смене спроса цены нельзя дергать так резко, чтобы подорвать доверие. Приёмы сглаживания (постепенные корректировки, ограничения и усреднение по окну времени) предотвращают резкие скачки от мелких флуктуаций, но позволяют быстрее реагировать на реальные события.
Поскольку поведение пользователей чувствительно, платформы полагаются на аккуратные эксперименты (контролируемые A/B-тесты), чтобы подобрать оптимальные параметры — балансируя конверсию, принятия, отмены и времена ожидания.
Диспетчеризация — момент, когда маркетплейс превращается в движение: система решает, какой водитель заберёт какого пассажира и какое лучшее следующее действие после этого.
В любой момент возможны множество сочетаний между рядом стоящими водителями и пассажирами. Диспетчеризация — выбор одной пары сейчас, понимая, что этот выбор изменит возможности через минуту.
Это не просто «ближайший водитель». Платформа учитывает, кто приедет скорее, кто скорее примет заказ и как назначение повлияет на загруженность в районе. При пуллинге она решает, можно ли посадить двоих без нарушения обещанных времен посадки и высадки.
Обычно цель — минимизировать время подачи и при этом сохранить здоровье системы: опыт пассажира (короткие ожидания, надёжные ETA), опыт водителя (стабильный заработок, разумные перемещения без дохода) и справедливость (избегать ситуаций, когда некоторые районы систематически получают худший сервис).
Решения диспетчера ограничены реальными правилами:
Каждый матч перемещает предложение. Отправка водителя на 6 минут на север улучшит ожидание этого пассажира, но уберёт машину с юга, увеличив там будущие ETA и возможно вызвав дальнейшее перераспределение. Диспетчеризация — это непрерывная задача координации: тысячи мелких решений формируют, где будут машины, что увидят пассажиры и насколько ликвиден рынок со временем.
Обещание Uber — не просто «машина приедет», а насколько скоро, насколько предсказуемо и насколько плавно пройдёт поездка. Координация логистики — слой, который пытается сделать это обещание надёжным, несмотря на меняющиеся улицы, погоду, события и поведение людей.
ETA — часть продукта: пассажиры решают вызывать ли поездку (или отменить) исходя из них, водители решают, стоит ли браться за поездку. Чтобы оценить время прибытия и продолжительность, система объединяет карту с реальными сигналами — недавними скоростями по сегментам дороги, типичными замедлениями по времени суток и текущими событиями (строительство, инциденты, заполнение стадиона).
Маршрутизация — это не только «короче по расстоянию», чаще «быстрее по времени», с постоянными обновлениями при изменении условий. Когда ETA ухудшаются, платформа может менять точки посадки, предлагать альтернативные повороты или обновлять ожидания обеим сторонам.
Даже при хорошей маршрутизации предложению нужно быть рядом со спросом. Перемещение — это когда водители по собственной воле едут в зоны, где вероятность запросов выше. Платформы стимулируют это не только повышением тарифов: теплокарты с зонами активности, подсказки типа «едьте в центр», системы очередей для аэропортов и правила приоритета, поощряющие ожидание в назначенных зонах.
Координация имеет обратную связь: когда много водителей следует одному сигналу, они сами создают трафик и снижают надёжность подачи. Платформа реагирует на город (трафик замедляет ETA), а город реагирует обратно (перемещение водителей меняет трафик). Эта двухсторонняя петля — причина, почему маршрутизация и сигналы перемещения постоянно корректируются, чтобы не погоняться за спросом и не создавать новые узкие места.
Uber не просто матчует однажды — он непрерывно формирует поведение. Малые улучшения (или провалы) накапливаются, потому что каждая поездка влияет на будущие решения людей.
Когда подача быстрая, а цены предсказуемы, пассажиры заказывают чаще. Стабильный спрос делает вождение привлекательным: водители заняты, зарабатывают предсказуемо и тратят меньше времени в простое.
Больше водителей в нужных местах снижает ETA и отмены, что снова улучшает опыт пассажиров. Проще говоря: лучший сервис → больше пассажиров → больше водителей → лучше сервис.
То же самое работает и в обратную сторону. Если пассажиры сталкиваются с повторными отменами или долгим ожиданием, они перестают полагаться на приложение для важных поездок. Они заказывают меньше или открывают сразу несколько приложений.
Меньше запросов снижает предсказуемость заработка водителей, и некоторые уходят с линии или уезжают в другие зоны. Это ухудшает ETA, что увеличивает отмены — и цикл повторяется.
Несколько мгновений отличного сервиса не имеют значения, если средний опыт непоследовательный. Люди планируют по тому, на что они могут положиться. Постоянные ETA и меньше «возможных» исходов (например, отмен в последний момент) формируют привычку — а привычка удерживает обе стороны.
Некоторые зоны попадают в локальный минимум: низкое предложение ведёт к долгому ожиданию, поэтому пассажиры перестают заказывать, и район становится ещё менее привлекательным для водителей. Без внешнего вмешательства — целевых стимулов, умной репозиции или ценовых сигналов — район может оставаться в низкой ликвидности, хотя рядом всё цветёт.
Чаще всего маркетплейс ведёт себя предсказуемо: спрос растёт и падает, водители перемещаются в загруженные зоны, ETA остаются в привычных пределах. «Крайние случаи» — моменты, когда эти паттерны ломаются внезапно и система должна решать при грязных и неполных входных данных.
Спайки из событий (концерты, выход из стадионов), погодные шоки и крупные перекрытия создают синхронизированный спрос и одновременно замедляют посадки и высадки. Сбои приложения или оплаты — другое дело: они не только меняют спрос, но и прерывают каналы обратной связи, которыми платформа «видит» город. Даже мелкие проблемы (дрейф GPS в центре, задержки метро) усиливаются, когда много пользователей испытывают их одновременно.
Координировать сложнее всего, когда сигналы задержаны или частично доступны. Доступность водителей может казаться высокой, но многие из них застряли в пробке, в поездке или не готовы принимать заказы с неопределённым доступом. Всплеск запросов может прийти быстрее, чем система подтвердит предложение, поэтому краткосрочные прогнозы могут переоценить или недооценить реальность.
Платформы обычно используют набор рычагов: замедление роста спроса (ограничение повторных запросов), приоритизация определённых типов поездок и адаптация логики сопоставления, чтобы снизить отток (лишние отмены и переназначения). Некоторые стратегии фокусируются на сохранении сервиса в меньшей зоне, а не на размывании по всему городу.
Когда условия нестабильны, важна понятная коммуникация для пользователей: реалистичные ETA, прозрачные изменения цен и понятные правила отмены. Даже небольшие улучшения в ясности снижают «паническое нажатие», лишние отмены и повторные запросы — поведение, которое может усилить стресс в сети.
Когда платформа может в реальном времени направлять машины и устанавливать цены, она также влияет на то, кто и где получает сервис и по какой цене. Поэтому «улучшить систему» нельзя свести к одной метрике.
Проблемы справедливости проявляются в повседневных результатах:
Любой алгоритм ценообразования или диспетчеризации неявно жертвует одними целями ради других, например:
Невозможно максимизировать всё одновременно. Выбор того, что оптимизировать, — это столько же политическое решение, сколько техническое.
Данные поездок чувствительны: они могут раскрыть дом/работу, рутины и посещения приватных мест. Ответственный подход включает минимизацию данных (собирать только необходимое), ограничение хранения, контроль доступа и аккуратное использование точных GPS-треков.
Стремитесь к мышлению «доверительная система»:
Если убрать бренд и приложение, эффект «программируемого города» Uberа держится на трёх непрерывных и усиливающих друг друга рычагах: ликвидность, ценообразование и диспетчеризация/логистика.
1) Ликвидность (плотность в нужное время/место). Больше ближайшего предложения сокращает время ожидания, увеличивает завершённые поездки, привлекает больше пассажиров и удерживает водителей — самоподдерживающаяся петля.
2) Ценообразование (навигация поведения). Динамические цены — это не только «более высокие тарифы», это способ смещать стимулы, чтобы поставка шла в зону пиков, а пассажиры проявляли срочность. При правильной настройке цены защищают надёжность; при ошибке — вызывают отток и регуляторные риски.
3) Диспетчеризация и логистика (максимально эффективно использовать имеющееся). Сопоставление, маршрутизация и репозиционирование превращают сырое предложение в пригодное. Лучшая ETA и умные матчи фактически «создают» ликвидность, снижая время простоя и отмены.
Когда они согласованы, возникает простой флайвил: лучшее сопоставление → быстрее подачи → выше конверсия → больше заработка/доступности → больше пассажиров → больше данных → ещё лучшее сопоставление и ценообразование.
Ту же модель можно применить к доставке еды, фрахту, бытовым услугам и даже к записям по времени:
Если хотите углубиться в измерения и материалы по ценообразованию, см. /blog/marketplace-metrics и /blog/dynamic-pricing-basics.
Если вы строите маркетплейс с похожими рычагами — реальное состояние, правила ценообразования, рабочие процессы диспетчеризации и ограждения — основная проблема обычно в скорости: превратить идеи в рабочий продукт достаточно быстро, чтобы итерации по поведению и метрикам были возможны. Платформы вроде Koder.ai помогают командам прототипировать и выпускать такие системы быстрее, позволяя строить бэк-офисы (часто на React), бэкенды на Go/PostgreSQL и даже мобильные приложения через чат-управляемые рабочие процессы — полезно, когда нужно протестировать логику диспетчеризации, панели экспериментов или конфигурацию правил ценообразования без переписывания всей инфраструктуры.
Что измерять: ETA подачи (p50/p90), fill rate, процент отмен (по сторонам), загрузку/время простоя, rate принятия, заработок в час, распределение множителей цен, долю повторных пользователей.
Что настраивать: правила сопоставления (приоритет, батчинг), подсказки по репозиционированию, дизайн стимулов (бонусы vs множители) и «ограждения», предотвращающие крайние результаты.
Что объяснять: что вызывает изменения цены, как защищается надёжность и что могут сделать пользователи (подождать, пройтись, запланировать, сменить тариф). Чёткие объяснения снижают страх, что «алгоритм случайный» — а доверие само по себе является формой ликвидности.
«Программируемый» город — это не буквальное ПО. Речь о городе, в котором платформа может:
Сервис по вызову такси хорошо иллюстрирует идею: он превращает уличный хаос в машиночитаемые сигналы и непрерывно действует по ним.
Программируемая сеть — это сочетание:
Ключевая идея — решения обновляются постоянно по мере поступления новых сигналов.
Потому что входные данные нестабильны и частично зависят от людей:
Платформа не просто прогнозирует город — она реагирует в реальном времени и при этом не должна создавать новых проблем (например, резких колебаний цен или неправильного перераспределения водителей).
Ликвидность — это наличие достаточного ближайшего числа водителей и пассажиров, чтобы совпадения происходили быстро и надежно.
Это не «много водителей по всему городу», а плотность на уровне блока, потому что расстояние увеличивает:
Низкая ликвидность обычно проявляется так:
Эти симптомы взаимосвязаны — разные лица одной локальной нехватки.
Динамическое ценообразование лучше рассматривать как инструмент балансировки, а не просто способ «больше взимать». Когда спрос превышает предложение, более высокая цена может:
Когда несоответствие снижается, цены могут вернуться к норме.
Ограждения (guardrails) — это дизайн-решения, которые защищают доверие и предотвращают вред. Частые примеры:
Цель — сохранить работоспособность рынка и предсказуемость для пользователей.
Это не всегда «ближайший водитель побеждает». При сопоставлении учитывают:
Хорошее сопоставление улучшает текущую поездку, не ухудшая следующие несколько минут работы системы.
Платформа формирует «реальное состояние» из сигналов вроде:
Решения часто принимаются пакетно (каждые несколько секунд) по ячейкам карты и за короткие временные окна, чтобы уменьшить шум.
Платформы, оптимизируя скорость и доходность, могут создавать нежелательные последствия. Главные проблемы:
Практические меры: аудит на предмет различий в обслуживании, минимизация и ограничение хранения данных, мониторинг аномалий и пути эскалации для ручного вмешательства.
