Во-первых, нужно подготовить данные. Они должны выглядеть как таблица фактов (fact table), которая делается на основе таблиц состояния на определенный момент или лога изменений данных (вспоминаем главу про данные). Если в таблице используются непонятные обычному человеку идентификаторы и у вас есть справочники на них, то лучше расшифровать это поле, присоединив (join или merge) данные справочника к таблице фактов. Поясню на примере. Мы ищем причину падения продаж. Пусть у нас есть таблица состояния заказов на определенный момент, у нее есть следующие поля:
• Дата и время создания заказа (например, 10 ноября 2020 года 12:35:02).
• ID типа клиента, который совершил заказ (1, 2).
• ID статуса клиента в программе лояльности (1, 2, 3).
• ID заказа (2134, 2135, …).
• ID клиента (1, 2, 3, 4…).
• Сумма заказа в рублях (102, 1012…).
Эта таблица будет таблицей фактов, так как в ней записаны факты появления заказов. Аналитик хочет увидеть, как заказывали клиенты разных типов и статусов в программе лояльности. У него есть гипотеза, что там находится основная причина изменения продаж. ID-поля нечитаемы и созданы для нормализации таблиц в учетной базе данных, но у нас есть справочники (табл. 7.1–7.2), которые полностью расшифровывают их.
Таблица 7.1. Справочник типа клиента
Таблица 7.2. Статусы клиента в программе лояльности
После соединения (join или merge) таблицы фактов со справочниками мы получим обновленную таблицу (табл. 7.3) фактов:
• datetime – дата и время создания заказа (например, 10 ноября 2020 года 12:35:02).
• client_type – тип клиента, который совершил заказ (физическое или юридическое лицо).
• client_status – статус клиента в программе лояльности (VIP, есть карта лояльности, нет карты лояльности).
• order_id – ID заказа (2134, 2135, …).
• client_id – ID клиента (1, 2…).
• amount – cумма заказа в рублях (102, 1012…).
Таблица 7.3. Пример объединения данных
Что в этой таблице фактов хорошо – нет id полей, кроме двух – заказов и клиентов, но это полезные поля, они, возможно, понадобятся, чтобы посмотреть более подробно какие-то заказы во внутренней учетной системе. Аналитик получил выборку данных в указанном выше виде, поместил ее в электронную таблицу, например Microsoft Excel или Google Sheets. Построил над этой таблицей сводную (pivot table). Приступим к ее анализу.
В сводных таблицах есть два типа данных: измерения (dimensions) и показатели (или меры, measures). Измерения представлены в формате системы координат. Когда я слышу слово «измерения», я представляю себе три оси координат, выходящие из одной точки перпендикулярно по отношению друг другу – как нас учили на уроках геометрии. Измерений (осей) может быть гораздо больше трех. Их можно будет использовать в виде столбцов, строк или фильтров сводной таблицы, но их нельзя помещать в ячейки. Примеры измерений:
• Дата и время.
• Тип клиента.
• Статус клиента.
Показатели – это уже статистики, которые будут рассчитываться в сводной таблице, когда вы будете «вращать» или менять измерения. Они, как правило, агрегатные: суммы, средние, количество уникальных значений (distinct count), количество непустых значений (count). Примеры показателей для нашей задачи:
• Сумма заказов.
• Средний чек заказа.
• Количество заказов (уникальность здесь обеспечена тем, что одна строка – это заказ, дублей заказов нет).
• Количество уникальных клиентов (нужно считать число уникальных ID, так как один клиент может сделать несколько заказов, и его посчитают несколько раз).
ID заказов и ID клиентов могут быть как измерениями – тогда вы сможете считать статистику по конкретным заказам или клиентам, так и показателями – тогда можно просто посчитать количество заказов или клиентов. Это целиком зависит от вашей задачи, оба способа работают.
Аналитик определяет для каждого столбца, являются ли данные в нем измерениями или показателями, а также какие статистики по показателям ему нужны. Подготовительные работы закончены, теперь время сформулировать гипотезы и для каждой из них определить один или несколько срезов, которые подтвердят гипотезу или опровергнут. Понятие среза происходит из многомерной природы сводных таблиц. Представьте себе трехмерный предмет, имеющий следующие измерения: длину, ширину и высоту. Пусть это будет кусок сливочного масла. Вы берете нож, разрезаете его и получаете срез, причем плоскость среза перпендикулярна оси, которую вы фиксируете. То же самое вы проделываете, когда работаете со сводной таблицей – делаете срез многомерных данных. Осей может быть много, это число равно числу измерений – вот откуда берется многомерность. Место на оси (измерение), перпендикулярно которой режете, попадет в фильтр отчета как значение. Вы фиксируете его. Измерения, которые будут лежать в плоскости среза, будут столбцами и строками нашей таблицы. Если фильтр отчета не используется, то все данные будут спроецированы на наш срез при помощи операции агрегации, которая для каждого показателя выбирается индивидуально (суммы, средние, количество).
Аналитик формулирует две гипотезы относительно падения продаж:
• Изменение поведения вызвано одним из типов клиента. Для этой гипотезы одно из измерений – тип клиента.
• Изменение поведения вызвано одной из групп лояльности. Для этой гипотезы одно из измерений – статус лояльности клиента.
Так как у нас произошли изменения во времени, то нам понадобится еще одно измерение – время. Итак, гипотеза и нужный срез данных сформулированы, а дальше дело техники: мышью перетащить нужные измерения, например, дату в столбцы, тип клиента в строки. Заполнить таблицу нужными показателями и проверить, подтверждается ли проверяемая гипотеза цифрами или нет. Правильность гипотезы желательно проверить подходящим статистическим критерием для гипотез, что в реальности делается довольно редко.
Гипотезы можно формулировать и проверять последовательно, а когда наработается опыт, то они будут формулироваться на уровне подсознания. Аналитик будет играть ими, чтобы найти самую вероятную причину проблемы или успеха: делать первый срез, а потом добавлять измерения, пересекая их со старыми, и изменять показатели.
