Аналіз якості виконання замовлень у Stores: з чого складається Order Defect Rate, хто його драйвить, де погіршення, де прогрес, та як Україна виглядає проти ТОП-3 країн Bolt за обсягом Stores.
ODR на рівні ринку виглядає помірно, але тренд негативний, і проблема сконцентрована у кількох grocery-партнерах.
Зважений Order Defect Rate двох live MWB-мереж без VARUS. Це не просте середнє двох брендів, а частка дефектних замовлень LOKO і Рукавички разом.
% замовлень · LOKO + Рукавичка зважено · джерело: Databricks
Order Defect Rate = частка доставлених замовлень, де був хоча б один item defect із впливом на клієнта: quantity, weight або price. Replacement рахується окремою метрикою.
Зміна кількості з впливом на клієнта: товар видалили або зменшили кількість (типово — OOS).
Вагові позиції: фактична вага відрізняється від замовленої з впливом на клієнта.
Підвищення ціни позиції після оформлення замовлення.
Кількість дефектних позицій, шт. · джерело: Databricks (щотижневе оновлення)
% доставлених замовлень · джерело: Databricks (store_*, dish items)
Три групи поведінки: стабільно високі (VARUS), ті що деградують (KOPIYKA, SANTIM), і ті що покращуються (TAISTRA). LOKO та HOP HEY — референс низького ODR при великому обсязі.
12 тижнів · джерело: Databricks weekly Order Defect Rate per brand
Одна методологія Databricks на всі таблиці: item-level метрики (A) і повний ТОП-15 за обсягом (B), включно з партнерами з нульовим ODR.
| Бренд | Items | ODR сер. | ODR посл. | Δ 12 тиж. | Qty % | Item repl % | Weight % | Order repl % | Статус |
|---|
Qty / Item repl / Weight — item-level (частка позицій). ODR та Order repl — order-level (частка замовлень). Тому Order repl завжди вищий за Item repl.
| Бренд | Orders 12 тиж. | ODR % | Qty % | Weight % | Price % | Replacement % |
|---|
Єдине визначення ODR = qty ∪ weight ∪ price на рівні замовлення. 7 із 15 партнерів мають ODR 0% — це переважно алкогольний / напої формат з вузьким асортиментом і високою наявністю.
Пріоритезація за впливом на ринковий ODR: обсяг × рівень дефектів × напрям тренду.
| Партнер | Проблема | Що робити |
|---|
Інтерактивний drill-down для 8 партнерів із найбільшим впливом. Оберіть партнера й категорію, щоб побачити конкретні SKU та тип сигналу.
| Категорія | Orders | Внесок в ODR | Qty % | Repl % | Weight % | Price % | Сигнал |
|---|
| SKU / товар | Категорія | Items | Affected orders | Qty % | Repl % | Weight % | Price % | Сигнал |
|---|
OOS-сигнал — аналітичний proxy, а не підтверджений статус запасу: quantity adjustment з eater impact та/або replacement. Відсотки SKU розраховані від active items.
Магазини з найвищим сумарним рівнем quantity adjustment та replacement.
| Магазин | Items | Qty % | Repl % |
|---|
ТОП-3 країни за обсягом Stores-замовлень за ті самі 12 тижнів. ODR порахований однаковим способом (qty ∪ weight ∪ price на рівні замовлення) для коректного порівняння. Для кожної країни — ТОП-5 партнерів за обсягом і середній ODR по них.
% замовлень · «excl Bolt Market» = без власного 1P, який має ODR ≈ 0 і занижує середнє
Частка delivered Stores-замовлень хоча б з одним replacement. TOTAL є зваженим результатом усіх сегментів, а не показником Enterprise.
| Сегмент | Orders | Частка UA Stores | Orders з replacement | Order Replacement Rate |
|---|
Послідовність важлива: спочатку почистити метрику, потім тиснути на операційку.
Розгорніть метрику, щоб побачити визначення, як вона рахується та які дії на неї впливають.
Визначення. Частка доставлених замовлень, у яких була хоча б одна позиція з дефектом, що вплинув на клієнта: зміна кількості, зміна ваги або підвищення ціни. Технічні правки без впливу на клієнта не рахуються.
Формула. orders with (quantity defect ∪ weight defect ∪ price defect) ÷ delivered orders.
Як покращити: real-time наявність товарів (OOS sync), приховування недоступних SKU, навчання пікерів, чистка каталогу від службових позицій (пакети, збори), буфер запасу на топ-SKU.
Визначення. Частка активних позицій, де кількість змінили з впливом на клієнта — зазвичай товар видалили або зменшили кількість через відсутність на полиці.
Чому важливо. Це 66.5% усіх дефектів в UA, тобто головний важіль впливу на ODR.
Як покращити: інвентаризація високооборотних SKU, автоматичне приховування OOS, пороги мінімального залишку, окремий контроль напоїв та свіжих категорій.
Визначення. Item-level: частка позицій, замінених іншим SKU. Order-level: частка замовлень, де була хоча б одна заміна. Order-рівень завжди вищий, бо одна заміна «маркує» все замовлення.
Особливість. Replacement не входить в ODR. Партнер може мати низький ODR і високий replacement (HOP HEY: ODR 5.1%, item repl 15.8%) — клієнт усе одно отримує не те, що замовив.
Як покращити: матриця допустимих замін з підтвердженням клієнта в апці, перевірка чи «replacement» не є артефактом меню (комбо, модифікатори, вагові позиції).
Визначення. Частка вагових позицій, де фактична вага відхилилася від замовленої з впливом на клієнта — недоважування або переплата.
Як покращити: калібрування ваг у магазинах, зрозумілі одиниці в меню (100 г, 1 кг), фото очікуваної порції, ліміт допустимого відхилення у системі.
Визначення. Частка позицій, де ціна зросла після оформлення замовлення.
Стан в UA. Практично 0% на рівні партнерів. У Румунії — 15.3% і головна складова ODR (Carrefour 58.6%).
Як покращити: синхронізація прайсу POS ↔ Bolt, заборона підвищення ціни після checkout, алерти на розбіжність цін.
Critical — середній ODR ≥30% або суттєва деградація при значному обсязі.
High — ODR 20–30% або нестабільна динаміка на малому обсязі.
Watch / improving — тренд покращується або специфічний патерн (високий replacement при помірному ODR).
Good — ODR <10% на стабільному обсязі.
Період: 12 повних тижнів.
Фільтри: delivered orders, dish items, вертикаль store_*, країна за
dim_provider_v2.country_code.
Джерело: Databricks main.ng_delivery.dim_basket_item_delivery ×
dim_provider_v2. Звіт оновлюється щопонеділка о 10:00 за Києвом.
Обмеження. «Середній ODR топ-5 партнерів» — просте середнє (не зважене на обсяг). Quantity item-rate: чисельник по всіх dish items з eater-impact, знаменник — active items (як у Looker). Обсяги weight/price на графіку — усі відповідні adjustment flags, тож стрибки якості даних видно окремо від ODR.