Аналитика данных: от записи до решения
Как данные проходят путь от события в бизнесе до цифры на экране, где эта цепочка рвётся чаще всего и какие пять проверок стоит сделать до покупки любого инструмента.
Аналитика данных — это цепочка от первичной записи в рабочей системе до решения руководителя. Данные собирают из источников, приводят к сопоставимому виду, считают по согласованной методике и показывают в форме, пригодной для действия. Рвётся цепочка почти всегда в середине — там, где данные должны стать сопоставимыми.
О качестве аналитики судят по последнему звену — по панели. Но панель лишь отображает то, что до неё дошло. Разберу всю цепочку по звеньям: где именно теряется достоверность и почему добавление ещё одного отчёта не помогает.
Как устроен путь данных
Между событием в бизнесе и цифрой на экране проходит пять преобразований. На каждом данные могут исказиться, и на каждом это лечится по-разному.
Самое дорогое звено — второе. Если событие не зафиксировано или зафиксировано неполно, восстановить его потом невозможно ничем. Никакая обработка не создаст данные, которых нет: причину отказа, источник обращения или дату этапа, если их не заполнили, придётся ждать заново — месяцами, пока накопится история.
Качество данных: пять проверок
Прежде чем строить что-либо поверх данных, их проверяют. Проверка занимает несколько дней и почти всегда меняет план проекта.
| Проверка | Что смотрим | Типичная находка |
|---|---|---|
| Полнота | Доля заполненных значимых полей | Источник обращения заполнен у трети записей |
| Дубли | Один объект под несколькими записями | Клиент заведён четырьмя способами написания |
| Непрерывность | Разрывы в истории по датам | Данные до смены системы недоступны |
| Согласованность | Совпадают ли пересекающиеся значения в разных системах | Сумма сделок в CRM не сходится с отгрузками |
| Актуальность | Задержка между событием и записью | Сделки заводятся в конце месяца задним числом |
Последняя проверка недооценивается сильнее прочих. Если менеджеры вносят сделки пачкой в конце месяца, то любая недельная динамика — фикция: она отражает не продажи, а привычку заполнения. Строить на ней оперативные решения нельзя, и это выясняется только на проверке актуальности.
Обычная последовательность: компания покупает инструмент, тратит два месяца на настройку, выводит панель — и видит цифры, которые не сходятся с ощущением руководителя. Дальше начинается разбор, который упирается в качество первичных данных, и проект останавливается на неопределённый срок. Проверка данных до покупки инструмента занимает несколько дней и снимает этот сценарий целиком.
Какие данные есть у компании
Полезно различать типы: у каждого своя ценность и своя стоимость получения.
- Транзакционные. Сделки, платежи, отгрузки. Самые надёжные — они привязаны к деньгам и обычно заполняются аккуратно.
- Поведенческие. Действия на сайте, открытия писем, использование продукта. Много объёма, но требуют разметки — без неё это шум. Об их сборе — в разборе веб-аналитики.
- Процессные. Даты переходов между этапами, трудозатраты, сроки. Обычно фиксируются хуже всего, а нужны для анализа процессов.
- Справочные. Клиенты, товары, сотрудники, каналы. Ценность не в них самих, а в том, что они связывают остальные типы между собой.
- Внешние. Цены конкурентов, спрос, рыночные индексы. Подробнее — аналитика рынка.
Практическое следствие: справочные данные важнее, чем кажется. Именно они позволяют соединить рекламу с деньгами. Если клиент в CRM и в учётной системе не связан общим идентификатором, вся цепочка «канал → сделка → выручка» рвётся, и никакой объём поведенческих данных этого не компенсирует.
Пять проверок по источникам: полнота, дубли, непрерывность, согласованность, актуальность. По итогу — что можно считать уже сейчас, а что придётся сначала начать фиксировать.
Где хранить данные
Вопрос возникает на третьем шаге и решается проще, чем принято думать. Выбор зависит от объёма и от того, нужна ли история за годы.
BI-инструмент читает источники напрямую. Быстро запускается, но нагружает рабочие системы.
Данные складываются в отдельную базу с расписанием обновления. Рабочий вариант для среднего бизнеса.
Готовые агрегаты по периодам. История есть, детализация ограничена.
Полная история с детализацией. Дороже в поддержке, оправдано при больших объёмах.
Ошибка здесь бывает в обе стороны. Прямое подключение к боевой CRM в рабочее время может её заметно замедлить — это выясняется в первый же понедельник. Обратная крайность — проектирование полноценного хранилища для компании, где значимых данных на несколько сотен тысяч строк: срок проекта вырастает в разы без выигрыша.
Кто работает с данными
Разделение труда здесь устойчивое, и понимание его помогает не искать одного человека на все задачи.
Настраивает сбор и хранение: выгрузки, расписание, базу. Отвечает за то, что данные приходят вовремя и полностью.
Строит модель и витрины, считает показатели, собирает панели. Отвечает за то, что цифра посчитана верно.
Со стороны бизнеса: решает, что считается сделкой и выручкой. Обычно финансовый директор. Не делегируется подрядчику.
Руководитель, который принимает решение. Формулирует вопросы и обязан приходить на разбор — иначе цепочка не замыкается.
Первые две роли можно отдать на сторону, третью и четвёртую — нет. Подробнее о том, как собрать эту конструкцию, — в статье про отдел аналитики.
Типовые ошибки в работе с данными
- Собирают всё подряд. «Выгрузим на всякий случай» превращается в массив, который никто не разбирает. Начинать нужно от вопроса, а не от источника.
- Чинят панель вместо источника. Цифра неверна — правят формулу на витрине. Через месяц расхождение всплывает в другом отчёте.
- Оставляют ручной шаг. Один Excel в середине цепочки обнуляет автоматизацию: данные обновляются, пока сотрудник на месте.
- Не хранят историю изменений. Клиент сменил категорию — старые отчёты пересчитались задним числом, сравнение с прошлым годом стало невозможным.
- Считают точность самоцелью. Доведение расхождения с двух процентов до нуля стоит дороже, чем даёт: для управленческого решения двухпроцентная погрешность несущественна.
Последний пункт вызывает споры, поэтому уточню. Точность нужна там, где на цифре стоит обязательство: расчёты с контрагентами, налоги, зарплата. Для управленческого контура важнее другое — стабильность методики. Показатель, посчитанный одинаково каждый месяц с известной погрешностью, полезнее идеально точного числа, методика которого менялась дважды за год.
Данные не бывают готовыми. Бывает решение, ради которого их привели в пригодный вид, — и объём работы определяется этим решением, а не объёмом данных.Владимир Герасимов
С чего начать работу с данными
- Один вопросВозьмите управленческий вопрос, ответ на который нужен еженедельно. Не список из двадцати — один.
- Проверка источниковПройдите пять проверок по тем системам, где лежат нужные для ответа данные. Обычно на этом шаге план меняется.
- МетодикаЗапишите, как считается ответ: какие поля, какие исключения, каким днём. Одна страница.
- Автоматизация до концаСоберите цепочку без ручных шагов. Если хоть один остался, вернитесь и уберите его.
- РазборНазначьте, кто и когда смотрит результат и что делает при отклонении.
Когда первый вопрос закрыт до конца, второй занимает в разы меньше времени: источники подключены, справочники сведены, методика описана. Именно поэтому имеет смысл довести один сценарий до рабочего состояния, а не начинать пять одновременно. Дальше вопросы наращиваются поверх готовой основы — и в этот момент отдельные отчёты начинают складываться в единый контур управления.
От источника до панели, без ручных шагов посередине. Начнём с одного управленческого вопроса и доведём его до автоматического обновления — дальше остальные достраиваются быстрее.
Сбор данных: как выгружать из разных систем
Технически сбор устроен одним из трёх способов, и выбор между ними определяет, сколько потом придётся тратить на поддержку.
Через программный интерфейс
Система отдаёт данные по запросу в машинном формате. Самый надёжный путь: данные приходят структурированными, обновление ставится на расписание, ручных шагов нет. Так работают почти все современные CRM, рекламные кабинеты и облачные сервисы. Ограничение — лимиты на объём запросов, из-за которых историю за несколько лет иногда приходится выгружать неделями.
Прямым чтением базы
Подходит для систем, установленных внутри компании: учётных программ, складских решений. Данные доступны целиком и без ограничений, но требуется понимание внутренней структуры базы, а она у большинства учётных систем нетривиальная. Отдельный риск — нагрузка на боевую систему, которую снимают чтением по ночам или с реплики.
Файловой выгрузкой
Система формирует файл по расписанию, а он забирается из папки или почты. Способ выглядит устаревшим, но остаётся единственным доступным для части отраслевого софта. Работает устойчиво при одном условии: формат файла зафиксирован и не меняется от выгрузки к выгрузке.
Практический совет по приоритету: начинайте с источника, который содержит деньги. Учётная система обычно оказывается самой сложной для подключения, но без неё контур не имеет опоры — все остальные данные так или иначе сверяются с выручкой. Подробнее о специфике выгрузок из учётных систем — в разборе аналитики в 1С и ERP.
Как данные приводят к сопоставимому виду
Это четвёртый шаг, и именно на нём разрозненные выгрузки превращаются в то, чем можно пользоваться. Работа состоит из трёх операций.
| Операция | Что делается | Что становится возможным |
|---|---|---|
| Сведение справочников | Один клиент, товар, канал получает единый идентификатор во всех системах | Соединить рекламу со сделкой, а сделку с оплатой |
| Единый календарь | Определяется, каким днём считается каждое событие и как закрываются периоды | Сравнивать периоды и складывать данные разных систем |
| Расчёт показателей | Метрики считаются по письменной методике в одном месте, а не в каждом отчёте | Получать одно значение показателя во всех панелях |
Сведение справочников — самая трудоёмкая часть и одновременно та, которую чаще всего пытаются пропустить. Соблазн понятен: кажется, что можно соединять записи по названию. На практике «ООО Ромашка», «Ромашка ООО» и «ромашка» — три разных клиента для машины, и отчёт по крупнейшим заказчикам получается неверным. Решается это либо общим идентификатором на стороне источников, либо таблицей соответствий, которую нужно поддерживать.
Показатель считается один раз и в одном месте — это правило экономит больше времени, чем любое другое. Как только одна и та же метрика вычисляется формулами внутри трёх разных отчётов, расхождения появляются в течение пары месяцев: кто-то поправил условие в одном месте и не поправил в двух других. Расчёт на уровне модели данных, а не на уровне отчёта, снимает этот класс проблем полностью.
Сколько данных нужно, чтобы делать выводы
Вопрос практический: часто компания хочет выводов по данным, которых для выводов не хватает. Ориентиры такие.
- Сравнение периодов. Нужны минимум три сопоставимых периода, иначе разница может быть обычным колебанием.
- Сезонность. Требуется полный годовой цикл, а лучше два — иначе спад в июле будет принят за проблему в маркетинге.
- Конверсии по этапам. Несколько десятков сделок на этап. При десяти сделках изменение конверсии на десять процентов — это одна сделка.
- Разбивка по сегментам. Каждый сегмент должен набирать достаточный объём сам по себе, иначе дробление даёт красивые, но случайные числа.
Отсюда практическое правило: чем мельче разбивка, тем осторожнее вывод. Компании часто дробят данные до уровня, где каждая ячейка содержит два-три события, и принимают решения по колебаниям. Это выглядит как аналитика, но по сути является гаданием с таблицей.
Что делать, если данных пока нет
Ситуация встречается чаще, чем принято думать, и она не тупиковая. Порядок действий обратный обычному.
- Определите минимумКакие три-четыре поля нужно начать фиксировать, чтобы через квартал ответить на главный вопрос.
- Встройте в процессЗаполнение должно быть частью действия сотрудника, а не отдельной обязанностью: обязательное поле при переводе сделки на этап работает, напоминание в чате — нет.
- Проверьте через две неделиПосмотрите долю заполненных значений. Если ниже восьмидесяти процентов, проблема в том, как встроено, а не в дисциплине.
- Начните считать на неполных данныхНе ждите идеала. Тренд виден и при частичном заполнении, если доля пропусков стабильна.
Последний пункт важен: ожидание «сначала наведём порядок, потом посчитаем» растягивается на годы. Работающий подход — считать параллельно с наведением порядка, отмечая на панели, какая часть данных пока неполна. Это честнее и быстрее приводит к результату, чем полгода подготовки без единого отчёта.
Отдельно про то, чем занимается аналитик данных в компании и в чём суть его работы: он отвечает не за красоту отчётов, а за то, что цифра посчитана по согласованной методике и обновляется без ручного вмешательства. Всё остальное — визуализация, выбор инструментов, оптимизация запросов — производные от этой задачи.
Частые вопросы
Это цепочка от первичной записи в рабочей системе до решения руководителя: сбор из источников, приведение к сопоставимому виду, расчёт по согласованной методике и показ в форме, пригодной для действия.
Панель — последнее звено этой цепочки, и она наследует все ошибки предыдущих. Поэтому исправлять картинку, когда проблема на этапе фиксации данных, бессмысленно.
Пятью проверками. Полнота: какая доля значимых полей заполнена. Дубли: не заведён ли один объект несколькими записями. Непрерывность: нет ли разрывов в истории. Согласованность: сходятся ли пересекающиеся значения в разных системах. Актуальность: какова задержка между событием и записью.
Последняя недооценивается сильнее прочих: если сделки заводятся пачкой в конце месяца, недельная динамика отражает привычку заполнения, а не продажи.
Выбор зависит от объёма и потребности в истории. Для компании с тремя-пятью источниками почти всегда достаточно промежуточной базы с расписанием обновления. Прямое подключение BI к рабочим системам запускается быстро, но может заметно их замедлить.
Полноценное хранилище оправдано, когда данные не помещаются в память и нужна детализированная история за несколько лет.
Причины отказа в сделке — поле есть, но заполняется формально. Себестоимость в разрезе направлений — общие затраты не разнесены. Источник обращения — без разметки вклад каналов не восстановить. Фактические трудозатраты и даты перехода между этапами.
Все они закрываются организационно, изменением правил заполнения, но эффект отложенный: чтобы увидеть тренд, нужна накопленная история за несколько месяцев.
Четыре роли. Инженер данных настраивает сбор и хранение. Аналитик строит модель, витрины и панели. Владелец методики со стороны бизнеса решает, что считается сделкой и выручкой, — обычно финансовый директор. Потребитель — руководитель, который формулирует вопросы и приходит на разбор.
Первые две роли можно отдать подрядчику, третью и четвёртую — нет.
Точность критична там, где на цифре стоит обязательство: расчёты с контрагентами, налоги, зарплата. Для управленческого контура важнее стабильность методики.
Показатель, посчитанный одинаково каждый месяц с известной погрешностью в пару процентов, полезнее идеально точного числа, методика расчёта которого менялась дважды за год.
Потому что объём не превращается в понимание. Выгрузка «на всякий случай» даёт массив, который никто не разбирает, зато требует места, поддержки и внимания.
Работающий порядок обратный: сначала управленческий вопрос, потом список данных, нужных для ответа на него, и только потом сбор. Один доведённый до конца сценарий полезнее пяти начатых.
Проверка источников — несколько дней. Описание методики по одному вопросу — примерно неделя. Сборка автоматической цепочки от источника до результата — от двух до пяти недель в зависимости от состояния данных и числа систем.
Дольше всего накапливается то, что раньше не фиксировалось: здесь счёт идёт на месяцы, и потому изменение правил заполнения начинают до всего остального.