Взвешенные средние и смешение: вопросы для собеседования (часть 3)
Взвешенное среднее, Simpson's paradox, некорректное усреднение средних — задачи, где интуиция обманывает. На собеседовании дают два сегмента, в каждом из которых новая версия лучше старой, но в сумме — хуже. Кандидат должен объяснить парадокс и предложить корректный способ сравнения.
Вопросы 11–15 из 20
11Вы посчитали средний чек по каждому продавцу, а затем усреднили эти значения по продавцам, чтобы получить «средний чек маркетплейса». Что здесь потенциально неверно?
AНичего: это и есть корректный `взвешенное среднее`
BЭто ломает только `сдвиг микса`, но на чек не влияет
CЭто `среднее средних` без `веса`: продавцы с 1 заказом влияют как продавцы с большим объёмом, поэтому нужен `взвешенное среднее` по числу заказов
DНужно наоборот усреднять по продавцам и умножать на число пользователей
Ответ: Простое среднее средних по продавцам — это `среднее средних` и оно искажает результат без `веса`.
Продавец с 1 заказом и продавец с 1000 заказов будут иметь одинаковый вклад, если просто усреднить их средние чеки. Чтобы получить чек по всем заказам, нужно `взвешенное среднее` продавцов с `веса` = количество заказов. Тогда каждый заказ будет иметь одинаковый вес на `уровень агрегации` заказа.
12У вас есть p95 времени ответа по регионам и количество запросов в каждом регионе. Можно ли корректно получить общий p95 как `взвешенное среднее` региональных p95 с `веса` = запросы?
AНет: процентили не агрегируются через `взвешенное среднее`, нужен пересчёт на объединённых данных или доступ к распределению
BДа: достаточно сделать `взвешенное среднее` по числу запросов
CДа: можно взять простое среднее p95 по регионам
DДа: нужно взять максимальный p95 по регионам, это и будет общий p95
Ответ: Процентили не агрегируются через `взвешенное среднее`; их нельзя корректно получить из одних только сегментных процентов и `веса`.
p95 зависит от формы распределения, а не только от среднего значения сегмента. Два сегмента с одинаковым p95 могут иметь разные «хвосты», и при объединении общий p95 может измениться непредсказуемо. Чтобы получить p95 на нужном `уровень агрегации`, нужно пересчитать его на объединённой выборке или иметь доступ к распределению/сырым логам.
13Вы считаете среднее время ответа поддержки по каналам (чат, email). В чате много тикетов, в email мало. Что неправильно в простом усреднении средних времен по каналам?
AНичего: это всегда корректный `взвешенное среднее`
BПроблема только в `сдвиг микса`, но на среднее время это не влияет
CЭто `среднее средних` без `веса`, поэтому маленький канал влияет непропорционально; нужно `взвешенное среднее` по числу тикетов
DНужно брать максимум из средних по каналам, чтобы быть консервативным
Ответ: Простое усреднение по каналам — это `среднее средних` и оно неверно, если `веса` (число тикетов) сильно различаются.
Канал с малым количеством тикетов может слишком сильно повлиять на итоговую метрику, если дать ему такой же вес, как крупному каналу. Если продуктовый вопрос — «среднее время ответа по всем тикетам», `уровень агрегации` — тикет. Тогда нужно считать `взвешенное среднее` каналов с `веса` = количество тикетов или пересчитать из суммарного времени и числа тикетов.
14У вас есть ARPPU по регионам и число платящих пользователей в каждом регионе. Как корректно получить общий ARPPU по продукту?
AВзять простое среднее региональных ARPPU, потому что регионов немного
BВзвесить региональные ARPPU по общей численности пользователей (включая неплатящих)
CВзвесить региональные ARPPU по числу визитов, потому что визиты — это трафик
DПосчитать (суммарная выручка)/(суммарное число платящих), что эквивалентно `взвешенное среднее` с `веса` = число платящих на `уровень агрегации` платящего пользователя
Ответ: Если у вас метрика «на пользователя», общий показатель считается как `взвешенное среднее` с `веса` = число пользователей, иначе вы получаете `среднее средних`.
ARPPU по региону — это выручка, делённая на число платящих пользователей, поэтому при объединении регионов весом должен быть объём платящих. Простое среднее региональных ARPPU завысит вклад маленьких регионов и исказит итог. Правильно посчитать общую выручку и общее число платящих на нужном `уровень агрегации` или эквивалентно применить `взвешенное среднее` с корректными `веса`.
15ARPU за период вырос, но в разрезе iOS и Android ARPU снизился в каждом сегменте. Что корректнее всего сделать перед выводом о росте продукта?
AСчитать, что продукт улучшился, потому что общая метрика выросла
BПроверить `сдвиг микса` и пересчитать общий показатель с фиксированными `веса` по платформам
CУсреднить сегментные ARPU поровну, чтобы «убрать шум»
DИгнорировать сегменты и продлить период сравнения, чтобы всё «усреднилось»
Ответ: Когда итоговая метрика конфликтует с сегментами, проверьте `сдвиг микса` и стандартизируйте с фиксированными `веса`.
Рост общей метрики может быть вызван тем, что выросла доля платформы с более высоким базовым ARPU, даже если внутри платформ ARPU падает. Это эффект `сдвиг микса`, а не обязательно улучшение продукта. Практика — сравнить метрики на одинаковом `уровень агрегации` внутри сегментов и собрать общий результат через `взвешенное среднее` с фиксированными `веса`.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram