Портфолио аналитика данных проигрывает, когда это галерея красивых дашбордов на открытых датасетах без вопроса. Нанимающий аналитик за две минуты понимает: человек умеет выбрать цвет графика и не умеет сформулировать решение. 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.

Как оформить, чтобы открыли

Один репозиторий или папка на кейс:

  1. README на 20–40 строк: вопрос, для кого, данные (источник, период, ограничения), вывод в 5 строках, ссылка на ключевой SQL/ноутбук.
  2. Папка sql/ с читаемыми запросами, не один монолит на 400 строк без комментария «зачем этот CTE».
  3. Короткий отчёт в Markdown или PDF: графиков мало, подписи «что видно» обязательны.
  4. Дашборд — опция. Если есть, в 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 дней соберите один разбор по открытым данным с продуктовым вопросом. Потом отклики. Вход без стажа: работа без опыта.

Неделя на первый кейс, если портфолио пустое

Не открывайте пять датасетов. Один вопрос.

  1. День 1. Выберите тип из вакансий: воронка, качество, недельный отчёт. Сформулируйте вопрос одной фразой и ограничение «чего не узнаем».
  2. Дни 2–3. Данные: схема, период, дыры. SQL: 3–5 запросов с CTE и понятными именами. Без модели «на всякий».
  3. День 4. Два графика или две таблицы с подписью «что видно». Вывод и что не утверждаете.
  4. День 5. README. Ссылка в резюме. Одно письмо на вакансию того же типа.

Если за неделю вы делаете «ещё чуть EDA», кейса нет. Обрежьте scope. Лучше узкий честный вывод, чем ноутбук на 80 ячеек без рекомендации.

Как показывать кейс на собеседовании

Три минуты: вопрос, данные и их дыра, метод, вывод, ограничение. Не тур по всем вкладкам дашборда. Если спрашивают SQL — откройте один запрос и объясните джойн. Если спрашивают «что бы сделали с прод-доступом» — назовите 2 проверки, не 15 идей.

Перед созвоном положите README в закладку. Не ищите файл в шаринге пять минут. Рассказ как про проект разработки: как рассказать о проекте. SQL-блок: вопросы SQL.

Частая поломка на интервью: кандидат открывает дашборд и говорит «здесь можно фильтровать». Слышат инструмент, не мысль. Говорите вывод первым, график — доказательством. Вторая поломка: не можете повторить SQL без ноутбука. Перед созвоном перескажите вслух джойн и зерно агрегации. Третья: спорите с интервьюером из-за открытых данных («в реальности так не бывает»). Назовите ограничение и что сделали бы с прод-логами — этого достаточно.

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

Перед публикацией вычитите README чужими глазами: есть ли вопрос в первом абзаце, видно ли ограничение данных, открывается ли SQL. Попросите коллегу задать «и что из этого делать продукту». Если ответа нет — это ещё EDA, не кейс. Второй проход: уберите жаргон ради жаргона, оставьте термины метрик. Третий: проверьте, что нет PII и внутренних URL. Затем одна пуля в резюме и отклик, не «когда будет пять работ». Навыки, которые кейс должен доказывать: навыки аналитика. SQL как база: SQL roadmap.

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

Если вакансия про эксперименты, а у вас только воронка — не притворяйтесь A/B-исследователем в README. Напишите, какой эксперимент предложили бы и каких данных не хватило. Честный пробел плюс план сильнее фейкового p-value. Собеседование всё равно спросит, откуда цифра. Этого хватает, чтобы кейс выглядел рабочим, а не декоративным.

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

Нужен ли сайт-портфолио на домене?

Нет. README и PDF достаточно. Сайт не вредит, если не заменяет суть. Не тратьте месяц на Next.js-обёртку вместо второго кейса.

Power BI обязателен?

Если его требуют ваши 10 слотов — сделайте один отчёт по тому же кейсу. Если слоты про SQL и Python — не коллекционируйте BI «на всякий».

Можно ли брать учебные датасеты магазина?

Да, если вопрос и ограничения взрослые. Нет, если отчёт = «тепловая карта продаж, спасибо за внимание».

Сколько страниц PDF?

3–6 на кейс. Если больше — вы не вырезали. Приложение SQL можно отдельно.

Как показать работу под NDA?

Обезличка + метод + тип результата. Или учебный кейс тем же методом. Не воруйте выгрузки.

Что, если все вакансии про «продуктовые гипотезы», а у меня только отчёты из 1С?

Переведите 1С-опыт на язык вопроса и ограничения данных — это ближе, чем кажется. Доберите один учебный продуктный кейс, не притворяйтесь PM. Вакансии всё равно читайте: что скрыто в описании.

Что сделать сейчас

Выберите один вопрос, похожий на ваши целевые вакансии в каталоге Data Analyst. Соберите README и 2–3 SQL. Вычеркните из GitHub дашборды без вывода. В резюме поставьте одну пулю и одну ссылку. На ближайший отклик приложите этот кейс, не «папку portfolio». Если файл не считывается — разбор резюме, письмо — черновик сопроводительного с правкой под вакансию.

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