Симулейтив

6 вопросов на собеседовании джуна: что я реально спрашиваю и каких ответов жду

Привет, аналитики! С вами Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

Когда мы говорим о собеседованиях, то очень важно понимать уровень позиции, на которую идет набор. В зависимости от этого необходимо корректировать ожидания. Я не жду от джуна идеального SQL на уровне сеньора и 5 лет опыта. Мне важно понять:

😶 Понимает ли человек базовые принципы;
😶 Умеет ли думать;
😶 Готов ли учиться и не боится ли данных.

Вот мои любимые вопросы, которые я задаю почти всем кандидатам, которые хотят попасть в мою команду. И сразу — какие ответы меня реально радуют:

1️⃣ «Расскажи о себе и почему ты хочешь стать аналитиком данных?»

Что я жду: человек объясняет, как он понял, чем аналитик отличается от разработчика/маркетолога/финансиста. Почему данные — это именно то, чем ему хочется заниматься. Приводит 1–2 примера из жизни/курса, например: «Когда я сделал дашборд по продажам на курсе и увидел, где компания теряет 30%, я понял, что хочу этим заниматься».

2️⃣ Базовый SQL-вопрос:

«Есть таблица orders (id, user_id, amount, order_date). Напиши запрос, который покажет топ-5 пользователей по сумме заказов за последний месяц».

Что я жду: понимание GROUP BY + ORDER BY + LIMIT и знание, как работать с датами (например, WHERE order_date >= date ’2026-03-01’). Не обязательно идеальный синтаксис, главное — логика.

3️⃣ «Как бы ты посчитал средний чек и медианный чек? В чём разница?»

Что я жду: чёткое объяснение: средний = SUM(amount) / COUNT(*), медианный — 50-й перцентиль, и почему медиана важнее при выбросах — один клиент на 500 тыс. руб. может сильно исказить средний чек.

4️⃣ «Представь: тебе дали таблицу с продажами за год. Там 15% пропущенных значений в колонке amount. Что будешь делать?»

Что я жду (один из вариантов):
➖ Сначала посмотрю, почему они пропущенные (возможно, техническая ошибка).
➖ Если техническая — заполню медианой или средним по сегменту.
➖ Если бизнес-логика — оставлю как NULL или создам отдельную категорию «неизвестно». Главное, чтобы человек не сказал просто «не буду учитывать пустые строки».

5️⃣ Мини-кейс (самый важный вопрос):

«Продажи в категории “кредиты” упали на 25 % за последний месяц. Что ты сделаешь первым делом?»

Что я жду (структура ответа):
🟠 Проверить данные — не ошибка ли в выгрузке;
🟠 Разложить по сегментам — найти группу клиентов, в которых произошло падение;
🟠 Посмотреть динамику предыдущих лет — возможно, сезонный фактор;
🟠 Сформулировать 2–3 гипотезы.
Кто начинает сразу с «запустим рекламу» — это сразу минус. Мне нужен аналитик, а не советчик.

6️⃣ Поведенческий вопрос:

«Были ли у тебя конфликты на прошлых местах работы. Как их урегулировал?»

Что я жду: честную историю. Важно услышать, как человек справился с ситуацией, кого обвинил в конфликте, как долго продолжался конфликт и повлиял ли на рабочий процесс?

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

🟠 Записаться на поток с моим участием: simulative.ru/data-analyst

📈 Симулейтив | ВК | YouTube

Присоединяйтесь к мастер-классу по SQL

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

На бесплатном мастер-классе c Евгением Буториным разберём, что такое SQL и почему без него не стать востребованным специалистом. А главное — перейдём к практике: будем решать задачи по SQL и разбирать реальные бизнес-кейсы.

На мастер-классе расскажем и покажем:
🟠 Что такое SQL и почему это основа работы с данными;
🟠 Почему аналитикам важно владеть этим инструментом;
🟠 Как решать практические задачи по SQL разного уровня сложности;
🟠 Как применять запросы к реальным бизнес-задачам: от сегментации клиентов до расчёта метрик;
🟠 Какие фишки и подходы используют в крупных компаниях на примере Альфа-Банка.

❗️ Встречаемся 7 апреля в 19:00 МСК.

💬 Подключайтесь к эфиру, чтобы задать Евгению вопросы про SQL и карьеру в аналитике и разобрать свои кейсы!

➡️ Зарегистрироваться на мастер-класс

📈 Симулейтив | ВК | YouTube

Как CUPED сократил нам время эксперимента с 3 недель до 10 дней

Привет, на связи Аслан Байрамкулов, автор курса по A/B-тестированию 👋🏻

На заре своей карьеры в A/B я столкнулся со следующей ситуацией. Мы упёрлись в потолок, тесты шли по 3 недели, очередь росла. И как сказал в старом интервью Олег Дерипаска: «Так больше продолжаться не может». Вот как мы вышли из данной ситуации.

Кейс: тестируем новую логику ранжирования в каталоге.
Основная метрика: revenue per user.

PM хочет результат через неделю. Классический дизайн эксперимента требовал от нас эксперимента с длительностью 21 день, но у нас просто не хватало трафика для достижения того же результата по надёжности оценки эффекта за 1 неделю, как этого хотел бизнес.

PM расстроен, мы тоже, потому что параллельно в очереди ещё 4 эксперимента, и каждый будет стоять по 3 недели. Но всё равно как-то надо придумывать решение данной проблемы.

В нашем случае revenue per user — метрика с довольно большой дисперсией. Есть пользователи с чеком 100 ₽, а есть с чеком 80 000 ₽. Эта естественная вариативность «забивает» сигнал от нашего воздействия. Мы ищем разницу в 3%, а шум — в разы больше.

И нам на помощь пришел CUPED.

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

CUPED вычитает эту предсказуемую часть из метрики. Формально:

Ŷ_cuped = Y − θ · (X − X̄)

где X — пре-экспериментальный revenue, θ — коэффициент, минимизирующий дисперсию.

В результате мы буквально вдвое сократили время эксперимента, не меняя ни трафик, ни дизайн, ни метрику. Просто умнее использовали данные, которые уже у нас были.

Где CUPED не поможет

Справедливости ради отмечу, что метод не волшебный. Если корреляция данных в пред- и пост-периодах слабая, то выигрыш будет минимальным. Например, для метрики «совершил ли пользователь первую покупку» предэкспериментальных данных просто нет. Для новых пользователей — тоже. Поэтому CUPED отлично работает в ситуациях с высокой корреляцией данных до/после эксперимента и на уже активных/существующих объектах, но плохо на всякого рода регистрациях и первых действиях.

Что это дало нам: пропускная способность экспериментов выросла почти вдвое. Раньше за квартал мы прогоняли 4-5 тестов последовательно. После внедрения CUPED — 8-9. Это не просто ускорение одного теста — это кумулятивный эффект на скорость принятия решений во всём продукте.

В курсе по A/B-тестам мы не только разбираем математику CUPED, но и пишем весь необходимый код на Python, который можно подключить к своему пайплайну для решения ваших задач. Плюс разбираем случаи, когда CUPED не помогает.

🔥 Записывайтесь уже сейчас: simulative.ru/ab-test

📈 Симулейтив | ВК | YouTube

5 SQL‑ошибок, которые продолжают ломать запросы даже у опытных аналитиков

Привет, коллеги! С вами снова Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

Сегодня разберём ещё пять ошибок, которые встречаются куда чаще, чем кажется.

1️⃣ Использование SELECT * в продовых запросах

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

Например, у нас есть таблица с пользователями и транзакциями:

SELECT *
FROM transactions t
JOIN users u ON t.client_id = u.client_id

Сделать SELECT * для изучения и проверки — правильное решение, но записывать такую конструкцию в созданную таблицу нельзя. Если в таблицу users добавят поле с большим текстом — например, выводы ИИ о клиенте — то во-первых, запрос сломается, так как появится новое поле. А во-вторых, если заменили содержимое существующего поля, то запрос внезапно станет в 10 раз тяжелее.

Правильно отбирать только нужные столбцы:

SELECT t.client_id, t.amount, u.segment
FROM transactions t
JOIN users u ON t.client_id = u.client_id

2️⃣ Неправильная работа с NULL в условиях

NULL — это не значение, это пустота. И многие забывают, что сравнения с NULL работают иначе, чем сравнение с заполненными полями.

Например, вам нужно отобрать всех клиентов, кроме клиентов с тестовым емейлом. Если написать:

WHERE email <> ‘test@example.com’

То строки, где email = NULL, не попадут в выборку, хотя логически должны. Это частая ошибка, на которой ловят новичков. Чтобы правильно отобрать клиентов, используйте:

WHERE email <> ‘test@example.com’ OR email IS NULL

или

WHERE nvl(email, ‘N/A’) <> ‘test@example.com’

3️⃣ Фильтрация после JOIN вместо фильтрации до JOIN

Очень часто нам нужно объединить таблицы и отфильтровать их одновременно. Многие начинающие аналитики делают так:

SELECT *
FROM users u
LEFT JOIN transactions t ON u.client_id = t.client_id
WHERE t.amount > 100

Фильтр превращает LEFT JOIN в INNER JOIN и убивает значения из таблицы users, так как отфильтровывает все данные после объединения. Но пользователи без транзакций вам тоже нужны. Чтобы сделать правильный запрос и ничего не потерять, используйте фильтрацию внутри JOIN:

LEFT JOIN transactions t 
    ON u.client_id = t.client_id
    AND t.amount > 100

Это не только правильно, но и оптимально с точки зрения производительности.

4️⃣ Использование HAVING вместо WHERE

Путаница между WHERE и HAVING — это вечная проблема. Запомните, HAVING — это фильтр после группировки. Давайте рассмотрим на примере:

SELECT employee_id, SUM(salary)
FROM salary
GROUP BY employee_id
HAVING SUM(salary) > 1000

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

SELECT employee_id, SUM(salary)
FROM salary
WHERE salary > 1000
GROUP BY employee_id

Выглядит похоже, но смысл совершенно разный.

5️⃣ Использование UNION вместо UNION ALL

UNION, в отличие от UNION ALL, сверяет все строки и удаляет дубли. Поэтому использование UNION значительно замедляет запрос. Если вам не нужно удалять дубли, то не пишите:

SELECT client_id FROM table1
UNION
SELECT client_id FROM table2

Вместо этого используйте:

SELECT client_id FROM table1
UNION ALL
SELECT client_id FROM table2

Ставьте 🔥, если было полезно, и сохраняйте к себе, чтобы не допускать эти ошибки!

📈 Симулейтив | ВК | YouTube

Записывайтесь на обучение в апреле 🍀

Публикуем расписание, когда завершаем наборы на обучение. Напоминаем, что все наши курсы (включая те, что выйдут в течение года) доступны по подписке с выгодой до 70%.

3 апреля

🍀 Дата-сайентист
Ментор курса: Мария Жарова, ML-инженер в команде рекомендаций в Wildberries

🍀 Инженер данных

🍀 Fullstack-аналитик

7 апреля

🍀 BI-аналитик

10 апреля

🍀 Аналитик данных
Ментор курса: Евгений Буторин, руководитель CRM-аналитики развития клиентской базы в Альфа-Банке

17 апреля

🍀 ML-инженер
Ментор курса: Мария Жарова, ML-инженер в команде рекомендаций в Wildberries

🍀 Fullstack-аналитик

24 апреля

🍀 Аналитик данных

🍀 Авторский курс по A/B-тестированию
Автор курса: Аслан Байрамкулов, руководитель направления алгоритмических продуктов в ЦУМ

30 апреля

🍀 Fullstack-аналитик

Сохраняйте к себе, делитесь с коллегами, и ждём вас на наших курсах!

📈 Симулейтив | ВК | YouTube

У вас на главном экране в Power BI все цифры красными стали — говорят, данные упали. Все в панике, срочно разберитесь

Через 2 часа — вебинар, как стать универсальным аналитиком

Подключайтесь в 19:00 МСК и узнайте, почему fullstack-подход становится стандартом, какие задачи теперь решает один специалист вместо трёх и за что на самом деле платят деньги в аналитике. Вебинар проведёт Илья Ковалёв, старший аналитик данных в Dodo Brands и автор канала кусочек пиццы. Присоединяйтесь!

➡️ Регистрация

📈 Симулейтив | ВК | YouTube

Что влияет на зарплату и карьеру аналитика?

Дождались большого исследования рынка аналитики от коллег из NEWHR за 2025 год! Спасибо всем, кто принял участие 🧡

В исследовании приняли участие 1493 аналитика из 14+ специализаций. Они рассказали, где живут, на какие компании работают, на какие рынки ориентируются, как ищут работу и к чему стремятся. А также — сколько зарабатывают и как изменилась их зарплата.

Выжимки из него смотрите в карточках, а с полным текстом исследования можете ознакомиться по ссылке.

Также прикрепляем несколько прямых ссылок на интересные инсайты:
➖ Какие задачи решают аналитики сегодня
➖ На какие компании и в каком формате работают
➖ Как менялись зарплаты аналитиков в течение 2025 года
➖ Сколько они получают сегодня в зависимости от специализации и грейда
➖ Откуда пришли в профессию и как планируют развиваться дальше
➖ ТОП и Анти-ТОП российских компаний по мнению аналитиков
➖ Что ценят в аналитической культуре
➖ На какие конференции ходят и за кем из экспертов следят

➡️ Для сравнения — исследование за 2024 год.

📈 Симулейтив | ВК | YouTube

Как работать с датами и временем в аналитике

Всем привет! На связи Александр Грудинин, ментор курса «Аналитик данных» 👋🏻

Сегодня поговорим про тему, которая кажется простой, но на практике входит в топ источников багов в аналитике — работа с датами и временем.

Самое неприятное, что ошибки с датами сложно заметить. Метрика считается, график строится, всё выглядит правдоподобно... но цифры неверные.

Примеры буду показывать на PostgreSQL, но логика применима и к другим БД.

🟠 DATE vs TIMESTAMP

DATE — просто календарная дата: 2025-03-15
TIMESTAMP — дата + время: 2025-03-15 14:30:00

Почему важно различать? Вот классический баг:

WHERE created_at = '2025-03-15'

Заказ в '2025-03-15 10:30:00' сюда НЕ попадет!

➖ Рабочий вариант #1 — приведение к дате:

WHERE created_at::date = '2025-03-15'

➖ Рабочий вариант #2 (есть мнение, что так лучше, но я сам использую предыдущий):

WHERE created_at >= '2025-03-15' AND created_at < '2025-03-16'

🟠 Часовые пояса — главная боль

Пользователь из Москвы сделал заказ в 1:30 ночи 15 марта. На сервере в UTC это записалось как 14 марта 22:30. Один заказ, два дня. Умножьте на тысячи заказов 🙃

Конвертируем UTC в московское время:

SELECT
 (created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Europe/Moscow')::date AS order_date,
 COUNT(1) AS orders_count
FROM orders GROUP BY 1

В pandas то же самое:

# Указываем что данные в UTC
df['created_at'] = pd.to_datetime(df['created_at']).dt.tz_localize('UTC')
# Конвертируем в Москву
df['created_at_msk'] = df['created_at'].dt.tz_convert('Europe/Moscow')`

Важно:
➖ tz_localize = «эти данные уже в таком поясе, запомни»
➖ tz_convert = «пересчитай из одного пояса в другой»
Перепутаете — и получите сдвиг на несколько часов во всех данных 🙂

🟠 Ещё одни грабли — формат дат

Дата 03/04/2025 — это 3 апреля или 4 марта? Pandas может угадать неправильно. Всегда указывайте формат явно:

df['date'] = pd.to_datetime(df['date'], format='%d/%m/%Y')

Чек-лист для проверки:

#️⃣ Проверяйте тип данных — DATE или TIMESTAMP?
#️⃣ Выясняйте, в каком часовом поясе хранятся данные в источнике данных
#️⃣ Договоритесь с командой о едином часовом поясе для отчётов
#️⃣ Явно указывайте формат при парсинге дат

Ставьте 🔥 и сохраняйте шпаргалку к себе!

📈 Симулейтив | ВК | YouTube

Propensity Score Matching: когда A/B-тест невозможен

Привет! На связи Илья Ковалёв, старший аналитик данных в Dodo Brands и автор канала про аналитику кусочек пиццы 👋🏻

Сегодня поговорим про один метод, который на первый взгляд может показаться ультимативным, но на самом деле он, как и прочие методы, применим не везде — Propensity Score Matching.

В чём суть метода?

Представьте ситуацию: вы запустили новую фичу, но не для всех пользователей случайно, а только для тех, кто сам её активировал. Классический A/B-тест не сработает — группы изначально разные. Активные пользователи включили фичу, пассивные — нет.

Вопрос: как понять, влияет ли фича на метрики, или разница только из-за того, что группы изначально были разными?

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

Вот краткий алгоритм:

Шаг 1: строим модель, которая предсказывает вероятность попадания в тестовую группу

Берём характеристики пользователей (возраст, город, количество заказов, средний чек) и строим логистическую регрессию. Она предсказывает вероятность попадания в тестовую группу — это и есть Propensity Score.

Шаг 2: мэтчим пользователей по Propensity Score

Для каждого пользователя из тестовой группы ищем пользователя из контрольной с максимально близким Propensity Score.

Шаг 3: сравниваем метрики

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

Когда PSM работает хорошо?

1️⃣ Есть много признаков, которыми можно описать пользователей
Больше данных → точнее модель → лучше мэтчинг.

2️⃣ Группы пересекаются по характеристикам
Если в тестовой группе только VIP-клиенты, а в контроле их нет — мэтчинг не сработает. Нужно, чтобы для каждого пользователя из теста нашёлся похожий в контроле.

3️⃣ Решение о попадании в группу зависит от наблюдаемых факторов
Если пользователь активировал фичу из-за факторов, которые мы можем измерить (активность, возраст, город) — отлично. Если из-за чего-то скрытого (настроение, рекомендация друга) — PSM это не учтёт и возникнет смещение.

Как проверить, что мэтчинг работает?

Недостаточно просто проверить баланс групп по характеристикам. Нужна валидация на историческом периоде.

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

Так, на выборках 100k+ пользователей возникает проблема: любая мизерная разница становится статистически значимой. P-value < 0.05 при разнице в 0.01% — технически значимо, но практически шум.

Решение: не использовать всю выборку. Можно определить MDE (минимальный детектируемый эффект, например +2%), расчитать нужный размер выборки под этот MDE и ограничить выборку до этого размера - т.е. взять случайные 50k вместо всех 500k.

Так вы не будете детектить шум как значимый эффект.

На что ещё стоит обратить внимание

1️⃣ Подбор фичей — самое важное. Включайте характеристики, которые реально влияют на решение попасть в тестовую группу. Используйте метрики, логически связанные с наличием воздействия.

2️⃣ Работайте с выбросами. Перед построением модели сглаживайте или убирайте выбросы. Экстремальные значения могут исказить Propensity Score и ухудшить матчинг.

3️⃣ Используйте Caliper Matching. Не мэтчите пользователей, если разница в Propensity Score больше порога (например, 0.01). Лучше потерять часть данных, чем получить плохие пары.

4️⃣ Всегда проверяйте качество мэтчинга на историческом периоде. Это единственный способ убедиться, что метод мэтчит без смещения.

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

📈 Симулейтив | ВК | YouTube

Вебинар: почему компаниям больше не нужны «узкие» специалисты

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

На вебинаре с Ильей Ковалёвым, старшим аналитиком данных в Dodo Brands и автором канала кусочек пиццы, разберём, почему fullstack-подход становится стандартом, какие задачи теперь решает один специалист вместо трёх и за что на самом деле платят деньги в аналитике.

➡️ Зарегистрироваться на вебинар

На вебинаре расскажем:
➖ Как выросли требования к аналитикам;
➖ Почему бизнес ищет специалиста, который понимает данные, умеет общаться с заказчиком и сам собирает решение;
➖ Реальные примеры задач, которые раньше делали три человека, а теперь делает один;
➖ Главные ошибки новичков: уход только в SQL/Python, непонимание бизнес-задач и страх ответственности.

❗️ Встречаемся 31 марта в 19:00 МСК

💬 Подключайтесь к эфиру, чтобы задать Илье вопросы про fullstack-аналитику, карьерные траектории и переход от узких ролей к комплексным задачам.

➡️ Зарегистрироваться на вебинар

📈 Симулейтив | ВК | YouTube

✅ Разбор: ошибки в визуализации

Вчера искали ошибки в двух графиках — давайте разберём.

📊 График 1 — «Выручка по кварталам»

➖ Ошибка 1: обрезанная ось Y
Ось начинается с 95, а не с 0. Из-за этого кажется, что выручка в Q4 в разы больше, чем в Q1. На самом деле разброс всего ~5% (от 98,2 до 103,8). Классический приём манипуляции данными. Разве что вы делаете это намеренно 😉

➖ Ошибка 2: перепутан порядок кварталов
Кварталы идут Q1 → Q3 → Q2 → Q4 вместо хронологического порядка. Это создаёт иллюзию стабильного роста, хотя в Q3 была просадка относительно Q2. Временны́е данные всегда должны идти по порядку.

➖ Ошибка 3: нет единиц измерения на оси Y
На оси — голые числа: 96, 98, 100… Это рубли? Тысячи? Миллионы? Без указания единиц читатель не может интерпретировать данные. Подпись оси — это обязательный элемент любого графика.

➖ Ошибка 4: разноцветные столбцы
Каждый квартал покрашен в свой цвет, хотя это одна и та же метрика за разные периоды. Разноцветность создаёт ложное впечатление разных категорий. Правильно сделать один цвет для всех столбцов.

💡 Как исправить: ось Y от 0, кварталы по порядку (Q1 → Q2 → Q3 → Q4), подпись «млн ₽» на оси и один цвет для всех столбцов.

📊 График 2 — «Источники трафика на сайт»

➖ Ошибка 1: слишком много сегментов
10 секторов на круговой диаграмме — перегруз. Глаз с трудом сравнивает больше 5–6 секторов, а мелкие доли (5-7%) визуально неотличимы друг от друга.

➖ Ошибка 2: все оттенки одного цвета
Все сегменты — синие, отличаются только яркостью. Соседние секторы сливаются, и без легенды понять, где какой источник невозможно.

➖ Ошибка 3: нет процентов на диаграмме
Доли указаны только в легенде сбоку. Читатель вынужден «скакать» глазами между пирогом и легендой. Подписи с процентами должны быть прямо на секторах.

➖ Ошибка 4: сумма долей ≠ 100%
Если сложить все значения: 18 + 15 + 12 + 11 + 9 + 8 + 7 + 6 + 5 + 14 = 105%. Круговая диаграмма по определению показывает части целого — сумма обязана быть ровно 100%.

💡 Как исправить: объединить мелкие источники в «Другое» (оставить 5-6 секторов), использовать контрастные цвета, добавить подписи с % прямо на секторах, пересчитать данные до 100%. Либо можно использовать другой тип графика, столбчатую диаграмму. В индустрии до сих пор не определились, стоит ли запретить круговые диаграммы на законодательном уровне 🙂

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

📈 Симулейтив | ВК | YouTube