🧑‍💻 Поговорим про аналитику на Data Driven

Обсудим, как находить точки роста, прокрашивать метрики и менять бизнес.

Когда и где

📆 20 сентября в Москве и онлайн

В программе два трека с докладами:

♾ Для продуктовых аналитиков, data-аналитиков и data scientists
♾ Для data-инженеров, системных и BI-аналитиков

А ещё:

🔵 Нетворкинг с экспертами Яндекса: будем много общаться и рассказывать о нашей аналитике

🔵 Встречи 1:1 с C-level-специалистами: вы сможете поговорить с руководителями направлений аналитики в Яндексе

🔵 Дискуссии: обсудим наболевшее в формате открытых нетворкинг-сессий с аналитиками Яндекса и других компаний

🔵 Карьерные консультации: проведём для всех желающих 1:1, на которых можно обсудить свою карьеру

🔵 Квизы и квест на реальных кейсах: а тут вы сможете проверить свои навыки на настоящих задачах и обсудить результаты с нашими экспертами

🔵 Подарки: за участие в активностях мы будем начислять баллы, которые вы сможете потратить на подарки, например на радиоуправляемого робота и Станцию с Алисой

🔵 Конечно, после докладов устроим афтерпати с фуршетом и музыкой

⏬ Зарегистрироваться на конференцию можно здесь

Подписывайтесь:
💬 @Yandex4Analytics

🚕 Как мы увеличили число межгородских поездок в Яндекс Go в два раза

Такси из одного города в другой можно было заказать всегда, но вот цены на это дело больно кусались. Проблема была не только в длине маршрута, но и в том, что в стоимость закладывался обратный путь водителя уже без клиента.

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

🥤 Изменили алгоритмы и снизили цены

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

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

👍 Переосмыслили возврат

Раньше межгородские водители пользовались режимом «домой». Но это сужало поиск заказов до конкретного района в их городе — ждать таких заказов можно очень долго.

Поэтому мы ввели режим «обратно» — его предлагают сразу после завершения межгородской поездки, а маршруты в нём идут в зону всего родного города.

♾ Первые A/B-эксперименты показали:

🔵 Предложений с обратными заказами стало больше на 25%
🔵 Доля водителей, которые возвращаются, увеличилась почти на треть

📆 Ввели предзаказ

Теперь и пользователи, и водители могут планировать поездки по межгороду заранее. Цены на такие заказы ещё ниже, а более долгий поиск позволяет делать долю возвратных водителей выше. Чего мы и хотели достичь 🙌

♾ Сейчас межгород — это:

🔵 188 маршрутов
🔵 38% предзаказов
🔵 1,4 миллиона поездок в месяц

💠 Мы уже запустили совместные поездки по предзаказам, чтобы ещё больше снизить цены для пользователей. Если вы хотите узнать подробности про эту фичу — ставьте 🔥 в реакциях!

Подписывайтесь:
💬 @Yandex4Analytics

🤖 Время потренировать SQL

⏬ Лучший способ вспомнить (или выучить) язык — говорить на нём. Или писать, если речь идёт о языке программирования. Подготовили для вас классическую задачу на знание SQL:

Есть две таблицы:

• users (user_id, registration_date)
• orders (order_id, user_id, order_date, amount)

Получите выгрузку за июнь 2024 года по всем зарегистрированным пользователям в формате:

• user_id
• дата регистрации
• сумма заказов в июне 2024 года (если заказов не было, должно быть 0)

💠 Опубликовали правильный ответ с разбором. Но если вы видите задачу в первый раз, поделитесь своим решением в комментариях!

#задачи_для_аналитиков

Подписывайтесь:
💬 @Yandex4Analytics

⏬ Показывайте, что нашкодили: продолжаем вспоминать SQL

Возвращаемся с правильным ответом и разбором задачи:

🔵 Чтобы отчёт был полным, вам понадобится найти всех зарегистрированных пользователей, даже если они ничего не заказывали в июне.

♾ Для этого используем LEFT JOIN и преобразуем NULL к 0. А ещё — отфильтруем только заказы за июнь 2024 года.

Например, так:

SELECT
u.user_id,
u.registration_date,
COALESCE(SUM(o.amount), 0) AS june_2024_total
FROM users u
LEFT JOIN orders o
ON u.user_id = o.user_id
WHERE o.order_date >= '2024-06-01'
AND o.order_date < '2024-07-01'
GROUP BY
u.user_id,
u.registration_date

💡 Совет. Прежде чем составлять SQL-запрос, внимательно изучите таблицы с данными. Определите, что следует считать ключом и какие данные могут отсутствовать. Так будет легче правильно выбрать JOIN и алгоритм решения задачи.

💎 Какую ещё теорию вы хотели бы вспомнить? Расскажите в комментариях

Подписывайтесь:
💬 @Yandex4Analytics

🧑‍💻 Прощай, фича: как понять, что пора отказаться от функциональности, если A/B-тесты не работают

Привет, это Алексей Чубуков, аналитик группы поиска и назначения водителей в Яндекс Такси. В этом посте я расскажу, как наша команда на 13% снизила нагрузку на сервис.

♾ Что случилось

В 2023 году мы запустили в прод ML-модель, которая прогнозировала вероятность заказа на этапе пина (когда пользователь уже ввёл адрес, но ещё не нажал «Заказать»). Если показатель был высокий, система заранее начинала искать водителя, чтобы ускорить подачу.

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

♾ При этом мы не могли поставить обычный А/B-тест

Допустим, у нас есть два пользователя: Таня (попала в тестовую группу) и Саша (попал в контрольную группу). Они работают в одном бизнес-центре и вечером после работы хотят уехать домой. Ребята одновременно нажимают на кнопку «Заказать», но Таня получает водителя чуть быстрее, потому что находится в тестовой группе, и ей назначается ближайший исполнитель. А Саше достаётся ближайший оставшийся исполнитель, который может быть далеко. Саша недоволен, он отменяет такси и едет домой на метро.

Это хороший пример сетевого эффекта, когда одна группа влияет на другую и меняет результаты исследования.

♾ Поэтому мы использовали свитчбэк

Нам не подходит рандомизация на уровне пользователя, поэтому мы начали делить группы по зоне и времени. Например, в Казани с 08:00 до 09:00 мы раскатывали на 100% пользователей контрольный алгоритм, а с 09:00 до 10:00 — тестовый. И так далее, чередуя периоды. Таким образом, внутри одного временного окна все пользователи находились в одинаковых условиях, и сетевые эффекты были сведены к минимуму.

♾ Что показал обратный эксперимент

🔵 Без фичи нагрузка на сервис снизилась на 13% (как мы и планировали)

🔵 При этом, что удивительно, время подачи (наша царь-метрика) только улучшилось

🔵 А бизнес-метрики остались без изменений

⏬ Если вы тоже думаете использовать свитчбэк-эксперимент — смотрите полную версию моего доклада на YouTube и VK Видео. Там я рассказываю, как выбрать правильную единицу наблюдений и избежать ошибки первого рода, а ещё отвечаю на вопросы из зала.

Подписывайтесь:
💬 @Yandex4Analytics