Вопросы по теме «Sanity-check и оценка»
Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
Вопросы 1–5 из 20
1На лендинг приходит 500 тыс `visits` в день. `conversion` в покупку составляет около 4% (доля визитов с покупкой). Какая грубая прикидка оценка числа покупок в день по `units` наиболее корректна?
AОколо 2 тыс покупок в день
BОколо 200 тыс покупок в день
CОколо 20 тыс покупок в день
DОколо 5 тыс покупок в день
Ответ: Чтобы перевести `visits per day` в покупки, умножайте на `conversion` и сохраняйте согласованные `units`.
4% от 500 тыс — это около 20 тыс покупок в день. Такой расчёт — хороший `sanity-check`, чтобы оценить нагрузку на оплату и поддержку. Если кто-то получает 200 тыс, скорее всего перепутал проценты и доли или потерял `units`. При необходимости можно построить `upper bound`, считая, что `conversion` не может быть выше 100%.
2Сервис получает 800 `requests per second` на эндпойнт. Какая грубая прикидка оценка `requests per day` ближе всего?
AОколо 70 тыс `requests per day`
BОколо 70 млн `requests per day`
CОколо 7 млн `requests per day`
DОколо 700 млн `requests per day`
Ответ: Перевод из `per second` в `per day` — это умножение на число секунд в дне и проверка `units`.
В сутках 86 400 секунд, поэтому 800 `requests per second` дают около 69 млн `requests per day`. Такая прикидка помогает оценить нагрузку и лимиты до подробных расчётов. Ошибки чаще всего связаны с потерянным нулём или смешением `units`. Для `upper bound` можно учитывать пик нагрузки, а не среднюю.
3У вас 2.5 млн `events` в день и нужно прикинуть объём `events` в месяц для планирования. Какой грубая прикидка перевод `units` самый разумный?
AРазделить дневное значение на 30, чтобы получить месячное.
BУмножить дневное значение примерно на 30, чтобы получить месячное.
CУмножить дневное значение на 365, потому что в году больше дней.
DРазделить дневное значение на 12, потому что в году 12 месяцев.
Ответ: Для грубой оценки месячного объёма из дневного используйте согласованные `units` и умножайте примерно на 30 дней.
В грубая прикидка оценках месячный период удобно брать как 30 дней, если не требуется точность до календаря. Важно не перепутать `units`: `events per day` нужно перевести в `events per month`. Если планируете инфраструктуру, можно также построить `upper bound`, взяв 31 день или пиковый день. Но для первичной прикидки достаточно 30.
4У вас `MAU` = 3 млн. Из исследований известно, что средний пользователь активен около 5 дней в месяц. Какая грубая прикидка оценка `DAU` по `units` ближе всего?
AОколо 500 тыс `DAU`
BОколо 3 млн `DAU`
CОколо 15 млн `DAU`
DОколо 50 тыс `DAU`
Ответ: Перевод из `MAU` в `DAU` удобно делать через `units` активных дней на пользователя.
Если каждый из 3 млн пользователей активен 5 дней в месяц, то суммарно это 15 млн пользователь-дней в месяц. Делим на 30 и получаем около 500 тыс `DAU` по грубая прикидка. Это не точное значение, но хороший `order of magnitude` `sanity-check`. Дальше можно уточнять распределение активности, потому что оно обычно неравномерное.
5Сессия определяется как последовательность действий с таймаутом 30 минут. В отчёте средняя длительность `session` получилась 40 часов. Что это вероятнее всего означает с точки зрения `constraints` и `units`?
AЭто нормально: значит пользователи стали намного более вовлечёнными.
BЭто похоже на нарушение `constraints` и ошибку в `units` или определении `session`, например секунды перепутали с миллисекундами или сессии не закрываются.
CЭто доказывает, что метрика корректна, потому что среднее всегда правдоподобно.
DНужно просто умножить 40 на 60, чтобы перевести в минуты, и всё станет правильно.
Ответ: Если метрика нарушает очевидные `constraints`, первым делом проверяйте определение и `units` расчёта.
При таймауте 30 минут средняя `session` на 40 часов противоречит здравому смыслу и бизнес-логике. Частые причины: перепутанные `units` времени (секунды и миллисекунда), неверное объединение событий или отсутствие закрывающего события. Такой грубая прикидка `sanity-check` помогает сразу искать баг в пайплайне, а не объяснять результат поведением пользователей. После фикса стоит проверить распределение длительностей и долю экстремальных значений.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram