Marketplace-инженерия: метрики для двусторонних продуктов
Один CTO маркетплейса сказал фразу, которую я слышу регулярно: «Supply-команда релизит быстро, demand-команда релизит быстро, а GMV стоит». Оба DORA-дашборда были зелёными. Matching-движок — нет. У двусторонних продуктов есть метрический разрыв, которого нет у односторонних SaaS: инженерный выход на одной стороне создаёт бизнес-ценность только в том случае, если ему отвечает выход на другой.
Фреймворк маркетплейсов от a16z ставит liquidity — вероятность того, что листинг реально совершит транзакцию в окне, — на первое место по прогностической силе здоровья маркетплейса. И это инженерный исход, не маркетинговый. Когда P95 поискового запроса растёт на 200ms, конверсия листингов падает измеримо. Когда онбординг продавца занимает 14 дней вместо 4 — кривая роста supply уплощается в пределах квартала.
{/* truncate */}
Чем marketplace-инженерия отличается
Односторонний SaaS релизит фичи одной аудитории и меряет результат в активации, retention и ARPU. Marketplace релизит двум аудиториям одновременно и меряет результат в матченных транзакциях. Провальная модель — асимметрия: фича, которая помогает supply, но не помогает demand (или наоборот), выглядит победой на одной стороне и ломает экономическую петлю в целом.
Три инженерных следствия:
Координация релизов — first-class concern. Изменение ранжирования на demand-стороне может обнулить мерчандайзинговый плейбук на supply-стороне, если продавцы не предупреждены. Deploy independence даёт меньше, чем в одностороннем продукте — всё равно нужны релизные ворота с учётом обеих аудиторий.
Задержка на любой стороне — налог на конверсию. Исследование SOASTA / Akamai установило: каждые 100ms задержки mobile-загрузки режут конверсию на 7%. На маркетплейсах это бьёт дважды — по upload-флоу продавца и по search-флоу покупателя — и эти эффекты компаундируются по воронке.
Trust-and-safety — это инженерная инфраструктура, а не ops-команда. Количество инженеров в модерации, антифроде и диспутах на маркетплейсе — структурная стоимость, и она растёт вместе с GMV, не с headcount. Опубликованные инженерные блоги Airbnb, Etsy и Uber описывают T&S-платформы, которые к пятому году больше core product platform.
На бумаге supply и demand pipeline выглядят симметричными. На практике они расходятся по failure modes и деплой-cadence.
5 метрик, которые важны на двусторонних продуктах
1. Соотношение деплоев supply / demand
Смотрим, какая доля инженерных деплоев идёт в supply-side сервисы vs demand-side. Здоровые маркетплейсы обычно попадают в диапазон 40/60 — 60/40. Если одна сторона проваливается ниже 30%, вы компаундируете дисбаланс, который проявится в liquidity-метриках через 2-3 квартала.
| Зрелость платформы | Supply-side deploys | Demand-side deploys |
|---|---|---|
| Pre-liquidity (год 1-2) | 55-70% | 30-45% |
| Liquidity-stable (год 3-5) | 40-55% | 45-60% |
| Category-leader (год 6+) | 35-45% | 35-45% (остальное — T&S/platform) |
Асимметрия в ранние годы корректна — supply обычно hard side — но после выхода на ликвидность устойчивый перекос это запах масштабирования.
2. Matching-latency P95
Не search latency. Matching latency: время от запроса покупателя до ранжированного списка релевантных listings. Сюда входят парсинг запроса, ретрив из инвертированного индекса, re-ranking (часто ML), мерчандайзинг и сборка ответа. Бенчмарки:
| Вертикаль маркетплейса | P95 приемлемо | P95 убивает конверсию |
|---|---|---|
| Ride-sharing (real-time) | < 300ms | > 800ms |
| E-commerce search | < 400ms | > 1.2s |
| Services marketplace | < 600ms | > 2s |
| B2B / enterprise | < 1s | > 3s |
Порог «убивает конверсию» — там, где drop-off покупателей превышает 5% по сравнению с сессиями median-latency. Чтобы это инструментировать, нужен session-level tracing по всему поисковому стеку, а не SLO одного сервиса.
3. Время онбординга продавца
Таймер стартует, когда новый продавец попал на форму регистрации. Останавливается, когда у него есть хотя бы один дискаверабельный листинг. Это преимущественно инженерная метрика — KYC-пайплайны, listing-quality checks, модерация изображений, маппинг категорий — и самая забытая на дашбордах маркетплейсов.
DoorDash публично отчитался: сокращение онбординга мерчантов с 14 дней до 4 дней дало +31% GMV на мерчанта в первые 90 дней. Инженерная работа почти вся была в verification + catalog-ingestion.
4. T&S MTTR (контент / фрод / диспуты)
Обычный MTTR — скорость восстановления системы после инцидента. T&S MTTR — скорость удаления вредного контента, реверса фродовой транзакции, разрешения диспута. Наш обзор MTTR аргументирует: скорость восстановления важнее частоты предотвращения. На маркетплейсах это правда вдвойне — систем с нулевым фродом не существует.
Целевые значения (публичные post-mortem + industry отчёты):
| Тип T&S события | Target MTTR | Red-flag MTTR |
|---|---|---|
| Контрафактный листинг (жалоба) | < 2ч | > 24ч |
| Подозрение на payment fraud (авто) | < 10мин | > 2ч |
| Взлом аккаунта (жалоба) | < 30мин | > 4ч |
| Диспут (покупатель vs продавец) | < 72ч | > 14 дней |
Инвестиция, которая двигает эти цифры, обычно — workflow-тулинг для T&S ops, а не только ML. Большинство маркетплейсов недоинвестируют здесь до первого публичного инцидента.
5. Время от листинга до первой транзакции
Supply-side funnel-метрика, преимущественно инженерная. С момента, когда продавец загрузил валидный листинг, сколько проходит до первой совершённой транзакции этого листинга? Распределение длиннохвостое, поэтому полезные статистики — медиана (среднему продавцу важно, найдут ли его типичный товар) и P90 (длина хвоста для ненайденных листингов).
Liquidity бессмысленна в агрегате, если 30% листингов не получают ни одного просмотра. Инженерные команды, владеющие search recall, cold-start ранжированием и merchandising placement, двигают эту метрику. Квартальный обзор распределения «листинг → первая транзакция» ловит дрейф модели ранжирования раньше, чем CTR-дашборды.
Как compliance и масштаб меняют toolchain
Маркетплейсы, работающие в нескольких юрисдикциях, сталкиваются с компаундирующимся инженерным грузом:
Фрагментация платежей. Разделение транзакции между покупателем, продавцом, платёжной комиссией, налогом и (часто) локальным compliance-эскроу — это 5+ journal-entries на заказ. Stripe Connect, Adyen MarketPay, Mangopay существуют потому, что наивный паттерн «зарядить покупателя, выплатить продавцу» ломается при работе в нескольких налоговых юрисдикциях.
Резидентность данных для отзывов и PII. Отзывы, сообщения в диспутах, KYC-документы — персональные данные. GDPR, CCPA, казахстанский Закон о персональных данных, российский 152-ФЗ задают разные правила резидентности. Маркетплейсы на масштабе часто запускают region-partitioned БД — и платформа метрик, которая меряет эти команды, должна уметь те же ограничения. Это одна из практических причин, по которым маркетплейс-клиенты в PanDev Metrics чаще выбирают on-prem Docker или Kubernetes-развёртывание вместо облака.
Search relevance — инженерная дисциплина, а не data-science проект. Разрыв между «мы выкатили ML-модель» и «детекция дрейфа ранжирования дежурит on-call» — 12-18 месяцев инженерных инвестиций. Команды, которые пропускают этот этап, получают случайные скачки и провалы конверсии, которые не могут объяснить.
Типовой профиль marketplace-команды
| Параметр | Горизонтальный (год 4-7) | Вертикальный (год 4-7) |
|---|---|---|
| Размер команды | 150-400 инженеров | 40-150 инженеров |
| Supply-side sub-team | 25-40% eng | 30-45% eng |
| Demand-side sub-team | 25-35% eng | 20-30% eng |
| Trust & safety eng | 10-15% eng | 8-12% eng |
| Platform / infra | 15-25% eng | 15-20% eng |
| Deploy cadence | Ежедневно per service | Ежедневно per service |
| Стек | Go или Java сервисы, Elasticsearch/OpenSearch, Kafka, Postgres + Redis, ML-платформа (Kubeflow / внутренняя) |
Вертикальный маркетплейс (Reverb, Chewy, StockX) может работать на меньшей команде, потому что сложность каталога ограничена. Горизонтальные (Ozon, Wildberries, eBay, Etsy, Amazon) абсорбируют полную сложность category-agnostic платформы и платят за это headcount'ом.
Контрарианское утверждение
Большинство marketplace-лидеров переоптимизируют под сторону запуска и недоинвестируют в зрелую сторону. Founder-плейбук говорит «supply — hard side» — это правда в первый год. К четвёртому году hard side обычно T&S на масштабе. Команды, которые всё ещё организованы вокруг бинаря supply/demand в этот момент, недоукомплектовывают T&S-инвестицию, которая предотвращает один публичный инцидент, убивающий доверие маркетплейса на год.
Те, кто вырываются вперёд, реорганизуются примерно на 100 инженерах: supply, demand и trust-and-safety как равноправный пиллар, со своими OKR и своим deploy-cadence. Остальные обнаруживают необходимость во время первой крупной фрод-волны.
Честный лимит
Наш датасет инженерной телеметрии скошен в сторону B2B SaaS и аутсорс-агентств. Значимый сигнал есть по ~15 marketplace-командам в Казахстане, России и СНГ плюс несколько в ЕС. Бенчмарки по matching latency и T&S MTTR выше — смесь наших данных, опубликованных инженерных блогов (Airbnb, DoorDash, Uber) и датасета a16z. Команды в гиперлокальных геометриях, регулируемых вертикалях (медицинские или финансовые маркетплейсы) или по-настоящему глобальных горизонтальных платформах увидят материально другие формы; используйте цифры выше как стартовую точку для собственных измерений, а не как универсальный закон.
Где PanDev Metrics встраивается
Marketplace-команды на 100+ инженерах обычно имеют классическую проблему: агрегированные DORA-показатели скрывают реальность по командам. IDE heartbeat-телеметрия плюс Git и task-tracker сигналы дают дашборды по пилларам (supply / demand / T&S / platform) из одного датасета — без того, чтобы каждая команда инструментировала себя отдельно. Единственное требование к setup — имена веток с task ID — большинство marketplace-команд уже соблюдают это, потому что изменения в каталоге или ордер-системе по умолчанию аудитно-чувствительные.
Дополнительное чтение
- DORA Metrics: полный гайд для инженерных лидеров — односторонний baseline, который надо сегментировать по marketplace-пилларам
- E-Commerce: как ускорить доставку фич перед high season — смежный retail-контекст с пересекающимися demand-side ограничениями
- MTTR: почему скорость восстановления важнее частоты предотвращения — recovery-focused подход, прямо применимый к T&S response times
- External: a16z Marketplace 100 methodology — самый чистый публичный фреймворк ранжирования marketplace health