Постановка задачи: вопросы для собеседования (часть 3)
Как превратить бизнес-вопрос в аналитическую задачу: определить метрику, выбрать гранулярность, учесть ограничения данных. На собеседовании дают кейс вроде «продажи упали» и ждут, что кандидат задаст правильные уточняющие вопросы, прежде чем бросаться писать запрос. Фреймирование задачи — первый шаг любого анализа.
Вопросы 11–15 из 20
11В чате написали: `churn` вырос, срочно нужен отчет. Какое уточнение важнее всего сделать первым, чтобы зафиксировать корректные `assumptions` и `definition`?
AЧто считается `churn`: какая `population`, какой период неактивности в `time window`, и как обрабатываем `edge cases` вроде возврата после паузы
BВ каких цветах сделать графики, чтобы лучше читалось
CСколько строк должно быть в итоговой таблице
DМожно ли взять данные только за вчера, чтобы быстрее
Ответ: Без явной `definition` `churn` и правил для `edge cases` выводы будут зависеть от скрытых `assumptions`.
Под `churn` могут понимать отмену подписки, отсутствие сессий, отсутствие покупок или другое событие. Нужны границы `time window` и понятная `population`, иначе динамика будет нечестно сравниваться между периодами. Обязательно проговорите `edge cases`, например пользователей, которые вернулись после паузы, и новые регистрации, которые еще не могли зачёрниться.
12Вам поручили: сделай метрику `time to first value`. Какое уточнение наиболее важное, чтобы корректно задать `definition` и `criteria`?
AНужно ли разбивать метрику по сегментам пользователей (когорты, каналы привлечения, платформа), чтобы видеть различия между группами?
BНужно ли считать среднее или медиану, и какой порог считать хорошим значением метрики для постановки целей команды?
CНужно ли показывать динамику метрики по неделям и настроить алерт, если значение выходит за пределы допустимого диапазона?
DКакое событие считается стартом, какое событие считается первой ценностью, какая `population` и как обрабатываем цензуру в `time window` для тех, кто не дошел до события
Ответ: `time to first value` требует `definition` стартового и целевого события и правил цензуры в `time window`.
Без четкого старта и целевого события метрика будет считать разные вещи в разных командах. Нужно определить `population`, например новые регистрации или все пользователи, и согласовать `time window`, в котором вы ожидаете первую ценность. Важно также задать правила для тех, кто не достиг события: это ключевой `edge case`, влияющий на интерпретацию. Только после этого выбирают агрегирование и разрезы.
13Маркетинг спрашивает: пуш-кампания сработала, сколько пользователей вернулось после пуша. Что важнее всего уточнить первым, чтобы определить корректный `criteria` и не перепутать эффект с `baseline`?
AКого именно пушили как `population`, какой `time window` после пуша считаем возвратом, и есть ли `control` или сравнение с `baseline` без пуша
BНужно ли сделать креативный отчет с иллюстрациями
CМожно ли сравнить только тех, кто открыл пуш, и игнорировать остальных
DНужно ли брать данные только за выходные, потому что там больше возвратов
Ответ: Чтобы приписать изменение пушу, нужен понятный `criteria` возврата, `time window` и сравнение с `baseline` или `control`.
Если вы просто посчитаете возвраты после пуша, вы измерите не эффект, а естественную активность `population`. Нужен `baseline` или `control`, иначе нельзя понять, что было бы без пуша. Также важно зафиксировать `time window` атрибуции и определить событие возврата по `definition`. Это защищает от неправильных выводов из-за сезонности и самоселекции.
14Техлид спрашивает: Сколько у нас ошибок в приложении. Какое уточнение самое важное, чтобы выбрать правильный `denominator` и `criteria`?
AВ каких цветах показать график ошибок
BНужно ли сделать отдельный отчет по моделям телефонов
CХотим ли мы сравнить ошибки с конкурентами
DЧто считать ошибкой по `definition`, какая `severity`, и нормируем ли на `denominator` вроде `sessions` или `users` в одном `time window`
Ответ: Без `definition` ошибки и выбора `denominator` нельзя интерпретировать уровень проблем и сравнивать периоды по `criteria`.
Сырые числа ошибок часто вводят в заблуждение, потому что растут вместе с трафиком. Нужна `definition` события ошибки, правила по `severity` и выбор `denominator`, чтобы понимать частоту на пользователя или на сессию. Также важно согласовать `time window`, иначе пики могут быть связаны с релизом или внешними событиями. После этого можно обсуждать разрезы по устройствам и источникам.
15Операции просят: Посчитай долю доставок вовремя. Какое уточнение критично для `definition` `metric` и обработки `edge cases`?
AНужно ли добавить график по дням недели
BНужно ли показывать медиану времени доставки
CЧто значит вовремя: порог в минутах, какой момент старта и конца, какой `time window`, и как считать `edge cases` вроде отмен и переносов
DНужно ли сделать сравнение с прошлым годом
Ответ: `metric` своевременности требует явной `definition` порога и правил для `edge cases` вроде отмен и переносов.
Без порога и точки отсчета невозможно понять, что именно измеряет доля вовремя. Важно зафиксировать, от какого события считаем время и что считаем успешным исходом. Также нужны правила для `edge cases`, потому что отмены и переносы могут либо исключаться из `population`, либо учитываться отдельно. После этого уже можно добавлять разрезы и сравнения периодов.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram