Анатолий Карпов не перестает радовать нас интересным контентом. Вчера прошел вебинар на тему использования нейросетей в аналитике.
Он является продолжением недавнего вебинара про решающие деревья (с небольшим самоцитированием со Степика).

В рекомендациях Youtube сегодня увидел свежее видео канала Retentioneering про сравнение работы Sankey diagram и нового для метода визуализации MatrixWave. Видимо, это был обзор вот этой статьи.
Метод интересный, но пока неочевидна польза. Кажется, что те же Sankey, а также графы, степ-матрицы вполне закрывают эту задачу. Возможно, стоит попробовать поработать с MatrixWave и тогда профит будет очевиднее.

На конференции про менеджмент продуктов ProductSense’23, которая в этом году пройдет 4–5 сентября, будет отдельный день воркшопов. И среди них есть один, который кажется мне особенно интересным.

На нём Елена Серёгина, автор фреймворка «Пирамида продуктовых метрик», аналитик и основатель бюро Datalatte, расскажет про мета-аналитику как метод создания метрик, которые помогают бизнесу смотреть в самую суть проблем, не перегружая процессы ненужными конкретно этому бизнесу фреймворками. На мастер-классе будут аналитические и продуктовые кейсы, пирамида метрик для продукта и портфеля продуктов, метрики ценности, фреймворк для KPI и OKR.

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

Примерно завтра GA-Universal Analytics закончится. Как модно говорить, уходит эпоха. Очень жаль. При всех претензиях, он был очень хорош. С GA4 так и не подружился, считаю его отвратительным - концепция отличная, интерфейсная реализация - хрень полная. Имхо. Рад, что не приходится с ним сейчас работать.
Впрочем, для тех, кто использует в работе исключительно сырые данные, ничего не изменится. И это отличная новость!
Хотел бы скриншот сделать завтра на 00:00:00:00, но не получится, буду где-то далеко от ноутбука.

Неожиданно наткнулся на картину, в которой художник пытался выразить суть нашей профессии.
Павел Филонов - Ударники (Мастера аналитического искусства).
https://muzei-mira.com/kartini_russkih_hudojnikov/3194-udarniki.html

Тут рассказывают, как работает performance review в Авито — подробный гайд составил их директор по аналитике Илья Гуров. Для больших команд аналитиков, где спецов выше мидла может быть несколько, это просто золото. Грамотная система ревью позволяет руководителю понятно описать грейды и получить адекватное представление о росте сотрудников, компетенциях и карьерных ожиданиях.

Если коротко, то у Авито все устроено так:

1. Self-review. Сотрудник предъявляет собственные результаты.

2. Сбор отзывов от коллег, которые участвовали в тех же проектах или заинтересованы в результатах.

3. Оценка компетенций. Руководитель собирает артефакты и доказательства по всем компетенциям.

4. Калибровка оценок между руководителями. Это защита оценки перед другими менеджерами с презентацией и фасилитатором. Душно, но эффективно.

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

Проводите у себя ревью? Поделитесь лайфхаками в комментах!

Продолжаю смотреть Аха23. 🎞🎞🎞

Очередной отличный доклад - про построение мониторинга событий для аналитики в Сбермегамаркете. Юля Зиновьева рассказывает механику и последовательность построения. Если эта проблема актуальна, рекомендую к просмотру. Ссылка.
Хорошо известно, что корректность отправки событий - один из краеугольных камней работы аналитики.

В целом, алгоритм расчета аномалий такой:
1. На основании исторических данных делается прогноз количества событий с некоторыми.
2. Факт сравнивается с прогнозом с учетом доверительного интервала.
3. Если разница выходит за пределы доверительного интервала, получается аномалия.
4. В месседжеры отправляется алерт. И на дашборды также выводится вся необходимая информация.

Все вроде бы не очень трудно реализовать. И профит очевиден.
На реализацию работающего продукта ушло 10 дней.

Неожиданно Мику Джаггеру сегодня исполнилось 80. Трудно поверить! И все же.
Отличный повод включить любимую песню Rolling Stones -https://www.youtube.com/watch?v=nVrdXUHvsF0

Коллега Юрий поднял очень полезный вопрос - формат постановки задач для аналитика. Можно почитать здесь.

А можно спуститься этажом ниже и обсудить, как еще могут ставиться задачи для аналитика.

Бывает, что продуктовые команды не очень сильно развиты, и продатк-менеджер может прийти с проблемой, которую сам не очень хорошо понимает. Например, он может сказать, что метрика MAU какой-нибудь фичи неправильно считается и нужно это проверить. А после выяснится, что ему нужен не MAU (который просто количество активных юзеров в месяц), а какой-нибудь показатель повышенной активности, например, количество юзеров в месяц, которые пользовались нашей фичей не менее 2 дней в неделю или не менее 8 дней в месяц. Только это уже не MAU, а какая-то другая метрика. И вот вы полчаса все вместе пытаетесь это втолковать. Вроде активность создал, а толку 0.

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

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

Так что же, джира (и аналоги) с нормальным описанием целей, ожидаемых результатов, сопутствующих обстоятельств - для слабых? Как разметка на дорогах в центре одного из городов Золотого кольца.

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

Продолжаем повествование про работу над задачами.
Коротко о том, как нужно брать в работу задачи. Взять задачу в работу (или не взять), обозначить сроки - это как отражение того, как ее описывает заказчик. Итак, как понять, что описанную задачу можно начать выполнять:
1. Понятен бизнес-смысл задачи, понятно, кем и как будут использованы результаты задачи - т.е. нам понятно, зачем и кому все это нужно.
2. Описан формат ожидаемого конечного результата - что мы должны отдать в качестве результата:
- короткий ответ "Да" или "Нет"
- эксель с некоторыми данными
- обновляемый дашборд
- описание причин проблемы и способы ее решения, и др.
Не всегда сразу понятен конечный формат, в таком случае нужно обсуждать, какие могут быть варианты.
3. Приоритет задачи. Он должен быть обоснован, а не просто "нужно еще вчера".
4. Ожидаемый срок выполнения задачи. Тут тоже ждем обоснования. Приоритет и срок нужны, чтобы правильно спланировать выполнение задачи.

Далее опционально:
5. Источники данных.
6. Дополнительные материалы - таблицы, статьи в confluence, связанные задачи в jira
7. Информация об ограничениях и прочих нюансах, которые нужно учитывать в работе над задачей.

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

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

И запись вчерашней конференции подъехала - https://www.youtube.com/watch?v=0Myg_-w_aPE

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

Коллега в одном из рабочих чатов поделился ссылкой на периодическую таблицу методов визуализации - https://www.visual-literacy.org/periodic_table/periodic_table.html

Наконец-то! Танцор теперь спасён!!!

🔥 Базовая Шпаргалка по Pandas 🔥

Pandas - один из самых основных и важных инструментов для работы с данными в Python. Он предоставляет множество удобных функций для загрузки, обработки, и анализа данных.

Мы собрали шпаргалку, в которой все основные функции, которые пригодятся вам в повседневной работе с Pandas:

✅ Импорт данных: Загрузка данных из разных источников.

✅ Исследование данных: Ознакомление с данными, просмотр первых и последних строк, получение информации о типах данных.

✅ Извлечение информации из датафреймов: Выбор столбцов и строк, выполнение различных операций.

✅ Добавление и удаление данных: Добавление новых столбцов и строк, удаление лишних данных.

✅ Фильтрация: Выбор данных по условию, множественные условия.

✅ Сортировка: Сортировка данных по столбцам, множественная сортировка.

✅ Агрегирование: Группировка данных, вычисление статистических показателей, подсчет уникальных значений.

И для удобства мы сделали для вас notebook 😊

Сохраняйте и пользуйтесь 👇

https://colab.research.google.com/drive/1XOF8oQB3kzs0Yxt17XdtGy8IFNudvp4c?usp=sharing

Если у вас есть какие-либо дополнения, не стесняйтесь оставлять в комментариях! 🐼

#python #pandas

Тут Яндекс сообщил, что сделал опенсорсным DataLens. По мне, так отлично - чем больше опенсорсных инструментов доступно, тем лучше. Не вечно же с Метабейзом возиться.

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

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

Бывает, к нам приходит заказчик, говорит, что нужно сделать так и эдак, ты спрашиваешь "а тебе это правда нужно?", он отвечает "ну конечно, вот затем и затем".

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

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

Кабы это произошло один или два раза, темы могло не быть. Но нет - существенно больше.

Если найдутся желающие швырнуть тапком или помидоркой (предпочитаю помидорки мягкие и сладкие, как у тещи, имейте ввиду), буду рад обсудить вопрос.

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