Задачи по pandas
на собеседовании
аналитика

Решение

search_data['query'].value_counts().head(10)

# home decor     273
# clothing       258
# electronics    246
# shoes          223

Ловушка

Просили топ-10, а вернулось 4 строки: разных запросов в данных всего четыре. Код правильный, но молча сдать «топ-10» из четырёх — слабый ответ. Сильный — заметить и сказать вслух: «Уникальных запросов 4, поэтому топ-10 совпадает со всем списком. Если бы их было больше, head(10) отрезал бы лишнее».

Второй вопрос, который стоит задать: популярность — это число поисков или число людей, которые искали? Если один пользователь ищет «shoes» 30 раз подряд, по поискам запрос вырастет, по людям — нет. Для продукта чаще важны люди: search_data.groupby('query')['user_id'].nunique().

Как решают почти все

df = search_data.merge(session_data, on='session_id')
df[df['platform'] == 'IOS'].groupby('location')['user_id'].nunique()

# Chicago          49
# Los Angeles      50
# New York         50
# San Francisco    49

Выглядит правдоподобно. Но всего пользователей в данных 50 — получается, почти каждый из них сидит с iOS в каждом из четырёх городов. Это первый звоночек.

Ловушка: merge размножил строки

Посмотрите на session_data: 1000 строк, а сессий в ней всего 100. У каждой сессии в среднем 10 строк — и разные платформы: в моём запуске у 89 сессий из 100 встречаются все три платформы сразу. Таблица «сессия → платформа» на деле не справочник.

session_data['session_id'].is_unique   # False
len(search_data)                        # 1000
len(df)                                 # 10010 — в 10 раз больше

После merge каждый поиск склеился со всеми строками своей сессии: из 1000 поисков стало 10 010 строк, и один и тот же поиск оказался одновременно на iOS, Android и в вебе. Отсюда «почти все пользователи на iOS».

Это та же ошибка, что в SQL называют размножением строк в JOIN. В нашей SQL-песочнице эталон одной задачи из-за неё месяцами отдавал 3 миллиона отзывов при 10 тысячах в таблице — и все проверки были зелёными, потому что сверяли ответ с самим собой.

Как надо

Сначала проверить ключ и спросить интервьюера, как быть с конфликтом платформ. Вариантов несколько: взять самую частую платформу сессии, первую по времени (если бы было время), или признать данные битыми. Я бы предложил самую частую и явно это проговорил:

# одна платформа на сессию — самая частая
sess = (session_data.groupby('session_id')['platform']
        .agg(lambda s: s.value_counts().index[0])
        .reset_index())

# validate упадёт с ошибкой, если ключ справа снова не уникален
df = search_data.merge(sess, on='session_id', how='left', validate='many_to_one')
len(df)  # 1000 — строк столько же, сколько поисков

df[df['platform'] == 'IOS'].groupby('location')['user_id'].nunique()

# Chicago          36
# Los Angeles      38
# New York         34
# San Francisco    38

Ловушка: доля от чего?

В формулировке нет знаменателя, и её можно понять двумя способами:

• Прочтение А. Какая доля пользователей платформы искала 'shoes'. Знаменатель — все пользователи этой платформы.
• Прочтение Б. Как пользователи, искавшие 'shoes', распределены по платформам. Знаменатель — все, кто искал 'shoes'.

Это разные вопросы для продукта. А отвечает «насколько обувь популярна у iOS-аудитории», Б — «откуда приходят те, кто ищет обувь». Правильный ход — спросить. Если интервьюер скажет «на ваше усмотрение», выберите одно и назовите знаменатель вслух.

Решение (на данных из вопроса 2, где одна платформа на сессию)

shoes = df[df['query'] == 'shoes']

# А: доля пользователей платформы, искавших shoes
shoes.groupby('platform')['user_id'].nunique() / df.groupby('platform')['user_id'].nunique()
# ANDROID 0.840   IOS 0.714   WEB 0.840

# Б: распределение искавших shoes по платформам
shoes.groupby('platform')['user_id'].nunique() / shoes['user_id'].nunique()
# ANDROID 0.84   IOS 0.70   WEB 0.84   — в сумме 2.38, а не 1

Во втором прочтении доли в сумме дают 238%. Это не ошибка: один человек пользуется несколькими платформами и попадает в каждую. Если от вас ждут распределения, которое складывается в 100%, нужно сначала закрепить пользователя за одной платформой — и снова спросить, по какому правилу.

Вторая ловушка: строки вместо людей

# так считать нельзя — это доля поисков, а не пользователей
shoes.groupby('platform').size() / df.groupby('platform').size()
# ANDROID 0.262   IOS 0.217   WEB 0.200

Разница в разы: 26% поисков против 84% пользователей. В вопросе прямо сказано «уникальных пользователей», значит нужен nunique по user_id, а не size или count.

search_data.groupby('query').agg(
    searches=('user_id', 'size'),
    users=('user_id', 'nunique'),
    sessions=('session_id', 'nunique'),
).sort_values('searches', ascending=False)

#              searches  users  sessions
# home decor        273     50        96
# clothing          258     50        95

Где режут

Путают size и count: size считает все строки, count — только непустые значения в колонке. На данных с пропусками результаты разойдутся. Именованная агрегация имя=(колонка, функция) сразу даёт читаемые названия колонок — интервьюеры это замечают.

search_data.pivot_table(index='location', columns='query',
                        values='user_id', aggfunc='nunique', fill_value=0)

# query          clothing  electronics  home decor  shoes
# Chicago              40           34          37     36

Где режут

Без aggfunc pandas посчитает среднее по user_id — бессмысленное число, которое выглядит как метрика. Ещё одна ловушка: сумма по строке не равна числу уникальных пользователей города, потому что один человек ищет несколько категорий.

dau = search_data.groupby(search_data['timestamp'].dt.date)['user_id'].nunique()
# 2024-01-01 49, 2024-01-02 46, ... 2024-01-07 47

# то же через resample — колонка должна быть datetime
search_data.set_index('timestamp').resample('D')['user_id'].nunique()

dau.sum()                          # 325 — НЕ пользователи за неделю
search_data['user_id'].nunique()   # 50 — а вот это они

Где режут

Складывают дневные DAU и называют результат недельной аудиторией: 325 вместо 50. Уникальные пользователи не складываются — их надо пересчитывать на нужном периоде. Это тот же подвох, что с rolling DAU в SQL-задачах.

s = search_data.sort_values(['user_id', 'timestamp']).copy()
gap = s.groupby('user_id')['timestamp'].diff()
s['new_session'] = gap.isna() | (gap > pd.Timedelta(minutes=30))
s['session_num'] = s.groupby('user_id')['new_session'].cumsum()

Где режут

Забывают отсортировать по времени — diff считает разницу между соседними строками в текущем порядке. Или делают diff без groupby, и первая строка нового пользователя получает разницу с последней строкой предыдущего. Первый поиск пользователя (NaN в gap) — всегда новая сессия, это условие легко потерять.

cnt = search_data.groupby(['location', 'query']).size().reset_index(name='n')
cnt['rnk'] = cnt.groupby('location')['n'].rank(method='dense', ascending=False)
cnt[cnt['rnk'] == 1]

# Chicago        clothing    69
# Los Angeles    clothing    68
# New York       home decor  84
# San Francisco  clothing    62
# San Francisco  home decor  62   ← ничья

Где режут

В Сан-Франциско ничья, и «топ-1» — это две строки. Решение через sort_values().groupby().head(1) молча выкинет одну из них. Спросите, что делать с ничьими: method='dense' оставит обе, method='first' — ровно одну. Это прямой аналог ROW_NUMBER против DENSE_RANK в SQL.

d = search_data.assign(day=search_data['timestamp'].dt.normalize())
d = d.join(d.groupby('user_id')['day'].min().rename('cohort'), on='user_id')
d['day_n'] = (d['day'] - d['cohort']).dt.days

ret = d.pivot_table(index='cohort', columns='day_n', values='user_id', aggfunc='nunique')
ret.div(ret[0], axis=0)   # делим на размер когорты — колонку дня 0

Где режут

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

random.seed(7)
events = pd.DataFrame({
    'user_id': [random.randint(1, 300) for _ in range(2000)],
    'event': [random.choices(['view', 'cart', 'purchase'], [70, 20, 10])[0] for _ in range(2000)],
})

steps = ['view', 'cart', 'purchase']
reached, users = [], None
for step in steps:
    step_users = set(events.loc[events['event'] == step, 'user_id'])
    users = step_users if users is None else users & step_users  # прошёл все предыдущие шаги
    reached.append(len(users))

funnel = pd.DataFrame({'step': steps, 'users': reached})
funnel['conv_from_prev'] = funnel['users'] / funnel['users'].shift()

#        step  users  conv_from_prev
# 0      view    299             NaN
# 1      cart    223           0.746
# 2  purchase    100           0.448

Где режут

Считают каждый шаг независимо: «купивших» тогда 131, а не 100. Разница — 31 человек, у которых есть покупка, но нет корзины или просмотра. В реальных логах так бывает (покупка из письма, потерянное событие). Спросите, строгая воронка нужна или нет, и учитывается ли порядок по времени. Здесь времени нет, поэтому порядок проверить нельзя — это тоже стоит сказать вслух.

cart = events.loc[events['event'] == 'cart', ['user_id']].drop_duplicates()
buy = events.loc[events['event'] == 'purchase', ['user_id']].drop_duplicates()

# способ 1: merge с indicator — аналог LEFT JOIN ... WHERE b.id IS NULL
x = cart.merge(buy, on='user_id', how='left', indicator=True)
lost = x.loc[x['_merge'] == 'left_only', 'user_id']

# способ 2: короче
lost = cart.loc[~cart['user_id'].isin(buy['user_id']), 'user_id']

len(cart), len(lost)   # 224, 123

Где режут

Делают обычный merge (inner) и получают ровно тех, кто купил — противоположность нужного. Или забывают drop_duplicates, и один пользователь с пятью добавлениями в корзину появляется в ответе пять раз. indicator=True полезен и как отладка: показывает, сколько строк нашли пару, а сколько нет.