Аналитическая культура. От сбора данных до бизнес-результатов Андерсон Карл
Качество данных невозможно свести к одной цифре. Качество — это не 5 или 32. Причина в том, что это понятие охватывает целый ряд аспектов, или направлений. Соответственно, начинают выделять уровни качества, при которых одни аспекты оказываются более серьезными, чем другие. Важность этих аспектов зависит от контекста анализа, который должен быть выполнен с этими данными. Например, если в базе данных с адресами клиентов везде указаны коды штатов, но иногда пропущены почтовые индексы, то отсутствие данных по почтовым индексам может стать серьезной проблемой, если вы планировали построить анализ на основе показателя почтового индекса, но никак не повлияет на анализ, если вы решили проводить его на уровне показателя по штатам.
Итак, качество данных определяется несколькими аспектами. Данные должны отвечать ряду требований.
Доступность
У аналитика должен быть доступ к данным. Это предполагает не только разрешение на их получение, но также наличие соответствующих инструментов, обеспечивающих возможность их использовать и анализировать. Например, в файле дампа памяти SQL (Structured Query Language — языка структурированных запросов при работе с базой данных) содержится информация, которая может потребоваться аналитику, но не в той форме, в которой он сможет ее использовать. Для работы с этими данными они должны быть представлены в работающей базе данных или в инструментах бизнес-аналитики (подключенных к этой базе данных).
Точность
Данные должны отражать истинные значения или положение дел. Например, показания неправильно настроенного термометра, ошибка в дате рождения или устаревший адрес — это все примеры неточных данных.
Взаимосвязанность
Должна быть возможность точно связать одни данные с другими. Например, заказ клиента должен быть связан с информацией о нем самом, с товаром или товарами из заказа, с платежной информацией и информацией об адресе доставки. Этот набор данных обеспечивает полную картину заказа клиента. Взаимосвязь обеспечивается набором идентификационных кодов или ключей, связывающих воедино информацию из разных частей базы данных.
Полнота
Под неполными данными может подразумеваться как отсутствие части информации (например, в сведениях о клиенте не указано его имя), так и полное отсутствие единицы информации (например, в результате ошибки при сохранении в базу данных потерялась вся информация о клиенте).
Непротиворечивость
Данные должны быть согласованными. Например, адрес конкретного клиента в одной базе данных должен совпадать с адресом этого же клиента в другой базе. При наличии разногласий один из источников следует считать основным или вообще не использовать сомнительные данные до устранения причины разногласий.
Однозначность
Каждое поле, содержащее индивидуальные данные, имеет определенное, недвусмысленное значение. Четко названные поля в совокупности со словарем базы данных (подробнее об этом чуть позже) помогают обеспечить качество данных.
Релевантность
Данные зависят от характера анализа. Например, исторический экскурс по биржевым ценам Американской ассоциации землевладельцев может быть интересным, но при этом не иметь никакого отношения к анализу фьючерсных контрактов на грудинную свинину.
Надежность
Данные должны быть одновременно полными (то есть содержать все сведения, которые вы ожидали получить) и точными (то есть отражать достоверную информацию).
Своевременность
Между сбором данных и их доступностью для использования в аналитической работе всегда проходит время. На практике это означает, что аналитики получают данные как раз вовремя, чтобы завершить анализ к необходимому сроку. Недавно мне довелось узнать об одной крупной корпорации, у которой время ожидания при работе с хранилищем данных составляет до одного месяца. При такой задержке данные становятся практически бесполезными (при сохранении издержек на их хранение и обработку), их можно использовать только в целях долгосрочного стратегического планирования и прогнозирования.
Ошибка всего в одном из этих аспектов может привести к тому, что данные окажутся частично или полностью непригодными к использованию или, хуже того, будут казаться достоверными, но приведут к неправильным выводам.
Далее мы остановимся на процессах и проблемах, способных ухудшить качество данных, на некоторых подходах для определения и решения этих вопросов, а также поговорим о том, кто отвечает за качество данных.
Ошибки могут появиться в данных по многим причинам и на любом этапе сбора информации. Давайте проследим весь жизненный цикл данных с момента их генерации и до момента анализа и посмотрим, как на каждом из этапов в данные могут закрадываться ошибки.
В данных всегда больше ошибок, чем кажется. По результатам одного из исследований[23], ежегодно американские компании терпят ущерб почти в 600 млн долл. из-за ошибочных данных или данных плохого качества (это 3,5 % ВВП!).
Во многих случаях аналитики лишены возможности контролировать сбор и первичную обработку данных. Обычно они бывают одним из последних звеньев в длинной цепочке по генерации данных, их фиксированию, передаче, обработке и объединению. Тем не менее важно понимать, какие проблемы с качеством данных могут возникнуть и как их потенциально можно разрешить.
Цель этой части книги — выделить общие проблемы с качеством данных и возможные подводные камни, показать, как избежать этих проблем и как понять, что эти проблемы присутствуют в наборе данных. Более того, чуть позже вы поймете, что это призыв ко всем специалистам, работающим с данными, по возможности активно участвовать в проверке качества данных.
Итак, начнем с самого начала — с источника данных. Почему в данные могут закрасться ошибки и как с этим бороться?
Генерация данных — самый очевидный источник возможных ошибок, которые могут появиться в результате технологического (приборы), программного (сбои) или человеческого факторов.
В случае технологического фактора приборы могут быть настроены неправильно, что может сказаться на полученных данных. Например, термометр показывает 35 °C вместо 33 °C на самом деле. Это легко исправить: прибор или датчик можно настроить по другому, «эталонному», прибору, отражающему достоверные данные.
Иногда приборы бывают ненадежными. Мне довелось работать в грантовом проекте Агентства передовых оборонных исследовательских проектов Министерства обороны США (DARPA), посвященном групповой робототехнике. В нашем распоряжении была группа простейших роботов, задача которых заключалась в совместном картографировании местности. Сложность состояла в том, что инфракрасные датчики, установленные на роботах, были очень плохого качества. Вместо того чтобы сосредоточиться на разработке децентрализованного алгоритма для нанесения здания на карту, большую часть времени я потратил на работу с алгоритмическими фильтрами, пытаясь справиться с качеством информации от этих датчиков, измерявших расстояние до ближайшей стены или до других роботов. Значения сбрасывались, или показатель расстояния до ближайшей стены мог неожиданно измениться на целый метр (неточность > 50 %), притом что робот оставался неподвижным. Информации от этих датчиков просто нельзя было верить.
Когда в сборе данных принимают участие люди, ошибки в данных могут появиться по самым разным причинам. Сотрудники могут не знать, как правильно пользоваться оборудованием, они могут торопиться или быть невнимательными, они могут неправильно понять инструкции или не следовать им. Например, в двух больницах могут по-разному измерять вес пациентов: в обуви и без обуви. Для исправления ошибок такого рода требуются четкие инструкции и обучение персонала. Как с любым экспериментом, необходимо попытаться контролировать и стандартизировать как можно больше этапов процесса, чтобы данные оставались максимально достоверными, сравнимыми и удобными в использовании.
Когда данные генерируются вручную, например при измерении веса пациентов, их необходимо зафиксировать. Несмотря на обещания электронного офиса, большой объем данных сегодня по-прежнему сначала попадает на бумагу в качестве промежуточного шага до попадания в компьютер. На этом этапе может возникнуть множество ошибок.
Ошибки случаются при расшифровке документов, заполненных от руки. (Если бы вы видели мой почерк, у вас бы не осталось в этом сомнений.) Больше всего исследований в этой области проведено в сфере здравоохранения, частично потому что последствия использования неточной информации могут быть слишком серьезными, как с точки зрения здоровья пациентов, так и с точки зрения стоимости проведения ненужных медицинских тестов. Согласно результатам одного из исследований, 46 % медицинских ошибок (при базовом уровне 11 % от всех записей) обусловлено неточностью при расшифровке[24]. Уровень ошибок в базах данных некоторых клинических исследований достигал 27 %[25]. Подобные ошибки могли быть результатом того, что медицинский персонал неправильно читал или понимал написанное от руки, не слышал или не понимал информацию из-за плохого качества аудиоисточника или непривычных слов или неправильно вносил информацию в компьютер.
Например, я работал в одной из компаний в сфере здравоохранения, и основными базами данных, которые компания использовала чаще всего, были данные статистических опросов населения в рамках Национальной программы проверки здоровья и питания (NHANES). Мобильные клиники по всей стране проводили опросы населения: измеряли вес и артериальное давление, выясняли, есть ли в семье больные диабетом или раком, и так далее. Когда мы изучили информацию о человеческом росте в одной из баз данных по этому проекту, то обнаружили целый ряд людей с показателем роста пять дюймов (примерно 12,5 см)! Эти данные вносили в базу специально обученные сотрудники, которые изо дня в день проводили опросы населения. Поскольку измерение роста — относительно простая процедура, наиболее вероятной причиной ошибки кажется некорректный ввод информации. Возможно, рост респондентов на самом деле был пять футов и пять дюймов (примерно 162 см) или шесть футов и пять дюймов (примерно 192 см). К сожалению, поскольку мы не знали этого наверняка, нам пришлось отметить эти значения как неизвестные.
К счастью, показатель роста человека пять дюймов — это настолько очевидная ошибка, что нам удалось определить ее с помощью простой гистограммы, и мы точно понимали, что это ошибка. Однако так бывает не всегда. Есть разные степени очевидности ошибки. Предположим, что при расшифровке записей, сделанных от руки, сотрудник вместо «аллергия на кошек и собак» написал: «аллергия на окшек и собак». Слова «окшек» не существует. Очевидно, что это опечатка, а смысл легко поддается восстановлению по контексту. Более сложными могут оказаться случаи, когда при перестановке букв могут образоваться другие слова, имеющие смысл. Тогда заметить ошибку сложнее. Разобраться со смыслом можно с помощью контекста, но он не всегда служит гарантией. Наконец, представьте, что местами случайно переставили не буквы, а цифры, например в числе 56,789 поменяли две последние цифры: 56,798. Заметить ошибку в этом случае будет чрезвычайно сложно или даже невозможно.
В целом ошибки при вводе информации можно свести к четырем типам.
Запись
Введенные слова или показатели не те, что были в оригинале.
Вставка
Появление дополнительного символа: 56,789 564,789.
Удаление
Один или несколько символов теряются: 56,789 56,89.
Перемена мест
Два или более символов меняются местами: 56,789 56,798.
В качестве отдельных категорий «Вставки» и «Удаления» можно выделить диттографию — случайное повторение символа (56,789 56,7789) и гаплографию — пропуск повторяющегося символа (56,779 56,79). Эти термины употребляют ученые, занимающиеся восстановлением поврежденных и переписанных от руки древних текстов, и обозначают разновидность проблемы с некачественными данными.
Особенно часто опечатки встречаются в написании дат. Например, я британец, и в английской культуре принят определенный формат написания даты: день/месяц/год. Однако я живу в США, где формат написания даты отличается: месяц/день/год. Первые несколько лет жизни в США я постоянно путался, и могу предположить, что эта проблема знакома не только мне. Представьте себе сайт, на котором пользователи со всего мира вводят в специальное поле дату. У пользователей из разных стран могут быть разные ожидания относительно формата ввода этой информации, и без необходимых подсказок могут возникнуть ошибки при вводе данных. Некоторые их них легко заметить: например, 25 марта (3/25 в американском варианте) — 25 явно не может быть обозначением месяца. А как насчет 4/5? Вы уверены, что для всех пользователей эта дата обозначает 5 апреля?
Как бороться с такого рода ошибками?
Первый шаг, если он возможен, заключается в сокращении количества этапов от генерации данных до ввода. Скажу очевидное: если есть возможность избежать бумажной формы, лучше сразу вносить данные в компьютер.
Везде, где возможно, добавьте проверку значения каждого поля в свою электронную форму (рис. 2.1). То есть если данные четко структурированы и имеют установленный формат (например, почтовый индекс в США содержит от пяти до девяти цифр, а номер социальной страховки состоит из девяти цифр), проверяйте данные на соответствие этому формату, в противнм случае предложите пользователю исправить возможные ошибки. Процесс проверки не ограничен только числовыми значениями. Например, можно проверять, чтобы дата или время вылета «обратно» были позже, чем вылета «туда». Иными словами, проверяйте все что можно, чтобы максимально избежать «мусора» в самом начале.
Рис. 2.1. Пример проверки значений в онлайновой регистрационной форме
Источник: http://www.jqwidgets.com
Если есть ограниченный набор допустимых значений, например аббревиатуры названий штатов в США, предложите пользователю выбрать нужный вариант из меню выпадающего списка. Автозаполнение может стать еще одним вариантом. В целом стремитесь к тому, чтобы пользователю пришлось вводить как можно меньше данных: лучше предложить варианты ответа на выбор, если, конечно, это позволяет формат требуемой информации.
В идеале постарайтесь максимально исключить человеческий фактор при сборе данных и по возможности автоматизируйте этот процесс.
Если вы располагаете временем и ресурсами, поручите двум сотрудникам независимо друг от друга расшифровывать данные (или пусть это дважды делает один сотрудник), сравнивать результаты и перепроверять данные в случае расхождений. Этот метод известен как «принцип двойной записи». Однажды я поручил стажеру расшифровать параметры из набора технических чертежей, он сделал это, а затем по собственной инициативе выполнил работу еще раз с последующей проверкой на различия. Мне как получателю данных это обеспечило уверенность в том, что точность данных максимально соответствует моим ожиданиям.
Интересный метод проверки применяется при передаче важных данных в цифровой форме, например номеров банковских счетов, номеров социальной страховки или даже номера ISBN этой книги. Этот метод называется контрольное число. После передаваемого номера добавляется число, которое представляет собой определенную функцию остальных цифр номера, и это число используется для проверки того, что предыдущие цифры были переданы из системы в систему без ошибок. Предположим, вам нужно передать индекс 94121. Воспользуемся самой простой схемой. Последовательно сложим все цифры, составляющие наш индекс, и получим 17. Сложим и эти цифры, получим 8. Передаем число 941218. Принимающая система выполняет все те же самые операции, но в обратной последовательности. Она отсекает последнюю цифру: 94121 17 8. Проверяет сумму цифр и получает в итоге 8. Почтовый индекс передан верно. В случае ошибки при передаче данных, например если бы вы передали почтовый индекс 841218, система обнаружила бы ошибку при проверке: 84121 16 7 8.
Эта схема не отличается надежностью: 93221 (случайное повторение символа) или 94211 (перестановка символов местами) эту проверку пройдут. В случае необходимости контрольного числа в реальной жизни применяются более сложные математические функции, которые способны выявить в том числе и две указанные выше ошибки. Маршрутный номер (код банка, присваиваемый Американской банковской ассоциацией) — уникальное девятизначное число, стоящее в нижней части чека перед номером счета, — один из таких примеров[26]. Контрольное число маршрутного номера — функция
3 (d1 + d4 + d7) + 7 (d2 + d5 + d8) + d3 + d6 + d9 mod 10 = 0
(mod означает получение остатка от целочисленного деления. Так, 32 mod 10 = 2, поскольку 32 = 3 10 + 2), которая проверяется простым кодом на языке Python:
routing_number = "122187238"
d = [int(c) for c in routing_number]
checksum = (# do the math!
7 * (d [0] + d [3] + d [6]) +
3 * (d [1] + d [4] + d [7]) +
9 * (d [2] + d [5])
)% 10
print(d [8] == checksum)
Как видите, есть ряд способов, позволяющих сохранить высокое качество данных на стадии ввода информации. Но, к сожалению, и их нельзя считать абсолютно надежными. Итак, у вас в системе есть данные, которые переходят на стадию анализа. Что дальше?
При получении любой информации аналитику в первую очередь следует в той или иной форме провести разведочный анализ данных (глава 5) для оценки их качества. Простой способ проверки на вопиющие ошибки, как в приведенном выше примере с людьми пятидюймового роста, — сделать сводку из данных. Для каждого показателя можно составить пятичисловую сводку: два крайних значения (максимальное и минимальное значение), нижний (25-й процентиль) и верхний (75-й процентиль) квартили и медиану. Посмотрите на крайние значения. Насколько они адекватны? Они выше или ниже значений, которые вы могли бы ожидать? Пять дюймов — это очевидно слишком мало.
Вот пример того, как выглядит классификация набора данных по ирисам, представленная с помощью R — бесплатной и открытой программной среды для статистических вычислений и построения графиков, которой часто пользуются специалисты по статистике и работе с данными[27]. Американский ботаник Эдгар Андерсон собрал данные о 150 экземплярах ириса, по 50 экземпляров из трех видов, а Рональд Фишер на примере этого набора данных продемонстрировал работу созданного им метода для решения задачи классификации[28].
В этом виде можно легко получить общее представление о данных (1-й кв. = 1-й квартиль, или 25-й процентиль; 3-й кв. = 75-й процентиль). Ту же самую информацию можно представить в виде коробчатой диаграммы (рис. 2.2).
Рис. 2.2. Коробчатая диаграмма классификации набора данных по ирисам
На рис. 2.3 отражены некоторые ошибки, которые можно определить с помощью представления данных в виде простой гистограммы. В базе данных NHANES меня также интересовали данные, касающиеся артериального давления. После классификации выборки я получил максимальные значения артериального давления, которые показались мне гораздо выше нормы. Сначала я решил, что это тоже ошибка. Однако распределение показало, что эти значения хоть и находятся в хвосте распределения, но с разумной частотой. Я сверился с медицинской литературой и убедился, что значения артериального давления действительно могут быть такими высокими. Однако респондентами были люди, которые, скорее всего, не получали лечения. Как вы помните, опрос проводился среди всего населения США, а не среди пациентов медицинских учреждений, где им была бы оказана помощь, — все зависит от контекста.
Рис. 2.3. Примеры типов ошибок, которые можно выявить с помощью простой гистограммы: А — значения по умолчанию, такие как –1, 0 или 1/1/1900; B — неправильный ввод или повтор данных; C — пропущенные данные; D — значения по умолчанию, такие как 999
Два важных навыка, которые должны развивать в себе аналитики, — прогнозирование возможных результатов и способность предварительно оценивать данные[29]. Я ошибся относительно значений артериального давления, так как оценивал их с точки зрения нормы для обычных здоровых людей. Тем не менее я узнал нечто новое для себя, скорректировал свои ожидания и убедился, что данные, скорее всего, верные.
Это наглядный пример того, что изначально вы, возможно, будете ставить под сомнение все источники данных. Я всегда исхожу из базового предположения, что данные могут быть ошибочными, и моя работа в том, чтобы выяснить источник проблемы. Я не впадаю в крайности, но непременно провожу определенную работу (например, пользуюсь функциями summary(), pairs() и boxplot() в R, чтобы убедиться, что в данных нет очевидных ошибок. При работе с базами данных NANES мы с коллегами создали гистограммы всех показателей, чтобы отследить случайные образцы, бимодальное распределение и другие резко выделяющиеся значения. Подсчет числа записей на конкретную дату может послужить еще одним простым тестом. Подобный разведочный анализ данных может быть простым, быстрым и чрезвычайно ценным.
ПРОПУЩЕННЫЕ ДАННЫЕ
Одна из наиболее существенных проблем — неполные или пропущенные данные (рис. 2.3C). Эта ошибка может быть двух видов: пропуск данных в записи или пропуск всей записи.
ЗАПОЛНЯЕМ ПРОПУСКИ: МЕТОД ВОССТАНОВЛЕНИЯСуществуют статистические подходы, которые можно применить для восстановления пропущенных данных или подстановки на их место наиболее вероятных значений (мне нравятся инструмент Amelia package от R[30] и сервис подстановки Google[31]). Их успех зависит от ряда факторов, в том числе от размера выборки, количества и характера пропущенных данных, типа переменных (являются ли они однозначными, непрерывными, дискретными и так далее), а также зашумленности данных. Один из наиболее простых подходов заключается в том, чтобы заполнить пропущенные значения средним значением этой переменной. В более сложных подходах применяются вариации EM-алгоритма[32]. Рекомендуемые к прочтению книги по этой теме: Missing Data (автор — П. Эллисон) и Statistical Analysis with Missing Data (авторы — Р. Литтл и Д. Рубин)[33]. Это эффективный инструмент, но в зависимости от типа данных сделанные с его помощью прогнозы в некоторых случаях могут быть неверными.
Зачем тогда рисковать и использовать этот подход? Во многих случаях, особенно в медицине и социальных науках, сбор данных может быть очень дорогим, к тому же возможность для сбора может быть только одна. Например, если вам нужно узнать значение артериального давления пациента на третий день клинического исследования, вы не можете вернуться в этот день, чтобы еще раз его измерить. Основная проблема заключается в том парадоксе, что чем меньше размер выборки, тем более ценна каждая запись. При этом чем меньше информации, с которой приходится работать алгоритму по восстановлению данных, тем менее точным получится результат.
Какое-то из пропущенных значений в записи способно сделать бесполезной всю эту запись. Это происходит в случае отсутствия ключевой информации, то есть показателя, определяющего тему записи (например, идентификационные данные клиента или заказа) и необходимого для объединения с другими данными. Кроме того, это может иметь место в случае, когда анализ строился на пропущенных данных. Например, если вы решили проанализировать продажи по почтовому индексу, а в какой-то записи индекс отсутствует, очевидно, что вы эту запись использовать не сможете. Если вам повезло и пропущенные данные не требуются для анализа, то выборка может и не сократиться.
Как уже говорилось ранее, причины пропуска данных могут быть самыми разными. Например, при проведении опроса респондент может не понять или пропустить вопрос, человек, обрабатывающий анкеты, может не разобрать почерк, или респондент может «на полпути» отказаться от участия в опросе. Бывает, что подводят технические средства: выходит из строя сервер или датчик. Поскольку эти причины в значительной мере влияют на качество данных, важно выяснить, почему данные отсутствуют.
Предположим, сломался сервер, на котором локально хранились нужные вам данные. Это может быть примером полностью потерянных записей. При наличии выравнивателя нагрузки, работающего на 20 серверов, один из которых вышел из строя, вы потеряли 5 % информации — это неприятно, но, так как это случайная выборка, не все данные потеряны полностью. При этом, если наблюдалась какая-то закономерность, у вас могут быть проблемы. Например, если на сломавшийся сервер обычно поступала информация из конкретного географического региона, вы можете лишиться несоразмерного объема данных по этому отдельному региону, что может существенно повлиять на результаты анализа.
Возможны и другие сценарии, при которых выборка окажется необъективной. Например, представьте, что вы проводите опрос среди своих клиентов и даете респондентам две недели на то, чтобы прислать ответы. Ответы, полученные после указанной даты, рассматриваться не будут. А теперь предположим, что из-за проблем с доставкой группа клиентов получила свои заказы с опозданием. Возможно, они недовольны этой ситуацией и хотели бы выразить свое мнение, также ответив на ваш опрос и прислав его даже с опозданием. Если вы не учтете их ответы при анализе данных, то можете исключить из выборки большую долю недовольных клиентов. Оставшаяся выборка будет нерепрезентативной. В своих обучающих материалах по статистике Дэниел Минтц приводит пример формирования необъективной выборки: «Вопрос, нравится ли вам участвовать в опросах: да или нет?»[34] Как вы думаете, кто примет участие в этом опросе, а кто нет?
Причина, по которой пропущены данные, чрезвычайно важна. (Далее мы воспользуемся терминологией из области статистики, хотя она и ужасна.) Необходимо изучить, являются ли данные:
MCAR
Пропуски совершенно случайны, например распределяемый случайным образом трафик веб-сервера.
MAR
Пропуски случайны, но есть закономерности. Пропущенные данные — это функция от наблюдаемых, непропущенных данных, например веб-сервер, обслуживающий определенный регион, результатом чего стало уменьшение размера выборки почтовых индексов.
MNAR
Пропуски неслучайны, а пропущенные данные — функция других пропущенных данных, например недовольные покупатели и их ответы на опрос. Это наиболее опасный случай, где присутствует серьезная необъективность.
Чем ниже по списку, тем больше у вас может возникнуть сложностей и тем меньше шансов справиться с ситуацией.
Самое важное — понимать, что может послужить источником необъективности. В некоторых случаях можно намеренно ввести ограничения или проследить влияние на показатели. Как ни странно, бывают даже такие необычные ситуации, при которых пропущенные предвзятые данные могут не оказать никакого влияния на показатели.
Когда я преподавал статистику, то приводил следующий пример, чтобы показать свойства медианного значения. Есть такой необычный спорт — голубиная гонка. Владельцы почтовых голубей отвозят своих питомцев за сотни миль от дома, выпускают, а затем мчатся домой и ждут их возвращения. Так как это «гонка», то по возвращении каждого голубя фиксируется время, за которое он долетел до дома: например, голубь номер шесть вернулся через два часа три минуты, голубь номер одиннадцать — через два часа тринадцать минут и так далее. Неизбежно некоторые голуби не возвращаются: возможно, они сбились с курса или стали жертвой хищников. Мы не можем вычислить среднее время возвращения всех птиц, так как по некоторым из них нет данных. При этом, если больше половины вернулись, можно вычислить медианное значение времени полета. Нам известна величина выборки, известна продолжительность времени полета более половины участников выборки, мы знаем, что все пропущенные данные будут меньше значения последней прилетевшей птицы. Таким образом, мы вполне можем вывести медианное значение: оно будет достоверным с этим набором пропущенных данных. Иногда выбор правильных показателей может спасти ситуацию (выбору системы показателей посвящена глава 6).
Еще одна распространенная проблема — дублирование данных. Это означает, что одна и та же запись появляется несколько раз. Причины могут быть разными: например, предположим, у вас десять файлов, которые нужно внести в базу данных, и вы случайно загрузили файл номер шесть дважды, или при загрузке файла возникала ошибка, вы остановили процесс, устранили ошибку и повторили загрузку, но при этом первая половина данных загрузилась в вашу базу дважды. Дублирование данных может возникнуть при повторной регистрации. Например, пользователь прошел регистрацию несколько раз, указал тот же самый или другой адрес электронной почты, в результате чего у него появилась другая учетная запись с той же самой персональной информацией. (Звучит просто, но подобная неопределенность может оказаться весьма коварной.) Дублирование информации также может возникнуть в результате того, что несколько приборов фиксируют ее по одному событию. В исследовании медицинских ошибок, о котором шла речь ранее, в 35 % случаев причиной ошибки был неправильный перенос данных из одной системы в другую: иногда данные терялись, иногда дублировались. По данным госпиталя Джонса Хопкинса, в 92 % случаев дублирование информации в их базе данных происходило в момент регистрации стационарных больных.
Когда речь идет о базах данных, есть несколько способов предотвратить дублирование. Наиболее эффективный — добавление ограничений в таблицу с базой данных. Вы можете создать составной ключ, который определяет одно или несколько полей и делает запись уникальной. После добавления этого ограничения у вас будет появляться оповещение, если вводимая комбинация данных совпадет с уже существующей в таблице. Второй способ — выбор варианта загрузки данных по принципу «все или ничего». Если в момент загрузки данных обнаруживается проблема, происходит откат на изначальные позиции, а новая информация в базе данных не сохраняется. Это дает шанс разобраться с причиной проблемы и повторить процесс загрузки данных без дублирования информации. Наконец, третий (менее эффективный) подход — выполнять две операции при загрузке: первая операция — SELECT, чтобы выяснить, не присутствует ли уже такая запись, вторая операция — INSERT, добавление новой записи.
Подобное дублирование данных случается чаще, чем вы думаете. Если вы не знаете, что в ваших данных встречается продублированная информация, это может повлиять на ваши показатели. Но хуже всего, что в какой-то момент времени это все равно обнаружится. А если качество данных будет поставлено под сомнение хотя бы однажды, это снизит доверие к выводам аналитиков, и эти выводы не будут учитываться в процессе принятия бизнес-решений.
При загрузке информации в базу данных часть ее может потеряться (Anderson anders или 5456757865 54567578). В лучшем случае можно лишиться пары символов в форме обратной связи. В худшем может произойти усечение и объединение идентификационных данных двух разных клиентов и вы непреднамеренно объедините данные двух разных клиентов или заказов в один.
Как такое может произойти? В обычных реляционных базах данных при создании таблицы задаются название и тип каждого поля: например, должен быть столбец под названием «Фамилия» с ячейками, содержащими до 32 символов, или столбец «ID клиента» с целым числом в диапазоне от 0 до 65535. Проблема в том, что не всегда заранее известно максимальное количество символов или максимальное значение идентификатора, с которыми вам придется столкнуться. Возможно, вы получите образец данных, рассчитаете длину ячейки и для подстраховки увеличите это значение в два раза. Но вы никогда не узнаете наверняка, достаточно ли этого, пока не начнете работать с реальными данными. Более того, в базах ошибки с усечением данных, как правило, относятся к категории предупреждений: появляется оповещение, но процесс загрузки данных не прекращается. В результате такие проблемы легко не заметить. Один из способов предотвратить это — изменить настройки в базе данных, чтобы предупреждения отображались как полноценные ошибки и заметить их было легче.
Еще один источник проблем с качеством данных — несовпадение единиц измерения, особенно когда речь идет о международных командах и наборах данных. CNN сообщает[35]:
Агентство NASA потеряло орбитальный аппарат по исследованию Марса стоимостью 125 млн долл. из-за того, что команда технических специалистов корпорации Lockheed Martin использовала при расчетах английские единицы измерения [фунт-секунда], в то время как специалисты самого агентства пользовались более привычной метрической системой [ньютон-секунда] для управления аппаратом.
Да, это действительно настолько важно. Единственный способ избежать подобного — иметь четко налаженную систему коммуникации. Разработайте нормативный документ, утверждающий процедуру всех проводимых измерений, то, как они должны выполняться, и в каких единицах измерения должен указываться результат. Необходимо, чтобы документ был однозначным и не допускал иных толкований, а итоговая база данных сопровождалась подробным словарем базы данных.
Другая область, где единицы измерения имеют критическое значение, — денежные валюты. Представим сайт для электронной коммерции, на котором размещен заказ стоимостью 23,12. В США по умолчанию будет считаться, что это 23,12 долл., в то время как во Франции это будет 23,12 евро. Если заказы из разных стран окажутся объединены в одну базу данных учета информации по валютам, то итоговый анализ будет иметь отклонения в сторону более слабой валюты (поскольку в числовом выражении цена за тот же предмет будет выше) и фактически окажется бесполезен.
Базы данных должны обеспечивать столько метаданных и контекста, сколько необходимо, чтобы избежать подобного недопонимания.
Кроме того, можно просто принять метрическую систему и придерживаться ее (проснись, Америка!).
Следующая проблема с данными, которую в некоторых случаях бывает сложно отследить, это значения по умолчанию (рис. 2.3A и D). Пропущенные данные могут отражаться в базе данных как NULL, но также может использоваться определенное значение, которое можно задать. Например, 1 января 1900 года — стандартная дата по умолчанию. С ней могут быть разные проблемы. Во-первых, если вы забудете о том, что эта дата появляется по умолчанию, результаты анализа могут вас весьма озадачить. Предположим, вы оставили это значение по умолчанию в ячейке с датой рождения. Аналитиков может смутить тот факт, что столько людей в вашей базе данных старше 100 лет. Во-вторых, при неудачном значении по умолчанию есть риск перестать различать пропущенные и актуальные данные. Например, если вы устанавливаете «0» как значение по умолчанию для пропущенных данных, а значение актуальных данных тоже может быть равным 0, впоследствии вы не сможете определить, в какой ячейке отражены результаты измерения, а в какой просто пропущены данные. Отнеситесь к выбору значений по умолчанию внимательно.
Происхождение данных
При обнаружении проблемы с качеством данных важно отследить источник данных. В этом случае можно будет извлечь из анализа проблемную выборку или предложить более эффективные процессы и протоколы работы с этими данными. Для метаданных, хранящих информацию об источнике данных и историю их изменений, я использую термин «происхождение данных».
Эти метаданные делятся на два типа: история источников (отслеживает, откуда появились данные) и история преобразований (отслеживает, какие изменения претерпевали данные).
В моей команде мы, например, ежедневно собираем файлы данных от разных разработчиков и загружаем их в нашу базу данных для проведения анализа и составления отчетов. Обычно промежуточные таблицы, в которые мы заносим всю информацию, содержат два дополнительных поля: время начала загрузки (конкретного файла или группы файлов) и название файла. Таким образом, если у нас возникают проблемы с качеством данных, мы легко можем определить, из какого файла эти данные, и уточнить их у разработчиков. Это пример истории источников.
В транзакционных базах данных (то есть тех, которые поддерживают работающие приложения и используются, например, для обработки заказов, а не для составления отчетов) довольно часто встречаются два поля: created_at (вемя создания) и last_modified (последнее изменение). Как следует из названия полей, они содержат уточняющую информацию о времени создания записи (эта метаинформация заносится один раз и больше не меняется) и о времени, когда было сделано самое недавнее изменение (эта метаинформация обновляется в режиме реального времени каждый раз, когда в запись вносятся любые изменения). Иногда в таблице может быть дополнительное поле modified_by, в котором фиксируется имя пользователя, внесшего последнее изменение. Это помогает определить, например, было ли изменение в заказе или адресе электронной почты сделано самими пользователями или представителем, действующим от имени клиента. В данном случае элемент created_at — история источников, в то время как элементы last_modified и modified_by отражают историю преобразований. Наиболее детальный инструмент отслеживания происхождения — таблицы с журналом событий, где четко протоколируется, какие именно изменения, кем и когда были внесены.
Метаданные о происхождении должны быть элементом проактивной стратегии проверки, поддержания и улучшения качества данных.
Велика вероятность, что важность фактора происхождения данных будет только расти. Сегодня становится все легче создавать системы для сбора и хранения собственных данных и предлагать для коммерческого использования подходящие дополнительные данные от третьих сторон (такие как демографические данные по почтовым индексам или история покупок по адресам электронной почты). Этим компаниям необходимо создавать более обширный контекст вокруг своих клиентов, а также вокруг своих открытых и внутренних данных по событиям и транзакциям. Это требует создания объектов на основе многочисленных источников данных, а также изменения существующих данных, например восстановления пропущенных данных или пояснения данных дополнительными характеристиками, такими как предполагаемый пол, цель и так далее. При этом всегда должна оставаться возможность отследить первоначальные значения данных, их источник, а также причину или метаинформацию по любому изменению данных.
Качество данных как совместная ответственность
Причины, обусловливающие снижение качества данных, могут быть самыми разными. Помимо уже перечисленных ранее, могут возникнуть проблемы с определением окончания строк, проблемы с кодировкой, когда данные в кодировке Юникод сохраняются в ASCII (это происходит сплошь и рядом), могут быть поврежденные данные, усеченные файлы, несовпадения в именах и адресах (см. табл. 2.1). Вопросами качества данных должны заниматься не только специалисты по сбору и обработке данных — эту ответственность должны разделять все сотрудники компании.
Таблица 2.1. Краткий обзор некоторых типов проблем с качеством данных и потенциальные варианты их решения. Более подробный список можно найти у Singh and Singh. A descriptive classification of causes of data quality problems in data warehousing, IJCSI Intl. J. Comp. Sci 7, no. 3 (2010): 41–50
Разработчик внешнего интерфейса может добавить в форму на сайте функцию контроля правильности ввода почтового индекса. Специалист по обработке данных может добавить контрольную цифру при передаче данных в другое хранилище. Администратор базы данных может проверить и предотвратить дублирование информации или отследить ошибки при загрузке данных. Однако сложно ожидать, что им известно, какие показатели систолического артериального давления находятся в пределах нормы, а какие нет. Когда компания получает данные на основе заполненных форм, руководители подразделений, эксперты в предметных областях и аналитики должны быть в тесном контакте с разработчиками внешнего интерфейса, чтобы допустимые границы ввода данных были заданы правильно. Кроме того, они должны принимать участие в процессе формулирования требований и управления проектом, чтобы обеспечить контроль качества данных там, где это возможно. Как уже отмечалось ранее, специалисты по аналитике должны активно участвовать в процессе сбора данных.
Далее руководители направлений и эксперты в предметных областях должны проверить качество данных. Аналитики должны провести разведочный анализ или воспользоваться собственными методами определения, находятся ли значения в допустимых границах, соблюдаются ли ожидаемые закономерности (например, соотношение систолического и диастолического давления), оценить объем пропущенных данных и так далее. На фермерском рынке шеф-повар ресторана сам выбирает продукты, пробует авокадо, нюхает базилик. Образно говоря, это его сырые ингредиенты. У аналитиков должно быть такое же отношение к данным. Это их сырые ингредиенты, которые они должны тщательно отобрать.
Руководители направлений, как правило, принимают решения о покупке баз данных у третьих сторон, о разработке инструментов по сегментированию аудитории в ходе опроса клиентов или о проведении A/B-тестирования онлайн. Они тоже должны задумываться об объективности данных, на которые опираются. Они должны проводить сами или делегировать проведение разведочного анализа данных, составлять диаграммы распределения и обнаруживать «пятидюймовых» людей.
Глава 3. Сбор данных
Ошибки, возникающие при использовании неправильных данных, все же меньше, чем те, которые возникают при отсутствии данных.
Чарльз Бэббидж[36]
Сложно даже представить себе ту власть, которой может обладать человек, когда в его распоряжении столько информации самого разного рода.
Тим Бернерс-Ли[37]
* * *
В предыдущей главе мы обсудили вопросы качества данных и их правильного сбора. В этой главе фокус сместится на выбор правильных источников для сбора данных и предоставления специалистам по аналитике. Мы остановимся на следующих вопросах: как расставить приоритеты при выборе источников данных, как осуществить сбор данных, как определить ценность данных для компании.
Собирайте все что можно
Предположим, вы внедряете новый процесс оформления и оплаты заказов на сайте. Вас интересует, как именно он работает по сравнению с вашими показателями. Для этого вы можете проанализировать конверсию, размер корзины и другие параметры. Кроме того, вам было бы весьма полезно понять, как этот новый процесс воспринимается со стороны покупателей. Например, на некоторых сайтах добавление товара в корзину происходит в один клик мыши, так что модель поведения покупателя может быть следующей: он добавляет в корзину все, что его заинтересовало, а перед оформлением заказа делает окончательный выбор, удаляя лишнее. На других сайтах добавление товаров в корзину и удаление из нее происходит не так просто, и фактически покупателю нужно принять окончательное решение перед добавлением товара в корзину. Очевидно, что всестороннее изучение и измерение процесса оформления и оплаты заказов помогает лучше его понять и внести изменения или улучшения.
В своей книге Building Data Science Teams[38] Ди Джей Патиль отмечает:
Легко сделать вид, что вы действуете на основании анализа данных. Но если на самом деле собирать и измерять все доступные вам данные и думать о том, что означают собранные вами данные, вы намного опередите все те компании, которые лишь заявляют об управлении на основе данных.
Собирайте все доступные данные. Никогда не знаешь, какая информация может понадобиться, а шанс собрать данные часто выдается только один, и вы будете кусать локти, когда поймете, что нужная вам информация больше недоступна. Чем больше данных вы соберете, тем больше вероятность, что вам удастся смоделировать и понять поведение пользователей (как в примере с процессом оформления и оплаты заказа) и, что более важно, понять контекст их действий. Контекст — наше все. Таким образом, чем лучше компания поймет своих покупателей, их вкусы, намерения, желания, тем успешнее ей удастся улучшить пользовательский опыт своих клиентов благодаря персонализации, рекомендациям или совершенствованию сервиса, что будет способствовать возникновению так называемого длинного хвоста[39].
При разработке онлайновых продуктов сбор абсолютно всех данных нельзя считать чем-то уникальным. Вы контролируете источник данных: сбор информации относительно одной какой-то характеристики может проводиться с помощью того же самого или похожего механизма, что и сбор информации относительно другой характеристики. То есть существует возможность использования общих шаблонов, потоков данных и механизмов хранения. Компания, в которой действительно уделяется большое внимание данным, вероятно, будет характеризоваться более широким горизонтом мышления. В такой компании все остальные функции также окажутся организованы на основе данных: маркетинг, продажи, обслуживание клиентов, цепочка поставок, работа с персоналом. Если по каждому из этих направлений имеется набор внутренних и внешних источников данных в разных форматах, с разным временем ожидания, проблемами с качеством данных, с разными требованиями к безопасности и соответствия нормативам и так далее, то это начинает превышать возможности команды специалистов по работе с данными. Это тот случай, когда «собирать все что можно» звучит как отличная идея, которая оборачивается серьезной «головной болью», когда доходит до дела.
Более того, этот процесс требует финансовых затрат. Чем больше данных, тем лучше[40] (см. приложение А, где приведены примеры и объяснение, почему это так), но какую цену компания за это платит? На создание инфраструктуры для сбора, очистки, трансформации и хранения данных нужны средства. Компания несет издержки на поддержание работоспособности этой инфраструктуры, резервное копирование данных, интеграцию источников этих данных для обеспечения целостной картины бизнеса. Кроме того, возможны значительные дальнейшие издержки на обеспечение качественного инструментария для специалистов по анализу данных, чтобы они могли максимально эффективно использовать эти несопоставимые источники данных. Компании не обойтись без всего этого, если она стремится, чтобы правильные данные попали в руки специалистов по анализу.
ОСНОВНЫЕ ХАРАКТЕРИСТИКИ БОЛЬШИХ ДАННЫХСпециалисты по большим данным выделяют три аспекта сбора и обработки большого количества данных: объем, разнообразие и скорость[41].
Объем
Объем данных напрямую влияет на издержки на их хранение и изменения. Хотя абсолютно верно, что расходы на хранение данных снижаются экспоненциально[42] (сегодня хранение информации обходится в 0,03 долл. за GB по сравнению с примерно 10 долл. за GB в 2000 году), число доступных источников данных повысилось настолько значительно, что это перекрывает снижение затрат на хранение информации.
Разнообразие
Это еще один важный аспект данных. С одной стороны, разнообразный набор источников способен обеспечить более богатый контекст и более полную картину. Таким образом, прогноз погоды, данные по инфляции, сообщения в социальных медиа могут оказаться весьма полезными для понимания продаж ваших продуктов. При этом, чем разнообразнее тип данных и источники данных (CSV-файлы из одного источника, объекты JavaScript (JSON) из другого источника, почасовой прогноз погоды отображается здесь, а данные о запасах — здесь), тем выше будут издержки на интеграцию. Довольно сложно собрать все данные вместе, чтобы получить общую картину.
Скорость
Объем данных, который требуется обработать в единицу времени. Представьте, что в ходе дебатов кандидатов в президенты вам нужно проанализировать сообщения в Twitter, чтобы вывести общее настроение избирателей. Необходимо не только обработать огромный объем информации, но также оперативно предоставить обобщенную информацию о настроении нации относительно комментариев во время дебатов. Масштабная обработка данных в режиме реального времени — процесс сложный и дорогостоящий.
(В некоторых случаях компании выделяют еще один аспект — «достоверность», для характеристики качества данных.)
Даже компаниям, сегодня собирающим огромные объемы данных, например Facebook, Google и Агентству национальной безопасности США (NSA), на это потребовалось время. Только со временем удается выстроить источники данных, взаимосвязи между ними и возможности обработки данных. Требуется рациональная и тщательно продуманная стратегия обеспечения данными. Более того, в большинстве компаний команды, работающие с данными, ограничены в ресурсах: они не в состоянии делать все и сразу, так что им приходится расставлять приоритеты, с какими источниками данных работать в первую очередь. Реальность такова, что процесс сбора данных идет медленно и последовательно: всегда возникают непредвиденные задержки и проблемы, так что приходится сосредоточиваться на ценности, рентабельности инвестиций и влиянии, которое новый источник данных окажет на компанию. Этому и будет посвящена данная глава.
Расстановка приоритетов при выборе источников данных
В обычных малых или средних компаниях, ограниченных в ресурсах, специалистам по работе с данными, как правило, приходится выбирать, с каким источником данных работать. Чем они при этом руководствуются? Определяя приоритеты при выборе источников данных, компания, в которой управление осуществляется на основе данных, должна сосредоточиться на таком важном аспекте, как ценность данных для бизнеса.
Основная цель команды по работе с данными заключается в том, чтобы предоставлять данные, отвечающие потребностям определенных подразделений компании и их аналитиков, и помогать оказывать влияние на эффективность деятельности компании. У каждой команды или подразделения, как правило, имеется набор «основных» данных. Например, для специалистов по обслуживанию клиентов это могут быть данные по взаимодействию с ними посредством электронной почты, телефонных звонков, социальных медиа, данные по заказам клиентов, а также разбор конкретных ситуаций. На основе этих данных команда может выполнять свои основные функции — максимально эффективно обслуживать клиентов. Кроме того, специалисты могут объединить эти источники для создания целостного взгляда на сценарии взаимодействия с клиентами. Они могут предоставить обобщенные показатели продуктивности работы команды, такие как среднее время решения проблемы клиента, а также проанализировать тип взаимодействий в случае каждого источника. У каждой команды специалистов должны быть свои основные данные. Однако, помимо этого, у них могут быть и другие данные, способные дополнить основной набор. Например, коэффициент дефектности продукции или данные A/B-тестирования, проясняющие, какая новая характеристика товара привела клиентов в замешательство. На основе этих данных специалисты могут прогнозировать частоту и характер ситуаций при работе с клиентами, которых можно ожидать. Эти другие источники данных также могут быть ценными и оказывать влияние, но они не критические.
Проблема компании с ограниченными ресурсами в том, что команда специалистов по работе с клиентами — лишь одна из многих. У команд специалистов в других областях есть свои наборы основных данных и свои пожелания относительно информации, «которую было бы неплохо иметь». Специалист по работе с данными или руководитель команды по работе с данными вынужден уравновешивать все эти запросы от разных команд специалистов. В табл. 3.1 приводится ряд показателей, способных помочь в расстановке приоритетов. Основной фактор — рентабельность инвестиций (ROI), но стоит принимать во внимание и другие факторы, такие как доступность, полнота, качество данных и некоторые другие.
Таблица 3.1. Аспекты, на которые следует обратить внимание при расстановке приоритетов при выборе новых источников данных в условиях ограниченности ресурсов
Очевидно, что самые разные, нередко конкурирующие аспекты определяют, какой новый источник данных целесообразно использовать в компании. Существует тонкий баланс между издержками на приобретение новых данных и сложностью этого процесса и той ценностью, которую эти данные имеют для аналитиков и компании в целом.
Установление взаимосвязи
Очевидно, что для проведения более глубокого анализа важное значение имеет сбор данных внутри компании: вы получаете определенные данные из отдела маркетинга, данные из отдела продаж, данные по цепочке поставок. Однако еще большую ценность эти данные обретают, когда вы начинаете устанавливать взаимосвязи между смежными данными. Что я имею в виду?
Представьте, что вам предложили тысячу элементов для составления пазла, но на коробке при этом нет изображения того, что должно в итоге получиться. По мере сортировки элементов вы выделили группу элементов голубого цвета. Вероятно, это небо. Группа элементов зеленого цвета может изображать траву. Вот вы нашли глаз. Но чей — животного или человека? У вас появляется смутное представление о картинке в целом, но не хватает деталей. Детали возникают, когда вы начинаете соединять смежные элементы, например элементы с изображением глаза и элементы с изображением уха. Появилась ясность. Давайте рассмотрим эту ситуацию с точки зрения аналитики.
Предположим, вы пользуетесь сервисом Google Analytics для анализа того, как пользователи попадают на ваш сайт. Вы получаете подборку веб-страниц, с которых произошел переход на ваш сайт, а также список поисковых запросов, географию пользователей и так далее, что дает вам общее представление о выборке пользователей или генеральной совокупности (это условные «кусочки неба»). Вы анализируете результаты опроса покупателей за последние три месяца: 75 % респондентов нравится цена, 20 % похвалили качественное обслуживание и так далее (это «кусочки травы»). У вас складывается общее представление о состоянии дел, но весьма поверхностное, так как данные остаются разрозненными.
Теперь, наоборот, представим, что мы имеем дело с одним заказом (см. рис. 3.1). Белинда Смит заказывает комплект садовой мебели. Если сопоставить ее заказ с сессией, во время которой она совершила покупку, можно сделать определенные выводы: она потратила 30 минут на просмотр 15 разных комплектов садовой мебели, прежде чем остановилась на одном. Очевидно, у нее не было четкого представления, какой комплект она ищет. Как она попала на страницу компании? Если добавить сопутствующую информацию, выяснится, что она ввела поисковый запрос в Google и перешла на сайт компании. Это подтверждает наше предположение относительно ее пользовательского поведения. Если к этому добавить полную историю ее онлайновых покупок, можно сделать вывод, что Белинда часто покупает товары для дома, а за последний месяц количество таких покупок у нее резко увеличилось. Те факты, что Белинда часто совершает покупки онлайн и пользуется поисковым сервисом Google, позволяют предположить, что у нее нет лояльности к конкретным брендам и компании придется постараться, чтобы она совершила повторную покупку. Каждый раз, добавляя новый элемент информации на индивидуальном уровне, вы начинаете лучше понимать этого покупателя. Продолжим. На основе данных переписи населения США определим вероятный пол по имени: Белинда практически наверняка женщина. Отлично. При оплате покупки она указала адрес доставки. Попробуем извлечь демографические данные на основании индекса. Это пригород с большими земельными участками, где живут состоятельные люди. Как еще можно проверить этот адрес? «Пробьем» его по единой базе данных недвижимости (MLS). Интересно, база данных показывает, что это дом с бассейном. Эту информацию можно использовать для полезных рекомендаций. Что еще? Дом был продан всего шесть недель назад. Ага, вероятно, Белинда только что въехала в новый дом. По результатам другого проведенного нами анализа известно, что новоселы часто покупают коврики, кровати и лампы (да, так и есть, я сам проводил этот анализ). Наконец, она нажала на виджет «приведи друга», чтобы получить купон при оформлении заказа. Так как она приняла условия пользовательского соглашения с Facebook, это открыло ее социальную сеть. (Подробнее о вопросах этики и сохранения конфиденциальности мы поговорим в главе 12.)
Рис. 3.1. Определение более широкого контекста для заказа Белинды на основе разных источников данных
Источник: https://www.slideshare.net/CarlAnderson4/ddo-seattle
Для аналитика этот подробный профиль и контекст предлагают огромный объем сырых данных, с которыми можно работать. Специалист получает четкое представление о демографических данных клиента, истории его покупок и, в этом случае, даже о его мотивации. Проведите такой анализ для других ваших клиентов и автоматизируйте хотя бы часть этого анализа — и вы получите значительное стратегическое преимущество.
Установление взаимосвязи между элементами информации на этом индивидуальном уровне, в противоположность уровню сегмента, имеет огромную ценность и должно влиять на решения о том, какой набор данных использовать следующим (без нарушения этических норм и границ конфиденциальности), а также как связать эти данные с уже имеющимися на индивидуальном уровне.
Сбор данных
Теперь, когда мы разобрались, какие данные нужно собирать, давайте кратко остановимся на вопросе, как это делать.
В случае со многими источниками можно просто системно собирать все доступные данные. Есть много способов управления потоками данных. Можно воспользоваться интерфейсом прикладного программирования (API) или собирать файлы с FTP-сервера, можно даже проводить анализ экранных данных и сохранять что необходимо. Если это одноразовая задача, с ней легко справиться. Однако при частом обновлении или добавлении данных нужно решить, как работать с этим потоком. Для небольших таблиц или файлов может быть проще полностью заменять их новым, более масштабным набором данных. В моей команде маленькими у нас считаются таблицы с количеством строк до 100 тысяч включительно. Для работы с более крупными массивами данных необходимо установить более сложный процесс с анализом изменений. В самом простом случае новые данные всегда вносятся в новые ряды (например, журналы транзакций, где не должно быть обновлений или удалений текущих данных). В этом случае можно просто добавить (INSERT) новые данные в таблицу с текущими данными. В более сложных случаях необходимо решить, будете ли вы добавлять (INSERT) строку с новыми данными, удалять (DELETE) или обновлять (UPDATE).
Для других источников данных может потребоваться сделать выборку. Проведение опросов и обработка результатов иногда бывает слишком дорогостоящим процессом, так же как и проведение клинических исследований или анализ всех записей в Twitter. То, каким образом осуществляется выборка, оказывает огромное влияние на качество данных. Мы поговорим об этом подробнее в главе 8, однако необъективная выборка в значительной степени влияет на качество данных и возможность их использования. Самый простой подход заключается в формировании «простой случайной выборки»[43], когда данные, которые будут включены в выборку, определяются простым подбрасыванием монетки. Суть в том, чтобы выборка была действительно репрезентативной относительно более крупного массива данных, из которого она формируется.
Внимательно стоит отнестись к формированию выборки данных, которые собираются в течение определенного периода времени. Предположим, вам требуется выборка сессий сайта за день. Вы отбираете 10 % сессий и загружаете информацию о них в базу данных для последующего анализа. Если вы проделываете эту процедуру ежедневно, у вас формируется набор независимых сессий, выбранных случайным образом, но при этом вы можете упустить данные о пользователях, которые посетят сайт в последующие дни. То есть в выборке может не оказаться информации о пользователях с несколькими сессиями: они могут попасть в выборку в понедельник, но не попадут туда при их возвращении на сайт в среду. Таким образом, если вас больше интересуют последующие повторные сессии, а пользователи вашего сайта часто возвращаются, для вас может быть эффективнее выбрать случайным образом посетителей и отслеживать их сессии на протяжении определенного времени, чем делать случайную выборку сессий. В этом случае вы получите для работы данные более высокого качества. (Хотя, возможно, вам будет не слишком приятно наблюдать за пользователями, которые не возвращаются на сайт.) Механизм формирования выборки должен определяться тем бизнес-вопросом, ответ на который вы ищете.
И последнее: следует ли собирать сырые или агрегированные данные? Некоторые поставщики данных предлагают дашборды, где данные агрегированы в соответствии с ключевыми показателями, необходимыми аналитикам. Для аналитиков это может оказаться большим подспорьем. Однако если данные действительно ценные, для аналитиков такого подхода будет недостаточно: они непременно захотят еще больше углубиться в их изучение и рассмотреть их с самых разных сторон, а с дашбордами сделать это не удастся. Все эти отчеты и дашборды эффективно использовать для архивного хранения данных. В других случаях, как показывает мой опыт, лучше по возможности собирать сырые данные, так как вы всегда сможете агрегировать их согласно показателям, но не наоборот. Имея сырые данные, вы сможете работать с ними как вам потребуется. Конечно, бывают редкие случаи, когда сбор сырых данных нерационален, например в силу большого их объема и высокой стоимости хранения или по причине того, что поставщик данных предлагает ценный сервис для обработки этих показателей (что вы не сможете сделать самостоятельно), но в большинстве случаев сбор сырых данных все-таки предпочтителен.
Покупка данных
Как правило, внутренние системы сбора данных в компании обеспечивают огромные массивы информации, которые можно дополнить данными, находящимися в открытом доступе, хотя иногда нужно заплатить за получение дополнительных данных от третьих сторон.
Существует множество причин, по которым вам может потребоваться покупать данные. Ранее мы анализировали заказ Белинды Смит на комплект садовой мебели, чтобы показать значимость контекста. Во-первых, другие партнеры, поставщики или даже государственные структуры могут располагать данными, способными обеспечить нужный контекст и добавить в вашу головоломку смежные элементы. Во-вторых, вы можете обладать внутренними данными, но данные третьей стороны могут выигрывать по объему или качеству.
В некоторых случаях выбор мест, где приобретать данные, может оказаться ограниченным. Например, единая база данных недвижимости (MLS) практически монопольно предоставляет информацию по сделкам. В других случаях возможна прямая конкуренция. Например, данные по профилям клиентов на основании их покупок, оплаченных с помощью кредитных карт, можно приобрести у нескольких компаний: Datalogix, Axciom, Epsilon или Experian. Это рыночные условия в действии.
При выборе между несколькими источниками данных, например при приобретении базы данных, в которой почтовые индексы соотнесены с местностью на карте, необходимо принять во внимание несколько факторов, в том числе перечисленные ниже.
Цена
Аналитики и их боссы любят «халяву», но иногда стоит заплатить за данные высокого качества. Следует взвесить, насколько рациональна цена и какой ценностью эти данные обладают для компании. Подробнее об этом мы поговорим в следующем разделе.
Качество
Насколько чисты и надежны эти данные?
Эксклюзивность
Подготовлен ли этот набор данных исключительно для вас и получите ли вы с его помощью преимущество перед конкурентами?
Выборка
Можно ли получить выборку, которая позволит судить о качестве и характере данных, а также понять формат без необходимости предварительно брать на себя обязательства?
Обновления
Насколько часто данные меняются или устаревают? Насколько часто данные обновляются?
Надежность
При обращении к интерфейсу прикладного программирования (API) каково время работоспособности системы? Каковы ограничения по обращениям к API или по другим сервисным соглашениям?
Безопасность
В случае, если данные важны, осуществляется ли их шифровка и какие меры безопасности предпринимаются при передаче?
Условия использования
Есть ли условия лицензирования или другие ограничения, которые могут не позволить воспользоваться данными в полной мере?
Формат
У всех есть любимые форматы данных, тем не менее обычно предпочтительно использование форматов, удобных для восприятия человеком, таких как CSV, JSON или XML (это подразумевает исключение бинарных форматов, кроме стандартного сжатия), так как эти форматы более удобны для использования при проведении анализа. Наконец, насколько просто вам будет поддерживать этот формат? Не потребуется ли от вас дополнительных вложений и времени на работу с этим форматом?
Документация
Предпочтение следует отдавать источникам, способным предоставить документацию. Обычно стоит поинтересоваться, как осуществляется сбор данных (чтобы понять, насколько они надежны и представляют ли они ценность для компании) и есть ли словарь данных (в нем указываются поля, тип данных, примеры значений и другая важная бизнес-логика, включенная в значения этих полей; см. табл. 3.2). Рэндалл Гроссмен, CDO корпорации Fulton Financial, заметил: «Словарь данных, которому можно доверять, — это самое важное, что CDO может предложить бизнес-пользователям».
Таблица 3.2. Пример словаря данных из проекта в области здравоохранения в Калифорнии
Объем
Сможете ли вы обеспечить хранение большого объема данных? При этом ценные наборы данных не обязательно бывают большими. Например, почтовый индекс для расчетной рыночной территории (то есть территории охвата конкретного региона телевещанием, по оценке компании Nielsen Company) может иметь всего 41 тыс. строк, но эти данные могут быть очень полезны команде специалистов по маркетингу, оценивающей расходы на телевизионную рекламу.
Степень детализации
Подходят ли данные для анализа того уровня, который вам необходим?
Благодаря качественному словарю становится понятно, как определяются данные, в каком формате и с какими допустимыми значениями. В данном случае также очевидно, как эти данные используются программным обеспечением. Приведены несколько строк из eHARS[44] (Enhanced HIV/AIDS Reporting System — Улучшенная система сбора информации о ВИЧ/СПИДе) в Калифорнии. (SAS — статистический набор приложений, активно применяющийся в области медицины.)
Сколько стоит набор данных?
Посчитать, во сколько вам обходятся данные, относительно легко. Можно проанализировать величину прямых расходов на хранение (например, стоимость услуг Amazon Web Services), стоимость сервисов резервного копирования, зарплаты сотрудников, обеспечивающих хранение и управление данными, а также их непроизводственные расходы, плюс стоимость приобретения данных (если актуально). При этом компания с управлением на основе данных должна определить ценность этих данных для бизнеса. Какова их ROI? А вот это уже не так просто.
Д’Алессандро и др.[45] предложили фреймворк, позволяющий оценить прямую рентабельность инвестиций ROI в долларах, по крайней мере в определенных ситуациях. Они работают в сфере рекламы и разработали прогнозные модели для вычисления, какие рекламные объявления эффективнее всего показывать каждому пользователю. Они получают деньги только за переход пользователя по рекламному объявлению. При этом сценарии результат и выручка очевидны: они получают, скажем, 1 долл., если пользователь переходит по рекламному объявлению, и 0 долл., если пользователь ничего не делает. У них есть собственный набор данных, на основании которых они строят свои модели. Некоторые из них — ретроспективные, взятые на основе действовавших ранее цен, а некоторые были ими приобретены в прошлом (их относят к категории невозвратных затрат). Вопрос, которым они руководствуются: «Какова рентабельность моделей, построенных на наших собственных данных, по сравнению с моделями, построенными на данных от третьих лиц?» Для этого требуется определить три компонента:
1) какова стоимость действия (в данном случае действие — это переход пользователя, его стоимость — 1 долл.);
2) какова ожидаемая стоимость модели на основе наших собственных данных;
3) какова ожидаемая стоимость модели на основе наших данных и дополнительных данных третьей стороны.
Итого:
Стоимость данных = ожидаемая стоимость (модель на основе данных третьей стороны) — ожидаемая стоимость (модель без использования данных третьей стороны)
и
Читать бесплатно другие книги:
