Вакансия Data Analyst в 2026 году в CIS и на русскоязычной удалёнке почти никогда не просит «знать всё про данные». Она просит одно: взять сырой след продукта — заказы, сессии, тикеты — и за разумное время ответить на вопрос бизнеса без folklore из дашборда, который никто не проверял.
Ниже — рабочий набор, а не программа курса. SQL, метрики, визуализация, эксперименты, Python. Что обязано быть на junior, что можно честно не указывать, как собрать доказательство за 90 дней и как не превратить резюме в свалку инструментов.
Коротко:
- Ядро найма — SQL плюс умение назвать метрику так, как её считает продукт, а не как в учебнике.
- Python нужен, когда без него не вытянуть выгрузку, повтор расчёта или небольшой пайплайн. Для части junior-ролей его нет в обязательных.
- Дашборд без определения метрики и проверки на дублях — это картинка, не навык.
- Эксперименты на junior спрашивают как грамотность: что нельзя сравнивать, что такое длительность, куда смотреть besides p-value.
- В резюме продаёт один разбор с вопросом, запросом и выводом, а не список из пятнадцати BI-инструментов.
Кого нанимают под этим названием
Под «аналитиком» прячутся разные работы. Продуктовый аналитик считает воронки и удержание. Маркетинговый — каналы и стоимость привлечения. Операционный — очереди, SLA, срывы поставок. «Аналитик данных» без уточнения часто оказывается человеком, который пишет SQL в DWH и тащит еженедельный отчёт.
До того как собирать навыки, откройте пять объявлений одной ветки, не пяти профессий. Смотреть живые формулировки удобно в вакансиях Data Analyst. Если в трёх из пяти есть PostgreSQL, dbt и Looker, а Python «будет плюсом» — ваш список уже другой, чем у вакансии с pandas, A/B и Amplitude.
Ошибка входа — учить «аналитику вообще»: немного SQL, немного Python, немного нейросетей. На отборе это читается как отсутствие роли. Смежная ловушка — путать аналитика с инженером данных или с ML. Если в объявлении нет моделей, не добавляйте sklearn в skills «для веса».
SQL — навык, без которого остальное не смотрят
На junior в CIS SQL проверяют чаще, чем «знание продуктового мышления». Типичный контур: JOIN без размножения строк, окна для кумулятива и ранжирования, группировки с фильтрами, аккуратная работа с датами и NULL, понимание, почему «уникальные пользователи» разъехались с «сессиями».
Что должно получаться без шпаргалки:
- схема заказа: пользователи, сессии, заказы, позиции, возвраты — и запрос, который не дублирует выручку из‑за JOIN к позициям;
- воронка по шагам с окном и отсечением ботов / тестовых аккаунтов;
- когорта: неделя регистрации × неделя активности, без «средней температуры по больнице»;
- проверка качества: дубли ключей, дыры в датах, заказы без пользователя.
Диалект вторичен относительно грамотности. Postgres в продуктовых командах встречается чаще Oracle. Если в вакансии ClickHouse — это отдельный плюс, не замена базового SQL. Карта тренировки запросов — в SQL roadmap; здесь важно другое: SQL без метрики — это просто синтаксис.
Метрики: определение важнее графика
Рекрутер и нанимающий аналитик слушают, умеете ли вы спорить с цифрой. «Конверсия выросла» без окна, знаменателя и фильтра по новым/старым — не ответ. Junior, который говорит «я бы сначала зафиксировал, кого считаем покупателем», выглядит сильнее, чем тот, кто сразу рисует столбцы.
Минимальный набор, который стоит уметь объяснить вслух:
- активность: DAU/WAU/MAU и почему отношение WAU/MAU не равно «вовлечённости» само по себе;
- воронка: шаг, окно атрибуции, что делать с людьми, которые перескочили шаг;
- деньги: GMV, выручка, AOV, доля возвратов — и где их нельзя складывать;
- удержание: D1/D7/D30, N-day vs unbounded, чем когорты лучше «среднего retention»;
- юнит-экономика на уровне здравого смысла: что входит в стоимость привлечения, чего вы не знаете без финансов.
Не зубрите двадцать аббревиатур из блога. Возьмите один продукт, который понимаете — доставку, маркетплейс, edtech, B2B SaaS — и распишите пять метрик так, будто пишете ТЗ аналитику. Это и есть навык, который потом переносится на чужой продукт.
Python: когда обязателен, когда нет
Python на аналитика в 2026-м — не «стать разработчиком». Это скрипт, который повторяет расчёт, чистит выгрузку, клеит два источника, иногда тянет API. Если вакансия — отчёты в SQL и BI, а Python в плюсах, не имитируйте backend-стек.
Когда Python почти наверняка спросят:
- в описании есть pandas, Jupyter, выгрузки, которые не влезают в BI;
- нужно повторять расчёт еженедельно, а не кликать руками;
- роль ближе к аналитику с элементами витрины: простые трансформации до dbt/инженера.
Когда можно честно не ставить в основной блок: вакансии «SQL + Tableau/Power BI + Excel», продуктовый аналитик с Amplitude/Mixpanel без скриптов. Если вы открывали pandas дважды на курсе — не пишите. На созвоне попросят прочитать свой ноутбук, и «это с модуля» закроет доверие к SQL, который мог быть нормальным.
Достаточный объём для входа: чтение CSV/Parquet, merge без сюрпризов по ключу, groupby, даты, простой график для себя, а не «ML pipeline». Ветку языка под работу, если целитесь ещё и в Python-разработку, разбирайте отдельно в Python roadmap — это другая роль.
Визуализация и отчёты
Инструмент (Tableau, Power BI, Metabase, Superset, Looker Studio) сам по себе не нанимает. Нанимает отчёт, по которому можно принять решение. Junior часто приносит дашборд с двенадцатью графиками и ни одним фильтром «зачем это смотреть утром».
Рабочий стандарт одного отчёта:
- вопрос наверху: «почему просела оплата на шаге 3»;
- определение метрики и исключений (тест, сотрудники, боты);
- срез, который проверяет гипотезу, а не «все измерения сразу»;
- подпись, где данные могут врать — лаг загрузки, дубли событий, смена трекинга.
Excel всё ещё жив в операционной аналитике CIS. Не стесняйтесь его, если вакансия про сводные и проверки. Стесняйтесь выдавать сводную без проверки ключей. BI указывайте тот, которым собирали отчёт, не «все, что слышал».
Эксперименты без культа p-value
На junior редко просят спроектировать платформу A/B. Часто просят не сделать глупость: сравнить неделю с акцией и неделю без, забыть про новичков, переехать на новую версию приложения в середине теста, принять решение по одной метрике при просевшей выручке.
Что уметь объяснить:
- единица рандомизации: пользователь, сессия, магазин — и почему нельзя мешать;
- длительность: мало дней — шум, много — мир изменился;
- peeking: смотреть каждый день и «останавливать, когда зелёное»;
- guardrail: что нельзя ухудшить, даже если целевая метрика выросла;
- когда эксперимент нельзя ставить и нужен до/после с оговорками.
Если коммерческих A/B не было, разберите чужой кейс письменно: что было единицей, какая метрика, какой риск. Это сильнее фразы «знаком с методологией экспериментов» в skills.