Коммуналка аналитиков

Платформа, которая сэкономила нам десятки тысяч человеко-часов

Привет! Это Георгий Фандеев. Я пришёл в Авито в 2017 году и поначалу занимался верхнеуровневой аналитикой: временные ряды, сложные бизнес-метрики...

Спустя год я был прикомандирован в команду опыта покупателя — предыдущий аналитик ушёл на другой проект. Здесь-то я и окунулся в мир продуктовой аналитики: логирование, DDS, метрики, фичи и, конечно же, A/B. 

Помню, как впервые увидел «разбор» A/B-теста. Аналитик соседней команды долго корпел над каким-то Ad hoc дашбордом с расчётом недавнего A/B. После чего ещё кучу времени пытался понять, что же в этом тесте произошло. Все ли нужные метрики посчитаны? Корректно? А если такой разрез добавить? А такую метрику?

— Это и есть анализ A/B!? — в ужасе спросил я.
— С A/B-тестами всегда так, Гошан... — фаталистически резюмировал мой коллега. 

В тот день я отчётливо понял, что не хочу заниматься A/B никогда в жизни. С тех пор я, так или иначе, поучаствовал в нескольких тысячах A/B-тестов. Ведь, на моё счастье, тем самым аналитиком, чьё место я занял, был Даня Леньков, который ушёл заниматься построением A/B-платформы Авито.

Сначала это были робкие Jupyter-ноутбуки. Затем витрины, результаты расчётов которых выводились в Tableau. Чуть позже появилась и своя обёртка для визуализации — поначалу минималистичная до наивности, а теперь над ней работают дизайнеры. 

A/B-платформа росла, усложнялась, появлялись и отмирали фичи, росла нагрузка, скорость, точность расчётов…

Теперь продукт вышел на рынок, и вы знаете его под названием Trisigma. Я очень рад и горд за ребят, но ещё больше рад за аналитиков Авито, ведь благодаря Trisigma они избавлены от рутинных расчётов. Достаточно лишь грамотно задизайнить A/B, а всё остальное платформа делает за нас.

Без шуток, Trisigma уже сэкономила десятки тысяч человеко-часов. И если вы хотите узнать больше об этом ключевом для Авито инструменте, приходите на онлайн-митап Trisigma.

📅 Он пройдёт онлайн 14 августа в 18:00, регистрация уже открыта: 
Зарегистрироваться →

Всем привет! Сегодня хотим поддержать соседей из коммуналки напротив 💚

Наши DS-инженеры тоже ведут канал, он называется Доска AI объявлений.

Там ребята рассказывают, как устроено их направление, какие технологии они используют и чему обучают модели, как развиваются и развлекаются вне работы.

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

🎁 Набор карточек с темами-айсбрейкерами, чтобы завести разговор в любой компании айтишников. Ребята уже попробовали карточки в деле на своём недавнем выезде.

Чтобы поучаствовать в розыгрыше:

1️⃣ Переходите в канал и подпишитесь.

2️⃣ Расскажите, как предпочитаете отдыхать, чтобы не выгорать от работы и летней жары, в комментариях к посту с розыгрышем.

🏆 Случайный комментатор получит набор карточек.

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

Читатели, привет!💜

В этот прекрасный пятничный вечер мы к вам без поста, но с порцией жизненных смешнявок! Призываем и вас делиться в комментариях любимыми аналитическими мемами - давайте повеселим друг друга и зарядим на классные выходные=)

До встречи на следующей неделе!

Привет! Продолжаем спонтанную серию постов про MDE — точнее, о том, как про него рассказывать. В первой части обсудили концептуальную идею MDE, а в этой рассмотрим, как его выбрать и от чего он зависит.

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

Как выбрать MDE?
Логичное предположение — давайте возьмём самый маленький MDE, чтобы детектить самые маленькие изменения!

〰️У всего есть размен: чем меньше MDE — тем больше людей нам понадобится для принятия решения.

На графике видно, как меняется MDE при увеличении объёма выборки от 100 до 10 000 пользователей. Можем сделать вывод: увеличение выборки со 100 до 2 000 сильно влияет на MDE, а вот дальше размен увеличения выборки на точность всё менее заманчивый.

Размер выборки — один из показателей, влияющих на MDE. А что ещё?

〰️Ещё разброс данных и стат параметры — в них сегодня погружаться не будем, но обсудим разброс данных.

Рассмотрим на коммон сенсе: если данные непредсказуемые — сегодня конверсия 5%, завтра 18%, а послезавтра 12% — то чтобы понять, есть ли относительный рост конверсии на 20%, нам нужно будет достаточно долго наблюдать за данными.

А если конверсия стабильно около 10% и колеблется от 9.9% — до 10.2%, то если при включении теста она станет 12%, мы за более короткий срок сможем удостовериться, что это влияние нашего теста. Так, при уменьшении разброса данных, MDE будет уменьшаться.

❤️ — если серия полезна и добавляем в канал больше размышлений про харды

В комментах — график влияния разброса данных на MDE и ещё несколько слайдов :)

#ЖеняМур

Привет! Я Женя — преподаватель Академии Аналитиков Авито. Веду лекции как для наших внешних студентов, так и для коллег в компании.

Сегодня хочу поделиться частью занятия «Эксперименты с 0». Это курс для сотрудников Авито, которые хотят понять, о чём же говорят аналитики.

Итак, MDE, а точнее — как его можно объяснить начинающим аналитикам и коллегам не аналитикам. Представьте:

Вы сидите в комнате и не слышите посторонних звуков. Значит ли, что в комнате тишина?

Может быть, да, а может, звук есть, но он такой тихий, что мы его не слышим.

Если мы не слышим звук, не всегда означает, что его нет. Вероятно, он есть, но он тише нашего порога слышимости.

Такой порог «слышимости» для теста — MDE.

Если на тесте мы не видим статистически значимый результат, возможно, его нет. А может, он есть, но находится на уровне меньше, чем наш уровень «слышимости».

За 4 года разных попыток объяснить, что такое MDE, на простом языке — мне впервые это удалось. Студенты из группы не аналитиков сказали, что всё очень понятно и логично. Был праздник!

❤️ — Лайк, если хотите вторую часть поста! Расскажем, как наглядно показать, от чего зависит MDE и как его подобрать.

А в комментах поделилась слайдами с занятия <3

#ЖеняМур

Да настройте вы уже эти лифты…🛗

Всем привет! На связи Дима Кротов. После нескольких лет в профессии у каждого из нас появляется «профдеформация»: стоматолог первым делом смотрит прикус, дизайнер — отступы и шрифты, а аналитик… не может пройти мимо криво работающего лифта 😳

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

Стоя в очередной послеобеденной очереди к лифту, я думал, как можно подойти к решению этой проблемы с аналитической точки зрения. Ведь лифт — это тот же алгоритм, задача которого собрать людей и доставить их в нужную точку, почти как тариф «Вместе» в Такси.

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

✅ Целевая: время от нажатия на кнопку до доставки на целевой этаж
🔷 Прокси: среднее время ожидания лифта, количество промежуточных остановок
🛑 Контр: доля пустых рейсов, износ лифта

А по пути можно ещё и какой-нибудь CSAT замерять🙂

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

1️⃣Batching (группировка заявок) — система собирает заявки за «интервал сбора», затем группирует людей с близкими целями в одну кабину (батчи), минимизируя число остановок и общее время поездки.

2️⃣Zoning (зональное разделение) — этажи делятся на зоны (например, 1–7, 8–14, 15–20). В зависимости от введённого пользователем этажа, система направляет его в лифт, обслуживающий именно эту зону. Это снижает количество «пересечений» между зонами и ускоряет доставку, однако разные зоны могут пользоваться разным спросом, из-за чего может простаивать свободный ресурс.

3️⃣Nearest (ближайший в своей группе) — из сгруппированных заявок система выбирает кабину, которая быстрее всех сможет забрать пассажиров и отвезти их по маршруту с минимальным «пробегом» без пассажиров.

Супер, мы близки к решению. Надо понять, как задизайнить тест.

Это оказалось непросто. Лифты работают в комплексе, и эффект от работы алгоритмов надо оценивать на целом лифтовом холле, а их у нас в бизнес-центре целых… один. Как вариант, можно сделать time‑based A/B (crossover) — переключаем всё здание между алгоритмами по дням или сменам, например: чётные/нечётные дни, утренние/вечерние смены. Или можно попробовать засетапить синтетический контроль — сконструировать его из комбинации данных других зданий или периодов, однако на практике такое сделать крайне непросто. При наличии похожих бизнес‑центров можно также попробовать сделать Difference‑in‑Difference.

Тут, конечно, придется позаботиться о логировании: фиксируем каждый вызов → поездку, промежуточные остановки, пустые рейсы, технические инциденты. Убеждаемся, что тест небесполезный: рассчитаем нужный объём выборки [кол‑во сотрудников × поездок на человека] и MDE.

На этом мой разгон закончился, так как лифт наконец-то довез меня до нужного этажа)

Как думаете, какой алгоритм был бы эффективнее? 🎯

P.S. Если вам зашла история про разбор аналитических кейсов в жизни — ставьте 🤓 и кидайте идеи задачек в чат. Разберём в следующий постах!

#ДимаКр

Как проверить 1 000 объектов в BI-системе и не сойти с ума (а главное — зачем?)

Всем привет, сегодня на связи Маша Аничкова, и я расскажу, как мы недавно провели BI-субботник. И нет, мы не выходили чистить свои дашборды в субботу с мётлами)

Для начала договоримся о терминах: под BI-объектами в этом посте я буду подразумевать дашборды и то, из чего они состоят — в нашем случае это квери и чартсы. А также датасеты — источники данных для дашборда — что-то вроде витрины данных внутри BI-системы.

⭐️ Итак, сначала мы определили понятие проблемных объектов. В эту категорию вошли: малоиспользуемые, с неактуальным владельцем, медленные, с большой долей ошибок, дублирующиеся с другими объектами, использующие временные таблицы вместо продовых витрин. Конкретные критерии и информацию по всем объектам мы вывели в отдельный отчёт — Health Score. В нём можно посмотреть проблемные объекты по себе или по своему отделу, а также он даёт оценку по каждому критерию и общую оценку здоровья объекта.

⭐️ Далее мы продумали формат проведения субботника. В нашем случае это был «марафон по уборке», в котором поучаствовали почти все BI-разработчики компании. Мы задали конкретные даты проведения, чтобы в этот период мониторить участие и активно помогать консультациями. При этом каждый участник мог выбрать удобный день для проверки своих объектов. Это дало гибкость, ведь обычную работу и «срочные задачи от бизнеса» тоже никто не отменял, к сожалению.

Также мы сделали эксель-файл со списком проблемных объектов с детализацией по критериям. Отмечали в нём конкретные call to actions и статусы для каждого объекта: «фикс выполнен», «объект удалён», «фикс запланирован».

⭐️ Как это прошло?
За 3 недели проверили почти 1 000 объектов с плохим Health Score. В течение всего этого времени мы:
👉архивировали неактуальные объекты;
👉переносили черновики из продовых папок в личные sandbox-ы;
👉обновляли владельцев;
👉удаляли дублирующиеся датасеты;
👉работали над скоростью объектов;
👉планировали дальнейшие оптимизации.

⭐️ А для чего это нужно?
👉Улучшение перформанса. Медленная работа дашбордов — одна из основных причин неудовлетворённости пользователей.

👉Улучшение навигации по объектам. Если в отчётах нужно копаться, чтобы найти актуальные — это как минимум неудобно. К тому же пользователи могут случайно заглядывать в неактуальные отчёты и принимать неверные решения на основе некорректных данных.

👉Освобождение ресурсов CPU. Неиспользуемые или неоптимальные объекты съедают лишний ресурс — это может создавать дополнительные очереди на обновление и ухудшать перформанс хороших объектов.

👉Погружение в работу с Health Score. Расчёт здоровья объектов у нас появился относительно недавно, и субботник — хороший способ всем вместе провести ревью объектов и познакомиться с этим процессом, чтобы в дальнейшем уже самостоятельно мониторить и периодически «подлечивать» свои объекты.

А вы следите за качеством своих BI-объектов?
❤️ — у меня BI-объекты здорового человека
🙈 — у меня BI-объекты курильщика
🐳 — у меня пока нет своих BI-объектов

#МашаАн

Авито сегодня празднует совершеннолетие, и Останкинская башня по этому поводу тоже нарядилась❤️
Фото авторов Коммуналки в студию!

А еще мы встретились с @analytess, она недавно присоединилась к Авито, поздравляем!🎉

Work hard, play hard!
Возможно, вы знаете, что фраза: «Work hard, play hard!» — один из слоганов Авито. После калибровок и конца полугодия только и разговоров что о море… Так что пора немного выдохнуть и провести время вместе, особенно если отпуск пока только в планах.

Хочу поделиться с вами топ-3 любимыми корпоративами 💚

📍 Летник 2023 — большой летний корпоратив Авито в дачном стиле в Строгино. Запомнился таким хайлайтом: на корпоратив пригласили пару, которая познакомилась на Авито — девушка продавала гирю, а нашла мужа. Для них даже устроили отдельный праздник в московском офисе, а на летнике они поделились своей историей.

🎄 Новогодники 2023 — у нас были и общий, и чисто аналитический корпоратив. Чууть больше запомнился аналитический: он прошёл в стиле эзотерики (моя тема 🔮). Можно было сделать расклад Таро, пофоткаться в фотозонах со свечами и загадочными артефактами, а баре предлагали коктейли с мистическим вайбом.

Ещё меня, например, нарядили в смирительную рубашку. Сказали: «Пусть побудет в комнате наедине со своими зелёными А/Б-тестами» 😅

А сегодня у нас будет корпоратив в стиле «18 мне уже» — в честь 18-летия Авито. Ждите кружочки!

А какие корпоративы вы любите больше?
😎 — Летние
🎄 — Зимние

#Новик