80% времени я трачу на очистку данных. Качественные данные всегда выигрывают у качественных моделей.
Томсон Нгуен
Данные это фундамент. Запомните раз и навсегда, что все знания технических аспектов не стоят и гроша без данных, потому что кирпичики ваших навыков не на что класть. Если люди принимающие решения не имеют данных, но обладают знанием кнопок и софта - это усиливает их стремление полагаться на свою интуицию, а там как повезет...
Статья называется качество данных и это понятие нужно рассматривать в самом широком смысле. Для анализа необходимы правильные данные, собранные в правильном месте, правильным образом и в нужное время. Не такие уж и большие требования оказывается, но если даже один из этих пунктов выполнен не в полной мере, сужается круг вопросов, на которые сможет ответить ваш техспец или аналитик.
Аспект качества данных
Невозможно свести качество данных к одной цифре. Никакой 10-бальной шкалы для оценки не существует. Определить можно только по группе аспектов, каждый из которых в должной мере влияет на общую картину. Например у вас есть база клиентов: почты, телефоны, города, точные адреса, но у некоторых пропущены индексы почтовых отделений, согласитесь, это уже создает серьезную проблему если вам необходимо рассчитать логистику доставок товаров.
Данные должны отвечать следующим требованиям:
- Доступность: это не только разрешение для аналитика к их чтению, но и все технические средства способные их анализировать
- Точность: данные должны отражать истину. Ошибки в дате рождения, сумме заказа все это создает серьезные проблемы
- Взаимосвязанность: должна быть возможность связать одни данные с другими, для этого существуют первичные ключи в виде ID клиента или товара. Но с этим сегодня редко бывают проблемы, потому что большинство данных собираются из крупных систем, где предусмотрен такой подход
- Полнота: если часть информации потеряна или не указана это так же создает проблемы в анализе
- Непротиворечивость: данные должны быть согласованы между собой, если у вас две базы и по клиенту куча адресов, почт и телефонов, тогда надо эту информацию структурировать и дробить на столбцы.
- Однозначность: ее часто называют однородностью. Если у вас есть столбец имен клиентов не надо в него указывать электронную почту или другие данные. Правильная разметка названий столбцов упрощает решение этой проблемы.
- Релевантность: если вы собрались анализировать и прогнозировать продажи на 2024 год, то исторические данные за 2016 год будут не релевантными, так как мы живем в быстро меняющемся мире. Тут лучше использовать ближайшую историческую перспективу.
- Своевременность: необходимо использовать только актуальную информацию. Если вам приходится ждать обработки и получения данных 2 недели, то это никуда не годится, они просто теряют свою актуальность и быстрое реагирование в принятии решений отсутствует.
В ваших данных всегда больше ошибок, чем кажется. И вам придется смириться с фактом, что вы по этой причине скорее всего теряете миллионы, я серьезно. И в этом не виноваты аналитики, потому что чаще всего они находятся в конце цепи генерации, обработки, получения и сведения цифр. Попробуем выделить проблемы и в дальнейшем избегать системных ошибок способных ухудшить качество данных, а также поговорим о том, кто отвечает за это.
Генерация данных
Самый очевидный источник проблем - это этап генерация. Ошибки могут быть программными, или виной станет человеческий фактор (чаще всего). С технологической точки зрения все просто, если рассмотреть пример сайта, то это некорректно настроенные счетчики, отсутствие CRM, или ошибка в скриптах при обработке/передаче. Если у вас производство, то тут чаще всего создают барьеры ошибки в показателях приборов.
Когда в сборе принимают участие люди и ручной ввод, возникает просто колоссальный список причин. Люди:
- не знают как пользоваться софтом или оборудованием
- торопятся
- не читают инструкций
- не знают зачем вообще собирать конкретные данные
- не понимают работы элементарных сводных таблиц
- и т.д.
Помню в детстве, в школе, мы раз в год проходили медосмотр. Врачи естественно менялись, и кто-то проводил взвешивание в обуви, а кто то без обуви, а иногда даже в одежде. Мы над этим всегда смеялись :) Вот вам и статистические погрешности в пару килограммов. Человеческий фактор здорово может напортачить!
Ввод данных
По-прежнему большинство данных сначала фиксируется на бумаге, а потом переносится в цифру. Ошибки при расшифровке почерка в медицинских учреждениях частый аспект. Думаю всем знаком почерк вашего участкового врача. :)
А сколько ошибок бывает в номере телефона в базе заказов! Человек вводит данные вручную, ошибается в одной цифре и этот номер падает к вам в базу. Или очень популярны ошибки при написании даты: бывают разные форматы и каждый может вводить их так, как привык.
В целом ошибки при в вводе происходят во время этапов записи, вставки, удаления или перемены места.
Как с этим бороться?
- Сокращаем количество этапов ввода данных. Банально, если есть возможность сразу вбивать данные в ПК, тогда так и делайте.
- Добавляйте маски в столбцы ваших таблиц, старайтесь все приводить к единому типу. Это касается и дат, и номеров сотовых телефонов, email и т.д.
- Проверяйте все в самом начале, при первичном вводе!
- Лучше всего исключать человеческий фактор и все автоматизировать с помощью софта.
- Если автоматизация невозможна назначьте задачу двум сотрудникам: вести сбор и учет данных независимо друг от друга. Тогда они будут проверять единую сводную и делать исправления.
Итак теперь у нас есть чистые данные без ошибок которые переходят в стадию анализа.
Анализ разведкой
При получении любой информации аналитику в первую очередь необходимо оценить ее на качество и ошибки, например
- Если ваш средний чек 10000р, нужно проверить столбец сумм и посмотреть, действительно ли такой расчет совпадает с реальным приходом денежных средств.
- Если вы работаете по РФ, то в столбце города не должно быть Лондона или Минска.
Предварительная оценка данных один из самых важнейших навыков аналитика. Всегда ставьте под сомнения любые источники и агрегированные таблицы. В 80% случаев там есть мелкие недочеты - все проверяем и никому не доверяем!
Пропущенные данные
Самая частая проблема - это пропуск части данных или пропуск целой строки. Это может сделать бесполезной всю запись. Показатель определяющий смысл записи самый важный и пропускать его точно нельзя: это могут быть ID заказа, важный тег или целевая метрика.
Даже в высокотехнологичных системах и счетчиках метрик на сайте существуют погрешности до 15%. Если сюда добавить ошибки человеческого фактора, набегает приличная критическая масса. С таким качеством данных работать просто опасно!
На первоначальном этапе определите причины пропуска. Необходимо выяснить:
- Пропуски совершенно случайны
- Пропуски случайны, но в этом есть определенные закономерности, например заранее обговариваете отметку «Города» в таблице в том случае, если он находится в определенной стране. В остальных случаях оставляете ячейку пустой.
- И самое опасное: пропуски не случайны, а пропущенные данные - это результат других пропущенных данных. Когда у вас сложная система сбора или несколько таблиц, перетекание пустоты в ячейках от одного менеджера к другому неизбежно. Это серьёзная необъективность.
Дубликаты
Еще одна популярная проблема. Возникает часто из-за неправильного переноса, копирования данных или повторных регистрациях на сайте: когда клиент указал другую почту или телефон. Так же дублирования могу возникать когда над таблицей работают два и более менеджеров без коммуникации друг с другом.
Обычно эта проблема для крупных баз данных решается с помощью первичного ключа (индекса), который определяет запись как уникальную, и при появлении похожих выдает оповещение о наличии дубликата. Но в случае с простым ведением таблиц нужно убирать все чисткой дубликатов с помощью инструментов Excel или Google таблиц и последующим пересведением. Power Query с этим отлично справляется. И конечно коммуникация между менеджерами должна быть максимальной!
Усечение
За этим стоит следить только в том случае, если вы часто сталкиваетесь с ограничением по количеству символов в ячейках или в вашей реляционной модели данных. Например, по умолчанию была установка маски в столбце телефона должно быть не более 10 символов, но существуют номера телефонов более длинные, и такие номера будут автоматически урезаны при отправке с вашей формы регистрации. Куда будем звонить?
Единицы измерения
В этом случае разночтения возникают при работе на международном уровне. Если у вас много показателей или валютных переводов, нужно четко определить порядок коммуникации между всеми сотрудниками, в котором будет понятно, какая валюта используется, считаем километры или мили и т.д. Лучше всего сформировать строгий документ/регламент.
Значение по умолчанию
Обычно в умных софтах пропущенные данные маркируются Null. Хотя иногда я замечал, что Power BI просто оставляет ячейку пустой по непонятным причинам. А иногда в столбцах даты в пустые ячейки выставляется минимальное значение внесенное в сам софт, всем вероятно встречалась дата - 1 января 1900 года. А потом мы удивляемся при анализе аудитории, почему так много людей за 100 лет в базе клиентов :)
Происхождение
Тут в роль вступают метаданные. Часто встречается как история изменений в разных софтах, Power Query и таблицах Гугл. Когда вы откатываете назад, вы возвращаетесь к моменту до совершения ошибки. Так же и в вашей базе данных желательно указывать источники данных и их историю изменений. Таким образом при обнаружении в сводных таблицах недочетов вы можете обратиться к первичному источнику и понять, почему он был сформирован неверно.
Качество данных как совместная ответственность
Считается, что за качество отвечает только сборщик данных, хочется вас разуверить - этим должны заниматься все специалисты в компании!
- Верстка сайта и тот кто ее делает может добавить маску для телефона, чтобы не было ошибок при вводе
- Специалист по сборке маркирует строки первичным ключом
- Менеджер может заметить дубликаты в строках и дать сигнал программисту базы
- и т.д.
Когда данные валятся непрерывным потоком в ваши таблицы, их в тесном сотрудничестве должны просматривать все участники бизнес процесса и сразу формулировать требования/идеи для предотвращения проблем, о которых я говорю в этой статье.
Особенно аналитик непрерывно взаимодействует с программистами, или техподдержкой софта, который агрегирует вашу базу.
В ресторанах чаще всего повар сам выбирает продукты, из которых будет готовить. Это его сырое сырье. Так же и с данными, руководители подразделений вместе с аналитиком на входе отделяют мух от котлет.
Как видите, мы продолжаем возвращаться к важности корпоративной культуры в организации. Без совместного анализа, обработки и четкой коммуникации, не получить крепкого фундамента для роста бизнеса с помощью данных. К этому я еще вернусь в следующих статьях.