Записался недавно в подкасте «Багрепорт»

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

Почему аналитиков делят на две касты: «требований» и «данных»? Всем ли так нужен SQL? Кстати, да. Excel — лучший друг аналитиков.

Где послушать:
В телеге
В Яндекс.Музыке
В Apple Podcasts
В VK
На сайте студии Red Barn
В PodParadise
В Castbox
В podcast.ru

Ну и в ту же тему - https://www.youtube.com/watch?v=5sZy7b_yGYY

И по поиску работы - Яндекс Маркет проводит Fast Track - требуются ML-аналитики (что бы это не значило).
Все этапы пройдут в течение нескольких дней. Первый этап, контест, будет доступен до завтрашнего дня, так что можно уже и поторопиться.
https://yandex.ru/promo/rec-comms/events/ft-ml2?utm_source=home

И еще найм по ускоренной программе - в Сбер. Ищут ML-разработчиков. Все произойдет в течение одного дня - 11 декабря.
https://developers.sber.ru/portal/onedayoffer-december/ml

А тут у нас прогнозирование результатов ЧМ по футболу с помощью Python. Пока турнир не кончился, есть шанс заработать миллионы на ставках.
https://medium.com/towards-data-science/predicting-the-fifa-world-cup-2022-with-a-simple-model-using-python-6b34bdd4f2a5

Импортзамещению дорогу! Подробный рассказ о том, как СберМегаМаркет перезжал с Tableau на Visiology - как выбирали, какие боли были при переходе, сильные и слабые стороны. Ссылка...

Всем привет! Вдруг обнаружил, что у Яндекса появился Курс «Продуктовая аналитика: симулятор». Заинтересовался, сходил на лендинг, почитал и огорчился.
Вижу, что тут нас будут учить все тому же - навыкам: снова SQL, AB тесты, Python, BI. Все это будет заточено под решение конкретных прикладных задач.

А чего не увидел:
- как научиться принимать решения
- как понять специфику работы конкретного продукта
- как живут продукты разных типов
- какие проблемы нужно решать в том или ином продукте
- как работают деньги
- как понимать, в каком случае какие метрики использовать, какие методы решения применять
- как помогать продакт-менеджеру решать проблемы продукта
- как принимать задачу в работу (или почему ее не нужно выполнять) и как отчитываться о результатах

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

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

Продолжаем тему образования. Набрел В блоге МВидео-Эльдорадо на статью про проблемы джунов в IT. Тут не конкретно про аналитиков, но ситуация примерно та же - https://habr.com/ru/company/mvideo/blog/688590/
И ролик про текущие требования к джунам - https://www.youtube.com/watch?v=l23LHX4G5iM
#образование

Иногда бывает нужно сохранять данные, передаваемые в dataLayer, при переходе по страницам.
Например, можно буквально на коленке построить скоринг пользователей при действиях на сайте, оценивать степень готовности пользователя к покупке. Чтобы, ессесна, потом догнать его ретаргетингом и склонить к покупке.
И вот нам в помощь статья Симо Ахавы: https://www.simoahava.com/analytics/persist-datalayer-across-pages/

Уже завтра, 20 декабря, пройдет вебинар Путь дата-аналитика.
Проведет его Алексе Колоколов, человек, который знает, что такое дата-аналитика, в отличие от тех, кто обещает по 300к/сек через полгода
Страничка - https://alexkolokolov.com/ru/data-analyst-webinar

Пересматриваю ММ 2019, неожиданно начал больше понимать, о чем там рассказывают спикеры. Интересное выступление про предиктивную аналитику в BigQuery - https://www.youtube.com/watch?v=HAPbkT9eRWA.
Допускаю, что не все так легко и быстро, как нам рассказали - придется пройти большой путь разметки, сборки первичных данных и т.д. Но результат может ждать очень интересный.
Жаль, что BigQuery сейчас стала менее доступна, чем ранее. Но, полагаю, все то же самое можно воспроизвести и другими, вполне доступнми инструментами.

21 декабря прошла четвертая встреча Salute AI Day. Все доклады есть в записи

- Выявление дефектов кода с помощью языковых моделей
- HaGRID - сбор самого большого датасета для распознавания жестов
- Обучить за 60 минут или как построить классификатор текста который и работает хорошо и обучается быстро
- Современные техники улучшения retrieval based моделей в NLP
- Нужно прокачать NER модель, но как
- Мультимодальные вопросно-ответные системы в задаче извлечения информации из документов - DocVQA  

И еще немного от Сбера. Анонсируют новые устройства, пока не говорят, какие. Видимо, уже в следующем году. И насколько умное, тоже посмотрим.
https://sberdevices.ru/soon/

Ресерчеры и аналитики из Мордакниги установили, что меньшее количество нотификаций в долгосрочке обеспечивает лучшую возвращаемость в продукт. Хотя поначалу продуктовые метрики и просели.

И выводят два тезиса:
* Результаты эксперимента в короткосроке и долгосроке могут сильно отличаться
* Меньше нотификаций, но более качественных полезнее в долгосрочной перспективе.

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

Чтобы этот эксперимент провести и защитить использовали данные из опросов и фактического поведения аудитории.

Еще один хороший пример как смешивание разных типов данных и методов помогают в сложных бизнес-ситуациях.

https://medium.com/@AnalyticsAtMeta/notifications-why-less-is-more-how-facebook-has-been-increasing-both-user-satisfaction-and-app-9463f7325e7d

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

Отличная статья про использование цепей Маркова в футбольной аналитике https://www.sports.ru/tribuna/blogs/footsci/2890716.html

Онлайн-курс по машинному обучению.
Ссылка:
https://berza.ru/ii-start-kurs-po-mashinnomu-obucheniyu/

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

И немного ссылок по теме. Неожиданно, но не все из них на материалы Елены Серегиной (последние две ссылки):
- https://www.youtube.com/watch?v=7wTO1GonUj4 - видео Пирамида метрик в 4х словах
- https://medium.com/@elenest/%D0%B8%D0%B5%D1%80%D0%B0%D1%80%D1%85%D0%B8%D1%8F-%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA-vs-%D0%BF%D0%B8%D1%80%D0%B0%D0%BC%D0%B8%D0%B4%D0%B0-%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA-8eeda61fdefe - статья Иерархия метрик VS Пирамида метрик
- https://www.youtube.com/watch?v=d5lV2KXVPfU - видео Фреймворк Пирамида метрик: чем он может вам помочь, даже если метрики не ваш конек
- https://www.youtube.com/watch?v=qIJECUgtfks - видео Еще одна Пирамида метрик - как навести порядок в числах и бэклоге. Analytics Day
- https://medium.com/@elenest/metrics-frameworks-d7c800f91246 - статья Если Пирамида метрик too much. Делаем проще
- https://medium.com/@elenest/%D0%BF%D0%B8%D1%80%D0%B0%D0%BC%D0%B8%D0%B4%D0%B0-%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA-2e18c657b305 - статья Пирамида метрик
- https://www.youtube.com/watch?v=rhOS-K5p8F0 - видео Пирамида метрик: как построить и найти NSM вашего продукта
- https://www.youtube.com/watch?v=v3HpOGsiVPY - видео Пирамида метрик прибыльного менеджмента. Первый уровень анализа
- https://deniskatkov.ru/piramida-metrik-podhod-s-pomoshhyu-kotorogo-vybirayut-pravilnye-metriki-i-opredelyayut-zavisimosti-mezhdu-nimi/ - статья Пирамида метрик – подход, с помощью которого выбирают правильные метрики и определяют зависимости между ними

Команда отдела аналитики VK задумалась над системным решением проблемы рассеивания внимания при контроле за показателями метрик и… придумала оптимальное решение.

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

О том, как они пришли к этому подходу, что имеют сейчас, а также о настройке интерфейса, почтовых оповещений, эффективности и общих итогах читайте тут.

Идем к продуктовым метрикам. Итак, какой у вас LTV?
Очень простой вопрос, на который трудно дать простой ответ.

Знание LTV часто встречается в требованиях к менеджерам продукта, к продуктовым аналитикам. Но вот знать и уметь, все же, не одно и то же.
Если мы быстренько погуглим, то найдем следующую формулу расчета: ARPU * LT, где:
- ARPU (Average Revenue Per Users) — средняя сумма дохода на одного пользователя за определенный период (неделя, месяц, квартал).
- LT (Live Time) — время “жизни” клиента.
Можно найти и другие методы, и большинство из них крутятся вокруг этих величин.

Тут и кроется проблема. Есть клиенты, которые платят уже 5 лет, а есть те, кто только что сделал первый платеж. Но, вот, пять лет назад у нас были другие тарифы, другие скидки и спецпредложения. Ну и старые пользователи с нами 60 месяцев, а новые меньше одного. И как же нам посчитать, сколько у нас платит клиент в среднем за один период (в нашем случае месяц) и сколько месяцев он живет. Получаем, что:
- Всегда будем рассчитывать “среднюю температуру по больнице” — в одну кучу сгребем всех пользователей и усредним. Странно, ведь обычно твердим, что хорошо, когда пользователи сегментированы, гомогенны.
- Посчитанная величина будет “на сейчас”, а через месяц она может быть больше или меньше.
- На изменение LTV во времени будут влиять промокампании, реактивации, раздача триалов, скидки, черные пятницы, рост стоимости подписки и прочие факторы. Поэтому наши LTV 3000 р. сейчас будет значить немного не то, что раньше. Т.е. LTV не может быть высечен в граните.

Итого — формула ARPU * LT более-менее работает на “мертвом” продукте, у которого уже нет ни новых пользователей, ни новых денег. Тут понятен и ARPU, и LT, все легко посчитать без ошибок. А если продукт живой, развивающийся, то будут проблемы...

Как же можно считать LTV, чтобы с ним можно было нормально работать. Считать LTV по когортам первой оплаты — по неделям, месяцам, кварталам — как посчитаем нужным. По формуле — Revenue/U (всю сумму дохода пользователей когорты делим на количество пользователей когорты, тут не привязываемся к чистой или не чистой прибыли).
Таким образом нивелируем проблему “старости” наших клиентов — LTV старых клиентов будет рассчитан отдельно от новых - у каждой когорты будет свой LTV.

Что еще можно посчитать на основе LTV:
- Средний LTV накопительно (берем весь доход на данный месяц и делим его на количество всех пользователей), пересчитываем на каждый месяц, смотрим с в динамике.
- Средний скользящий LTV - делаем то же самое, но каждый раз за несколько последних периодов, например, 6 месяцев, и также смотрим в динамике.

Статьи про приоритезацию задач в работе аналитика (на несколько минут забудем про продактов и прочих заказчиков и подумаем - а как правильно-то):
Часть 1
Часть 2