Портфолио аналитика данных: 5 pet-проектов и шаблон README

Коротко

Портфолио аналитика данных — это не витрина навыков, а два-три разбора, по которым видно, как вы думаете. Один законченный проект ценнее пяти начатых.

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

Зачем junior-аналитику портфолио

У кандидата с опытом работы есть история: задачи, решения, последствия. У начинающего её нет, и резюме превращается в список инструментов — SQL, Python, pandas, DataLens. Такой список ничего не доказывает: так пишут все. Портфолио отвечает на вопрос, который список оставляет открытым, — что вы делаете, когда получаете данные и нечёткую задачу.

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

Чего портфолио не заменит: базовых знаний SQL и статистики, которые проверят задачами, и тестового задания. Но после хорошего проекта и тестовое делается быстрее: структура сдачи та же.

Что нанимающий смотрит за две-три минуты

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

Таблица ниже — порядок просмотра, под который стоит собирать проект. Это не регламент какой-то компании, а логика человека, у которого на кандидата несколько минут.

Из чего состоит хороший проект: вопрос → данные → метод → вывод → ограничения

Вопрос. Не «анализ продаж», а «какие категории товаров чаще получают низкую оценку из-за доставки». Хороший вопрос подразумевает решение: если ответ «да», кто-то что-то сделает иначе.

Данные. Источник, дата скачивания, версия, лицензия, размер, что одна строка значит. Если вы что-то выбросили — сколько строк и почему.

Метод. Определение метрики, окно, знаменатель, способ сравнения. Для junior достаточно долей, медиан, когорт и доверительного интервала там, где сравниваете группы. Сложная модель без обоснования настораживает сильнее, чем её отсутствие.

Вывод. Одна-две фразы, которые можно переслать менеджеру. С числом и с тем, что из него следует.

Ограничения. Чего данные не говорят, какую альтернативу вы не исключили, что проверили бы дальше. Этот раздел чаще всего отличает аналитика от человека, который умеет строить графики.

Мини-пример: начало проекта на учебной базе

Покажем, как выглядит первый шаг проекта. База — «Маяк», синтетические данные SaaS-продукта из Симулятора SQL-аналитика: пользователи, события, оплаты. Запрос выполняется в бесплатной песочнице без установки. Вопрос: какое действие в первую неделю после регистрации связано с последующей оплатой?

Окно — регистрации с 1 июля по 9 августа 2026 года, 2 165 человек. В июле появился четвёртый канал привлечения, поэтому раньше не берём. Первая оплата в этих данных приходит на 3–20-й день, оплаты записаны по 30 августа: у каждого из когорты срок вышел. Событие app_open не считаем действием — его делают все, кто зашёл.

WITH cohort AS (
  SELECT user_id, signup_date
  FROM users
  WHERE signup_date BETWEEN DATE '2026-07-01' AND DATE '2026-08-09'
),
first_week AS (
  SELECT DISTINCT e.user_id, e.event_name
  FROM events AS e
  JOIN cohort AS c ON c.user_id = e.user_id
  WHERE e.event_name <> 'app_open'
    AND e.event_time < c.signup_date + 7
),
payers AS (
  SELECT DISTINCT user_id
  FROM payments
),
actions AS (
  SELECT DISTINCT event_name
  FROM first_week
)
SELECT
  a.event_name AS action,
  COUNT(f.user_id) AS did_users,
  ROUND(CAST(100.0 * COUNT(CASE WHEN f.user_id IS NOT NULL THEN p.user_id END)
             / COUNT(f.user_id) AS numeric(18, 6)), 1) AS paid_pct_did,
  ROUND(CAST(100.0 * COUNT(CASE WHEN f.user_id IS NULL THEN p.user_id END)
             / (COUNT(*) - COUNT(f.user_id)) AS numeric(18, 6)), 1) AS paid_pct_not
FROM actions AS a
CROSS JOIN cohort AS c
LEFT JOIN first_week AS f
  ON f.user_id = c.user_id AND f.event_name = a.event_name
LEFT JOIN payers AS p ON p.user_id = c.user_id
GROUP BY a.event_name
ORDER BY paid_pct_did DESC;

Что из этого результата делает проект

Сам запрос — ещё не проект. Проектом его делают следующие шаги, и каждый из них стоит записать в README.

Проверка устойчивости. Четыре разницы выглядят похоже, но надёжны не все. Для 95%-го доверительного интервала разницы долей хватит пяти строк Python: у создания рабочего пространства разница 6,3 процентного пункта, интервал от 2,9 до 9,8 — ноль не попадает. У приглашения коллеги разница 4,1 пункта, но нижняя граница интервала около нуля. У отчёта и выгрузки интервалы уверенно накрывают ноль: по этим данным их связь с оплатой не видна.

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

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

Отсюда вывод для README: «Создание рабочего пространства в первую неделю связано с оплатой: 24,6% против 18,3%. Это кандидат на эксперимент в онбординге, а не доказанная причина». Такой текст интересно обсуждать на собеседовании.

Пять идей pet-проектов на открытых данных

Ниже пять проектов на данных, которые можно скачать без регистрации в платном сервисе. Источники проверены 23 октября 2026 года. Проекты разного типа: продуктовая метрика, операционная эффективность, качество данных и выгрузки из госстатистики, клиентский опыт. Брать все пять не нужно — двух-трёх разных хватит.

Идея 1. Какое действие новичка связано с оплатой

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

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

Идея 2. Какие рейсы летают полупустыми

Вопрос: на каких направлениях и моделях самолётов заполняемость ниже всего и сколько выручки приходится на одно занятое место? Данные: демонстрационная база «Авиаперевозки» от Postgres Professional, лицензия MIT — её можно использовать в публичном проекте с указанием источника. На производной от неё версии работают наши курсы и SQL онлайн: первые запросы можно писать прямо в браузере.

Что посчитать: заполняемость рейса — посадочные талоны, делённые на число мест в модели самолёта; затем распределение по направлениям и классам обслуживания. Подвох для раздела ограничений: посадочные талоны есть только у вылетевших рейсов, у запланированных продажи ещё идут. Сравнивать нужно рейсы с одинаковым статусом.

Учтите версию. На сайте Postgres Pro сейчас лежит редакция от 1 сентября 2025 года с другими таблицами (segments, routes, airplanes_data) и требованием PostgreSQL 15+. Наши курсы построены на версии 2017 года с таблицами ticket_flights и aircrafts. В README укажите, какую версию взяли, иначе чужой запрос не повторится.

Идея 3. Как меняется пассажиропоток на станциях метро

Вопрос: какие станции московского метро больше всего выросли или потеряли пассажиров за последние годы и связано ли это с открытием соседних станций? Данные: портал открытых данных Москвы data.mos.ru, набор «Пассажиропоток по станциям Московского метрополитена» (номер 62743) — входы и выходы по станции, линии, году и кварталу с 2021 года.

Что посчитать: изменение входов год к году по одному и тому же кварталу, чтобы не путать сезонность с трендом; станции с наибольшим отклонением; дисбаланс входов и выходов. Перед расчётами проверьте нули и пропуски: квартал с нулём может означать закрытие станции на ремонт, а не отсутствие пассажиров. Что показать: таблицу лидеров роста и падения с объяснением хотя бы трёх случаев.

Идея 4. Где одинаковые продукты стоят дороже

Вопрос: насколько различаются цены на один и тот же набор товаров между регионами и что подорожало сильнее всего за год? Данные: раздел «Цены» на сайте Росстата, таблицы «Средние потребительские цены на товары и услуги» в XLSX — на каждый месяц отдельный лист, строки — страна, округа, регионы и города.

Главная работа здесь — превратить широкую таблицу с объединёнными ячейками в длинную: регион, товар, месяц, цена. Это обычная задача аналитика, и в портфолио она смотрится честно. Что посчитать: отношение цены в регионе к средней по стране, рост за двенадцать месяцев по товарам, разброс между регионами. Ограничение: средняя цена — не индекс цен, и сравнивать нужно только одинаковые позиции.

Идея 5. Как опоздание доставки сказывается на отзыве

Вопрос: насколько чаще покупатель ставит низкую оценку, если заказ приехал позже обещанной даты, и в каких категориях эффект сильнее? Данные: Brazilian E-Commerce Public Dataset by Olist на Kaggle — 100 тысяч заказов 2016–2018 годов, отдельные таблицы заказов, товаров, продавцов, оплат и отзывов, лицензия CC BY-NC-SA 4.0 (некоммерческое использование с указанием авторства).

Что посчитать: опоздание как разницу фактической и плановой даты доставки, долю оценок 1–2 у опоздавших и вовремя доставленных, зависимость от длины опоздания. Ловушка: в заказе может быть несколько товаров от разных продавцов, и наивное соединение размножит отзывы. Этот датасет разбирали тысячи раз, поэтому вопрос должен быть своим, а проверка зерна — видна в коде.

Где публиковать: GitHub, Jupyter, дашборд

GitHub — основной адрес портфолио. Профиль с закреплёнными проектами, у каждого README на русском, если ищете работу в России. GitHub показывает Jupyter-ноутбуки прямо на странице, поэтому проверяющему не нужно ничего запускать. Перед публикацией перезапустите ноутбук с первой ячейки: выводы должны совпадать с текстом README.

Ноутбук хорош для разбора, но плох как первая страница: в нём вперемешку код, промежуточные таблицы и выводы. Держите его вторым слоем, а итог — в README. Если проект на SQL, положите запросы отдельными файлами .sql с комментариями.

Дашборд — для проектов, где результат живёт во времени: пассажиропоток, цены. Самый простой путь — Yandex DataLens: облачный сервис с публичным доступом к дашборду по ссылке. Apache Superset и Metabase ставятся на свой сервер; для портфолио обычно хватает запуска в Docker, скриншотов в README и файлов с запросами. Дашборд без README с вопросом и выводом читается как набор графиков, поэтому не заменяет его.

Шаблон README для проекта

Шаблон ниже рассчитан на то, что первый экран прочитают, а остальное — только если заинтересует. Скопируйте его и заполните сверху вниз. Если какой-то раздел заполнить нечем — скорее всего, проект ещё не закончен.

# Название: вопрос, а не тема
Пример: «Связано ли создание пространства в первую неделю с оплатой»

## Ответ за 30 секунд
- Главный вывод одной фразой, с числом.
- Что из этого следует: решение или следующий шаг.
- Главное ограничение.

## Данные
- Источник: ссылка, дата скачивания, версия.
- Лицензия и условия использования.
- Что значит одна строка; сколько строк до и после очистки.

## Метод
- Определения метрик, окно, знаменатель.
- Как сравнивали группы и почему так.

## Результат
- Одна таблица или один график с подписями.
- Проверки: что могло опровергнуть вывод и что показало.

## Ограничения и что дальше
- Чего данные не говорят.
- Что проверил бы следующим, будь больше данных или времени.

## Как повторить
- Структура папок: data/, sql/, notebooks/, README.md
- Команды запуска и версии пакетов.
- Ожидаемый контрольный итог (например, 2 165 строк в когорте).

Чек-лист: проект готов к отправке

Пройдите по списку перед тем, как ставить ссылку в резюме или сопроводительное письмо. Каждый пункт — то, что проверяющий заметит за первые минуты.

• Название репозитория и заголовок README говорят, какой вопрос решается.
• Ответ с числом — на первом экране, без прокрутки.
• Источник данных, дата и лицензия указаны; учебные данные подписаны как учебные.
• Есть хотя бы одна проверка: число строк после соединения, уникальность ключа, интервал.
• Раздел ограничений есть и в нём не формальность, а конкретная альтернатива.
• Ноутбук перезапущен с начала, выводы совпадают с README.
• В коде нет паролей, токенов и личных данных.
• Знакомый без вашей помощи открыл проект и пересказал вывод.
• Вы можете за две минуты рассказать проект вслух и ответить «почему так».

Ошибки, из-за которых проект не засчитывают

Туториал вместо вопроса. «Анализ Titanic», «EDA датасета», повтор урока с теми же графиками. Проверяющий видел этот проект много раз и не узнает из него ничего о вас. Если взяли популярный датасет — задайте вопрос, которого нет в первых найденных разборах.

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

Грязный код. Ячейки, которые работают только в определённом порядке, переменные df1, df2, df_final_final, закомментированные куски. Код в портфолио читают как образец вашей рабочей аккуратности.

Данные из платного курса без разрешения. Датасеты и задания платных программ обычно принадлежат их авторам; публикация решения может нарушать условия курса и вдобавок показывает чужой вопрос. Если хочется показать курсовой проект — проверьте условия или перенесите метод на открытые данные. То же касается рабочих данных прошлого работодателя: их не публикуют даже обезличенными без разрешения.

Вывод сильнее данных. «Опоздание доставки снижает оценку на 1,5 балла» из сравнения средних без учёта категорий — первая цель вопросов на интервью. Осторожная формулировка с ограничением выглядит профессиональнее уверенной.

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

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