Есть тема в аналитике, о которой не очень принято говорить, но именно она занимает до 50% рабочего времени и создает больше всего геморроя. Речь о качестве данных (data quality).
На моем опыте — большинство проблем с построением отчетов/дашбордов возникает именно из-за качества исходных данных. Написать запрос — несложно. Построить дашборд — тоже рядовая задача. А собрать воедино кучу грязных и разрозненных данных — задача практически нерешаемая, все равно упустите какие-то corner cases.
А самое ужасное, что низкий уровень data quality приводит к неправильным решениям.
Смотришь в отчет и видишь, что большинство клиентов покупает после вебинаров. А на самом деле покупает после чего-то еще, просто у тебя сделки «расклеиваются» и ты этого не видишь. У нас ушло очень много времени (и до сих пор ловим флешбеки), чтобы сметчить лог активностей наших лидов с уже купившими клиентами.
Вот небольшой чек-лист, который подойдет большинству компаний. Проверьте качество сбора хотя бы этих данных и ваша жизнь станет легче на 90%.
1/ Одинаковая маска для телефонов. Определитесь — либо везде «+7», либо «8», либо вообще без префикса. Сразу подумайте, что делать с зарубежными номерами.
2/ Все почты, имена и прочие важные текстовые поля сохранять в одном регистре. В некоторых БД поиск и сравнение регистрозависимое, поэтому
андрон и Андрон — разные вещи. 3/ Все url-адреса сохранять по одному шаблону. Чтобы не было так: часть с «www» — часть без, часть с «https» — часть с «http», у части в конце слеш — у части нет, и так далее.
4/ Приводите дату и время к одному формату и одной таймзоне. К одному формату — чтобы на уровне БД потом эффективно работать с датой, без преобразований. К одной таймзоне — чтобы потом понять, во сколько человек реально оставил заявку и по Мск это или по Владивостоку.
5/ Периодически проверяйте базу на дубли. Например, сделки в CRM могут дублироваться, но почта одна и та же. Пробегайтесь раз в сутки автоматизированным скриптом и объединяйте такие сущности в мастер-записи.
6/ Номенклатуры/другие важные названия задавайте по одному паттерну. Например, чтобы группа товаров «Носки» иногда не превращалась в «Носочные изделия», а где-то — вообще в «Носки теплые». Любая витрина данных — это большое количество соединений разный таблиц, поэтому любые отличия, даже минимальные, приведут к «выпаданию» некоторых строк. А вы даже не увидите этого.
7/ Стандартизируйте паттерны. Например, договоритесь, что все UTM-метки задаются по строгой структуре, а разделитель — всегда нижнее подчеркивание или дефис. Такая жесткая стандартизация позволит в некоторых сложных ситуациях работать прям со значениями, сплитовать по разделителю, делать поиск с помощью регулярных выражений и прочие страшные штуки — иногда такое пригождается.
8/ Удаляйте все лишние пробельные символы. При сохранении в БД в начале/конце не должно быть никаких пробелов, табов и прочих штук — это сильно может усложнить жизнь.
9/ Удаляйте все лишние пробельные символы [2]. Только теперь не в начале, а вообще в строке. Если кто-то указал 3 пробела между именем и фамилией — перед записью в БД замените с помощью регулярки на один пробел.
10/ Правильные форматы данных. Не сохраняйте даты и числа — как строки и т.д.
Это минимальный набор правил, но он покрывает большинство проблем, которые я встречал в своей практике. Просто выполняйте все эти проверки/преобразования ДО записи в БД и ваши данные будут близки к идеальным.
Кстати, я тут подумал — давайте наберем 200 разных реакций на этот пост и я прям поделюсь некоторыми заготовками скриптов для очистки данных по этим пунктам 🔥
ANDRON ALEXANYAN