Як правильно оцінити якість даних?
Даємо поради, розбираємо обмеження та ділимося метриками
Соціальна мережа QuizUp спершу задумували як застосунок-вікторину. Згодом аудиторія виросла до понад 100 млн користувачів. Колишня керівниця напряму роботи з даними в QuizUp згадує: коли обсяги інформації різко збільшилися, процеси ускладнилися. Команди почали використовувати різні інструменти, що призвело до проблем на всіх етапах передачі даних.
Спершу ненадійність інформації вплинула на швидкість ухвалення рішень. Згодом низька якість даних призвела до запуску невдалого оновлення продукту. Щоб розв’язати проблему, в компанії створили внутрішній інструмент Inspector. Його завдання — обробляти потоки даних, візуалізувати їх та показувати потенційні помилки.
Цей кейс добре ілюструє, чому оцінка якості даних є критично важливою для бізнесу. І це стосується не лише світових компаній, а й українських банків, маркетплейсів чи державних систем, які щодня працюють з мільйонами записів.
Тому в цій статті поговоримо про важливість оцінювання якості даних, про те, як створювати показники якості та якими метриками користуватися.
Ключові напрями оцінювання якості даних
Навіть використовуючи один інструмент профілювання даних (наприклад, IBM Information Analyzer або його аналоги з відкритим кодом), можна аналізувати якість інформації з різних боків:
- використати статистику, щоб визначити, які значення чи формати є валідними (наприклад, чи всі номери телефонів у форматі +380…);
- встановити допустимі діапазони (наприклад, дата народження користувача не може бути пізніше сьогоднішньої);
- призначити класи даних (наприклад, «місто» — текст, «сума платежу» — число) і перевірити відповідність;
- проаналізувати відсутні значення;
- виявити дублікати у ключових полях (наприклад, ІПН чи номер паспорта);
- перевірити зв’язки між таблицями (наприклад, чи всі платежі в базі мають відповідний запис про користувача).
Як створювати показники якості
Гарна система оцінювання якості формується на основі трьох принципів:
1. Простота й зрозумілість
Будь-який показник якості має бути інтуїтивно зрозумілим не лише для аналітиків, але й для менеджерів, які ухвалюють рішення.
Наприклад, якщо у звіті видно, що дані про транзакції мають 98 % валідності, а про клієнтів — лише 82 %, то це відразу сигналізує, на що варто спрямувати ресурси.
У державних сервісах, як-от «Дія», показник «повнота даних профілю» може бути простим індикатором (наприклад, 70 % — заповнено паспорт і РНОКПП, але відсутня адреса).
У маркетингу, якщо система CRM показує, що 15 % email-адрес клієнтів некоректні, то навіть менеджер без технічних знань зрозуміє масштаб проблеми.
Що простіший показник, то швидше бізнес може реагувати.
2. Незалежність від обсягу
Якість даних не повинна залежати від кількості рядків чи таблиць у базі. Інакше показники будуть некоректними:
- Google Sheets на 500 рядків може мати таку саму частку помилок, як і база з 1 млн записів у «Дії».
- Якщо в маленькому наборі зі 100 записів є 20 некоректних, то це 20 % проблем. Якщо у великій базі з мільйоном рядків — 200 000 некоректних записів, то це ті самі 20 %. Обсяг різний, але якість однакова.
Це важливо для масштабування: компанія, яка зростає, має бачити якість у відсотках чи індексі, а не в «голих» цифрах.
Завдяки цьому принципу метрики можна застосовувати і для стартапу, і для великої корпорації без перекручувань.
3. Нормалізованість
Показники повинні мати зрозумілу шкалу з чіткими мінімальними та максимальними значеннями, як у 0–100, де 100 — ідеальна якість.
Наприклад, в E-commerce, якщо у базі товарів лише 50 % записів мають фото, то показник «повнота каталогу» дорівнює 50 зі 100. Або якщо точність у кількості товарів на складі становить 88 %, то можна оцінити, наскільки близько система до ідеального рівня.
Нормалізовані метрики дають змогу:
- швидко порівнювати різні набори даних;
- будувати дашборди, де всі показники відтворюються в одній шкалі;
- оцінювати прогрес у динаміці (наприклад, зростання з 72 до 85 балів за 3 місяці).
Обмеження в роботі з даними
Щоб дані працювали на бізнес чи державний сервіс, вони повинні відповідати певним обмеженням — формальним правилам, які визначають, що вважають «якісною» інформацією. Інакше система починає давати збої: виникають помилки у платежах, затримки в доставках або дублікати у звітах. Обмеження можна умовно поділити на кілька типів.
1. Обмеження цілісності (повноти даних)
Дані мають бути заповненими там, де це критично. Наприклад, у формі реєстрації користувача обов’язковим є email та номер телефону, у державному реєстрі неможливо створити запис без ідентифікаційного коду (РНОКПП).
Нецілісні дані вважають неякісними, бо не дозволяють завершити процес.
2. Форматні та синтаксичні обмеження
Дані повинні відповідати певному формату або шаблону, щоб їх не потрібно було редагувати вручну. Наприклад:
- номер телефону в Україні має починатися з +380;
- ідентифікаційний код платника податків — рівно 10 цифр;
- дата має бути у форматі ДД.ММ.РРРР, а не «12 серпня 25» чи «2025/08/12».
Якщо навіть 5 % email-адрес у базі виявляться без «@», система email-розсилок згенерує помилки або втратить частину клієнтів.
3. Логічні обмеження (правдоподібність)
Дані мають відповідати реальності, щоб їх можна було використати. Так, вік користувача не може бути меншим за 18 чи більшим за 120 років, дата закінчення контракту не може передувати даті його початку, а в логістиці вага посилки не може бути від’ємною чи перевищувати фізично допустимі межі (наприклад, 2 тонни для звичайного відділення «Нової Пошти»).
4. Реляційні обмеження (зв’язки між таблицями)
Дані в одній таблиці мають коректно співвідноситися з даними в іншій, щоб працювати у синергії.
- У логістичній системі кожна накладна має бути прив’язаною до ідентифікатора клієнта.
- У банківській системі кожна транзакція повинна бути пов’язаною з дійсним рахунком клієнта.
- У системі освіти оцінка студента має бути прив’язаною до чинного предмета й викладача.
5. Бізнес-обмеження (галузеві правила)
Ці обмеження безпосередньо відбивають специфіку конкретної сфери.
- У банку кредит не можуть видати без перевірки доходів.
- В E-commerce кількість товару на складі не може бути від’ємною.
- У медичній системі пацієнту не можна призначити ліки, на які є алергія в його історії хвороб.
Кожне обмеження виконує роль «фільтра якості». Якщо дані не проходять перевірку — ви отримуєте проблему якості, яку можна класифікувати (пропущені значення, помилки формату, нелогічні дані, відсутні зв’язки тощо).
Як виміряти якість даних: ключові метрики
Щоб покращення не відбувалося «наосліп», потрібні зрозумілі та вимірювані метрики. Вони допомагають не лише фіксувати проблеми, а й оцінювати прогрес після змін.
1. Співвідношення даних до помилок (error rate).
Це базова метрика, що показує, яка частка даних не відповідає вимогам. Вона допомагає виявити «больові точки» процесу, чи помилки виникають під час введення користувачем, чи через автоматичне завантаження даних.
2. Кількість порожніх значень (completeness).
Вимірює, скільки даних у наборі залишилися незаповненими.
3. Частота помилок під час трансформації (consistency during processing).
Важливо відстежувати не лише якість «на вході», а й що відбувається з даними під час обробки. Дублікати, некоректні дані та похибки можуть затримувати весь процес. Що нижче значення цієї метрики, то краще налаштовані ETL-процеси (Extract, Transform, Load).
4. Витрати на зберігання (storage efficiency).
Погана якість даних — це не лише про точність, а й про «баласт». А як ми знаємо, зберігання теж коштує грошей. Окрім витрат на зберігання, це може створювати плутанину з актуальністю даних.
5. Час отримання цінності з даних (time-to-insight).
Це стратегічна метрика: вона показує, наскільки дані реально допомагають ухвалювати рішення. Так, з її допомогою можна визначити, скільки часу потрібно, щоб підготувати статистичний звіт на основі даних, або чи може аналітик за кілька годин сформувати звіт про продажі, чи йому потрібен тиждень на «чистку» даних.
Ця метрика напряму пов’язана з ефективністю компанії — що швидший доступ до якісних даних, то швидше ухвалюють рішення.
Також іноді додають і метрики актуальності (freshness) — наскільки дані нові (наприклад, чи відтворює база стан складу на «вчора» чи на «місяць тому»). Це особливо критично для логістики, фінансів та E-commerce.
