Чому market basket analysis дає сміття на сирих транзакціях
Market basket analysis ламається не на алгоритмі, а на вході. Транзакції вивантажують із каси як є: у масив потрапляють скасовані чеки, повернення, дублі артикулів, службові рядки на кшталт пакета чи доставки й позиції, розбиті на кілька операцій.
Якщо рахувати правила сполучення товарів за таким набором, модель чесно виносить нагору те, що лежить у кожному другому чеку, — і замість керованих сполучень віддає очевидні «хліб і молоко».
Ціна помилки не в дивних числах, а у втраті довіри до інструменту. Категорійний менеджер один раз відкриває звіт, бачить тривіальні пари й більше ним не користується — рішення про викладку та перехресні пропозиції знову ухвалюються на відчуттях.
Підготовка даних тут важливіша за вибір міри цікавості. Повернення й скасування прибирають, дублі артикулів склеюють, ваговий товар приводять до зіставних одиниць, сервісні рядки відокремлюють від товарних, а межі кошика відновлюють, якщо чек розбитий на кілька операцій.
Лише після цього аналіз кошика покупця показує поведінку, а не артефакти обліку, і пара перестає бути наслідком того, що обидва товари просто часто купують.
Розбираємо, як це закривається: які перевірки якості даних про замовлення ставимо до розрахунку, за якими ознаками відсікаємо статистичний шум і як переконатися, що знайдені сполучення взагалі можна перетворити на дію.
Що змінюється на полиці та у звітах після впровадження
Перескладання правил сполучень перестає бути квартальним проєктом. Раніше вивантаження кошиків, чищення та перерахунок займали дні ручної роботи аналітика, тому правила застарівали між запусками.
Тепер розрахунок іде за розкладом на свіжих транзакціях, і нова партія сполучень з’являється у звітах того самого дня.
Другий зсув — частка ручної роботи з асортиментом. Категорійний менеджер більше не зводить пари в таблицях: спірні сполучення надходять із числом кошиків, часткою спільних покупок та оцінкою стійкості. Ручною залишається перевірка на полиці й рішення про викладку — те, що розрахунок закрити не може.
Третій — стійкість рекомендацій. Правило, що виросло на кількох випадкових чеках, відсікається за порогами підтримки й достовірності, тому в робочі рекомендації не потрапляє разовий сплеск.
Окремо перевіряємо, як зв’язок тримається на різних періодах: якщо під час розбиття історичних даних він розпадається, правило не доходить до викладки.
На полиці це видно як перестановку: пов’язані товари стають поруч, доповнювальні потрапляють у зону імпульсу, невикористовувані зв’язки виходять із плану.
У звітах змінюється набір метрик — замість частки товару у виторзі на перший план виходять частота спільних покупок і покриття кошика.
Що перевіряємо перед передачею: відтворюваність розрахунку на історичних даних, частку правил, що пройшли пороги, час повного перерахунку та список пар, які менеджер підтверджує вручну.
Це і є список приймання — за ним видно, чи працює модель на ваших даних, а не на демонстраційному наборі.
Режими розрахунку market basket: пакетний, потоковий, гібридний
Частота оновлення правил задає одразу дві речі: користь видачі та навантаження на сховище. Перераховувати зв’язки на кожному новому кошику сенсу немає — на короткому вікні вони шумлять, а рекомендації стрибають від сесії до сесії.
Занадто рідкий перерахунок дає стійкі правила, але пропускає зміну попиту: новинки й сезонні позиції випадають із видачі на дні.
Режим обирають за двома питаннями: як швидко змінюється асортимент і чи потрібна реакція всередині поточної сесії покупця. Нижче — три схеми, між якими вибір відбувається на практиці.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Пакетний перерахунок правил | Асортимент змінюється повільно, рішення потрібні до ранку: поповнення полиці, категорійні звіти | Правила живуть до наступного вікна, реакція на сплеск попиту — лише після перерахунку |
| Потоковий розрахунок кошиків | Потрібна реакція всередині сесії: допродаж, підказка в кошику, динамічні набори | Довге вікно дороге за ресурсами, зв’язки на малій вибірці нестабільні — потрібні пороги підтримки |
| Гібридний режим | Великий каталог: стійкі зв’язки перераховуються рідко, швидкі підказки потрібні часто | Два шари правил узгоджують за ключами товарів, складніше налагоджувати й пояснювати видачу |
На старті майже завжди беруть пакетний перерахунок: він передбачуваний і легко перевіряється на історичних даних. Потоковий вмикають, коли з’являється сценарій, де важлива свіжість, — інакше ускладнення не окупається.
У гібридному режимі правила двох шарів зіставляють за ключами: якщо ключі розійшлися, видача починає суперечити сама собі.
«Пакетний перерахунок закриває більшість задач; до гібрида переходять, коли з’являється метрика, яку не можна порахувати вночі» — з практики наших впроваджень у ритейлі
Як ми впроваджуємо кошиковий аналіз: етапи робіт
Впровадження кошикового аналізу (market basket analysis) починається не з моделі, а з даних про замовлення. Поки не перевірені повнота чеків і розмітка товарів, будь-які асоціативні правила описуватимуть шум. Нижче — порядок робіт, який ми проходимо разом із командою замовника.
- Аудит даних про замовлення. Звіряємо склад чеків, ідентифікатори товарів і категорій, розбираємо дублі, скасування, повернення та вагові позиції, оцінюємо глибину історії. Підсумок — звіт про придатність даних і перелік прогалин, які потрібно закрити до розрахунку.
- Схема розрахунку. Узгоджуємо рівень аналізу — чек чи замовлення, вікно історії, мінімальні пороги підтримки й достовірності. Фіксуємо, які зв’язки вважаємо значущими, а що йде у винятки.
- Налаштування розрахунку правил. Збираємо регулярний перерахунок: повний прогін за накопиченою історією та інкрементальний за новими чеками. Результат складається у вітрину, звідки його забирають рекомендації, розсилки та інтерфейси.
- Перевірка правил на історії. Проганяємо зв’язки на минулих періодах: скільки підтвердилося, скільки виявилося хибним, що розсипалося на сезонних сплесках. Нестійкі комбінації відсікаємо до запуску.
- Вбудовування в процеси. Правила підключаємо туди, де ухвалюються рішення: підбір супутніх товарів, навігація каталогом, складання наборів. За зворотним зв’язком коригуємо пороги та склад винятків.
- Передача рішення команді. Віддаємо конфігурації, схему даних, регламент перерахунку та розбір типових збоїв, навчаємо фахівців замовника — далі система працює без нашої участі.
Що передаємо на руки: правила, схеми, регламенти
Проєкт із market basket analysis закінчується не списком частих пар товарів, а набором артефактів, за якими систему можна розвивати без нас.
Передаємо все у відтворюваному вигляді: той самий розрахунок на нових даних дає зіставний результат, а логіка відбору пояснюється порогами, а не усними домовленостями.
- Документація щодо рішення — описи сутностей: кошик, транзакція, товарна позиція, правило, сегмент покупця; словник метрик із формулами.
- Правила відбору сполучень — виставлені пороги підтримки й достовірності, фільтри за категоріями, стоп-листи та винятки службових позицій.
- Схема даних — структура вітрини транзакцій, джерела, вимоги до повноти й частоти надходження, обробка повернень і вагових товарів.
- Регламент перерахунку — тригери й періодичність, порядок прогону в разі накопичення нових транзакцій і зміни довідників.
- Контроль стійкості правил — перевірка зв’язок на кількох періодах і точках продажів, відсів випадкових збігів, журнал причин винятку.
- Регламент оновлення довідників — фіксація дати актуальності, контроль частки нерозпізнаних позицій у кошиках і поріг, за якого правило йде на перегляд.
- Звітність і передача — склад регулярних вивантажень, опис вітрин для аналітиків, порядок доступу до середовища розрахунку та порядок супроводу.
Кейс: як скоротили порожні кошики та рідкісні сполучення
До: інтуїція замість даних
Мережа магазинів, кілька десятків точок, асортимент у тисячі позицій. Сполучення товарів у чеку розбирали вручну: категорійні менеджери спиралися на досвід і на продажі окремих позицій, а не на спільні покупки.
У результаті 44% чеків залишалися порожніми кошиками з однією позицією, а рідкісні сполучення товарів із сильним зв’язком жодного разу не потрапляли в акцію — їх просто не бачили.
Що змінили і що отримали
Зібрали історію чеків за довгий період і порахували правила асоціацій за підтримкою, достовірністю та силою зв’язку. Відсіяли шум: сезонні сплески, пари, склеєні однією знижкою, позиції без маржинальності.
На виході — ранжований список зв’язок, який пішов у категорійний менеджмент як план викладки та спільних акцій; ефект перевіряли на зіставних за трафіком точках.
Впровадження скоротило частку чеків з однією позицією з 44% до 31%, середня кількість позицій у чеку зросла на 0,6, а частка акцій, побудованих на зв’язках із моделі, сягнула 70%.
Метрики до і після рахували за одними й тими самими правилами, тому зростання не можна списати на сезонність.
Сполучення товарів перестали бути справою смаку: бачимо, які пари справді тягнуть одна одну, і плануємо викладку за цим списком — результат повторюється від точки до точки.
— керівник напряму «ПродМаркет»
Що робити, якщо в каталозі вже є ручні правила сполучень?
Ручні правила сполучень — це домовленості: промо-зв’язки, вимоги постачальників, логіка викладки, яку менеджер править в адмінці. Даними вони не перевіряються: пара живе в каталозі роками, а в чеках перетинається рідко.
Робоча схема — гібрид: ручні правила залишаються жорсткими обмеженнями, розрахунковий шар дає рекомендації з вагою та поясненням. Частоту наборів і силу зв’язку рахуємо за класичним підходом Agrawal і Srikant — він дає числа замість смакових оцінок.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Тільки ручні правила | Мало даних, вузький асортимент | Конфлікти правил не видні, не масштабується |
| Тіньовий прогін розрахунку | Перший крок міграції на розрахунок | Викладка поки керується вручну |
| Гібрид: ручні як обмеження | Каталог із промо та зобов’язаннями | Потрібен регламент пріоритетів |
| Повний перехід на розрахунок | Великий потік чеків, немає зовнішніх зобов’язань | Втрачається формальна логіка категорій |
Міграція на розрахунок іде етапами: зводимо поточні правила в один реєстр із джерелом і строком, проганяємо розрахунок у тіньовому режимі, збираємо звіт щодо конфліктів. Кожну спірну пару віддаємо менеджеру з цифрами — підтримка, впевненість, число чеків.
Після узгодження правило отримує пріоритет, і розрахунок починає керувати викладкою в обумовлених зонах каталогу. Зазвичай 10-15% ручних правил скасовуються як помилкові, решта зберігаються й починають працювати на даних.
Часті технічні сумніви перед стартом
Перед стартом технічні команди ставлять майже ті самі питання: як правило поводиться на даних, яких не було під час навчання, і що станеться, коли зміниться асортимент, ціни чи канал продажів. Нижче — короткі відповіді щодо чотирьох вузьких місць, які найчастіше ламають довіру до результату.
Сезонність у правилах — як не тягнути святковий сплеск у звичайний місяць?
Правила рахуємо на ковзному вікні й зберігаємо прив’язку до періоду: передсвятковий, базовий, період розпродажів. Зв’язок, що піднявся на сезонному попиті, не потрапляє в базовий набір — інакше літні рекомендації тягнуть новорічні позиції.
Оптові відвантаження в даних — чи не зіпсують вони статистику?
Зіпсують, якщо рахувати все в одному потоці: одне велике відвантаження важить як сотні звичайних чеків. Розділяємо потоки за типом відвантаження й каналом, будуємо правила окремо для роздрібної торгівлі й для опту, а змішані сполучення позначаємо як низькопріоритетні.
Як зрозуміти, що зв’язок справжній, а не випадковий?
Кожне правило перевіряємо на стійкість: перерахунок на незалежних періодах, оцінка сили зв’язку щодо випадкового збігу, відсікання рідкісних сполучень. У робочий набір іде лише те, що повторюється в різних вікнах і не тримається на одиничній великій закупівлі.
Як часто перераховувати правила?
Частота задається темпом змін: за швидкого оновлення асортименту й цін — щоденне доповнення на нових даних, за стабільного каталогу — повний перерахунок раз на тиждень. Розклад фіксуємо в регламенті, щоб набір правил не «дрижав» між запусками.
Обговоримо вашу задачу й повернемося з оцінкою та планом
Перша розмова триває близько години й іде по суті — дивимося на дані, а не на презентацію. Щоб повернутися з оцінкою проєкту та планом робіт, нам потрібен мінімум контексту, решту уточнюємо самі.
- Вивантаження транзакцій за кілька місяців: чеки, позиції, час покупки, канал продажів.
- Розшифрування довідника товарів: категорії, набори, вагові позиції, сезонні заміни.
- Перелік бізнес-питань: допродаж у чеку, викладка на полиці, складання наборів, акції.
- Де лежать дані й як до них підключитися: сховище, звітний шар, регулярне вивантаження.
- Обмеження щодо доступу: правила знеособлення, вимоги служби безпеки, режим.
- Хто на боці замовника приймає результат і в якому вигляді його очікує.
За підсумками розмови надсилаємо план робіт: етапи, склад даних, формат видачі, строк старту проєкту та точки, де ви ухвалюєте рішення про продовження. Схема розрахунку показників теж іде в комплекті — щоб результат можна було пояснити бізнесу, а не прийняти на віру.
Далі — короткий пілот на вашому зрізі даних: він показує, чи ловить модель стійкі зв’язки, і лише після цього ми говоримо про масштабування. Обговорити задачу можна листом або коротким дзвінком — цього достатньо, щоб перейти до оцінки.
