Портфолио аналитика данных проигрывает, когда это галерея красивых дашбордов на открытых датасетах без вопроса. Нанимающий аналитик за две минуты понимает: человек умеет выбрать цвет графика и не умеет сформулировать решение. Junior/middle закрывают сомнение разбором: вопрос бизнеса, данные и их дыры, метод, вывод, что не стали утверждать. Три сильных кейса сильнее десяти «COVID dashboard» с Kaggle.
Ниже — какие работы работают в 2026, как оформить репозиторий и PDF, чего избегать, как связать портфолио с резюме и откликом. Два полных каркаса кейса: продукт (воронка) и операционный (качество данных). Вакансии: Data Analyst. Вход в роль: как стать Data Analyst. Резюме: резюме Data Analyst.
Коротко:
- Один кейс = вопрос → данные → метод → вывод → ограничение. Дашборд без вопроса не считается.
- Хватит 2–4 работ. Лучше глубина, чем каталог визуализаций.
- SQL должен быть виден: запросы, схема, почему такой джойн. «В Tableau накликал» — слабый сигнал.
- Открытые данные допустимы, если вопрос похож на рабочие (продукт, воронка, эксперимент, качество), а не «топ стран по счастью».
- Навыки, без которых кейс пустой: что должен знать Data Analyst, SQL roadmap.
Что портфолио должно закрыть за 10 минут
Читатель — аналитик или продакт, не HR. Он хочет увидеть: вы умеете перевести расплывчатое «почему упало» в метрику; не врёте данным; выбираете простой метод, если хватает; пишете вывод, который можно оспорить. Python и красивый Plotly вторичны, если SQL и мысль держатся. Python обязателен только если его требуют ваши слоты — смотрите 10 вакансий в каталоге, не миф «всем нужен Python».
Системный аналитик и бизнес-аналитик — другие портфолио (постановки, ТЗ, процессы). Не мешайте в одну папку, если цель — data/product analyst. Соседние роли: системный аналитик, бизнес-аналитик.
Какие кейсы набирать
Берите типы, которые повторяются в вакансиях:
- Воронка / продукт. Где отвал, гипотеза почему, что проверить экспериментом, чего нельзя сказать по этим данным.
- Качество данных. Дубли, дыры в датах, сломанный джойн, как это ломает метрику, какой мониторинг предложили бы.
- Эксперимент или квази-эксперимент. Даже учебный A/B: дизайн, метрика, подводные камни peeking и SRM — на уровне, который вытянете честно. Не притворяйтесь исследователем, если считали средние в Excel.
- Операционный отчёт. Еженедельный срез, который экономит время: не «ещё один дашборд», а «эти 3 цифры смотрим каждый понедельник, вот SQL».
Один учебный EDA «посмотреть корреляции» без решения — не кладите в топ. Kaggle-ноутбук с чужим feature engineering без вашего вопроса — тоже. Если есть рабочий кейс под NDA — обезличьте: отрасль, тип метрики, метод, без названий клиентов и скринов с PII.
Как оформить, чтобы открыли
Один репозиторий или папка на кейс:
- README на 20–40 строк: вопрос, для кого, данные (источник, период, ограничения), вывод в 5 строках, ссылка на ключевой SQL/ноутбук.
- Папка sql/ с читаемыми запросами, не один монолит на 400 строк без комментария «зачем этот CTE».
- Короткий отчёт в Markdown или PDF: графиков мало, подписи «что видно» обязательны.
- Дашборд — опция. Если есть, в README напишите, какие 3 фильтра рабочие, а какие вы не успели.
Не просите «посмотрите весь GitHub». В сопроводительном — одна ссылка на лучший кейс, стыкующийся с вакансией. Письмо: короткое сопроводительное. Ссылки в резюме: проекты в резюме.
Пример 1. Кейс «воронка оплаты»
Учебный или анонимизированный сервис заказов. Вопрос: где ломается путь «корзина → оплата» и что проверять продукту.
Вопрос. В апреле конверсия в оплату просела. Это баг на шаге оплаты, смена трафика или сезонный эффект?
Данные. События воронки, источник трафика, устройство, статус платежа. Ограничение: нет данных о недоступности платёжного провайдера напрямую — только косвенно по кодам ошибок.
Метод. SQL: воронка по шагам, срез по неделе, по источнику, по устройству. Проверка: не сломался ли трекинг (сравнение заказов в БД и событий). Вывод: просадка на шаге «ввод карты» у мобильного Safari, десктоп стабилен. Не утверждаю «виноват провайдер» — нет их логов. Рекомендация: логировать код ошибки, проверить вёрстку поля, не катить новый лендинг как причину без среза.
Артефакты. 3 запроса, 2 графика, README с «чего нельзя сказать». Дашборд не строил: для решения хватило таблицы.
Это выглядит как работа. «Сделал дашборд воронки в Tableau» — нет.
Пример 2. Кейс «метрика врёт»
Вопрос: почему «активные пользователи» выросли, а выручка нет.
Нашёл дубли user_id после смены SDK, часть событий пишется дважды. «Активные» раздуты. SQL: как поймал дубли (окно, ключ события), как пересобрал метрику, какой мониторинг (дневной контроль уникальности). Вывод для бизнеса: не праздновать рост аудитории, пока не починят SDK. Ограничение: не знаю, сколько маркетинговых денег уже потратили на ложную цифру — нет их таблицы.
Такой кейс закрывает вакансии, где в тексте «качество данных», «ad-hoc», «проверить цифру до отчёта совету». Собеседование SQL: SQL на интервью. Общая подготовка: interview prep.
Связка с резюме и откликом
В резюме кейс — не название репозитория. Пуля: вопрос, действие, исход. «Разобрал просадку конверсии в оплату: отделил трекинг от продукта, нашёл срез Safari; рекомендация в README». В отклике на вакансию про платежи — эта ссылка. На вакансию про маркетинг — другой кейс, не тот же дашборд.
Не тащите в skills Tableau, Power BI, Looker, Metabase, Python, R, Spark, если в кейсах один SQL и Google Sheets. Стек как в вакансии, подтверждённый работой: стек в резюме. Проверка файла: разбор резюме.
Чего не класть и как не врать
- Чужой ноутбук, слегка переименованный.
- Генеративные «инсайты», которые не следуют из таблиц.
- Персональные данные, внутренние дашборды с работы, скрины CRM.
- Десять однотипных bar chart «продажи по месяцам».
- Титул «построил ML-модель», если это линейная регрессия ради галочки и вакансия про SQL.
Если кейсов нет — не рассылайте пустое портфолио. За 7–10 дней соберите один разбор по открытым данным с продуктовым вопросом. Потом отклики. Вход без стажа: работа без опыта.