Я твой продукт анализировал

📌 R или Python (2/2)

Аргументы в пользу Python:

🔵ML и DL: Из-за TensorFlow, PyTorch и scikit-learn, Python считается стандартом для машинного и глубокого обучения. Мощно, быстро, качественно.

🔵NLP: Библиотеки NLTK, spaCy и transformers для обработки естественного языка намного мощнее аналогов R. Топ инструмент для чат-ботов, переводчиков или анализа текстов.

🔵Веб-разработка: Python поддерживает Django и Flask, поэтому задачи, которые требуют на выходе интерфейсов для взаимодействия с пользователями тут создавать тупо удобнее. В R это пытается делать Shiny, но он пока далёк от такого.

🔵Автоматизация: Тут R даже не пытается конкурировать, под задачи автоматизации там ничего сносного не завезли. Нет, он, конечно умеет в скриптинг, даже Airflow его поддерживает. Но шансы увидеть на проде скрипты автоматизации через R примерно такие же, как найти горшочек лепрекона.

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

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

Для исследований, стат. анализа, визуализации и публикаций материалов я бы смотрел в сторону R. И так уж совпало, что это стандартный набор задач продуктовой аналитики.

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

📌 R или Python (1/2)

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

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

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

Аргументы в пользу R:

🔵Пакеты для стат. анализа: R изначально разрабатывался статистиками для статистиков, поэтому тут огромный набор пакетов, специально для стат. анализа. Да, в Python они тоже есть, но многие перекочевали из R почти без изменений, тот же statsmodels это сборка базовых функций R, pandas вдохновлён dplyr, а seaborn старается перенести питонистам декларативный подход из ggplot2. Так как R больше популярен в научной среде, новые методы и техники сначала появляются здесь.

🔵Визуализация: ggplot2 считается одним из лучших пакетов для создания сложных графиков. Он вышел в 2005 и активно развивается. Сейчас он способен создать почти любую визуализацию, ограничен только фантазией автора.

🔵Анализ временных рядов: Пакеты forecast и tseries пока, вроде как, являются наиболее полноценными инструментами для этой задачи. Они часто используются в эконометрике и фин. моделировании.

🔵CRAN: (Сеть архивов комплексных пакетов) крайне удобная штука, которая позволяет быстро найти пакет под любую аналитическую задачу или стат. метод. Обеспечивает высокую гибкость и модульность в развитии языка. Во всех статьях это один из главных аргументов в пользу R. Я с этим полностью согласен 🙂

🔵Интеграция с документами: Через R Markdown и Shiny можно интегрировать анализ данных куда угодно, никаких файлов ноутбуков — прямой импорт хоть в док, хоть в интерактивный апп.

Приветики, теперь о действительно важных вещах! У меня тут произошло незапланированное обновление винды, пока устанавливаю всякий софт, захотелось обновить и оформление R Studio. Выбрал 3 фаворита, никак не определюсь 😅

1-й Дефолтный Tommorow Night 80s (пусть будет 🤷‍♀️)

2-й Дефолтный Material (🤷‍♂️)

3-й Кастомный Dracula, нагло спёртый с тёмной темы PyCharm (🤷)

📌 Несмещённая дисперсия, степени свободы и почему же n-1 (2/2)

В контексте расчёта дисперсии у нас похожая история, но вместо итоговой суммы в 100р, все наши переменные взаимосвязаны через среднее значение выборки. Т.е. зная среднее и все значения, кроме последнего, мы можем его легко посчитать.

Когда мы используем n-1, мы никак не увеличиваем или не уменьшаем количество независимых наблюдений, но мы начинаем корректно учитывать тот факт, что последнее всегда зависимо. Таким образом мы расширяем степень вариативности, и закладываем идею о том, что мы точно не знаем какой разброс в ГС, т.е. математически признаём этот факт.

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

Использование n-1 в расчёте дисперсии является частным проявлением этого принципа.

P.S. Если прям совсем грубо, то у нас есть требование к анализу, что там всё должно быть независимо. А тут блин, последнее число зависит от остальных. Надо его выпилить и всё будет ок 🙂 но фактически мы не знаем что есть последнее, зависит от того, с какой стороны считать, поэтому как будто в формуле задаём это автоматическое выпиливание. Но эт если совсем условно 🙂

#собесы

📌 Несмещённая дисперсия, степени свободы и почему же n-1 (1/2)

Уже второй день в чатиках мелькает вопрос “почему при оценке несмещённой дисперсии мы делим на n-1”.

Тема не самая простая и наглядная, но давай попробуем разобраться.

Для начала о дисперсии.

Дисперсия — это мера оценки степени разброса или вариативности данных относительно среднего значения. Чтобы посчитать дисперсию в ГС, нужно:

🔵Вычислить среднее значение;

🔵 Вычислить разницу между каждым наблюдением и средним значением;

🔵Отклонение может быть в большую или меньшую сторону, поэтому каждое значение возводим в квадрат, чтобы избавиться от знаков;

🔵Сложить все получившиеся квадраты отклонений;

🔵Поделить их сумму на n (количество наблюдений).

Но если мы имеем дело с выборкой, а не с ГС, то делить нужно на n-1. А почему так?

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

Допустим, мы с друзьями решили скинуться на подарок. Нам нужна сумма в 100р., нас четверо. Первый принёс 30, второй 20, третий 25. Зная это и целевую сумму, последний должен принести ровно 25. Это не он так решил, а у него просто уже не осталось свободы выбора, т.к. он ограничен итоговой суммой.

В этом примере в начале у каждого из трёх первых друзей есть “свобода” принести любую сумму. Они могут решить, сколько именно денег внести, не зная, сколько внесут другие. Т.е. для первых трёх друзей есть три степени свободы, потому что каждый из них может внести разную сумму независимо от остальных.

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

Т.е. если подытожить, в нашей выборке только 3 независимых наблюдения, а последнее всегда зависит от остальных и итоговой цели.

В твиттере на очередной круг вышла дискуссия о том, чем бы занимались айтишники, если бы за любую работу платили одинаково и выбирать можно то, к чему душа лежит. Я не могу выбрать между выращиванием оливок / крафтом масла или всё таки производством виски 🙂 и там и там тишина, покой, природа)

Кто куда после айтишечки двинет?

📌 Обнаружение аномалий

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

Есть много способов, как сделать графики более красноречивыми, один из них, пожалуй самый простой и распространённый — это обнаружение аномалий через плавающие доверительные интервалы. Разбираем на примере конверсий.

Кстати, про поиск аномалий иногда спрашивают на собесах, такой способ обычно ценят 🙂

Суть в следующем:

1️⃣ Мы выбираем окно, по которому будем “скользить” и на основе этого окна строим интервалы. Как базу можно взять неделю.

2️⃣ Исходя из предположения о нормальности, считаем скользящее среднее и отклонения, а на их основе задаём границы ДИ.

3️⃣ Накладываем интервалы на исходный график. Точки графика, выходящие за пределы ДИ уже сигнализируют о необычном поведении метрики. Да, не всегда там точно есть причина, но уже сильно понятнее когда пора напрячься, а когда всё ок 🙂

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

Реализация не влезает в пост, поэтому вынес в Gist. Код на R, но общий смысл там понятен, переписать на Python труда не составит 🙂

Зацените в какую красоту на выходных гоняли. Арбалетчиков расставить и готовый оборон пункт 🙂

Перебирал тут диск, нашёл старые консоли. Вот, например, прикольный. Это запрос в кликхаус из алертов Redash, который обновлялся каждый час и отправлялся в Slack, тегая ответственного, если срабатывало условие, когда байер тратил больше дневного капа.

Какие только костыли не выдумывали 😀

select if(length(slack_string) > 0, slack_string, 'OK') as slack_string
from (select arrayStringConcat(
                     arrayMap(x - > toString(x),
                              groupArray(if(to_alert = 'y', '<@user>\n', '') ||
                                         'Campaign: ' || campaignName || '\n' ||
                                         'Current cost: $' || toString(daily_cost) || '\n' ||
                                         'Daily cap: $' || toString(daily_cap)
                                  )),
                     '\n\n') as slack_string
      from (select campaignName,
                   round(sum(daily_cost), 2) as daily_cost,
                   round(daily_cap, 2)       as daily_cap,
                   case
                       when daily_cost >= toFloat64(daily_cap)
                           then 'y'
                       else 'n' end          as to_alert
            from (select campaign,
                         spot,
                         spot_id,
                         name       as spot_name,
                         daily_cost as daily_cost,
                         daily_cap  as daily_cap
                  from (select *
                        from (select campaign,
                                     spot,
                                     sum(cost) as daily_cost
                              from client.actions
                              where date = today()
                                and owner = '5fbb4d4b61d6e257153928a1'
                              group by 1, 2)

                             left join (select id as campaign,
                                               daily_cap
                                        from client.campaings
                                        where owner_id = '5fbb4d4b61d6e257153928a1') using campaign)

                       left join (select spot_id,
                                         spot_aid as spot,
                                         name
                                  from client.dictionary_spot
                                  where name like '%opunder%') using spot
                  where name like '%_%')

                 left join (select campaignId as campaign,
                                   campaignName
                            from client.dictionary_campaigns) using campaign
            group by 1, 3)
      where to_alert = 'y')

Интересно, зайдут тут SQL-сниппеты, или не нужны никому, потестим 🙂

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

Я это делаю через подсчёт строк и отбора топ-1 по каждому юзеру. Для примера, нужно найти самый популярный девайс юзера:

select user_id,
       device as most_used_device
from (select user_id,
             device,
             row_number() as over(partition by user_id order by user_id, count(*) desc) as rn
      from database
      group by 1, 2) as t1
where rn = 1

Логика простая, сначала выстраиваем поюзерный список девайсов с сортировкой по бОльшему количеству чего-нибудь, нумеруем строки, а потом отрезаем все строки, что не 1.

Тут весь прикол в count(*), сюда засовывать нужно то, что логически подойдёт, если это ивенты, то лучше их на дни попилить, чтобы мы не девайсы по количеству ивентов тащили 🙂

#сниппеты

📌 Аналитическая система с единорогами и пони

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

Почти всё я выбрал исключительно потому что нравится 🙂 Я не дата-инженер, поэтому что-то может быть не оптимально, но это мой комфортный стек работы со стороны ПА.

Получился вот такой наборчик:

🔵Данные с бэка, про платежи, регистрации, данные юзеров и вот это вот всё я бы хранил в Postgre. Потому что надёжная и неубиваемая система. Как та самая нокия. А для бэка это главный критерий, на мой взгляд, т.к. тут самые чувствительные данные.

🔵Фронтовый трекер для событий — вот тут хз, раньше был крутой опенсорсный Segment. Весил мало, загрузку не импрувил, user-based. Не умел ничего кроме трека ивентов, но с этой задачей справлялся прекрасно. Вот какой-то такой аналог бы. Может в сторону своей разработки бы смотрел. Ключевой параметр — легкость.

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

🔵Кликстрим по фронту складывал бы в колоночную бд, т.к. в запросе обычно нужно мало полей на много строк, а не наоборот. Тут бы зашёл Clickhouse или Vertica. Работал с кликстримом в строковых бд, запрос на >5 млн строк вообще не реально выгрузить. Но вроде как CH на масштабах проигрывает Вертике (но это не точно, слышал такое где-то).

🔵По BI тут два инструмента. В качестве основы для постоянных бордов Shiny (жестко, но стабильно, быстро и функционал ограничен только твоей фантазией). А для временных бордов и черновиков Redash (простой, быстрый, гибкости для времянок достаточно).

🔵Как working-area / хранилище артефактов, рисерчей, результатов экспериментов и т.д. для аналитиков поднял бы DataLore.

Интересно, насколько это вообще жизнеспособная схема со стороны инженерии, но работать аналитику в такой — одно удовольствие 🙂

📌 Про DataLore и DataSpell

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

Как-то кто-то мне с воодушевлением рассказывал про новый продукт JetBrains, который DataSpell, я послушал, покивал и благополучно забил. А на днях у меня появилось желание завести Jupyter в облаке под R. С юпитером я не работал толком, когда-то давно под это дело ставил Anaconda, потом немножко смотрел на блокноты через VSCode и PyCharm, но мне не понравилось.

А тут ради интереса пошёл посмотреть на DataSpell. Там я конечно вообще не понял как работать с блокнотами в R, но это и не важно стало потом 🙂

Когда я его ставил, JB любезно предложили мне попробовать ещё их облачный сервис DataLore. И вот это уже оказалось офигенно. Это простое корпоративное облако, к которому можно затянуть предустановленные коннекторы к базам данных (выбор по джетбрейновски огромный) или накидать файлами в проекты. Проект там это блокнот Jupyter с поддержкой R в том числе, все базовые приколы типа обновлений по расписанию и репортов — в наличии. А ещё блокнот можно компилировать в отчёт для не-аналитиков, скрыв код. За это отвечает отдельный интерфейс а-ля конструктор отчётов.

Секьюрность настраивается гибко. По дефолту в домене компании, но можно и раздавать отдельно на конкретных юзеров. В общем — моё почтение.

Как инструмент синхронизации аналитических артефактов — пока видится мне единственным завершённым на рынке, с удобным хранением скриптов R/Python/SQL и документации, например к тестам. Единственный минус для меня — не умеет запускать реактивные приложения Shiny. Но это было бы уже совсем круто 🙂

Кароч выглядит как конкурент Google Collab, только убивает последнего за счет гибкости.

А DataSpell, с которого всё началось, в целом выглядит как удобная комбинация DataGrip + PyCharm + R Studio + DBT. Всё в одном месте, всё удобно и красиво. Но я пока не готов переходить на него, R Studio всё-таки имеет много мелких приколов, от которых я не готов отказаться пока.

#инструменты

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

Кароч, 3Д-экшон суть такова как-то у меня был проект рабочий, где нужно было выпилить часть фичей из продукта, которые не выгодно обслуживать. Какие — не уточнялось, но что-нибудь надо снести. Чтобы вычислить аутсайдеров, логично сравнить все фичи между собой. Это понятно. Не понятно как сравнить и по каким критериям. Потому что начиная в этом всём копаться, осознаёшь что у каждой части свои приколы и как будто стандартизировать шкалу оценок нельзя. И так то оно так, но немножко, всё таки, можно.

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

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

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

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

📌 Метрика Adoption Rate

В продуктовой аналитике есть такая внегласная область User Interaction, это про взаимодействие юзера с продуктом через интерфейс. Так вот там есть “свой” набор метрик. Это те же самые продуктовые метрики, но с щепоткой контекста. Т.е. используются более узко, в рамках конкретной фичи.

Например, Retention rate. В классическом понимании RR показывает насколько часто юзер возвращается, хороший показатель метрики намекает, что юзера всё устраивает и он продолжает пользоваться продуктом.

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

‼️ И вот одна из главных метрик в UI-аналитике это Adoption Rate. AR показывает “заметность” фичи для пользователя И/ИЛИ соответствие ожидания-реальности при её использовании. Считается как количество юзеров фичи / всех активных юзеров.

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

А что про ожидание? Это скорее вопрос интуитивности. Возьмём для примера задачку из прошлого поста. Никого не смутило поведение функции “Сравнения”? Любой, кто хоть раз покупал что-то в магазине, может задаться вопросом “а что я буду сравнивать, с чем, и по каким характеристикам? А зачем мне это вообще надо?” Хотя нажми он кнопку, получил бы классную подборку вариантов не хуже, а может и дешевле.

Низкий AR при хороших прочих показателях фичи, задизайненной под большинство, почти всегда КРИЧИТ о проблемах в восприятии юзерами. Или триггер старта сценария фичи слишком спрятан, или не очевидна его ценность, или он просто затирается “баннерной слепотой”.

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