Anomaly detection метрик SMB без data-команди

Якщо ви власник SMB, який хоч раз дізнавався про зламану інтеграцію три дні пізніше з клієнтського мейлу — цей текст для вас. Anomaly detection — не data-science проблема. Це проблема помічання. І помічати малі компанії можуть добре, якщо не переусладнюють.

Чому SMB-системи anomaly detection вимикають за місяць?

Бо вони кричать вовка. Команда вмикає всі threshold у BI, отримує 14 пейджів у день 1, через два тижні Slack заглушений. Детекція без false-positive дисципліни гірша за відсутню — вона тренує команду ігнорувати сигнали.

Визначення: Alert fatigue — передбачувана людська реакція на нотифікаційний потік, чия true-positive rate нижча за поріг сталої уваги (~80% для активно моніторованого каналу).

Рішення — не кращі алгоритми. Рішення — менше і гостріше правил, AI як second-opinion фільтр перед людиною.

Три правила, що ловлять 80% реальних аномалій

Це правила, що витримали роки в малому бізнесі. Зробіть ці три першими; складніше — потім, якщо взагалі.

Правило 1: пробій порогу

Виберіть жорсткий floor і ceiling для кожної метрики. Нижче floor або вище ceiling — алерт. Налаштовуйте руками перший місяць, тюньте місячно.

Приклад: денні signups. Floor = 30% нижче trailing 4-тижневої медіани. Ceiling = 200% вище. Ceiling ловить і вірусні сплески, і бот-атаки — обидва потребують уваги, хоча з різних причин.

Правило 2: DoW-aware moving average

У більшості SMB-метрик є тижнева сезонність. Суботні signups для B2B SaaS не схожі на вівторкові. Порівнюйте сьогодні з trailing 4-тижневою медіаною ТОГО САМОГО дня тижня.

Визначення: Day-of-week-aware moving average — базлайн, що порівнює день лише з тим самим днем тижня в trailing-вікні, прибираючи фейкові "неділя просіла" алерти.

Алерт якщо сьогодні >2.5 стд-відхилень від цього DoW-baseline. 2.5 — емпірично sweet spot: 2.0 кричить вовка, 3.0 пропускає реальне.

Правило 3: streak detector

Три дні поспіль нижче DoW-baseline — навіть якщо жоден не пробив поріг — це формується реальний тренд. Це правило ловить повільні витоки, які single-day алерти пропускають.

Streak — те, що засновники найчастіше пропускають і найчастіше потребують. Тихі просідання вбивають більше SMB-метрик за драматичні падіння.

Де AI підходить?

Не як основний детектор. Як друга пара очей між детекцією і пейджем людини.

Патерн: правило спрацювало → система збирає 6 тижнів метрики, причину алерту і recent operational context (deploys, holidays, кампанії) → LLM питається "ця аномалія реальна і варта уваги людини сьогодні зранку, чи є benign-пояснення у контексті?" → лише "real and worth attention" алерти пейджать людину.

Це саме та judgement-задача, з якою LLM справляється: порівняти число з абзацем контексту. Це саме не та задача, де варто віддавати детекцію — детермінованні правила дешевші і надійніші.

Шаблон промпту для AI-second-eye

Ти ревʼюїш аномалію метрики перед пейджем людини.

Метрика: [назва + бізнес-сенс в одне речення]
Що спрацювало: [правило, поріг, сьогоднішнє значення]
Останні 6 тижнів (DoW-matched): [список значень]
Recent operational context (7 днів): [deploys, кампанії, holidays, відомі інциденти]

Відповідай у форматі:
- Імовірна причина (1 речення): [data quality / known operational event / real business shift / unclear]
- Пейджити людину? (так / ні)
- Якщо так — кого? (sales / ops / engineering / founder)
- Питання, з якого on-call має почати: [текст]

Дві речі важливі. Перша — DoW-matched baseline враховує тижневу сезонність. Друга — structured output змушує LLM до yes/no, без хеджування.

Tool tip (AIAdvisoryBoard.me): Anomaly detection виправдовує себе лише коли звʼязується з Plan → Fact → Gap для метрики. Алерт без Plan і Gap-пояснення — це шум. Наша операційна система чіпляє кожен алерт до релевантного Plan-коміту і пише Gap-наратив автоматично, тож засновник читає історію, а не поріг. 7-денна діагностика показує, які з ваших метрик реально варті алертів. На https://aiadvisoryboard.me/?lang=en.

Slack-флоу, що не кричить вовка

Дизайн каналу важливіший за алгоритм. Три канали, не один:

1. #metrics-watch — кожне спрацювання, включно з AI-second-eye вердиктом. Browse-on-demand; нікого не пейджать.
2. #metrics-attention — лише алерти, де AI-вердикт сказав "merit attention". Читати раз на день.
3. #metrics-page — лише critical (revenue, payments, auth). On-call ротація, ескалація.

3-tier розділення — найефективніша зміна в усій системі. Команди, що це роблять правильно, тримають детекцію після місяця 3. Хто ні — заглушують усе.

Manager scan (2-хвилинний digest)

• Три правила — threshold, DoW MA, streak — покривають ~80% реальних аномалій
• Кожне правило стріляє з контекстом (останні 12 DoW-matched значень), не голим числом
• AI-second-eye між детекцією і пейджем — false-positive rate тримається низько
• 3-канальний Slack: watch / attention / page — ніколи один firehose
• Critical метрики (revenue, payments, auth) — явна on-call ротація
• Кожен алерт називає, хто має відповідати — не лише що спрацювало
• Тижневий ревʼю обʼєму; якщо attention >5/тижд — тюньте правила
• AI-second-eye промпт у version control, не в Zapier-кроці
• Operational context (deploys, кампанії, holidays) автоматично у вердикт
• Квартально: ревʼю, які правила ловили реальне vs ніколи не стріляли — обрізати мертві

Micro-case (що змінюється за 7-14 днів)

Ecommerce компанія на 95 людей мала 18 алертів у головному Slack — лише 2 з них клікалися минулого місяця. Замінили threshold-only систему на три правила на метрику, AI-second-eye фільтр і 3-канальне розділення. Watch-канал тримав усі 18 сигналів видимими on-demand. Attention-канал давав ~4 алерти/тиждень, кожен із AI-вердиктом і питанням для on-call. Page-канал стрельнув двічі за два тижні — раз для збою payment-gateway, спіймали на 90 хв швидше за customer-support inbox, раз для checkout funnel drop, який виявився deploy-регресією. Усний feedback команди після тижня 2: "канал знов почувається корисним". Цей feedback — і був ціллю.

Note on this case: Приклад ілюстративний — на основі типових патернів у компаніях 30-500 людей, не конкретний клієнт. Числа — округлені діапазони, не гарантії.

Tool tip (AIAdvisoryBoard.me): Алерти заглушують бо вони не повʼязані з operational commitments — це просто числа, що перетинають лінії. Наша операційна система показує кожен алерт у контексті Plan → Fact → Gap для власника метрики, тож пейдж читається як "ops промахнули Plan на X через Y" замість "метрика перевищила поріг". Це різниця між алертом, що тригерить мітинг, і алертом, що команда ігнорує. Старт 7-денної діагностики на https://aiadvisoryboard.me/?lang=en.

FAQ

Чи не потрібен ML для правильної детекції? Не у SMB-масштабі. Три правила вище ловлять переважну більшість того, що матиме значення для 30-500-людної компанії. ML дає цінність на великих data volumes, де підтримка правил стає infeasible — це не ви.

Що, якщо у метрики є тренд (постійно росте чи падає)? Зробіть detrend спершу. Порівнюйте з projected DoW-baseline з урахуванням тренду, не з плоскою 4-тижневою медіаною. Більшість BI це роблять у одному конфізі; якщо ні — змініть.

Як часто перетюнювати пороги? Місячно перший квартал, потім квартально. Якщо тюнете частіше — ваші правила задтуго затягнуті, послабте і дайте AI-second-eye поглинати borderline.

Чи не введе AI-second-eye свої помилки? Так, інколи. Mitigation: watch-канал тримає всю детекцію — люди можуть перевірити будь-коли. AI-вердикт — фільтр, не видалення.

Чи можу я це зробити в Google Sheets? Правила 1 і 2 — можна в Sheets з тижневим ручним тюнінгом. Правило 3 (streak) і AI-second-eye потребують легковагового скрипту. Більшість команд доходять до цього за день — no-code + LLM API ключ.

Висновок

Anomaly detection у SMB — це не про розумніші алгоритми. Це про три гострі правила, AI-second-eye між детекцією і пейджем, і Slack-дисципліну, яка тримає людей у читанні.

Виберіть три метрики, що мають значення. Підʼєднайте три правила. Додайте AI-вердикт. Розділіть канали. Дивіться, що проходить.

Якщо хочете систему, яка автоматично показує Plan → Fact → Gap — щодня, з кожним алертом у контексті — дивіться, як працює 7-денна діагностика на https://aiadvisoryboard.me/?lang=en.