карьерааналитика данныхонбордингпервая работачек-лист

Первые 90 дней аналитика данных: план онбординга

2026-07-06 12 мин

Главная мысль (BLUF): первые 90 дней аналитика — это не про то, чтобы поразить всех сложным анализом. Это про то, чтобы понять, где лежат данные, как считаются ключевые метрики, кому они принадлежат, и выдать один надёжный результат, которому доверяют. Порядок такой: недели 1–2 — разобраться в данных и не трогать ничего лишнего; месяц 1 — маленький быстрый win плюс документация; месяц 2–3 — своя зона метрик и первый самостоятельный анализ или A/B. Кто лезет оптимизировать пайплайн на второй день или молча выдаёт цифру, которую сам не проверил, — тот к третьему месяцу теряет доверие, а не набирает его.

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

Почему первые 90 дней решают всё

Испытательный срок в РФ — обычно 3 месяца. За это время команда формирует про вас устойчивое мнение: «на него можно положиться» или «за ним надо перепроверять». Мнение это складывается не из того, насколько красивый у вас код, а из того, совпадают ли ваши цифры с реальностью и не создаёте ли вы работу другим.

Аналитик — узел доверия. Продакт принимает решение о фиче, потому что вы сказали «конверсия в этой воронке 4,2%, а не 6%». Если через неделю выяснится, что вы забыли отфильтровать ботов и на самом деле 5,8%, — решение развернут, а к вашим числам приклеится звёздочка «проверить». Отмыться от неё сложнее, чем заработать репутацию с нуля.

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

Недели 1–2: разобраться в данных

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

Чек-лист «карта данных»

Первый практический шаг — посчитать метрику самому

Не верьте цифре на дашборде, пока не воспроизвели её своим запросом. Возьмите DAU за вчера, посчитайте руками и сверьте с чужой панелью:

SELECT
    event_date,
    COUNT(DISTINCT user_id) AS dau
FROM events
WHERE event_date = CURRENT_DATE - INTERVAL '1 day'
GROUP BY event_date;

Если ваша цифра — 48 210, а на дашборде 51 400, у вас появился первый по-настоящему полезный вопрос: почему расходится? Обычно причина в одной из трёх вещей: другой фильтр (исключают internal-пользователей по домену почты), другая гранулярность (там считают session_id, а не user_id), другой часовой пояс (UTC против Москвы). Найти это расхождение — лучшее упражнение недели: вы разом узнаёте и таблицу, и её подводные камни.

Сразу закладывайте привычку сверять таймзону. В РФ данные часто хранятся в UTC, а бизнес живёт по Москве:

SELECT
    toStartOfDay(event_time, 'Europe/Moscow') AS msk_day,
    count() AS events
FROM events
WHERE event_time >= now() - INTERVAL 7 DAY
GROUP BY msk_day
ORDER BY msk_day;

Расхождение «на один день» в отчётах в 80% случаев — именно таймзона, а не битые данные.

Что спрашивать и у кого

Вопросы бьются по адресатам. Не тащите всё к одному человеку — это верный способ его выжечь.

Отдельно про глупые вопросы: их не существует в первые две недели. «Что такое в нашей компании активный пользователь?» — не глупый вопрос, а критичный. Задавать его на третьем месяце уже стыдно, а сейчас — норма. Пользуйтесь окном.

Месяц 1: первый быстрый win и документация

К концу первого месяца от вас ждут не подвига, а доказательства, что вы полезны. Быстрый win — это маленькая задача, которую вы закрыли полностью и правильно, и которая избавила кого-то от рутины.

Как выбрать первый win

Хороший первый win отвечает трём критериям: он нужен конкретному человеку прямо сейчас, его можно закрыть за 2–4 дня, и результат легко проверить. Плохой первый win — «отрефакторить витрину заказов»: долго, рискованно, и никто не просил.

Примеры удачных первых задач:

Последний пример — золотой. Расследование расхождений одновременно учит вас данным, приносит пользу и показывает, что вы умеете копать, а не только строить SELECT *.

Чек-лист первого месяца

Документируйте с первого дня

Пока вы новичок, у вас есть суперспособность, которая исчезнет через полгода: свежий взгляд. Вы видите, что нигде не написано, чем orders_raw отличается от orders_clean, потому что вы только что на этом споткнулись. Через полгода это станет для вас очевидным, и вы, как все, перестанете это документировать.

Заведите личный файл notes.md и пишите туда каждую разгаданную загадку: «метрика retention считается по когорте регистрации, а не первой покупки», «таблица payments дублирует строки при рефанде, нужен DISTINCT ON (payment_id)». Через месяц этот файл спасёт вас от повторного расследования, а ещё через два — станет основой командной вики и вашим первым заметным вкладом.

Стейкхолдеры: знакомьтесь как человек, а не как SQL-машина

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

Месяц 2–3: своя зона метрик и первый самостоятельный анализ

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

Взять зону — значит: вы знаете эти метрики лучше всех в команде, вы первым замечаете аномалии, к вам идут с вопросами по этой теме. Это переход из «принеси-подай запрос» в «эксперт по направлению», и именно он определяет, останетесь вы джуном или растёте.

Первый самостоятельный анализ

Первый серьёзный анализ — это не «посчитать цифру», а «ответить на вопрос бизнеса и дать рекомендацию». Структура, которая работает:

Считаете разницу в конверсии между сегментами — приводите не только проценты, но и абсолют, чтобы было видно значимость масштаба:

SELECT
    platform,
    COUNT(*) AS users,
    COUNT(*) FILTER (WHERE paid) AS buyers,
    ROUND(100.0 * COUNT(*) FILTER (WHERE paid) / COUNT(*), 2) AS cr_pct
FROM funnel
GROUP BY platform
ORDER BY users DESC;

Разница 4,1% против 5,6% выглядит серьёзно, но если во втором сегменте всего 300 человек, это шум. Всегда смотрите знаменатель.

Первый A/B-тест

Если в компании есть эксперименты, ваша зона рано или поздно включит A/B. Здесь новички чаще всего ошибаются, потому что торопятся с выводом. Три вещи, которые надо держать в голове:

Во-первых, размер выборки считается до запуска, а не «когда наберётся». Для разницы конверсий нужен минимальный детектируемый эффект (MDE), базовая конверсия и мощность. Прикидка для базовой конверсии $p$ и MDE в абсолютных пунктах:

$$n \approx \frac{16 \cdot p \cdot (1 - p)}{(\text{MDE})^2}$$

При базе $p = 0{,}05$ и MDE $= 0{,}01$ получаем примерно $n \approx \frac{16 \cdot 0{,}05 \cdot 0{,}95}{0{,}0001} \approx 7600$ на группу. Не 500, как хочется продакту к пятнице.

Во-вторых, не подглядывайте в тест каждый день и не останавливайте его, как только увидели «p-value стало 0,04». Это раздувает долю ложных срабатываний в разы. Тест идёт до заранее посчитанной даты.

В-третьих, проверяйте не только целевую метрику, но и guardrail-метрики: не выросла ли выручка ценой оттока, не сломалась ли скорость загрузки. Разобрать проверку значимости на scipy.stats можно на конкретных примерах в разборе A/B — а прежде чем защищать первый результат перед командой, прогоните логику на задачах в /python-sandbox.

Чек-лист месяцев 2–3

Типичные ошибки новичка

Лезть оптимизировать до понимания. Классика: на второй неделе видите «неоптимальный» запрос и переписываете. А он такой, потому что джойнит через костыль хитрую бизнес-логику, о которой вы не знаете. Итог — сломанный отчёт и подорванное доверие. Правило: первые два месяца оптимизируете только то, что понимаете на 100% и о чём попросили.

Доверять чужим цифрам без проверки. Вам скидывают «вот выгрузка, посчитай по ней конверсию». Вы считаете, отдаёте, а в выгрузке были дубли. Ошибка теперь ваша, не того, кто дал выгрузку. Проверяйте вход: COUNT(*) против COUNT(DISTINCT id), диапазон дат, нет ли NULL там, где их быть не должно. Тридцать секунд проверки экономят день разбирательств.

Молчать. Застряли на два дня и никому не сказали — худшее, что можно сделать на испытательном сроке. В команде это читается не как «самостоятельный», а как «не справляется и скрывает». Правило пары часов: покопались сами 1–2 часа, не сдвинулись — сформулировали конкретный вопрос и спросили. «Не могу понять, почему в таблице X дублируются строки по Y, вот что я уже проверил» — это сильный вопрос, а не признак слабости.

Выдавать цифру без контекста. «Конверсия 4%» — бесполезно. «Конверсия 4%, месяц назад была 5,5%, падение в основном на Android, данные с 1 по 20 июня» — вот это ответ. Всегда добавляйте динамику, разрез и период.

Идеализм вместо результата. Новичок хочет сделать «правильно и красиво», строит идеальную витрину неделю. Бизнесу нужен был ответ вчера, пусть и в лоб. Скорость и «достаточно хорошо» на старте ценятся выше архитектурного совершенства.

Как заработать доверие

Доверие складывается из трёх простых вещей, повторённых много раз.

Ваши цифры сходятся. Когда вы называете число, оно совпадает с реальностью. Для этого — привычка перепроверять себя вторым способом. Посчитали выручку джойном — сверьте с прямой суммой по таблице платежей. Совпало — отдаёте. Не совпало — разбираетесь, а не отдаёте «примерно».

Вы говорите, когда не знаете. «Я не уверен в этой цифре, надо проверить фильтр по рефандам» звучит в тысячу раз лучше, чем уверенный неправильный ответ. Люди быстро запоминают, кто честен про свои границы.

Вы доводите до конца. Взяли задачу — закрыли и сообщили результат, а не бросили на полпути с «ну там сложно». Даже маленькая задача, доведённая до конца и оформленная понятно, добавляет к репутации больше, чем большой начатый и заброшенный проект.

Полезно параллельно поддерживать техническую форму: разбирать реальные кейсы, держать в голове определения метрик и не терять беглость в SQL на /sql-sandbox. Чем меньше вы буксуете на технике, тем больше внимания остаётся на бизнес-смысл — а именно за него платят.

Частые вопросы

Что делать, если нет наставника и никто ничего не объясняет?

Такое бывает чаще, чем хотелось бы. Стройте карту сами через код: читайте существующие запросы и дашборды — они содержат все принятые соглашения. Найдите самого доброжелательного человека в команде и задавайте ему точечные вопросы дозированно. Ведите свой словарь метрик — он заменит отсутствующую документацию. И проговорите с тимлидом ожидания явно: «На что мне ориентироваться в первый месяц, чтобы считалось, что я справляюсь?»

Нормально ли не выдать ничего впечатляющего за первый месяц?

Абсолютно. От джуна в первый месяц ждут, что он разберётся в данных и закроет пару маленьких задач без ошибок, а не что построит ML-модель. Один надёжный отчёт, которому доверяют, ценнее сложного анализа с ошибкой. Впечатлять будете на третьем–шестом месяце, когда возьмёте свою зону.

Как понять, что я успешно прохожу испытательный срок?

Сигналы: к вам начали приходить с вопросами по вашей зоне, ваши цифры перестали перепроверять, тимлид даёт задачи без детального ТЗ («разберись с падением конверсии»), стейкхолдеры зовут вас в обсуждения на этапе постановки, а не только за выгрузкой. Если через два месяца вас всё ещё используют как «принеси конкретный SELECT» — стоит прямо спросить про обратную связь.

Стоит ли учить новые инструменты в первые 90 дней или хватит того, что знаю?

Приоритет — освоить стек, который уже используется в команде, а не тащить любимые инструменты. Если все на ClickHouse и DataLens, ваше знание условного Tableau сейчас не поможет — научитесь тому, на чём работает команда. Точечно подтягивайте то, чего не хватает под конкретные задачи: понадобился A/B — освежите статистику, дали витрину на dbt — разберитесь с dbt. Системное обучение оставьте на после испытательного срока, когда освободится голова. Готовиться к собеседованиям и расти по грейду проще, когда база закрыта — загляните в /course и [/interviews], когда почувствуете почву под ногами.

Первые 90 дней — это марафон доверия, а не спринт производительности. Разберитесь в данных, не ломайте чужое, выдайте один надёжный результат, документируйте свежим взглядом и говорите вслух, когда застряли или не уверены. Сделаете это — и к концу испытательного срока станете человеком, к чьим цифрам не приклеивают звёздочку «проверить». А техническую форму держите на практике и разборе собеседований аналитика данных — чтобы техника не отвлекала от главного, ради чего вас взяли: превращать данные в решения.

Практикуйся на реальных задачах
545 SQL + 538 Python задач с автопроверкой, 618 кейсов. Первые — без регистрации.
Прокачать SQL на реальных задачах →

Похожие статьи