惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
博客园 - 司徒正美
Last Week in AI
Last Week in AI
Recent Announcements
Recent Announcements
Y
Y Combinator Blog
博客园 - 聂微东
M
MIT News - Artificial intelligence
博客园_首页
Jina AI
Jina AI
博客园 - 叶小钗
酷 壳 – CoolShell
酷 壳 – CoolShell
H
Hackread – Cybersecurity News, Data Breaches, AI and More
J
Java Code Geeks
F
Fortinet All Blogs
aimingoo的专栏
aimingoo的专栏
小众软件
小众软件
Vercel News
Vercel News
The Cloudflare Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
云风的 BLOG
云风的 BLOG
N
Netflix TechBlog - Medium
B
Blog
Google DeepMind News
Google DeepMind News
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
GMV — это не главная метрика маркетплейса. Метчинг плотно...
Власенко Дмитрий (CTO Statzilla) · 2026-05-13 · via Все публикации подряд на Хабре

Средний

5 мин

6.4K

Если вы занимаетесь аналитикой в маркетплейсах, вы знаете, что GMV (Gross Merchandise Value) — это «священная корова». Она понятна: сколько денег прошло через платформу. Но у GMV есть критический изъян: она показывает только то, что уже случилось. Она не видит упущенных возможностей, разочарованных пользователей и зон, где ваш бизнес вот-вот сломается.

Предлагаю взглянуть на маркетплейс как на систему мэтчинга (совмещения) и вывести North Star Metric, которая реально управляет ростом. Причем стоит сказать, что маркетплейс это не только Amazon, Ozon и WB, это YouTube, это Я.Такси, это Авито и все прочие площадки, задача которых в совмещении спроса и предложения, и все ниже вполне годится и для них.

Почему GMV — это «плохо»?

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

Но как только один продавец хлеба перейдет в нужную зону — GMV вырастет.

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

Шаг 1. Карта потребностей

Любая площадка — это пространство параметров\mathcal{X}. Для товара это категория, цена, срок доставки. Для контента — жанр, длительность, тема.

Давайте представим это пространство как карту.

  • Поставим точку там, где возникла потребность (кто-то ввел запрос в поиск).

  • Чем больше таких точек в одном районе, тем выше там Плотность Спроса \rho_D(x, t).

Это наше первое «облако». Оно показывает, где сейчас «болит» у пользователей.

Шаг 2. Карта возможностей

В этом же пространстве мы рисуем второе облако — Плотность Предложения \rho_S(x, t). Это товары на складах или ролики в базе.

Идеальный маркетплейс — это когда два этих облака идеально накладываются друг на друга. Но в реальности они часто смещены.

Шаг 3. Логика «Бутылочного горлышка»

Теперь самое важное. Ценность площадки рождается только там, где спрос и предложение встретились.

Но объем этой ценности всегда ограничен самым слабым звеном.

  • Если 1000 человек хотят купить iPhone, а у вас их всего 2 — вы совершите 2 сделки. Лимитирует предложение.

  • Если у вас на складе 1000 iPhone, но купить их хотят 2 человека — вы всё равно совершите 2 сделки. Лимитирует спрос.

Математически это «правило минимума»: в каждой точке пространства мы берем \min(\rho_D, \rho_S). Это и есть наш объем потенциальных сделок.

Шаг 4. Фактор Качества (Функция трения)

Даже если покупатель и товар встретились, сделка может сорваться из-за подводных камней на вашей платформе. Мы называем это Трением или Качеством сервиса Q(x, t).

Это вероятность того, что мэтч превратится в успешную покупку. Q — это число от 0 до 1, и оно складывается из конкретных «болей»:

  1. Скорость: Если товар нужен завтра, а приедет через неделю — Q падает.

  2. Доверие: Если карточка товара плохая или мало отзывов — Q падает.

  3. Брак и возвраты: Если товар приехал битым, сделка «откатывается». Это тоже трение.

Мы можем представить Q как штраф: чем выше трение (задержки, плохой UI), тем меньше полезного объема мы получаем от встречи спроса и предложения.

Традиционные подходы пытаются измерить это через коэффициент конверсии (CR) или время до транзакции. Однако для более глубокого анализа можно декомпозировать Q через модель штрафов. Определим вектор независимых факторов трения: \mathbf{f}(x, t) = [f_{delay}, f_{UI}, f_{quality}, \dots], где:

  • f_{delay} — временное трение (время доставки, ожидания ответа или загрузки контента).

  • f_{UI} — информационное трение (плохое оформление карточек, сложность интерфейса, отсутствие отзывов).

  • f_{quality} — риск возврата или брака (вероятность того, что сделка будет «откачена» после совершения).

Функция качества можно определить через экспоненциальное затухание, где \mathbf{w} — вектор весов, отражающий чувствительность платформы к конкретному виду трения :

Q(x, t) = \exp(-\mathbf{w}^T \cdot \mathbf{f}(x, t))

Эта формулировка позволяет интерпретировать Q как потенциал «пропускания» спроса через фильтры платформы. Если трение в точке x бесконечно велико (например, доставка невозможна), то Q \to 0, и даже при наличии спроса и предложения полезная работа системы обнуляется.

Итоговая метрика: Поверхностный интеграл

Сложим всё вместе. Наша North Star Metric (\Phi) — это сумма (интеграл) всех успешно закрытых потребностей по всей карте параметров:

\Phi(t) = \int_{\mathcal{X}} Q(x, t) \cdot \min(\rho_D(x, t), \rho_S(x, t)) \, d\mu(x)

Что нам это дает? Это не просто цифра. Это объем сопряжения потребностей.

Почему эта метрика «умнее» GMV?

Она превращает сухую статистику в карту действий для продукта. Если взглянуть на подынтегральное выражение, то мы увидим две критические зоны, к которые GMV практически слеп. ПустьG(x, t)это функцию Дефицита

1. Поиск «Черных дыр» спроса

Это области, где пользователи ищут, но не находят.

G_{supply}(x, t) = \max(0, \rho_D(x, t) - \rho_S(x, t)) \cdot Q(x, t)

Если в какой-то точке x (например, категория «крафтовые лампы в стиле киберпанк» или контент про «книга про квантовую топологию на латыни») это значение высоко, значит, вы теряете деньги.

Действие: Идем в отдел продаж/закупок и говорим: «Нам нужны поставщики вот в этой конкретной координате эмбеддинга».

2. Зоны чрезмерного трения

Это области, где и спроса, и предложения много, но «метча» не происходит из-за низкого Q.

G_{friction}(x, t) = \min(\rho_D, \rho_S) \cdot (1 - Q(x, t))

Это идеальное место для А/Б теста. Здесь любой сдвиг Q вверх даст взрывной рост \Phi.

Действие: Здесь, слишком сложный процесс выбора или проблемы с логистикой именно этих габаритов, улучшаем сервис

3. Связь с A/B тестами: чувствительность и градиентный спуск

Одной из самых болезненных проблем в продуктовой аналитике является низкая чувствительность классических метрик в A/B тестах. Тесты часто «не прокрашиваются» из-за огромной дисперсии средних чеков или долгого цикла принятия решения.

Предлагаемая интегральная метрика \Phi обладает встроенной высокой чувствительностью поскольку он локальный. Когда мы вносим изменение в продукт (например, ускоряем загрузку карточки товара), мы фактически изменяем трения в определенных точках: \Delta f(x). Изменение главной метрики оценивается через градиент:

\Delta \Phi \approx \int_X \left( \frac{\partial Q}{\partial \mathbf{f}} \cdot \Delta \mathbf{f} \right) \cdot \min(\rho_D, \rho_S) \, d\mu(x)

По итогу мы видим, что тест «прокрасился» не просто «в среднем по больнице», а именно в тех точках x, где \min(\rho_D, \rho_S) был высок (то есть там, где был потенциал, готовый к транзакции, но оставался скован трением).

Но самая вишенка на торте это Прогноз потенциала - мы можем посчитать \frac{\partial \Phi}{\partial w_j} — это покажет, улучшение какого параметра (доставки, качества контента или цены) даст максимальный прирост всей системе. Это буквально карта приоритетов бэклога.

Опыт индустрии: Uber и Airbnb

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

Uber: Управление ликвидностью через перемещение водителей

Uber рассматривает город не как единый рынок, а как динамическое поле плотностей. Проблема дефицита машин в аэропортах в вечернее время — это классическая «черная дыра» предложения (\rho_D \gg \rho_S). Платформа использует динамическое ценообразование как инструмент управления: высокая цена в дефицитной зоне «втягивает» туда водителей из зон профицита, восстанавливая баланс. Это классический пример максимизации интеграла \Phi через изменение предложения.

Airbnb: Поле листингов

Airbnb оценивает LTV каждого нового листинга через призму его инкрементальности. Если новый дом появляется в районе, где спрос уже полностью «накрыт» существующим предложением, его вклад в интеграл\Phiбудет минимален из-за оператора min. Система поощряет появление уникальных объектов (например, пет-френдли листинги), которые закрывают специфические сегменты спроса, где\rho_D > \rho_S, тем самым реально увеличивая общую плотность спроса.

Вместо вывода

GMV — это производная метрика. Она лишь следствие того, как соотносятся «облака» спроса и предложения и насколько эффективно работает функция Q.

Если вы хотите вырастить GMV, вы обязаны либо расширять площадь соприкосновения \min(\rho_D, \rho_S), либо «латать» функцию качества Q.

Интеграл дает нам прогнозный GMV. Если сегодня ваш интеграл \Phiвырос (например, вы завезли товар в дефицитную нишу), то реальный GMV догонит его завтра-послезавтра, когда пользователи обнаружат это предложение. Это делает вашу метрику опережающим индикатором, в то время как классический GMV всегда запаздывающий.

А что дальше?

На практике для перехода на эти рельсы, конечно нужно выполнить не мало подготовительной работы. Каждое действие пользователя (поиск, клик, просмотр) и каждая единица предложения (товарный остаток, листинг) переводится в латентное пространство с помощью нейросетей типа CLIP. Дискретные точки клиентов и товаров переводятся в непрерывные функции плотности через (Kernel Density Estimation — KDE), над которыми можно производить математические операции. Если будет интерес к теме, то в следующей статье разберем эту техническую реализацию.

Дмитрий Власенко
технический директор Statzilla