Каждый раз радуюсь когда в общеаналитических каналах Авито выходят посты от биайщиков= )
А если по теме - тут главное не переборщить с уточнениями, один раз я на заказчика выкатил бриф на 50 вопросов и он мне потом это на ревью припомнил😁

Сегодня встретил график настолько же гениальный, насколько пугающий

Нельзя просто так взять и рассортировать Лего. Профдеформация похоже)

Сегодня в МИРЭА читал небольшую лекцию об аналитике в целом, аналитике в Авито, и BI аналитике в частности. Очень отзывчивые и вовлеченные студенты были, две пары пролетели незаметно)
Чтобы не было так скучно и приторно, провел для них небольшой интерактив из двух частей - «Прожарка», где надо было критиковать и предлагать улучшения сомнительных визуализаций (спасибо за них каналу «Отвратительные графики» @awfulcharts ) и обзор нескольких видов графиков, где надо было поставить оценки по нескольким критериям типа понятности и применимости и придумать кейс к которому подходит тот или иной тип графиков (нетривиальность и остроумие приветствовалось)

Промежуточные выводы:
1) Абсолютно зря повально ругают зумеров
2) Когда на лекции появляется возможность поругать чужую работу - аудитория оживляется

Собственно слайд со второго интерактива на фото и вы в комментариях можете предложить свой вариант что можно изобразить с их помощью

Если московский ветер унёс вас в сторону кластера Ломоносова и вы тоже на Aha - пишите, встретимся поболтаем:)

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

Ревью близко!

Для многих компаний и команд с полугодовым циклом перф ревью этот мем становится актуален и добавляет стресса в текущей работе

Я впервые буду проходить/проводить ревью как руководитель, и определённый мандраж присутствует конечно. Получится ли откалибровать своих так как задумано, получится ли защититься самому 😅

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

Еще стрессовый момент- запрашивание отзыва о своей работе от коллег. Тут я могу поделиться маленьким лайфхаком - запрашивая отзыв, напишите человеку: объясните оценку каких качеств себя и своей работы вы бы хотели получить, какие проекты вы с ним сделали (помогите ему вспомнить и начать писать - не все набили руку на написании отзывов, и зачастую сами испытывают стресс). Так вы уменьшите вероятность получить неинформативный отзыв «Вася классный, все было супер»

Пожелаю вам терпения и выдержки для этого непростого периода, а также сознательности не использовать для всего этого LLM :)

Жизненная жиза от Aurélien Vautier

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

Приглашаю послушать и подискутировать)

PharmaDataMeeting №2

29 июня 2025, 15:00 (воскресенье)

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

1️⃣ Герингер Владимир - директор бизнес-аналитики, GLS pharmaceuticals: "Информационная система: архитектура решения"
Автор канала: PharmaDataLab

2️⃣ Снигирев Дмитрий - тимлид Core BI - Авито: "Как выглядит роль BI аналитика в требованиях разных компаний"
Автор канала: Делаю BI

3️⃣ Корнев Иван - аналитик данных: "Приблизительный подсчёт уникальных записей в SQL"
Автор канала: Откровенная аналитика

Приходите, будет интересно!

Ссылка для подключения: https://telemost.yandex.ru/j/65617501912823

🔥 - ставь, если придешь в эфир

В самом разгаре подготовка к ревью, поэтому у меня нет для вас ничего кроме странных мемов= )

Я сейчас провожу небольшое открытое исследование на тему "Как изменилась профессия BI аналитика/разработчика за последние годы"
Если у вас есть что сказать по этому поводу и поделиться своим мнением по трем открытым вопросам (Что было, что есть, что будет) то буду очень благодарен= )
https://forms.gle/xJNudQWXbfXAU4ge9

Чувство когда попал в пост к Роме Бунину @revealthedata
Да еще в такой приятной компании)

Биайщик: собрал требования, рассчитал данные, сделал красивый дэш
Заказчик:

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

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

История в трех актах (трагическая) как я в несколько подходов расчитывал неаддитивные метрики для дашборда

Предисловие/ликбез
Некоторые метрики являются неаддитивными - то есть сумма их разрезов не равна самой метрике. Например у нас есть DAU сайта (количество активных пользователей на сайте)
И есть на сайте несколько страниц - на каждой из которой свое количество активных пользователей. В итоге нельзя так просто взять и сложить DAU каждой страницы и получить DAU сайта, потому что один пользователь может посетить несколько страниц, и при этом быть единственным посетителем сайта

Акт 1 «Выглядит все просто»

В принципе расчёт несложный - считаем агрегат для сайта и делаем union all агрегат для каждой из страниц. Общему DAU присваиваем значение page= 'Any' и вуаля - мы посчитали эту метрику.
Но вообще, в SQL предусмотрен очень мощный «синтаксический сахар» для таких расчётов - функционал GROUP BY GROUPING SETS (<перечисление необходимых агрегаций>), написав
GROUP BY GROUPING SETS ((event_dt), (event_dt, page)) мы как раз получим такой union all двух группировок, в которых недостающие разрезы будут null
Есть еще два вида этих функций, которые тоже своего рода синтаксический сахар над grouping sets - ROLLUP и CUBE: один для ступенчатого перебора разрезов, а второй перебирает вообще все возможные варианты группировок.

Вроде пока звучит просто? Но уже тут можно словить подвох - если у вас есть измерение NULL до группировки, то после неё вы не сможете отличить вышестоящий уровень агрегации от отсутствия разреза (в некоторых СУБД можно уровень агрегации выводить, но далеко не во всех). Так что если вы используете этот метод - запаситесь колясками! (COALESCE в разговорной речи:)

В акте 2 расскажу что делать если оказалась что не все так просто

Акт 2 - «Похоже все не так просто»
Акт 1 - https://news.1rj.ru/str/withdata/134

Теперь допустим у нас не два измерения - дата и страница, а пять: дата, страница, тип пользователя, ОС с которого пользователь заходил, и его регион.
Так как мы уже на опыте и знаем про GROUP BY CUBE - хватаем его, запускаем, получаем свои 2^5 = 32 группировки и в принципе довольны. До тех пор пока не выясняется, что нам потребуется не только тип ОС пользователя, но ещё и версия приложения с которого он заходил. И не просто регион, а регион + город.
Запуская CUBE мы сходу ловим 128 группировок и идём грустить, потому что на больших объёмах данных (допустим десятки миллионов пользователей в день) такие расчёты вызывают лёгкое подергивание глаза. Что делать? Убирать лишние группировки. Два разреза у нас иерархические - регион+город и ОС + версия приложения. Получается нам нет смысла считать разрез вида «сколько людей из Сочи и Чукотки заходили на сайт». В итоге мы сидим, пишем разрезы которые нам нужны в огромном grouping sets и довольные запускаем скрипт. Экономия - космическая, у меня вместо 128 возможных разрезов получилось что требуется всего 18.

В чем проблема?
Их не 18.
При ревью отчёта уже на проде я обнаружил что в некоторых комбинациях фильтров у меня отсутствуют данные, хотя вроде должны быть. Пришлось идти думать (и напоминать себе что думать и полностью!!! тестировать надо до выкатки в прод)
Посидел, порисовал как формируются разрезы, и понял разрезов должно быть
1*2*2*(2+1) *(2+1)
Это все ещё лучше чем куб, когда
2*2*2*2*2*2*2.
Какие и как схлопываются разрезы?
Дата - нас не интересует метрика за весь период, поэтому 1 а не 2
Регион + город, нам не нужны все регионы для каждого города, а только родительский регион - значит вместо 2*2 получаем 2+1
И с ОС + версия аналогично.
В итоге получается 36 разрезов, что конечно лучше чем 128, но все равно сложнее и дольше чем 1 для стандартной метрики:)

В третьем акте будут подниматься экзистенциальные вопросы «зачем все это?» «как не страдать в таких ситуациях?» «почему я не пошёл в сварщики?»

Акт 3 "Зачем вообще все это?"

Акт 2 https://news.1rj.ru/str/withdata/135
Акт 1 https://news.1rj.ru/str/withdata/134

На фото - useless box, который выключает тумблер сразу после того как ты его включишь

Иногда такие упражнения приходится делать и для вполне себе аддитивных метрик (на самом деле в исходной задаче у меня была именно она, и где то на стадии «Акт 0» я написал group by 1,2,3,4,5,6,7 и успокоился). Но потом мне понадобилось добавить на дашборд ещё несколько метрик, включая ratio метрику, у которой в числителе была как раз неаддитивная метрика в готовом виде, которую посчитал другой человек. А потом еще на горизонте выплыли несколько финансовых метрик, которые надо было подружить с этим цирком, и у них разрезы совпадали только частично с исходной метрикой. В итоге волевым решением я решил усложнить жизнь всем кто будет разбираться в этом в будущем (коллеги подтвердят что я так частенько делаю) - но упростил добавление новых расчитанных метрик.
Оказалось что подобный метод расчёта хорошо подходит для стыковки между собой метрик разных типов.

Вообще у нас в Авито есть удобный инструмент под названием 3sigma (точнее нас интересует его компонент M42 для визуализации метрик) - куда можно положить скрипт метрики, задать конфиг и измерения, которые требуется рассчитать неаддитивно - и все, скрипты крутятся, разрезы мутятся.
Почему не воспользовался им? На то были объективные причины, но если бы я сразу корректно оценил трудоёмкость - пошёл бы договариваться с заказчиком о сокращении функционала в пользу более быстрой разработки и более простой поддержки (не факт что они бы согласились конечно)

Но на будущее я бы посоветовал себе и вам следующее: нафиг эту аналитику, айда в сварщики если есть хоть небольшой шанс, что вам такое упражнение придётся делать более одного раза - пишите сразу python генератор SQL скрипта, либо пользуйтесь готовым инструментов (если у вас есть свой аналог М42) иначе путаница повергнет вас в хаос, а хаос в витринах приведет на темную сторону силы...

Заключение (филосовское)

Решение может быть простым или сложным, быстрым или внедряемым через боль и N итераций. Но в любом случае полезно задавать себе вопрос - вы все еще решаете потребность пользователя или делаете сложность ради сложности?

Всем привет= )

upd: прием резюме завершен, пост оставляю для истории

У нас в Core BI Авито открылась новая ставка и мы ищем крутого спеца senior - lead уровня, который и швец и жнец и всем пиз и в датавиз и в инженерию и в построение BI процессов.
Цель амбициозная - строить вместе с нами крутую BI функцию во всем Авито с достаточно низкого старта.
Непосредственно тимлидом буду я, команда работает в прямом подчинении head of bi (@alexbarakov)
Задачи на любой вкус:
1) Можно заниматься построением высокоуровнего репортинга для всего Авито или C-level пользователей
2) Можно писать много SQL и выстраивать архитектуру витрин
3) Можно лидировать проекты развития всей фукнции BI (как пример: продумать и внедрить процессы сертификации отчетности, разработать концепцию и внедрить аналитические рабочие места для разных ролей не-аналитиков, разработать стандары репортинга BI)
Пропорции этих типов задач будут примерно 30/20/50

Автономность - высокая, свобода выбора интересных проектов - еще выше. Комьюнити BI ламповое и вовлеченное.

Опыт работы в кор командах BI или выстраивании BI процессов - весомый плюс. Опыт участия в таких проектах - желателен и почти обязателен

За подробностями - велкам в лс @astigo

Пятница? Пятничный мем!

Чтобы не собесить LLM надо собесить LLM

или что за тг канал без поста про AI

Думаю для всех тех, кто проводит собеседования по hard-скиллам актуален вопрос - что делать со списыванием из LLM любой вариации?
Конечно нельзя сбрасывать со счетов вопрос более верхнеуровневый - а надо ли что-то делать?
На него общепринятого ответа нет, но я вижу риски такого найма - кандидат который не может думать и решать без LLM качественно - будет хуже кандидата который способен это делать. Потому что когда эти два абстрактных кандидата воплотятся на работе и возьмут в руки LLM - мы получим из одного связку "Senior + junior AI" а из другого "Junior + intern AI". Ну либо Senior без AI если наняли луддита)

Так что в своем размышлении над решением этой задачи я принял следующее допущение - мы хотим на техсекциях собесов, особенно на проверке хардов, исключить влияние LLM на оценку кандидата

Вижу тут два основных направления:

1) Сделать так, чтобы LLM нельзя/сложнее было воспользоваться. Так сказать "ЕГЭобразный" подхож- ужесточаем контроль, закрываем кандидата в комнате с белыми стенами, даем ему карандаш и бумажку, запрещаем моргать чтобы не подал сигналы в космос
Понятно что я довел этот пример до абсурда, но сильными ужесточениями мы срежем себе воронку из приличных кандидатов, которые не захотят участвовать в этом перформансе. Ну и кто захочет - тот спишет, проверено в универе еще до всяких чатгптей)

2) Сделать так, чтобы LLM было пользоваться бессмысленно.
Нужен такой подход к собеседованию, когда использование LLM ухудшает результат собеседования.
Например: LLM-устойчивые задачи, специфичный бизнес контекст, хорошо воспринимаемый человеком но плохо распознаваемый и учитываемый моделью.
Таким образом, мы вынесем на первый план оценивания не написание кода, а более высокие уровни решения задач - аналитические выводы по коду, умение применить контекст, оценить сложность задачи, внести правки и корректно собрать требования (и какое совпадение - этого мы и ждем от кандидата, а вовсе не знания синтаксиса)

Остался основной вопрос - а как же построить такое "идеальное" собеседование - чтобы при адекватной трудоемкости проведения техсекций минимизировать ошибку определения подходящего кандидата?

Тут пока готового ответа у меня нет) А по поводу тезиса из заголовка - чтобы отладить такой подход я буквально собеседую ChatGPT на должность BI разработчика - чтобы понять с чем у него есть сложности и как это можно применить)