Кто такой аналитик данных

Одна задача — три профессии

В понедельник владелец продукта Котомаркета приносит в дата-команду одну фразу:

Покупатели стали реже возвращаться. Разберитесь.

Дальше три специалиста смотрят на одну проблему с разных сторон.

Аналитик данных отвечает на вопрос «что именно происходит и с чем это связано». Он режет retention (долю вернувшихся) по срезам — месяц первой покупки, канал привлечения, платформа, город — и ищет, где сосредоточено падение и с какими изменениями оно совпало. Через два дня приносит: «Повторные покупки упали только у когорт, пришедших по промо „корм за рубль“ с 1 июня; у остальных retention не изменился». Это ещё не доказывает, что именно промо вызвало падение, но резко сужает круг гипотез для проверки. Инструменты: SQL, Python/pandas, метрики, дашборды, здравый смысл.

Data scientist в этой же задаче может отвечать на вопрос «кто, скорее всего, уйдёт следующим». Он строит модель, которая по поведению пользователя оценивает вероятность, что тот не вернётся в ближайшие 30 дней, — чтобы служба удержания слала письма не всем подряд, а трём тысячам пользователей с самым высоким прогнозируемым риском. Инструменты: те же SQL и Python плюс статистика и машинное обучение.

Инженер данных отвечает на вопрос «откуда вообще берутся эти цифры». Он строит ежедневную загрузку: каждую ночь события приложения переливаются из потока в хранилище, чистятся от дублей, раскладываются по таблицам — так, чтобы к девяти утра retention пересчитался автоматически и по одним и тем же правилам. Инструменты: SQL, Python, оркестраторы, хранилища.

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

Цикл аналитика

Любая задача проходит один и тот же круг. Каждый шаг — одной фразой:

1. Вопрос. Превратить просьбу («посмотри, что там с возвратами») в вопрос с проверяемым ответом и понятной ценой ошибки.
2. Данные. Найти таблицы, где ответ может жить, и убедиться, что им можно верить.
3. Расчёт. Посчитать метрику по явно записанному правилу и разложить её по срезам.
4. Вывод. Сформулировать, что именно доказано числами — и чего они не доказывают.
5. Рекомендация. Предложить действие с ценой и сроком.
6. Проверка. Посмотреть, что изменилось после действия, — и вернуться на шаг 1.

Что значит «проверить данные»

Это один из шагов, которые новички чаще всего пропускают. Но без него аккуратный расчёт может дать уверенный ответ на плохих данных. Проверка складывается из пяти вопросов к таблице.

• Полнота. Все ли дни на месте? Нет ли дней, где строк подозрительно мало или вообще нет? Дыра в данных может выглядеть на графике так же, как реальное падение показателя.
• Свежесть. Когда таблица обновлялась? Если последний день ещё не закончился или данные за него загрузились не полностью, показатель может оказаться ниже обычного просто из-за неполноты данных.
• Дубли. Не пришло ли одно событие дважды? Не задвоились ли строки после склейки таблиц? Дубли искажают результат: сумма или количество строк могут вырасти, а средние, доли и другие метрики — измениться по-разному в зависимости от того, что именно задвоилось.
• Зерно: чему равна одна строка. Это строка-заказ, строка-товар-в-заказе или строка-доставка? Если принять товар в заказе за отдельный заказ, можно несколько раз посчитать одну и ту же покупку. Число при этом вполне может выглядеть правдоподобно.
• Согласованность. Бьётся ли число с соседним источником? Например, можно сравнить число заказов в событиях с числом заказов в рабочей базе. Небольшое расхождение ещё нужно объяснить, а большое — повод остановиться и сначала выяснить его причину.

Л., запись №11: «Пока ты не знаешь, чему равна одна строка, ты не считаешь метрику. Ты складываешь непонятное».

Лестница: от наблюдения до решения

Слова «наблюдение», «вывод» и «решение» в разговоре сливаются в одно. В работе это разные этажи, и путать их — значит либо паниковать раньше времени, либо брать на себя чужую ответственность. Разберём на деле из журнала Л.

Этаж 1. Наблюдение — что видно, без объяснений.

DAU: 4 200 → 2 950 за одну ночь   (−30%)

Это ещё не объяснение проблемы и не находка — только факт, который требует проверки. Здесь рано и паниковать, и успокаиваться.

Этаж 2. Находка — где именно сидит падение. Режем метрику по платформам:

платформа    было     стало   изменение
iOS         1 000       980      −2%
Web           560       566      +1%
Android     2 640     1 404     −47%   ← почти всё падение здесь

Почти всё общее падение приходится на Android: там DAU снизился на 1 236 пользователей из общего снижения на 1 250. Режем Android дальше — по версии приложения:

версия       было     стало   изменение
4.11          920       920       0%
4.12        1 720       484     −72%   ← и здесь

Находка: внутри Android всё падение приходится на версию 4.12. Обрати внимание: общая метрика упала примерно на 30%, но ни в одном из показанных сегментов нет падения ровно на 30%. Часть аудитории почти не изменилась, а Android 4.12 провалился почти на три четверти. Агрегированная метрика может прятать именно тот сегмент, где произошло изменение.

Этаж 3. Интерпретация — версия, привязанная к внешнему факту. Релиз 4.12 выкатили накануне вечером, в нём переписали стартовый экран. Одна версия: пользователи действительно перестали открывать приложение. Другая: в новой версии перестало отправляться событие app_open, по которому считается DAU. Проверяем их через независимый сигнал — покупки:

покупки с Android 4.12:  124 → 121   (−2%)

Покупки почти не изменились, хотя DAU этой же группы по app_open упал на 72%. Это плохо согласуется с версией о массовом исчезновении пользователей и делает проблему трекинга гораздо более вероятной. Следующий шаг — проверить сбор app_open напрямую: логи, схему событий или данные другого независимого источника.

Этаж 4. Вывод — что подтверждено и где проходят границы уверенности.

Почти всё падение DAU приходится на пользователей Android, а внутри Android — на версию 4.12. При этом покупки в Android 4.12 почти не изменились. Значит, резкое падение DAU, скорее всего, связано не с исчезновением аудитории, а со сбором app_open после релиза 4.12. До проверки трекинга данные о DAU с 12 марта нельзя считать надёжными.

Вывод говорит и о том, чего он не утверждает: мы не доказали, что версия 4.12 вообще не навредила продукту, и пока не доказали саму поломку app_open. Мы установили, где возникло расхождение, и получили сильный сигнал в пользу проблемы измерения.

Этаж 5. Рекомендация — что предлагаешь сделать и во что это обойдётся.

Не откатывать релиз только из-за падения DAU, пока другие сигналы не показывают сопоставимого провала. Сначала проверить и исправить трекинг app_open. После этого восстановить DAU за затронутые дни из надёжного источника, если это возможно; иначе пометить эти дни в отчётах как неполные.

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

Аналитик отвечает не за то, чтобы единолично принять решение, а за то, чтобы оно принималось со знанием фактов, ограничений и степени уверенности. Тебе не нужно заранее знать, «что делать компании», чтобы быть полезным. Нужно разобраться, что происходит на самом деле, отделить факт от гипотезы — и ясно это объяснить.

Что спрашивают на собеседовании

Требования разнятся от вакансии к вакансии, но набор тем на позиции джуна часто похож.

Отдельным этапом нередко идёт тестовое задание. Типичная формулировка:

Во вложении два файла: события приложения за 90 дней и справочник пользователей. Посчитайте DAU по дням и retention недельных когорт, найдите и опишите аномалию. Ждём ноутбук с кодом и 3–5 слайдов с выводами для продуктовой команды. Срок — 3 дня.

Здесь проверяют не только скорость работы с кодом. Важно, заметишь ли ты аномалию, догадаешься ли перепроверить данные до расчётов и сумеешь ли уложить итог в несколько слайдов, понятных человеку без SQL. Именно эти навыки ты будешь собирать дальше по курсу — а к последней главе у тебя будет своё разобранное дело.