Шишова Ирина 
Тендеры и лиды
Информация
Есть плохой способ искать профессию аналитика: открыть десять вакансий, выписать из них все инструменты и попытаться выучить их одновременно.
Так легко провести год в состоянии вечного студента и так и не выйти на рынок.
Хороший аналитик нужен бизнесу не потому, что знает больше функций SQL или помнит формулу дисперсии. Его задача сложнее: разобраться, что происходит, найти причину, проверить гипотезу и помочь принять решение.
В этом смысле аналитик действительно похож на следователя. Вопрос «сколько?» — только начало. Гораздо важнее вопросы «почему?» и «что с этим делать?».
В 2026 году рынок особенно заметно разделяет два направления. Technical Data Analyst работает ближе к данным, автоматизации и инфраструктуре. Product / Growth Analyst — ближе к продукту, пользователю и бизнес-результату. Граница между ролями не абсолютна, но требования меняются: SQL, Python и статистика уже воспринимаются как базовая техническая грамотность. Конкурентным преимуществом становится способность связать данные с решением.
Идеального набора навыков не существует. Есть набор, который нужен конкретной компании на конкретной позиции. Поэтому цель подготовки — не знать всё, а закрыть базовый минимум и постепенно наращивать глубину.
Аналитик начинает не с SQL
Представим обычную задачу.
Руководитель говорит: «Посчитай конверсию».
Начинающий аналитик открывает SQL и начинает писать запрос.
Опытный сначала задаёт вопросы.
Что считать конверсией? За какой период? Кто входит в знаменатель? Какое событие считается целевым? Что делать с отменёнными заказами? Как учитывать повторные покупки? Нужна общая конверсия или разрез по устройствам, каналам и новым пользователям?
Это называется problem framing — правильная постановка аналитической задачи.
Без неё можно написать безупречный SQL и получить цифру, которая никому не поможет.
Поэтому аналитика начинается раньше кода: с понимания бизнес-вопроса, контекста и решения, которое должна поддержать цифра.
Grain: одна строка может изменить весь результат
Есть ещё одна тема, которую начинающие часто пропускают. Это grain — гранулярность данных.
Проще говоря: что означает одна строка таблицы?
Один пользователь? Один заказ? Товар внутри заказа? Сессия? Событие?
Представим две таблицы: заказы и товары в заказах. В первой один заказ занимает одну строку. Во второй один заказ может занимать пять строк, если покупатель взял пять товаров.
Соединим таблицы и посчитаем выручку.
SQL выполнится без ошибки.
А выручка может внезапно увеличиться в несколько раз.
Проблема не в SQL. Проблема в том, что аналитик не понял гранулярность данных.
Поэтому перед каждым серьёзным запросом полезно ответить на простой вопрос: что представляет собой одна строка?
Grain тесно связан с JOIN, агрегациями и оконными функциями. Без понимания этого слоя даже сильное знание SQL не защищает от логических ошибок.
Data modeling: сначала понять, как устроены данные
Следующий уровень — модель данных.
Аналитику нужно понимать, где лежит факт, где измерение, какие ключи связывают таблицы и почему данные устроены именно так.
В DWH часто используют star schema: центральная таблица фактов окружена таблицами измерений. Например, продажи находятся в факте, а товар, клиент, магазин и дата — в измерениях.
Важно не столько запомнить названия схем, сколько понимать логику.
Где хранится событие? На каком уровне детализации? Как связаны таблицы? Можно ли суммировать показатель после JOIN? Что произойдёт, если соединить факт продаж с таблицей, где одна сущность встречается несколько раз?
Для BI и Middle-позиций это уже рабочий навык, а не теория из учебника.
SQL: язык, на котором говорят данные
SQL остаётся одним из главных фильтров на собеседовании. Причина проста: хороший запрос показывает не только знание синтаксиса, но и способность структурировать задачу.
База выглядит знакомо: SELECT, WHERE, GROUP BY, ORDER BY, HAVING, агрегатные функции, подзапросы, LIKE, IN, BETWEEN.
Затем идут JOIN — и здесь начинаются реальные ошибки.
Важно понимать не только, как написать LEFT JOIN, но и что произойдёт с количеством строк после соединения. Что случится с дубликатами? Почему появились дополнительные строки? Как поведёт себя NULL?
Следующий уровень — оконные функции. ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, FIRST_VALUE, LAST_VALUE, агрегаты с OVER — это уже не набор функций для запоминания.
С их помощью аналитик сравнивает пользователя с предыдущим периодом, ищет первое событие, считает накопительный итог и ранжирует товары внутри категории.
Для Middle+ оконные функции почти обязательны.
Отдельно стоит освоить CTE — конструкции WITH ... AS. Они позволяют разбить сложный запрос на логические этапы. Такой SQL проще читать, проверять и поддерживать.
На более высоких позициях появляется оптимизация: индексы, EXPLAIN, планы выполнения, партиционирование.
Есть и ещё один важный сдвиг. В продуктовых компаниях аналитик всё чаще работает не с привычными таблицами продаж, а с event log — потоком пользовательских событий: просмотр, клик, добавление в корзину, покупка, выход.
Здесь нужно уметь собирать сессии, строить воронки, считать retention и когорты. Плюс понимать разницу между OLTP и OLAP и хотя бы на базовом уровне разбираться в аналитических моделях данных.
Современный SQL-аналитик должен понимать не только язык запросов, но и среду, в которой эти запросы работают.
Метрика — это не просто название
Выручка, заказ, активный пользователь, конверсия — звучит однозначно только до тех пор, пока не начинаются расчёты.
Например, выручку можно считать до возвратов или после. Заказ — по созданию, оплате или отгрузке. Активного пользователя — по факту входа или целевого действия.
Поэтому аналитик должен уметь формализовать каждую важную метрику:
· название
· формула
· источник
· гранулярность
· фильтры
· период
· исключения.
Это кажется бюрократией только до первого конфликта цифр.
Маркетинг показывает одну выручку по своим расчетам, финансовый отдел другую, BI-отчет третью. Все уверены, что правы.
Чаще всего проблема не в арифметике. Команды просто по-разному определили показатель.
Поэтому хороший аналитик не только считает метрики. Он помогает договориться, что именно компания считает.
Python: инструмент автоматизации, а не самоцель
Для аналитика Python прежде всего нужен для обработки данных и автоматизации рутины.
Базовый уровень — типы данных, условия, циклы, исключения, файлы CSV и JSON, списки, словари, множества, кортежи. Отдельно стоит довести до автоматизма работу со строками и датами.
Но главная рабочая лошадка — Pandas.
Нужно уверенно загружать данные, быстро оценивать их структуру, фильтровать строки, группировать, объединять таблицы через merge и concat, строить сводные таблицы и преобразовывать значения.
И здесь есть важный момент, который плохо передают учебные датасеты.
Реальные данные почти никогда не бывают чистыми.
В таблицах встречаются пропуски, дубликаты, неправильные типы, странные даты и выбросы. Аналитик должен не просто построить красивый график, а заметить, что данные пока нельзя использовать для вывода.
На Middle+ появляется вопрос эффективности. Векторизация часто выигрывает у циклов и apply, тип category помогает экономить память, большие файлы приходится обрабатывать частями.
Для больших объёмов данных всё чаще встречаются Spark и Databricks. Polars становится ещё одним полезным инструментом для быстрой обработки таблиц.
Но технология здесь вторична. Python нужен не ради Python. Он должен сокращать путь от задачи до результата.
Data quality: сначала убедитесь, что цифрам можно доверять
В учебном проекте можно взять чистый CSV и сразу считать показатели.
В реальной компании данные могут сломаться ещё до того, как попадут в SQL.
Пропал источник. Изменился формат поля. Дублировались события. Не приехали данные за несколько часов. В одном справочнике товар называется одним кодом, в другом — другим.
Поэтому аналитик должен не только очищать данные, но и проверять их качество.
Представим: запрос показал выручку 10 млн рублей.
Откуда уверенность, что это правильные 10 млн?
Нужно сверить результат с источником, проверить количество заказов, найти дубли, посмотреть период, проверить пропуски и выбросы, сравнить результат с предыдущими периодами и другими контрольными показателями.
Так появляется reconciliation — сверка результата с независимым источником или контрольным расчётом.
Для Junior достаточно уметь находить очевидные проблемы в данных. Для Middle уже важно системно проверять результат перед публикацией.
Хороший аналитик отвечает не только за цифру. Он отвечает за её достоверность.
Статистика: не зубрить формулы, а научиться сомневаться в цифрах
Статистика нужна аналитику не для того, чтобы красиво произносить «p-value».
Она нужна, чтобы понимать, насколько вообще можно доверять результату.
Теория вероятностей даёт базовый язык для работы с неопределённостью. Нужно понимать условную вероятность, теорему Байеса, закон больших чисел и центральную предельную теорему.
Математическая статистика добавляет инструменты для проверки гипотез: доверительные интервалы, t-тесты, Z-тесты, хи-квадрат, мощность теста и расчёт размера выборки.
Но на собеседовании редко требуется вывести формулу t-теста. Гораздо важнее объяснить, когда метод применять, какие у него предпосылки и что может пойти не так.
Особенно часто кандидаты ошибаются с p-value и доверительными интервалами.
p-value не показывает вероятность того, что гипотеза верна. Он отвечает на другой вопрос: насколько необычны полученные данные при условии, что нулевая гипотеза верна.
Ещё важнее различать статистическую и практическую значимость.
Рост конверсии на 0,3% может быть статистически значимым и при этом не иметь смысла для бизнеса. Если внедрение функции стоит дороже полученного эффекта, раскатывать её невыгодно.
Хороший аналитик всегда задаёт два вопроса: Эффект реален? и Он достаточно велик, чтобы что-то менять?
A/B-тест: момент, когда аналитика начинает влиять на бизнес
A/B-тест превращает аналитика из человека, который считает показатели, в участника принятия решений.
Маркетолог хочет новый баннер. Продакт предлагает изменить онбординг. Команда хочет добавить рекомендацию перед оплатой.
Можно просто запустить изменение и посмотреть, что произойдёт.
А можно поставить эксперимент.
Для этого нужно понимать рандомизацию, контрольную и тестовую группы, MDE, уровень значимости, статистическую мощность и размер выборки.
Но главное — видеть весь цикл:
· гипотеза
· дизайн
· запуск
· проверка
· анализ
· решение.
Даже технически корректный тест может дать плохой результат.
Пользователь может реагировать на новизну, а не на качество функции. Аналитик может ежедневно смотреть результаты и остановить эксперимент сразу после достижения статистической значимости. В выборке может появиться SRM — несоответствие распределения пользователей между группами.
Иногда обычный A/B-тест вообще не подходит. Пользователи могут влиять друг на друга. Тогда нужны другие экспериментальные дизайны — switchback или geo-experiments.
На продвинутых позициях появляются CUPED, sequential testing и Bayesian A/B-testing.
Но учить их до базовой статистики бессмысленно. Сложные методы не компенсируют плохое понимание основ.
Метрика → диагностика → решение
Это центральная компетенция хорошего аналитика.
Представим, что конверсия вчера упала с 5,2% до 4,7%.
Начинающий аналитик сообщает: Конверсия упала на 0,5 процентного пункта.
Хороший аналитик продолжает расследование.
Падение произошло везде или только на мобильных устройствах? Только у новых пользователей? На одном этапе воронки? После изменения checkout? Изменилась ли структура трафика?
Допустим, выяснилось: desktop остался без изменений, а основной провал произошёл на мобильных устройствах после запуска нового шага авторизации.
Теперь появляется гипотеза: проблема может быть связана с новым сценарием входа.
Следующий шаг — проверить гипотезу и оценить эффект.
Вот цепочка, которую стоит запомнить:
· метрика
· изменение
· декомпозиция
· причина
· гипотеза
· проверка
· решение.
Именно она превращает работу с данными в аналитику.
Продуктовое мышление: цифра сама по себе ничего не решает
Здесь технический специалист начинает превращаться в продуктового аналитика.
Можно идеально посчитать DAU, retention или LTV. Но если после расчёта никто не понимает, какое решение принять, аналитика не закончена.
Продуктовый аналитик знает метрики, но не поклоняется им.
Он понимает, как устроена воронка, что такое retention и churn, как связаны LTV и CAC, почему растущий ARPU может скрывать ухудшение удержания.
Главный рабочий навык здесь — декомпозиция.
Если конверсия упала, недостаточно сообщить об этом. Нужно разложить проблему: на каком этапе воронки произошёл провал? В каком сегменте? На какой платформе? В какой стране? После какого изменения?
Так появляется root-cause analysis — поиск первопричины.
Retention и экономика: графики должны доходить до денег
Retention показывает, возвращается ли пользователь. Но бизнесу важно другое: что это возвращение означает в деньгах.
Поэтому аналитик должен понимать LTV, CAC, маржинальность, contribution profit и срок окупаемости привлечения.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13701 тендер
проведено за восемь лет работы нашего сайта.
Важно различать N-day retention и rolling retention и уметь читать retention curve.
Универсального «хорошего» retention не существует. Показатель зависит от продукта, модели потребления и частоты использования.
Та же логика работает с LTV. Высокое значение ничего не говорит, если стоимость привлечения растёт ещё быстрее.
Экономическое мышление отделяет аналитика от специалиста, который просто строит графики.
Дашборд — не результат. Результат — решение
BI-инструментом можно владеть блестяще и при этом оставаться слабым аналитиком.
Power BI, Tableau или Looker Studio позволяют показать данные. Но вопрос начинается после построения графика: что должен понять человек, который смотрит на экран?
Хороший дашборд ведёт пользователя от проблемы к выводу. Показывает ключевые отклонения и помогает быстро понять, что требует внимания.
Для Middle полезно уметь строить executive dashboards, KPI-иерархию и автоматические оповещения.
Но визуализация не должна подменять анализ. Красивый график с неправильным выводом остаётся неправильным выводом.
Data Engineering: аналитику нужно знать, откуда берутся данные
Аналитику не обязательно становиться инженером данных.
Но если непонятно, как данные попадают в таблицу, сложно разобраться, почему цифры вдруг изменились.
Полезно понимать ETL и ELT, data pipelines, API, Git, dbt, Airflow и базовые принципы работы DWH.
Не нужно глубоко изучать каждый инструмент. Важно понимать цепочку:
источник
· загрузка
· преобразование
· хранилище
· витрина
· аналитика
· решение.
Тогда становится понятнее, где искать проблему, если утром дашборд показывает пустые данные.
Для Middle всё чаще требуется базовый Git и понимание dbt. Для Senior к этому добавляется архитектура данных и analytics engineering.
Почему технически сильному кандидату могут отказать
Кандидат идеально решает SQL-задачи, знает статистику, уверенно работает с Python — и всё равно получает отказ.
Причина часто не в hard skills.
Один аналитик получает задачу, достаёт данные, строит отчёт и отдаёт результат.
Другой сам замечает проблему, формулирует гипотезу, проверяет её и приходит к продакту уже с вариантом решения.
Обе роли нужны. Но степень влияния на бизнес разная.
Поэтому на собеседовании мало сказать: Я знаю SQL, Python и Power BI.
Намного сильнее звучит история: Конверсия упала. Я разобрал воронку, нашёл проблему на конкретном этапе, проверил сегменты и предложил изменение. После внедрения показатель вырос на X%.
Это уже не перечень навыков. Это доказательство пользы.
Самопрезентация: рассказывайте не о должности, а о действиях
На вопрос «Расскажите о себе» не стоит пересказывать резюме.
Интервьюеру нужно понять, какую задачу кандидат сможет решить в его компании.
Поэтому полезнее говорить через последовательность:
· что произошло
· что требовалось сделать
· что сделали лично вы
· какой получили результат.
Не «работал аналитиком три года», а «нашёл причину падения конверсии и помог команде увеличить показатель на X%».
Если результата в деньгах нет, можно показать масштаб: объём данных, количество пользователей, размер команды, сложность системы или время, которое удалось сэкономить.
Заранее стоит подготовить несколько историй. Особенно сильны кейсы, где была проблема, ограничение, конкретное действие и измеримый результат.
Что изменилось в 2026 году
Рынок аналитики расширяет требования.
Растёт роль Analytics Engineering. Аналитик всё чаще работает не только с готовыми таблицами, но и с логикой преобразования данных.
Развивается причинно-следственный анализ (causal inference). Он помогает понять, стало ли изменение причиной результата, даже без A/B-теста — например, с помощью diff-in-diff и Causal Impact.
Сейчас в профессию входит новый обязательный слой — генеративный ИИ. LLM уже можно использовать для генерации SQL и Python, первичного анализа данных, поиска аномалий и подготовки гипотез.
Стоит понимать, что модель может написать правильный SQL и дать неправильный бизнес-вывод. Логику задает аналитик именно он указывает рамки, поэтому ИИ не отменяет аналитика, она просто дает еще один удобный инструмент ему в руки.
Рабочая модель проста: относиться к ИИ как к очень быстрому стажёру, которому нужно все подробно объяснить и проконтролировать его действия и результаты, проверить важные места и только потом использовать его ответ в работе. Аналитик, который умеет ускорять работу с помощью ИИ получает заметное преимущество.
Что пока можно не учить, если только начинаешь карьеру
Самая распространённая ошибка начинающего аналитика — пытаться освоить весь стек одновременно.
Не обязательно глубоко изучать каждый BI-инструмент. Если компания использует Tableau, освоить его после выхода на работу проще, чем заранее пытаться стать экспертом сразу в Tableau, Power BI и Looker.
Не стоит уходить слишком глубоко в инженерные инструменты, если цель — Junior Data Analyst. Базовое понимание Git и dbt полезно, но сначала важнее закрыть SQL, Python, статистику и продуктовые метрики.
Высшая математика тоже редко становится узким местом. Сложные интегралы не заменят понимания статистики и вероятностей.
И точно не стоит учить сложные статистические методы только ради красивого списка навыков.
Если человек не умеет определить grain таблицы, проверить JOIN и сформулировать метрику, CUPED не сделает его сильнее. Сначала фундамент - потом глубина навыков.
От Junior до Senior по шагам.
На Junior главная задача — научиться самостоятельно решать типовые аналитические задачи.
SQL с оконными функциями и CTE, Python и Pandas, очистка данных, базовая статистика, продуктовые метрики и визуализация — основа, с которой можно начинать.
Следующий слой - аналитическое мышление: правильно поставить вопрос, определить метрику, понять структуру данных и проверить результат.
При переходе на Middle меняется масштаб задач. Появляются оптимизация SQL и Python, data modeling, data quality, event-based аналитика, root-cause analysis, полноценный цикл A/B-тестирования, BI, API, Git и бизнес-экономика.
Здесь уже недостаточно получить правильную цифру. Нужно объяснить, почему она изменилась, насколько вывод надёжен и что с ним делать.
Senior отвечает за более дорогие решения, у него выше уровень ответственности. Появляются causal inference, продвинутые экспериментальные дизайны, архитектура данных, analytics engineering, автоматизация с помощью ИИ и глубокая экспертиза в конкретной отрасли — e-commerce, финтехе, SaaS, маркетплейсах.
Senior — не человек, который знает больше инструментов, важнее уровень его влияния на продукт.
Senior лучше формулирует проблему, быстрее находит причину, понимает ограничения данных и помогает принимать решения с большим эффектом и меньшим риском.
Портфолио важнее сертификатов
Работодатель не покупает количество пройденных курсов. Он нанимает способность решать задачи.
Поэтому сильное портфолио строится вокруг проблемы.
Был бизнес-вопрос. Были данные. Вы выбрали метод анализа, нашли закономерность, сформулировали вывод и предложили действие.
Если есть реальный результат — покажите его в цифрах.
Хороший кейс можно рассказать за несколько минут:
Была проблема
посмотрел данные
обнаружил причину
проверил гипотезу
предложил решение
получили такой-то эффект
Именно такую историю потом можно использовать и в резюме, и на собеседовании.
Pet-проект тоже лучше строить по этой логике. Не анализировал датасет продаж, а «хотел понять, почему падает повторная покупка и какие сегменты дают основной отток».
Разница небольшая только на бумаге. Для работодателя она огромна.
Что на самом деле проверяют на собеседовании
В конце концов, интервью не проверяет, сколько терминов кандидат успел запомнить.
Оно проверяет способ мышления.
Можете ли вы понять бизнес-контекст? Видите ли связь метрики с выручкой и затратами? Умеете ли перейти от проблемы к гипотезе, от данных к выводу, от вывода к действию?
Можете ли объяснить сложное простыми словами?
Понимаете ли ограничения собственных методов?
Знаете ли, когда данные могут врать? Когда A/B-тест нельзя проводить? Почему корреляция не доказывает причинность? Почему статистическая значимость ещё не означает бизнес-ценность?
И главное — можете ли вы пройти всю цепочку:
вопрос
данные
качество
метрика
анализ
причина
гипотеза
проверка
решение.
Вот здесь проходит граница между специалистом, который работает с данными, и аналитиком, который влияет на бизнес.
Что учить в первую очередь
Не нужно учить всю профессию последовательно. Такой программы не существует.
Для входа в профессию достаточно построить первый фундамент:
SQL
Python/Pandas
Статистика
продуктовые метрики
визуализация
аналитическое мышление
несколько хороших проектов.
Но внутри SQL сразу стоит учить не только синтаксис. Разбирайтесь в JOIN, grain, агрегациях и структуре данных.
Следующий уровень:
SQL optimization
data modeling
data quality
A/B testing
root-cause analysis
BI
API
Git
business/economics
stakeholder management.
Для Senior:
Experimentation
causal inference
advanced statistics
data architecture
analytics engineering
domain expertise
strategy
executive communication
AI/automation.
И здесь есть важный принцип.
Не нужно становиться коллекционером технологий.
Сильный аналитик не тот, кто знает двадцать инструментов. Сильный аналитик понимает, какой инструмент нужен для конкретной задачи, знает ограничения метода и способен объяснить результат человеку, который вообще не работает с данными.
Самая дорогая ошибка начинающего — бесконечно готовиться к профессии вместо того, чтобы начать работать в ней.
Закрыли базовый минимум — идите на собеседования. Не хватает навыка — реальная задача быстро покажет какого именно.
В профессию попадают не те, кто знает всё.
Попадают те, кто умеет разобраться в задаче, проверить свои выводы и превратить данные в решение.
Аналитик начинается не с SQL.
Он начинается с вопроса.
И заканчивается решением.
