Качество данных: как проверить таблицу перед анализом
- Сначала определите, для какого расчёта нужны данные
- Различайте критерии качества
- Проверьте границы выгрузки
- Разберите небольшую учебную таблицу
- Не удаляйте похожие строки автоматически
- Отделите пропуск от нуля
- Проверьте форматы, единицы и смысл
- Ведите реестр исправлений и сверяйте результат
- Решите, можно ли передавать данные в работу
- Вопросы и ответы
Сначала определите, для какого расчёта нужны данные
Качество данных означает их пригодность для конкретного использования. Таблица может выглядеть аккуратно, но не отвечать на рабочий вопрос. Например, перечень созданных заказов нельзя без дополнительной проверки использовать как список оплаченных продаж. Ошибка возникает ещё до формул: выбран неподходящий набор событий.
Запишите, что именно нужно посчитать, за какой период и по какой единице наблюдения. Для отчёта об оплаченных заказах одна строка может соответствовать одному заказу. Для отчёта о товарных позициях один заказ займёт несколько строк. Пока это различие не определено, невозможно уверенно искать дубли и сравнивать итог с другой системой.
Проверка качества входит в более широкий процесс подготовки табличных данных. Здесь сосредоточимся на решении, можно ли использовать записи, какие дефекты нужно исправить и какие ограничения обязательно сообщить получателю отчёта.
Различайте критерии качества
В Government Data Quality Framework рассматриваются полнота, уникальность, согласованность, своевременность, валидность и точность. Это удобный набор вопросов для проверки. При этом высокий результат по одному критерию не исправляет провал по другому: заполненная дата может быть неверной, а уникальная строка — относиться к чужому периоду.
| Критерий | Рабочий вопрос | Пример дефекта |
|---|---|---|
| Полнота | Есть ли необходимые записи и поля? | У оплаченного заказа не указана дата оплаты |
| Уникальность | Не посчитано ли событие повторно? | Одна выгрузка загружена дважды |
| Согласованность | Не противоречат ли сведения друг другу? | Статус отмены соседствует с включением в продажи |
| Своевременность | Подходят ли данные по времени? | Вчерашняя выгрузка используется как текущий остаток |
| Валидность | Соответствует ли значение допустимому формату? | Дата записана в поле суммы |
| Точность | Соответствует ли запись реальному событию? | Сумма отличается от подтверждённого платежа |
Не объединяйте критерии в средний балл без объяснения. Для одной задачи отсутствие телефона покупателя несущественно, для другой оно делает обработку обращения невозможной. Требования задаются назначением отчёта и договорённостью с пользователем данных.
Проверьте границы выгрузки
До поиска ошибок в строках убедитесь, что набор вообще полный. Узнайте источник, время формирования, применённый фильтр и дату, по которой выбраны события. «Заказы за месяц» могут означать созданные, оплаченные или завершённые за месяц заказы. Эти выборки различаются даже при одинаковом диапазоне дат.
Сохраните исходный файл отдельно от рабочей копии. Зафиксируйте число строк и контрольную сумму показателя, если она имеет смысл. Не считайте такой итог доказательством правильности: он нужен, чтобы объяснить изменения после обработки. Если исходная выгрузка включала отменённые заказы, её сумма может быть непригодна для отчёта о продажах.
При объединении нескольких файлов проверьте, не пересекаются ли периоды и не включён ли общий итог вместе с деталями. Одинаковое название столбца тоже не гарантирует одинакового смысла. В одном источнике «сумма» может включать доставку, в другом — только товары.
Разберите небольшую учебную таблицу
Ниже условные данные. Задача — получить сумму оплаченных заказов из выгрузки. Каждая строка должна представлять отдельный заказ, а идентификатор служит ключом. Все суммы указаны в рублях; налоги и состав выручки в этом учебном примере не рассматриваются.
| Заказ | Статус | Сумма, ₽ | Что проверить |
|---|---|---|---|
| А | Оплачен | 1 200 | Обычная запись |
| А | Оплачен | 1 200 | Повтор того же события |
| Б | Оплачен | 800 | Обычная запись |
| В | Отменён | 600 | Не подходит под условие отбора |
| Г | Не указан | 500 | Нужен ответ владельца источника |
Простое сложение даст 4 300 рублей. Но это сумма всех строк, а не подтверждённая сумма оплаченных заказов. После проверки, что повтор заказа А действительно технический, он учитывается один раз. Заказ В исключается по условию задачи. По заказу Г пока нельзя утверждать, была ли оплата.
Не удаляйте похожие строки автоматически
Одинаковые имя клиента и сумма ещё не означают дубль. Человек мог оформить разные заказы. И наоборот: повторная выгрузка одного события может содержать небольшое различие в написании имени. Нужен ключ, который соответствует выбранной единице наблюдения, и понятное правило проверки.
В нашем примере совпали идентификатор, статус и сумма, а источник подтвердил повтор загрузки. Поэтому одну строку убираем из расчёта, сохраняя запись о причине. Если это разные позиции одного заказа, удаление было бы ошибкой: сначала нужно изменить единицу анализа или собрать позиции в итог заказа.
Технические способы поиска рассмотрены в материале о дубликатах и уникальных значениях. Но решение, что считать повтором, предшествует выбору команды. При неопределённости пометьте строки для разбора, вместо того чтобы безвозвратно очищать их ради красивой таблицы.
Отделите пропуск от нуля
Пустое поле означает отсутствие значения, а не автоматически нулевой результат. Если сумма платежа неизвестна, подстановка нуля уменьшит итог и создаст ложную определённость. Если показатель действительно равен нулю, это должно следовать из события или правила учёта, а не из внешнего вида ячейки.
Пропуски полезно разделять по причинам: значение не требуется, ещё не поступило, потерялось при выгрузке или не было заполнено в источнике. Действия будут разными. Необязательное поле можно оставить пустым; отсутствие критичного статуса потребует уточнения или исключения записи из подтверждённого расчёта.
Для заказа Г создаём вопрос владельцу данных: «Подтвердите статус и основание оплаты». До ответа показываем его отдельно. Так читатель отчёта видит границу достоверного результата и не принимает незавершённую проверку за окончательную цифру.
Проверьте форматы, единицы и смысл
Число, сохранённое текстом, может не участвовать в ожидаемом расчёте. Дата в другом порядке компонентов способна попасть не в тот период. Но исправление формата не доказывает точность значения. Правильно оформленная сумма всё равно может быть ошибочно перенесена из другого заказа.
Сначала определите допустимый тип, затем сверяйте смысл с источником. Для денежных данных дополнительно проверьте валюту, масштаб и состав суммы. Тысячи рублей нельзя складывать с рублями без преобразования. Возвраты, скидки и отмены не следует менять местами только потому, что все они уменьшают итог.
Полезный контроль — сопоставить несколько записей с первичным источником, включая обычные и пограничные случаи. Такой просмотр не доказывает точность всего массива, но помогает обнаружить системную ошибку преобразования. Если она найдена, проверку распространяют на записи, обработанные тем же правилом.
Ведите реестр исправлений и сверяйте результат
Запишите для каждого типа дефекта правило, действие и основание. В учебной таблице повтор А уменьшает сумму строк на 1 200 рублей, исключение отменённого В — на 600 рублей, отделение неподтверждённого Г — на 500 рублей. Получаем 4 300 − 1 200 − 600 − 500 = 2 000 рублей подтверждённых оплаченных заказов.
Независимая проверка проще: сложить оставшиеся А и Б — 1 200 + 800 = 2 000 рублей. Оба пути совпали. При этом 500 рублей не исчезли из истории: запись Г остаётся в списке неопределённостей. После подтверждения её статуса итог может измениться, и это должно быть объяснимо.
Не исправляйте вручную исходник, если файл будет регулярно поступать заново. Лучше сохранить правило преобразования и контроль результата. Для повторяемых операций пригодится Power Query, но автоматизировать стоит уже понятное правило, а не неразобранную неоднозначность.
Решите, можно ли передавать данные в работу
Передача возможна, когда известны назначение таблицы, критичные ограничения и результат основных проверок. Иногда допустим предварительный отчёт с явно обозначенными неопределённостями. В другой ситуации пропуск ключевого источника делает расчёт бесполезным. Универсального процента ошибок, после которого любые данные становятся хорошими, здесь нет.
Сформулируйте заключение предметно: «Подтверждены оплаченные заказы А и Б на сумму 2 000 рублей; статус Г требует уточнения». Это полезнее фразы «таблица очищена». Получатель понимает и результат, и причину возможного будущего изменения, и ответственное следующее действие.
Если подготовка таблиц стала регулярной частью работы, на курсе Excel и Google Таблицы с нуля до PRO изучают форматы, проверку данных, дубликаты, формулы и преобразования в Power Query. Основа навыка остаётся одинаковой: сначала понять событие и правила данных, затем выполнять обработку и проверять получившийся результат.
Вопросы и ответы
- Чем качество данных отличается от оформления?
Оформление влияет на удобство чтения. Качество связано с пригодностью записей для задачи: их составом, точностью, согласованностью и актуальностью. Красивую таблицу всё равно нужно проверять.
- Любые одинаковые строки являются дублями?
Нет. Сначала определите единицу наблюдения и ключ. Похожие суммы могут относиться к разным заказам, а строки одного заказа — к разным товарным позициям.
- Можно ли заменить пустые значения нулями?
Только если это соответствует смыслу данных и принятому правилу. Неизвестное значение и подтверждённый ноль различаются; автоматическая подстановка может исказить расчёт.
- Нужно ли исправлять все поля перед анализом?
В первую очередь проверяют критичные для задачи сведения. Допустимые ограничения фиксируют и сообщают пользователю результата. Необязательное поле может не влиять на конкретный расчёт.
- Можно ли автоматизировать проверку?
Повторяемые понятные правила можно реализовать средствами таблиц и Power Query. Неоднозначные случаи требуют решения по содержанию; автоматизация не выбирает правильное определение события.