Отваряме отчета.

Покупките са се увеличили.

Revenue също.

Графиката върви нагоре.

На пръв поглед изводът изглежда лесен:

бизнесът се представя по-добре.

После отваряме системата, в която реално се управляват поръчките.

Там подобен ръст няма.

Сега вече имаме проблем.

Кое число е вярно?

Естествената реакция е да изберем системата, на която вярваме повече.

Но това идва прекалено рано.

Преди да решим кой източник е „прав“, трябва да разберем:

Какво точно брои първата система?

Какво точно брои втората?

Кога го брои?

Как се създава стойността?

Какво може да бъде пропуснато?

Какво може да бъде отчетено два пъти?

Защото два различни резултата невинаги означават, че единият е грешен.

Понякога двете системи просто измерват различни неща.

А понякога една от тях действително произвежда лоши данни.

Това трябва да бъде установено, преди да започнем да обясняваме бизнеса с тях.

Числото не става факт само защото е в dashboard

Една стойност изглежда много убедително, когато е част от добре направен отчет.

12,4%.

1 248 покупки.

€86 420 revenue.

4,7% conversion rate.

Точността на визуалното представяне лесно създава усещане за точност и на самата информация.

Но dashboard-ът не знае дали сме измерили правилното.

Той показва резултата от това, което системата е получила и обработила.

Ако входът е грешен, можем да получим напълно последователна и професионално изглеждаща грешна картина.

Затова преди:

„Какво показват данните?“

трябва да съществува друг въпрос:

„Какво трябва да е вярно, за да можем да използваме тези данни?“

Това е същинският въпрос за качеството.

Правилният източник и добрите данни са две различни неща

В предишната статия за източниците разгледахме избора на източник.

Ако искаме да знаем какво се е случило с реалните поръчки, трябва да намерим системата, която управлява този процес.

Но това още не решава проблема.

Да приемем, че сме намерили правилния източник.

В него може да има:

тестови поръчки;

дублирани записи;

отказани поръчки;

липсващи стойности;

непоследователни статуси;

грешни дати;

ръчни корекции;

поръчки, създадени по различни канали и обработени по различен начин.

Тоест можем да гледаме на правилното място и пак да получим грешен отговор.

Следователно:

правилен източник ≠ автоматично качествени данни.

Да се върнем към покупките

Представете си следния случай.

GA4 показва 1 200 purchase събития.

Системата за поръчки показва 1 050 поръчки.

Разликата е значителна.

Можем веднага да кажем:

„GA4 греши.“

Но нека първо разглобим проблема.

Какво означава purchase в GA4?

Това е събитие, което трябва да бъде изпратено при определено действие.

Как е реализирано?

Изпраща ли се само веднъж?

Може ли refresh на thank-you страницата да го задейства отново?

Изпраща ли се едновременно от browser и server implementation?

Има ли transaction_id?

Какво означава поръчка в другата система?

Създадена поръчка?

Платена?

Потвърдена?

Неотказана?

Изпратена?

Приключена?

Ако едната система брои създаването на поръчката, а друга само успешно платените поръчки, двете числа трябва да бъдат различни.

Тогава разминаването не е непременно data quality проблем.

Може просто да сравняваме различни дефиниции.

Еднаквото име не означава еднаква дефиниция

„Продажба“.

„Клиент“.

„Активен клиент“.

„Върнат продукт“.

„Конверсия“.

„Наличен продукт“.

Всички звучат достатъчно ясно, докато не попитаме:

Как точно го определяме?

Например:

Клиент ли е човекът, който е направил поръчка?

Или само този, който я е платил?

Или трябва да е получил продукта?

Какво правим с отказаната поръчка?

С върнатата?

С поръчка, създадена по телефона?

С две покупки от един и същ човек?

Това не е семантичен спор.

Отговорът променя числото.

А ако двама души или две системи използват една дума с различна дефиниция, могат да спорят за резултата, докато всъщност измерват различни неща.

Затова качеството започва и от ясното значение на данните.

Един грешен сигнал може да произведе цяла правилна логическа верига

Това е една от най-опасните ситуации.

Представете си:

Analytics показва повече покупки.

След това виждаме, че рекламната кампания има повече отчетени conversions.

Изчисляваме по-добър ROAS.

Заключаваме, че кампанията работи.

Увеличаваме бюджета.

Логиката между стъпките може да е напълно последователна.

Проблемът е в началото.

Ако purchase събитието се дублира, последващият анализ не става правилен само защото математиката е правилна.

Грешният вход може да произведе:

правилно изчисление;

красива графика;

логично обяснение;

и грешно решение.

Точно затова качеството на данните трябва да бъде проверено преди интерпретацията, а не когато резултатът вече ни изглежда подозрителен.

Липсващите данни също могат да изглеждат като реалност

Не всяка грешка създава прекалено висока стойност.

Понякога информация просто липсва.

Например:

определен browser блокира част от измерването;

една версия на checkout не изпраща събитие;

част от продажбите минават през друг канал;

някои продукти нямат попълнена характеристика;

част от клиентските контакти не се категоризират;

определена система не синхронизира всички записи.

Тогава отчетът не казва:

„Тук липсва част от реалността.“

Той просто показва това, което има.

И точно затова липсващите данни могат да бъдат подвеждащи.

Не защото стойностите вътре непременно са грешни.

А защото лесно ги приемаме за пълна картина.

Затова трябва да попитаме:

Какво би трябвало да присъства тук и има ли причина част от него да липсва?

Данните могат да бъдат технически валидни и фактически грешни

Да излезем от Analytics.

Представете си продуктов каталог.

Един физически продукт има SKU:

ABC-125

При импорт обаче за него са създадени два отделни продуктови записа.

И двата са технически валидни.

И двата имат име, цена, категория и характеристики.

Но реално описват един и същ артикул.

Сега вече имаме проблем с уникалността.

Ако анализираме броя продукти, можем да го отчетем два пъти.

Ако синхронизираме наличност, можем да разпределим една физическа наличност между два записа.

Ако подаваме каталога към друга система, дублирането може да продължи нататък.

Данните съществуват.

Форматът им е валиден.

Но това не означава, че представят реалността правилно.

Същото важи и за точността.

Една стойност може да бъде записана в напълно правилен формат и просто да е грешна.

Затова качеството не е само:

„Има ли стойност?“

А:

„Стойността вярна ли е, уникална ли е там, където трябва, и достатъчно надеждна ли е за конкретната употреба?“

Не всяко несъответствие трябва да бъде поправено с код

При дублираните записи можем да кажем:

„Ще ги дедупликираме автоматично.“

Технически това може да бъде възможно.

Но по какво ще разпознаем, че два записа действително представляват един продукт?

По SKU?

По EAN?

По комбинация от характеристики?

Какво става, ако идентификаторът също е грешен?

Коя система определя правилния запис?

Как ще предотвратим следващия импорт да създаде същия проблем отново?

Кодът може да автоматизира правило.

Но първо трябва да разбираме какво прави един запис правилен или уникален за конкретния бизнес процес.

Ако само почистим текущите данни, но оставим механизма, който произвежда дубликатите, сме коригирали състоянието.

Не причината.

Единичната грешка и повтарящият се тип грешка са различни проблеми

Един продукт е дублиран.

Поправяме го.

Възможно е случаят да приключи там.

Но ако всяка седмица откриваме нови дублирани продукти, въпросът се променя.

Не:

„Кой е сгрешил този запис?“

А:

„Как системата продължава да произвежда този тип грешка?“

Възможно е:

импортът да няма достатъчна проверка;

различни източници да използват различни идентификатори;

няколко души да създават продукти по различен начин;

да липсва правило за уникалност;

да няма проверка преди създаването на нов запис;

да не е ясно коя система носи отговорност за данните.

Тогава качеството на данните вече не е задача за еднократно „почистване“.

То е характеристика на процеса, който създава и поддържа информацията.

Затова при повтаряща се грешка трябва да попитаме:

Защо може да възникне?

Как преминава през системата?

Защо не се открива по-рано?

Какво трябва да се промени, за да не я произвеждаме отново?

Една грешка може да е случай.

Повтарящият се тип грешка е въпрос към системата зад данните.

Съвпадението между две системи не доказва автоматично качество

Да приемем, че:

GA4 показва 1 050 покупки.

Backend показва 1 050 поръчки.

Чудесно.

Доказали ли сме, че всичко е правилно?

Не.

Възможно е:

тестовите поръчки да попадат и в двете;

едни и същи отказани поръчки да се броят и на двете места;

дефиницията ни за „покупка“ да е неподходяща за бизнес въпроса;

стойностите да съвпадат като общ брой, но да съдържат различни отделни записи.

Например едната система може да пропуска част от реалните поръчки и едновременно да съдържа дублирани.

Крайният брой пак може да съвпадне.

Следователно:

съвпадението е полезен сигнал, но не е само по себе си доказателство.

Трябва да можем да проверим и структурата зад общото число.

Не всяко отклонение означава лоши данни

Ако две системи показват различни числа, не трябва автоматично да започваме „data cleanup“.

Първо трябва да проверим дали изобщо очакваме да съвпадат.

Например:

създадени поръчки;

платени поръчки;

изпратени поръчки;

доставени поръчки

са различни състояния.

Различните стойности могат да бъдат напълно правилни.

Качеството не означава всички системи да показват едно и също.

Означава стойностите да бъдат правилни спрямо това, което твърдят, че измерват.

Добре събраният KPI не е непременно добре дефиниран KPI

Има една важна граница.

Един показател може да бъде събран технически безупречно и пак да не измерва това, за което го използваме.

Например „обработен клиентски казус“ може да означава затворен ticket, изпратен отговор или действително решен проблем.

Това вече не е въпрос само за техническото качество на записите.

Това е въпрос дали сме дефинирали правилно самия сигнал.

Тук тази статия спира.

Как показателят трябва да се интерпретира спрямо други бизнес резултати е отделна тема.

Колко силна проверка изисква решението?

Изкушаващо е да кажем, че всички данни трябва да бъдат 100% точни.

На практика по-полезният въпрос е:

Какво ще направим с тях, ако им повярваме?

Да сравним две решения.

Решение А

Променяме текст на вътрешна страница.

Рискът е малък.

Промяната е лесно обратима.

Вероятно няма смисъл да изграждаме сложен процес за валидиране на всяка входна стойност.

Решение Б

Автоматично променяме ценообразуването на хиляди продукти въз основа на тези данни.

Тук неточен вход може да произведе много по-голяма щета.

Следователно изискването към проверката трябва да бъде по-високо.

Въпросът не е:

„Перфектни ли са данните?“

А:

„Колко сигурни трябва да бъдем в тях, преди да вземем точно това решение?“

Колкото по-голям е потенциалният ефект и колкото по-трудно обратима е грешката, толкова по-силна трябва да бъде проверката.

Качеството на данните не е самоцел.

То е условие да използваме информацията с приемлив риск.

Как бих проверил дали един сигнал е достатъчно надежден

Преди да използвам важен сигнал като основа за решение, бих започнал с няколко въпроса.

Какво точно означава?

Има ли ясна дефиниция?

Как се произвежда?

Автоматично?

Ръчно?

Чрез импорт?

Чрез tracking?

Чрез комбинация от системи?

Пълни ли са данните?

Има ли случаи, които би трябвало да присъстват, но не попадат в тях?

Точни и валидни ли са стойностите?

Съответстват ли на реалния обект или събитие?

Допустими ли са за полето и бизнес правилото?

Уникални ли са там, където трябва да бъдат?

Може ли един и същ продукт, клиент, поръчка или събитие да бъде отчетен повече от веднъж?

Последователни ли са?

Използваме ли една и съща дефиниция, статус и логика в рамките на анализа?

Можем ли да проследим отделен запис?

Ако общото число изглежда странно, можем ли да стигнем обратно до конкретните случаи?

Рамката става:

сигнал → дефиниция → начин на производство → пълнота → точност и валидност →

уникалност → последователност → проверка → достатъчно надежден ли е за конкретната употреба

Едва след това има смисъл да питаме:

„Какво можем да заключим от този сигнал?“

Качеството идва преди увереността в анализа

Лошите данни не винаги изглеждат лошо.

Това е основният риск.

Те могат да бъдат:

подредени;

визуализирани;

агрегирани;

сравнени;

изчислени до втория знак след десетичната запетая.

И пак да описват грешна картина.

Затова добрият анализ не започва с доверие към числото само защото числото съществува.

Първо трябва да разберем:

какво означава;

как е произведено;

какво може да липсва;

какво може да е неточно;

какво може да е дублирано;

дали правилата са последователни;

и колко надежден трябва да бъде сигналът за решението, което ще вземем.

Едва тогава данните могат да се превърнат от налична информация в основа за анализ.

А следващият въпрос вече е различен:

Какво се случва, когато проверим този надежден сигнал спрямо останалите?