Продолжаю смотреть Аха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 очень нужных и полезных графиков. И вот, как-то ты замечаешь, что пара графиков сломано. Первая мысль - надо чинить. Но опыт ведь не пропьешь (в отличие от глобуса) - оставляешь как есть. И фиксируешь дату обнаружения.

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

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

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

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

Существует немало фреймворков приоритизации гипотез. Поговорю про RICE, ICE. Не буду подробно разбирать механику, плюсы и минусы, а придерусь к параметру C - Confidence (уверенность), как, по моему мнению, самому слабому месту.

Как-то посмотрел на последние фичи, появившиеся в продукте, и заинтересовался, а почему именно эти, а не другие, так как показалось, что они какие-то сомнительные. Поговорил с продакт-менеджером и узнал, что используется RICE, он также показал оценки за последние несколько месяцев. Меня впечатлило, что по всем из них Confidence 75%-100%. Вопрос, почему так много, остался без внятного ответа.

При этом вижу, что фичи по этим гипотезам не то, чтобы сильно зашли пользователям. Т.е. фичи, уверенность в которых была 100%, легко могли провалиться. И, например, из 10 гипотез могло быть успешными только 3. Получается конверсия в 30%.

Собственно, к чему я это. Вполне можно в качестве Confidence использовать не наши влажные фантазии (75%-100%). А реальные результаты за последние 3 или 6 месяцев, те же 30%, которые будут своеобразной оценкой качества гипотез. Это может добавить осознанности оценки гипотезы. О она станет более объективной.

Уровень душноты аналитика просто зашкаливает. Сразу понятно, что это минимум сеньор.

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

С алгоритмами в духе LeetCode на собеседованиях пора кончать / Хабр
https://habr.com/ru/companies/productivity_inside/articles/777566/

Не упущу возможности признаться в любви к алгоритмам

Леша Никушин в аналитическом чате прислал ссылку на исследование, посвященное ожиданиям сотрудника от компании. Можно обсуждать репрезентативность, методику, корректность ответов, но, в любом случае, это очень интересная информация в разрезе HR-бренда.
Собственно, исследование.

Кликнул на кликбейтный заголовок и прочитал полностью статью про плюсы и минусы удаленки. Хоть тема уже не нова, но, тем не менее, актуальна. Описанное универсально для большинства айтишных профессий. И в комментариях вполне себе дискуссия.
Меня умиляет коврик для мыши (понятно, что определяет покрытие стола, но все же).