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

📌 4. T-тест. Проверка дисперсий

С теорией разобрались, едем дальше.

Для расчёта АБ существует много методов. Мы рассмотрим самые популярные, которые чаще других применяются на практике. И начнём, конечно, с T-теста Стьюдента / Уэлча.

‼️ Кстати, тоже частая тема на собесах.

Нулевая гипотеза Т-теста предполагает, что средние значения переменной в выборках равны. Отклонение гипотезы (p-value < 0.05) это наша желаемая цель.

Я часто подхожу к расчётам через T-тест. Он простой и довольно точный. Из минусов — имеет пару ограничений (но и инструменты для их обхода).

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

Для проверки дисперсий обычно используют какой-то из критериев:

✅ Бартлетта. Он чувствителен к нормальности распределения;

✅ Левена. Менее чувствителен к нормальности, самый популярный тест;

✅ Флигнера-Килина. Не чувствителен к отклонениям от нормальности и выбросам, подходит для ненормального распределения;

Нулевые гипотезы всех критериев похожи, они предполагают, что дисперсии в выборках равны. Т.е. нам эту гипотезу отклонять не хочется (цель p-value > 0.05).

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

В коде далее df — датасет, metric — метрика, столбец который проверяем, var — категория варианта.

Проверка дисперсий в R и Python:

library(car) # библиотека с тестом Левена

bartlett.test(metric ~ var, df) # тест Бартлетта
leveneTest(metric ~ var, df) # тест Левена
fligner.test(metric ~ var, df) # тест Флигнера-Килина

from scipy.stats import bartlett, fligner, levene

# тест Бартлетта
bartlett_result = bartlett(df[df['var'] == 'A']['metric'], df[df['var'] == 'B']['metric']).pvalue

# тест Левена
levene_result = levene(df[df['var'] == 'A']['metric'], df[df['var'] == 'B']['metric']).pvalue

# тест Флигнера-Килина
fligner_result = fligner(df[df['var'] == 'A']['metric'], df[df['var'] == 'B']['metric']).pvalue

#ABtest

📌 Созвоны

Пока ты перевариваешь базовую теорию АБ, давай немного отдохнём и обсудим действительно важные вещи 🙂

Вот ты прошёл свои первые собесы, получил оффер и вышел на работу. Сидишь такой с утра, пьёшь кофе и заглядываешь в рабочий календарь…

Созвоны — любимая часть работы 😅.

Их плотность может варьироваться от ежедневных до раза в неделю.

✅ Самый популярный у аналитиков это планинг. Его ставят раз в неделю, в понедельник-вторник, чтобы раскидать задачки на спринт (интервал в 1-2 недели, в который ты планируешь свою работу).

Чаще ты просто рассказываешь чем планируешь заниматься. Иногда более официально, с оценками или стори-поинтами (есть в IT такое развлечение — пленнинг покер — когда ты рассказываешь суть задачи, а остальные участники в закрытую оценивают её сложность).

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

✅ Не самый частый у аналитиков — дейли. Короткий созвон, на 15-30 минут, обычно каждый день утром. Задача — свериться с планами и сообщить о каких-то, блокирующих задачу, факторах.

✅ Синхро — не самый популярный созвон, по сути похож на дейли, только подольше и раз в неделю. Они взаимозаменяемые.

✅ Груминг — чистка бэклога (общего списка задач), груминг тоже довольно редкий созвон у аналитиков, но как по мне зря. Иногда очень полезен, т.к. часто бывает что задачи просто зависают — они уже не так нужны как казалось, но смотрят на тебя и бесят.

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

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

📌 3. Экспресс-курс статистики для АБ

Классическая механика расчёта АБ-тестов основывается на стат. критериях.

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

✅ Распределение — способ описания того, как разбросаны значения в наборе данных. Распределение бывает разных видов, но нас пока интересует только нормальное.

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

✅ Выбросы — это экстремально большие или маленькие значения в наборе данных, которые могут искажать общие результаты. В АБ с выбросами осторожно.

✅ Статистические тесты — не путать с АБ-тестами. Стат. тесты это инструменты, с помощью которых мы проверяем заранее заданные статистические гипотезы. Их много разных. У каждого стат. теста есть нулевая гипотеза, и задача теста её отклонить или не. Т.е. по простому, стат. тесты позволяют нам делать различные проверки наших данных, например, проверку на нормальность распределения, или гомогенность дисперсий.

✅ ЦПТ (Центральная предельная теорема) — фундамент статистики: “при достаточно большом размере выборки, распределение средних значений выборочных данных будет приближаться к нормальному распределению, независимо от формы распределения исходной популяции.”

✅ P-value — главный термин в контексте АБ, это вероятность получить такие же, или ещё более выраженные отличия, при условии, что верна нулевая гипотеза.

✅ Ошибка первого рода — ситуация, когда мы отклоняем нулевую гипотезу, хотя на самом деле она верна. В АБ это значит что мы радуемся победе тестового варианта, но на самом деле он не выиграл.

✅ Ошибка второго рода — противоположность ошибке первого рода. Мы не отклоняем нулевую гипотезу, хотя на самом деле должны.

P.S. эту базу, кстати, часто спрашивают на собесах, сохрани и не теряй 🙂

#ABtest #собесы

📌 2. Дизайн теста, ч.2

Дальше ты берёшь наработки заказчика и напильник, и начинаешь детализировать:

5️⃣ Ключевая метрика / ОЕС.
По началу будет достаточно просто выбрать метрику, на которую тест должен повлиять сильнее всего. Конверсия в регу, в покупку, средний чек, общий доход и т.д. Выбирай вдумчиво, это важный шаг. Со временем, вместо одной ключевой метрики ты придёшь к ОЕС (overall evaluation criterion), это такая штука, которая получается при взвешивании переменных. Об этом потом поговорим, тема немного сложнее чем кажется.

6️⃣ Дополнительные метрики.
Укажи пару-тройку дополнительных метрик, которые тоже нужно мониторить, но они чуть менее важны чем ключевая. Не перебарщивай с набором метрик, бери только важное, иначе утонешь в интерпретации ☝️

7️⃣ Базовое значение ключевой метрики и её вариативность.
Как базу обычно берут среднее, а вариативность это стандартное отклонение. Не бери большой период, 2-4 недели истории будет достаточно. Нужно чтобы значения были свежими.

8️⃣ MDE (minimum detectable effect).
Наши ожидаемые изменения ключевой метрики по итогам теста. Это никак не вычисляется, обычно на опыте просто 🙂
Например, мы хотим провести тест на конверсию, мы верим в гипотезу, она разрывная. Наша конверсия обычно 5%, мы хотим поднять её тестом до 7%. Вот эта разница и есть MDE. Указывать можно как в % так и в п.п. (проц. пунктах). Чем ниже MDE, тем дольше проводить тест, но тем выше вероятность получить стат. значимый результат. Если мы слишком завысим MDE, то тест будет быстрым, но скорее всего, не значимым.

9️⃣ Валидация MDE.
Так как понять какой MDE брать? Обычно эффект никто не валидирует (потому что далеко не во всех компаниях развита культура тестов), но я поклонник метода через сигмы — MDE не должен быть выше 2-3 стандартных отклонений, это снижает реалистичность, MDE ниже одного отклонения, возможно, слишком мал и тест может затянуться. Тут надо балансировать. Вернемся к этому в п.11

1️⃣0️⃣ Рассчитываем выборку.
У нас есть всё что нужно для расчёта размеров теста: базовая метрика и MDE. Ещё в настройках указывают доверительный уровень (0.05), мощность (0.8) и направление (”two.sided”). Обычно их редко меняют без серьезных оснований, чаще ставят дефолтные. В R выборка считается функцией power.prop.test(), в Python statsmodels.NormalIndPower(). В конце поста ссылка на пример.

1️⃣1️⃣ Расчёт сроков теста.
На основании рассчитанных объёмов выборки и средних показателей трафика можно прикинуть сроки проведения теста. Есть нюансы — тест не должен быть короче 1 полной недели, чтобы включить выходные. Если тест слишком долгий, попробуй увеличить MDE.

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

Вот здесь можно посмотреть пример заполненного дизайна: ПРИМЕР ДИЗАЙНА ТЕСТА

#ABtest

📌 2. Дизайн теста, ч.1

Тест, по определению, проверяет какую-то идею. По умному эта идея называется гипотезой.

📎Гипотезы могут появляться просто как идеи или их может приносить команда (продакты, проджекты или дизайнеры), но чаще гипотезы вытекают из твоих рисёрчей. Когда ты исследуешь какую-то проблему или анализируешь фичу, хорошим тоном считается в выводах описать идеи по решению проблемы или улучшению фичи. Вот эти идеи — уже гипотезы.

Кстати, генерирование гипотез по итогам рисёрча отличает хорошего аналитика от не. Новички, как правило, вообще не заморачиваются с выводами. Итак таблицы есть — заказчик разберётся (спойлер — не разберётся).

Когда гипотеза ясна, первым шагом в подготовке теста является документирование. В аналитическом сообществе мы называем этот артефакт дизайном теста (ДТ).

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

ДТ все заполняют по разному, кто как. Структура, которую я покажу здесь, моя авторская, я начинал её делать года 4 назад, она постепенно эволюционировала, и вот финальная версия на сегодня. Моим командам нравится, пользуйтесь и в своих 🙂

Эту часть заполняет заказчик гипотезы ⬇️

1️⃣ Гипотеза.
Тут мы описываем суть идеи, что хотим поменять и зачем.

2️⃣ Описание вариантов.
Что меняем в тестовом варианте. Иногда, в зависимости от твоей системы, нужно проставить id вариантов перед стартом, это ты уже потом в доку добавишь.

3️⃣ Чего ожидаем от теста.
Ожидаем больше заказов или хотим увеличить возвращаемость, повысить средний чек и т.д. Эта инфа тебе понадобится чуть дальше, при выборе метрик.

4️⃣ Ограничения.
Если есть, тут стоит указать. Проводим только на определённом гео или платформе и т.д.

#ABtest

📌 1. Интро

По результатам опроса, в ближайшие 2 недели мы поговорим про АБ-тесты:

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

⚡️В конце, при желании, порешаем реальный тест.

И в качестве введения в тему, немного теории — что это вообще такое и зачем оно надо ⬇️

Смысл АБ довольно прост: мы делим юзеров на несколько групп (этот процесс называется сплитование), в одной ничего не трогаем — это наш контроль, в других что-то меняем. Сравниваем, и принимаем решение как лучше.

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

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

Доставай тетрадочку, на курсах тебе такого не расскажут 🙂

#ABtest

Фан-факт:

8 из 10 АБ-тестов не показывают статистической значимости.

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

И помни: не найти полезной информации в данных — это найти полезную информацию о её отсутствии.

#funfact

📌 Корреляция и причинно-следственная связь

Перед тем, как мы нырнём в долгий разговор про АБ, закину небольшую мысль, которую всегда нужно помнить.

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

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

Но так бывает не всегда. Чаще как раз причинно-следственные связи не очевидны. Статистика и аналитика в целом не так уверенно справляется с поиском причинности, как бы это сделал, например, твой астролог.

Если твой банк никогда не грабили, вряд ли хорошей идеей будет уволить охранников ради экономии бюджета 🧐.

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

В аналитике “официально” эта идея закреплена в законе Гудхарта:

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

И замечании Лукаса:

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

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

И сам так никогда не делай, а то можно очень далеко уйти по ложному следу.

В который раз натыкаюсь, но всегда смешно)

📌 Взаимодействия внутри команды

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

Мы уже понимаем что он умеет и какие задачи выполняет. Давай поговорим про его интеграцию в команду.

Есть две популярные структуры внутри IT-компаний:

1️⃣ Горизонтальная — когда у вас есть обособленный отдел аналитики, который обслуживает интересы остальных команд. Плюсы такой структуры в том, что каждый аналитик может взять разные задачи и быть в контексте всей работы всех департаментов. Минусы — экспертиза не глубокая.

2️⃣ Вертикальная — более популярная, и как по мне, более оптимальная — когда у вас есть отдел аналитики, но он номинальный, в основном юниты раскиданы по своим командам. Т.е. продуктовый аналитик состоит в команде разработки продукта, маркетинговый в маркетинге и т.д. Из плюсов — глубокая экспертиза, из минусов — такой чел становится единственным источником знаний своего куска продукта (документация ахахаха, не слышал).

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

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

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

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

Мудрецы говорят что постить рабочий сетап — хорошая примета 🙂

📌 Нейросети заменят аналитиков?

Обсудим холиварную тему? 😈

Я в работе часто использую нейронки, в основном это GPT и Copilot, а иногда под узкую задачу можно и свою написать. Они, в большинстве случаев, хорошо справляются с генерированием несложного кода, а иногда даже и сложного.

Удобно закинуть им образец датасета и провести какую-то базовую обработку — поменять типы данных, трансформировать в long-формат, или накидать функцию для очистки выбросов. С этим они, как правило, справляются быстро и почти без косяков.

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

Но самое больное, это их попытки тебе угодить, когда ты спрашиваешь про теорию. И это прям опасно:

— Эй, GPT, для t-критерия нужно равномерное распределение?

— Да, всё верно, нужно.

— Но ведь не нужно, это миф из-за косяка перевода источника.

— Да, вы правы, оно не нужно.

— Но ведь нужно равномерное распределение выборочных средних!

— Да, простите за ошибку, оно всё же нужно.

Да, это просто стадия развития пока такая, и когда-нибудь они начнут отрабатывать верно с первого раза (но это не точно). Кроме того, нейронки пока не умеют выполнять код, а значит и понимать результаты.

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

К сожалению или к счастью, кроме аналитика, мало кто может взять на себя эту роль.

📌 Грейды в аналитике

Давайте разберёмся с грейдами. Что это вообще такое и какие у них требования.

Тут мы опустим грейдирование разработки, т.к. у них там своя атмосфера, у нас своя.

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

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

Вот допустим, джун. Ему нужно уметь пользоваться базовым инструментарием, иначе он просто ничего не сможет сделать (а это уже стажёр или что-то из этой серии). Вот джун получает таску (обычно это какие-то не сложные вещи, типа выгрузки и очистки данных). Т.к. у джуна мало опыта, он может неосознанно наделать ошибок, считая свою логику верной. И она, конечно, может быть верной, но в аналитике можно легко изменить выводы, если упустить какую-то неочевидную деталь, например, из-за недостаточного погружения в данные. Поэтому обычным флоу работы джуна будет отправка работы на ревью более опытному коллеге.

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

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

На картинке пример как обычно ставят одну и ту же простую задачу разным грейдам 🙂

📌 Python или R

Хотел бы я чтобы этот вопрос был холиварным, но, к сожалению, мы п-R-оигрываем.

Мы знаем, что скриптовый язык это наш хлеб. В профессии популярны два языка, новомодный Python и олдскульный R. В чем разница и какой выбрать?

Думаю не стоит объяснять про Python, ты итак в курсе что это самый быстроразвивающийся и востребованный язык в сфере.

Поэтому если кратко — на старте выбирай Python.

А вот про R ты мог и не знать. Исторически он пришел из сферы фармацевтики, науки и библиотечного дела (what?). Это скриптовый язык с уклоном в статистику. У него из коробки, без всяких дополнительных пакетов, присутствует огромная база статистических методов. А если с пакетами, то за всю свою карьеру я лишь 2 раза столкнулся с задачами, которые было сильно проще решить с помощью Python (это алгоритм цепей Маркова и предиктор Catboost от Яндекса, который поддерживает R, но там даже документация не воспроизводится 🙂).

R прекрасно себя показывает в рисёрчах и расчётах экспериментов.

Если ты уже на чём-то писал, то синтаксис типа:
df_1 <- df %>% filter(col1 %in% df_2$col1)
— может резануть глаз.

В РФ про R даже слышали не все аналитики, но в Европе и США он, до недавнего времени, был популярнее Python’а.

К тому же у него классный IDE — R Studio, красивейшие отчёты в markdown на базе Quarto, а фреймворк Shiny абсолютная реактивная киллфича.

Из минусов его работа с ML, он жрёт память как не в себя на миллионах строк. Да, Python тоже, но если я не могу завести модель на R из-за проблем с памятью, я просто иду в Python и завожу её там. Обычно помогает 🙂

Но главная проблема R это его непопулярность. С ним тупо сложнее найти работу. HR-фильтры требуют Python, не вникая в тот факт, что скриптовый язык аналитика чаще всего не интегрирован в поток разработки отдела, и что ты используешь это твоё дело. Хотя иногда и правда, команды могут, например, синхронить наработки в каком-нибудь Google Collab, который не поддерживает R.

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

Я уже пару раз упомянул EDA (exploratory data analysis), обзорный анализ данных на твоей выгрузке. И если ты используешь в работе язык R, поделюсь инструментом, который я часто использую для EDA.

Постараюсь не забывать помечать такие рекомендации тегом #инструменты

📌 Необходимые навыки

Какие знания и навыки необходимы продуктовому аналитику в большей степени?

Когда я только учился профессии, у меня голова взрывалась от объёмов поглощаемых знаний. Чего там только нет, и всё надо уметь.

Стартер пак, must have для любого специалиста:

▶️ Статистика. Без понимания статистики никуда. Меры тенденции, распределения, критерии, ЦПТ, p-value — всё это ежедневно фигурирует в работе.

▶️ SQL. Основа основ, без знания языка будет очень сложно получить данные для анализа, построить отчёт, работать с ad-hoc задачами. В работе используется даже чаще статистики, сложно вспомнить хотя бы один день, когда я не лез в базу.

▶️ Python/R. Скриптовый язык нужен как минимум для собесов. На практике я встречал аналитиков, которые не владели языком, но умудрялись решать задачи с помощью таблиц. Но хорошим аналитиком без скриптового языка стать нельзя. Он нужен для очистки и обработка данных, построения моделей и расчётов экспериментов. Любой анализ, сложнее EDA быстрее и проще реализовать через скриптовый язык.

▶️ Аналитическое мышление. Навык, который хорошо развивается с опытом. Понимание причинно-следственных связей, умение отследить и понимать логику происходящего.

И штуки чуть менее базовые, но не менее важные:

▶️ Юнит-экономика. Нужно разбираться в метриках, все аналитические артефакты на них завязаны. Существует целый список базовых метрик, которые исторически сформировались (типа CR, Retention, Aquisition, ARPU, LTV и тд.), но от продукта к продукту никто не запрещает придумывать свои. Когда я начинал, я был уверен что это высечено в граните и пытался их зазубрить 😅

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

▶️ АБ-тесты. 90% работы над тестом базируются на статистике, но свои нюансы, конечно, там есть.

▶️ Data mining. Умение получать идеи из ничего потока сырых данных. Реализуется через SQL + Python/R.

📌 Нужно ли шарить в ML

Спойлер — рекомендуется.

ML (Machine Learning) исторически считается прерогативой дата-сатанистов. И в целом, оно так и есть. Но ML ML’ю рознь.

В контексте продуктовых исследований часто недостаточно собрать просто статистику (эта стадия, кстати, называется EDA — exploratory data analysis, разведка). Чтобы понимать закономерности и зависимости, иногда приходится нырять в алгоритмы.

Да, не весь спектр ML тебе понадобится, но есть прям очень полезные штуки, которые хорошо бы уметь, а именно классификация, кластеризация и предикты.

▶️ Классификация — очень мощная штука, нужна для сортировки всего и вся: раскидать юзеров по сегментам, определить товары в группы, присвоить сегменты странам. Да что только не придумаешь.

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

▶️ Предиктивные модели часто помогают держать руку на пульсе. Но с ними тоже не всё так однозначно, часто прогнозы могут сильно косячить, поэтому не увлекайся.

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

p.s. Картинку не какую хотели, а какую заслужили, предоставил мой кореш DALL-E

📌 Типы продуктовых задач

Давай разовьём тему задач. Что конкретно делает продуктовый аналитик?

Основные цели твоей работы мы уже уловили:

▶️ Понимать пульс продукта и реагировать на его изменения;

▶️ Улучшать, то что работает плохо;

▶️ Зарабатывать компании больше золота;

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

Позже детально разберём каждый тип, но в общем виде это выглядит следующим образом:

1️⃣ Продуктовые исследования (в народе рисёрчи). Наверное, самая частая задача. Обычно нужно разобраться что происходит с какой-то фичей, нужна ли она, можем ли как-то её улучшить. Или, например, как юзеры себя повели в какой-то период времени — когда мы увеличили закупку, или в какую-то знаковую дату для продукта. Рисёрчи это основной источник гипотез на тестирование.

2️⃣ Актуализация разметки. Разметка — твой главный друг и товарищ. То, как собираются данные, какие есть события и какие у них свойства, во многом определяют сколько боли будет в твоей работе. В теории задача не частая, в основном нужно допиливать разметку под новые фичи. На практике — у всех разметка кривая, нужно всё корректировать под себя. Но по важности — одна из топовых задач. Осложняет дело ещё и тот факт, что кроме тебя это никому не нужно.

3️⃣ АБ-тесты. Самая спорная история со времен изобретения экспериментов. Я не встречал 2 компании с одинаковыми процессами в тестах. В основном расхождения на этапе расчётов. В 80% компаний, где я работал, мне приходилось выкидывать все наработки компании и писать новую документацию. Но как по мне, эксперименты — самая интересная часть работы. Про АБ мы будем говорить ещё много.

4️⃣ Юнит-экономика. Чтобы что-то улучшать, надо понимать зачем. Любой эксперимент или рисёрч всегда проводится в контексте метрик, на которые мы опираемся. Разбираться в метриках и проектировать их систему под твой продукт — задача твоя и продакта.

5️⃣ BI. Последние года 3 я почти не занимался задачами BI, чему я очень рад. Одно дело строить небольшие дашборды в Redash или SS, подкрепляющие твои рисёрчи, совсем другое писать на каком-нибудь DAX’е архитектуру для Power BI. Многие недооценивают уровень происходящей там жести, а я очень уважаю хороших BI-щиков, они крутые. Но часто это входит в пулл продуктовых задач.

6️⃣ Ad-hoc. К эд-хокам относится прочая мелочевка для поддержки команды, выгрузки, срезы, статистика чего-нибудь.