Одна из самых опасных иллюзий в аналитике выглядит так: если данные лежат в таблице, значит они уже отражают реальность.

На практике строка в базе данных почти никогда не возникает сама по себе. До неё всегда был какой-то процесс: клиент нажал кнопку, сотрудник изменил статус, система отправила запрос, оператор занёс информацию вручную, API передал событие, платёж прошёл через несколько сервисов. И только после всей этой цепочки вы увидели запись в таблице.

Поэтому я всегда стараюсь сначала понять не только структуру данных, но и то, как эти данные вообще появились.

Допустим, вы видите, что количество отказов клиентов резко выросло. Можно сразу открыть SQL, построить динамику, сегментировать клиентов и искать закономерности. А можно сначала пойти к людям, которые отвечают за процесс, и спросить: что изменилось?

Иногда выясняется, что бизнес вообще не менялся. Просто разработчики добавили новый статус, который раньше записывался иначе. Или операторов обязали по-другому закрывать заявки. Или изменился источник данных. Для базы это огромный скачок показателя. Для реального мира почти ничего не произошло.

С подобным я сталкивался много раз. Особенно хорошо начинаешь это понимать, когда сталкиваешь с крупными процессами, где одна бизнес-сущность проходит через несколько систем. Клиент может сначала оставить заявку, потом получить предварительное решение, затем пройти проверку, подписать документы, затем снова пройти проверку и только после этого открыть продукт. На каждом этапе появляется новая запись, новый статус и иногда даже новый идентификатор.

Если смотреть только на таблицу, легко решить, что это пять разных событий. Если понимать процесс, становится ясно, что перед вами одна история одного клиента.

То же самое работает и в обратную сторону. Иногда в данных чего-то нет не потому, что событие не произошло, а потому что его просто никто не записал. Например, менеджер договорился с клиентом по телефону, но не поставил нужный статус в CRM. Для бизнеса коммуникация была. Для аналитика её не существует.

Именно поэтому я считаю, что одна из первых вещей, которую аналитик должен сделать в новой предметной области, это пройти весь путь данных руками.

Откуда появляется запись? Кто её создаёт? Какие системы участвуют? Когда меняются статусы? Можно ли изменить данные вручную? Что происходит при ошибке? Какие события вообще не попадают в базу?

После этого SQL начинает читаться совершенно иначе.

Вы перестаёте видеть "client_id", "status", "event_date" и "product_code". За ними появляются реальные сущности, процессы и причинно-следственные связи.

И в этот момент аналитик перестаёт быть человеком, который просто умеет хорошо работать с таблицами. Он начинает понимать систему, которую эти таблицы описывают.

А это уже совсем другой уровень аналитики.

Запомните, даже самый спокойный медведь умеет рычать, когда надо. Берегите голову, берегите данные — и пусть в вашем дне будет немного тишины, ясности и добрых переменных.