А гоу сразу для всех прибывших определимся. Кто победит?
Anonymous Poll
77%
Python
7%
R
16%
Excell111
📌 Отличие джунов от сеньоров
В номинации "Первый пост" в моём личном рейтинге выиграла эта тема.
Если закинуть голосовалку, подозреваю, что многие ответят “хард-скиллы”. Но тут я не соглашусь. Аналитик это не фронт, у которого каждую неделю выкатывается новый фреймворк. За последние лет 100 принципы анализа данных не то чтобы супер сильно шагнули вперёд. Основных хардовых вещей в профессии тоже не много — достань данные, обработай и проанализируй. Языков в распоряжении аж целых полтора: Python или R и SQL (да, я его в полу-язык записал). Да и то, часто используется меньшая часть возможностей языков. Базовая математика? Да, конечно, но это скорее порог входа, всем нужна в равной степени.
На мой взгляд, ключевым отличием является подход к выполнению задач. Я часто встречаю ребят, которые при получении таски идут её делать. Но мы-то знаем кто эти таски ставил. Продакты, которых, я, конечно, люблю, но они не всегда умеют донести суть задачи.
Вот это вот докапывание до сути и есть ключевое отличие опытных аналитиков от не. Зачем вообще мы это делаем? Что мы хотим получить? Как мы будем это использовать? Целесообразна ли затрата ресурсов аналитики ради прогнозируемого профита?
Да, звучит как база, но я за свою карьеру встречал всего 2 человека с таким основательным подходом.
Не надо бояться ставить эстимейты в 5 раз выше того, что разыграл покер, закладывайте время на докапывание до сути, и вы удивитесь, насколько сильно изменится начальная таска.
В номинации "Первый пост" в моём личном рейтинге выиграла эта тема.
Если закинуть голосовалку, подозреваю, что многие ответят “хард-скиллы”. Но тут я не соглашусь. Аналитик это не фронт, у которого каждую неделю выкатывается новый фреймворк. За последние лет 100 принципы анализа данных не то чтобы супер сильно шагнули вперёд. Основных хардовых вещей в профессии тоже не много — достань данные, обработай и проанализируй. Языков в распоряжении аж целых полтора: Python или R и SQL (да, я его в полу-язык записал). Да и то, часто используется меньшая часть возможностей языков. Базовая математика? Да, конечно, но это скорее порог входа, всем нужна в равной степени.
На мой взгляд, ключевым отличием является подход к выполнению задач. Я часто встречаю ребят, которые при получении таски идут её делать. Но мы-то знаем кто эти таски ставил. Продакты, которых, я, конечно, люблю, но они не всегда умеют донести суть задачи.
Вот это вот докапывание до сути и есть ключевое отличие опытных аналитиков от не. Зачем вообще мы это делаем? Что мы хотим получить? Как мы будем это использовать? Целесообразна ли затрата ресурсов аналитики ради прогнозируемого профита?
Да, звучит как база, но я за свою карьеру встречал всего 2 человека с таким основательным подходом.
Не надо бояться ставить эстимейты в 5 раз выше того, что разыграл покер, закладывайте время на докапывание до сути, и вы удивитесь, насколько сильно изменится начальная таска.
👍17❤6
📌 Специализации аналитиков
У новичков в теме может возникнуть вопрос — а чем вообще занимается продуктовый аналитик? Когда-нибудь я распишу подробно наиболее частые типы задач продуктовой аналитики, а сейчас просто попробуем сравнить его с другими популярными направлениями.
▶️ Итак, продуктовый аналитик — чел, который работает внутри продукта в составе команды разработки или развития. В основном, в тесной связке с продактом и дизайнером, занимается улучшением приложения или сайта. Исследует, как себя чувствует продукт и его юзеры, проводит эксперименты, работает с метриками и тд.
▶️ Маркетинговый аналитик — в моей практике бизнес часто называет его веб-аналитиком, что, в целом, не критично, они похожи — занимается в основном анализом трафика на ранних этапах, плюс-минус до этапа реги, т.е. всё то, что происходит в твоей аппке перед тем как попасть в ведение продуктового аналитика. Срачи между маркетингом и продуктом по поводу плохого конверта — обязательная часть успешного стартапа.
▶️ Дата-аналитик — классический офисный чел, которого ты представляешь при слове аналитик. Таблички какие-то перебирает, какие-то когорты строит, выгрузки делает, иногда пилит дашборды. Как по мне так это такой универсальный юнит без специализации.
▶️ BI-аналитики — узкоспециализированные ребята, занимаются разработкой и поддержкой вашей BI-инфраструктуры, собирают витрины данных, строят дашборды и настраивают репорты. Я лично очень люблю когда в команде есть BI-йщики, иначе их задачи валятся на меня, а мне BI не так интересен.
▶️ Дата сайентисты — больше математики, чем классические аналитики. Занимаются разработкой моделей Deep- и Machine Learning'а для автоматизации, прогнозирования, классификаций и тд. Очень полезны бизнесу на поздних этапах развития аналитического направления. Хотя если у вас бизнес строится на какой нибудь персонализации, то это первый необходимый юнит.
▶️ Есть ещё всякие бизнес- и финансовые-аналитики (типичные представители менеджмента или команды рисков), системные аналитики (это вообще ребята из разработки, к классическому анализу отношение имеют крайне посредственное), ux-аналитики (с упором в качественные исследования) и много более специализированных.
Тут я расписал плюс-минус популярные позиции, которые я встречал.
Надеюсь, теперь стало немножко понятнее из чего состоит весь этот аналитический зоопарк.
У новичков в теме может возникнуть вопрос — а чем вообще занимается продуктовый аналитик? Когда-нибудь я распишу подробно наиболее частые типы задач продуктовой аналитики, а сейчас просто попробуем сравнить его с другими популярными направлениями.
▶️ Итак, продуктовый аналитик — чел, который работает внутри продукта в составе команды разработки или развития. В основном, в тесной связке с продактом и дизайнером, занимается улучшением приложения или сайта. Исследует, как себя чувствует продукт и его юзеры, проводит эксперименты, работает с метриками и тд.
▶️ Маркетинговый аналитик — в моей практике бизнес часто называет его веб-аналитиком, что, в целом, не критично, они похожи — занимается в основном анализом трафика на ранних этапах, плюс-минус до этапа реги, т.е. всё то, что происходит в твоей аппке перед тем как попасть в ведение продуктового аналитика. Срачи между маркетингом и продуктом по поводу плохого конверта — обязательная часть успешного стартапа.
▶️ Дата-аналитик — классический офисный чел, которого ты представляешь при слове аналитик. Таблички какие-то перебирает, какие-то когорты строит, выгрузки делает, иногда пилит дашборды. Как по мне так это такой универсальный юнит без специализации.
▶️ BI-аналитики — узкоспециализированные ребята, занимаются разработкой и поддержкой вашей BI-инфраструктуры, собирают витрины данных, строят дашборды и настраивают репорты. Я лично очень люблю когда в команде есть BI-йщики, иначе их задачи валятся на меня, а мне BI не так интересен.
▶️ Дата сайентисты — больше математики, чем классические аналитики. Занимаются разработкой моделей Deep- и Machine Learning'а для автоматизации, прогнозирования, классификаций и тд. Очень полезны бизнесу на поздних этапах развития аналитического направления. Хотя если у вас бизнес строится на какой нибудь персонализации, то это первый необходимый юнит.
▶️ Есть ещё всякие бизнес- и финансовые-аналитики (типичные представители менеджмента или команды рисков), системные аналитики (это вообще ребята из разработки, к классическому анализу отношение имеют крайне посредственное), ux-аналитики (с упором в качественные исследования) и много более специализированных.
Тут я расписал плюс-минус популярные позиции, которые я встречал.
Надеюсь, теперь стало немножко понятнее из чего состоит весь этот аналитический зоопарк.
👍25❤1
📌 Типы продуктовых задач
Давай разовьём тему задач. Что конкретно делает продуктовый аналитик?
Основные цели твоей работы мы уже уловили:
▶️ Понимать пульс продукта и реагировать на его изменения;
▶️ Улучшать, то что работает плохо;
▶️ Зарабатывать компании больше золота;
В контексте этих целей у тебя есть несколько базовых типов задач, каждую из которых можно решать несколькими методами.
Позже детально разберём каждый тип, но в общем виде это выглядит следующим образом:
1️⃣ Продуктовые исследования (в народе рисёрчи). Наверное, самая частая задача. Обычно нужно разобраться что происходит с какой-то фичей, нужна ли она, можем ли как-то её улучшить. Или, например, как юзеры себя повели в какой-то период времени — когда мы увеличили закупку, или в какую-то знаковую дату для продукта. Рисёрчи это основной источник гипотез на тестирование.
2️⃣ Актуализация разметки. Разметка — твой главный друг и товарищ. То, как собираются данные, какие есть события и какие у них свойства, во многом определяют сколько боли будет в твоей работе. В теории задача не частая, в основном нужно допиливать разметку под новые фичи. На практике — у всех разметка кривая, нужно всё корректировать под себя. Но по важности — одна из топовых задач. Осложняет дело ещё и тот факт, что кроме тебя это никому не нужно.
3️⃣ АБ-тесты. Самая спорная история со времен изобретения экспериментов. Я не встречал 2 компании с одинаковыми процессами в тестах. В основном расхождения на этапе расчётов. В 80% компаний, где я работал, мне приходилось выкидывать все наработки компании и писать новую документацию. Но как по мне, эксперименты — самая интересная часть работы. Про АБ мы будем говорить ещё много.
4️⃣ Юнит-экономика. Чтобы что-то улучшать, надо понимать зачем. Любой эксперимент или рисёрч всегда проводится в контексте метрик, на которые мы опираемся. Разбираться в метриках и проектировать их систему под твой продукт — задача твоя и продакта.
5️⃣ BI. Последние года 3 я почти не занимался задачами BI, чему я очень рад. Одно дело строить небольшие дашборды в Redash или SS, подкрепляющие твои рисёрчи, совсем другое писать на каком-нибудь DAX’е архитектуру для Power BI. Многие недооценивают уровень происходящей там жести, а я очень уважаю хороших BI-щиков, они крутые. Но часто это входит в пулл продуктовых задач.
6️⃣ Ad-hoc. К эд-хокам относится прочая мелочевка для поддержки команды, выгрузки, срезы, статистика чего-нибудь.
Давай разовьём тему задач. Что конкретно делает продуктовый аналитик?
Основные цели твоей работы мы уже уловили:
▶️ Понимать пульс продукта и реагировать на его изменения;
▶️ Улучшать, то что работает плохо;
▶️ Зарабатывать компании больше золота;
В контексте этих целей у тебя есть несколько базовых типов задач, каждую из которых можно решать несколькими методами.
Позже детально разберём каждый тип, но в общем виде это выглядит следующим образом:
1️⃣ Продуктовые исследования (в народе рисёрчи). Наверное, самая частая задача. Обычно нужно разобраться что происходит с какой-то фичей, нужна ли она, можем ли как-то её улучшить. Или, например, как юзеры себя повели в какой-то период времени — когда мы увеличили закупку, или в какую-то знаковую дату для продукта. Рисёрчи это основной источник гипотез на тестирование.
2️⃣ Актуализация разметки. Разметка — твой главный друг и товарищ. То, как собираются данные, какие есть события и какие у них свойства, во многом определяют сколько боли будет в твоей работе. В теории задача не частая, в основном нужно допиливать разметку под новые фичи. На практике — у всех разметка кривая, нужно всё корректировать под себя. Но по важности — одна из топовых задач. Осложняет дело ещё и тот факт, что кроме тебя это никому не нужно.
3️⃣ АБ-тесты. Самая спорная история со времен изобретения экспериментов. Я не встречал 2 компании с одинаковыми процессами в тестах. В основном расхождения на этапе расчётов. В 80% компаний, где я работал, мне приходилось выкидывать все наработки компании и писать новую документацию. Но как по мне, эксперименты — самая интересная часть работы. Про АБ мы будем говорить ещё много.
4️⃣ Юнит-экономика. Чтобы что-то улучшать, надо понимать зачем. Любой эксперимент или рисёрч всегда проводится в контексте метрик, на которые мы опираемся. Разбираться в метриках и проектировать их систему под твой продукт — задача твоя и продакта.
5️⃣ BI. Последние года 3 я почти не занимался задачами BI, чему я очень рад. Одно дело строить небольшие дашборды в Redash или SS, подкрепляющие твои рисёрчи, совсем другое писать на каком-нибудь DAX’е архитектуру для Power BI. Многие недооценивают уровень происходящей там жести, а я очень уважаю хороших BI-щиков, они крутые. Но часто это входит в пулл продуктовых задач.
6️⃣ Ad-hoc. К эд-хокам относится прочая мелочевка для поддержки команды, выгрузки, срезы, статистика чего-нибудь.
👍13❤3
📌 Нужно ли шарить в ML
Спойлер — рекомендуется.
ML (Machine Learning) исторически считается прерогативой дата-сатанистов. И в целом, оно так и есть. Но ML ML’ю рознь.
В контексте продуктовых исследований часто недостаточно собрать просто статистику (эта стадия, кстати, называется EDA — exploratory data analysis, разведка). Чтобы понимать закономерности и зависимости, иногда приходится нырять в алгоритмы.
Да, не весь спектр ML тебе понадобится, но есть прям очень полезные штуки, которые хорошо бы уметь, а именно классификация, кластеризация и предикты.
▶️ Классификация — очень мощная штука, нужна для сортировки всего и вся: раскидать юзеров по сегментам, определить товары в группы, присвоить сегменты странам. Да что только не придумаешь.
▶️ Кластеризация похожа по своей сути, но работает от обратного, вычислить какие популярные сегменты (кластеры) вырисовываются в твоих данных.
▶️ Предиктивные модели часто помогают держать руку на пульсе. Но с ними тоже не всё так однозначно, часто прогнозы могут сильно косячить, поэтому не увлекайся.
О разных алгоритмах ML в контексте задач мы тоже как-нибудь поговорим.
p.s. Картинку не какую хотели, а какую заслужили, предоставил мой кореш DALL-E
Спойлер — рекомендуется.
ML (Machine Learning) исторически считается прерогативой дата-сатанистов. И в целом, оно так и есть. Но ML ML’ю рознь.
В контексте продуктовых исследований часто недостаточно собрать просто статистику (эта стадия, кстати, называется EDA — exploratory data analysis, разведка). Чтобы понимать закономерности и зависимости, иногда приходится нырять в алгоритмы.
Да, не весь спектр ML тебе понадобится, но есть прям очень полезные штуки, которые хорошо бы уметь, а именно классификация, кластеризация и предикты.
▶️ Классификация — очень мощная штука, нужна для сортировки всего и вся: раскидать юзеров по сегментам, определить товары в группы, присвоить сегменты странам. Да что только не придумаешь.
▶️ Кластеризация похожа по своей сути, но работает от обратного, вычислить какие популярные сегменты (кластеры) вырисовываются в твоих данных.
▶️ Предиктивные модели часто помогают держать руку на пульсе. Но с ними тоже не всё так однозначно, часто прогнозы могут сильно косячить, поэтому не увлекайся.
О разных алгоритмах ML в контексте задач мы тоже как-нибудь поговорим.
p.s. Картинку не какую хотели, а какую заслужили, предоставил мой кореш DALL-E
👍12
📌 Необходимые навыки
Какие знания и навыки необходимы продуктовому аналитику в большей степени?
Когда я только учился профессии, у меня голова взрывалась от объёмов поглощаемых знаний. Чего там только нет, и всё надо уметь.
Стартер пак, must have для любого специалиста:
▶️ Статистика. Без понимания статистики никуда. Меры тенденции, распределения, критерии, ЦПТ, p-value — всё это ежедневно фигурирует в работе.
▶️ SQL. Основа основ, без знания языка будет очень сложно получить данные для анализа, построить отчёт, работать с ad-hoc задачами. В работе используется даже чаще статистики, сложно вспомнить хотя бы один день, когда я не лез в базу.
▶️ Python/R. Скриптовый язык нужен как минимум для собесов. На практике я встречал аналитиков, которые не владели языком, но умудрялись решать задачи с помощью таблиц. Но хорошим аналитиком без скриптового языка стать нельзя. Он нужен для очистки и обработка данных, построения моделей и расчётов экспериментов. Любой анализ, сложнее EDA быстрее и проще реализовать через скриптовый язык.
▶️ Аналитическое мышление. Навык, который хорошо развивается с опытом. Понимание причинно-следственных связей, умение отследить и понимать логику происходящего.
И штуки чуть менее базовые, но не менее важные:
▶️ Юнит-экономика. Нужно разбираться в метриках, все аналитические артефакты на них завязаны. Существует целый список базовых метрик, которые исторически сформировались (типа CR, Retention, Aquisition, ARPU, LTV и тд.), но от продукта к продукту никто не запрещает придумывать свои. Когда я начинал, я был уверен что это высечено в граните и пытался их зазубрить 😅
▶️ Визуализация. Важно знать основной набор графиков и понимать какой из них лучше показывает то, что ты хочешь показать. Полезно уметь строить правильные графики, что это значит обсудим когда будем подробно рассматривать BI.
▶️ АБ-тесты. 90% работы над тестом базируются на статистике, но свои нюансы, конечно, там есть.
▶️ Data mining. Умение получать идеи изничего потока сырых данных. Реализуется через SQL + Python/R.
Какие знания и навыки необходимы продуктовому аналитику в большей степени?
Когда я только учился профессии, у меня голова взрывалась от объёмов поглощаемых знаний. Чего там только нет, и всё надо уметь.
Стартер пак, must have для любого специалиста:
▶️ Статистика. Без понимания статистики никуда. Меры тенденции, распределения, критерии, ЦПТ, p-value — всё это ежедневно фигурирует в работе.
▶️ SQL. Основа основ, без знания языка будет очень сложно получить данные для анализа, построить отчёт, работать с ad-hoc задачами. В работе используется даже чаще статистики, сложно вспомнить хотя бы один день, когда я не лез в базу.
▶️ Python/R. Скриптовый язык нужен как минимум для собесов. На практике я встречал аналитиков, которые не владели языком, но умудрялись решать задачи с помощью таблиц. Но хорошим аналитиком без скриптового языка стать нельзя. Он нужен для очистки и обработка данных, построения моделей и расчётов экспериментов. Любой анализ, сложнее EDA быстрее и проще реализовать через скриптовый язык.
▶️ Аналитическое мышление. Навык, который хорошо развивается с опытом. Понимание причинно-следственных связей, умение отследить и понимать логику происходящего.
И штуки чуть менее базовые, но не менее важные:
▶️ Юнит-экономика. Нужно разбираться в метриках, все аналитические артефакты на них завязаны. Существует целый список базовых метрик, которые исторически сформировались (типа CR, Retention, Aquisition, ARPU, LTV и тд.), но от продукта к продукту никто не запрещает придумывать свои. Когда я начинал, я был уверен что это высечено в граните и пытался их зазубрить 😅
▶️ Визуализация. Важно знать основной набор графиков и понимать какой из них лучше показывает то, что ты хочешь показать. Полезно уметь строить правильные графики, что это значит обсудим когда будем подробно рассматривать BI.
▶️ АБ-тесты. 90% работы над тестом базируются на статистике, но свои нюансы, конечно, там есть.
▶️ Data mining. Умение получать идеи из
👍12
This media is not supported in your browser
VIEW IN TELEGRAM
Я уже пару раз упомянул EDA (exploratory data analysis), обзорный анализ данных на твоей выгрузке. И если ты используешь в работе язык R, поделюсь инструментом, который я часто использую для EDA.
Постараюсь не забывать помечать такие рекомендации тегом #инструменты
Постараюсь не забывать помечать такие рекомендации тегом #инструменты
👍3
📌 Python или R
Хотел бы я чтобы этот вопрос был холиварным, но, к сожалению, мы п-R-оигрываем.
Мы знаем, что скриптовый язык это наш хлеб. В профессии популярны два языка, новомодный Python и олдскульный R. В чем разница и какой выбрать?
Думаю не стоит объяснять про Python, ты итак в курсе что это самый быстроразвивающийся и востребованный язык в сфере.
Поэтому если кратко — на старте выбирай Python.
А вот про R ты мог и не знать. Исторически он пришел из сферы фармацевтики, науки и библиотечного дела (what?). Это скриптовый язык с уклоном в статистику. У него из коробки, без всяких дополнительных пакетов, присутствует огромная база статистических методов. А если с пакетами, то за всю свою карьеру я лишь 2 раза столкнулся с задачами, которые было сильно проще решить с помощью Python (это алгоритм цепей Маркова и предиктор Catboost от Яндекса, который поддерживает R, но там даже документация не воспроизводится 🙂).
R прекрасно себя показывает в рисёрчах и расчётах экспериментов.
Если ты уже на чём-то писал, то синтаксис типа:
— может резануть глаз.
В РФ про R даже слышали не все аналитики, но в Европе и США он, до недавнего времени, был популярнее Python’а.
К тому же у него классный IDE — R Studio, красивейшие отчёты в markdown на базе Quarto, а фреймворк Shiny абсолютная реактивная киллфича.
Из минусов его работа с ML, он жрёт память как не в себя на миллионах строк. Да, Python тоже, но если я не могу завести модель на R из-за проблем с памятью, я просто иду в Python и завожу её там. Обычно помогает 🙂
Но главная проблема R это его непопулярность. С ним тупо сложнее найти работу. HR-фильтры требуют Python, не вникая в тот факт, что скриптовый язык аналитика чаще всего не интегрирован в поток разработки отдела, и что ты используешь это твоё дело. Хотя иногда и правда, команды могут, например, синхронить наработки в каком-нибудь Google Collab, который не поддерживает 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.
Но в целом, со временем, никто не запрещает использовать оба языка для разных типов задач.
👍3🤔3🔥1
📌 Грейды в аналитике
Давайте разберёмся с грейдами. Что это вообще такое и какие у них требования.
Тут мы опустим грейдирование разработки, т.к. у них там своя атмосфера, у нас своя.
Много раз сталкивался с мнением, что грейд можно вычислить по количеству лет опыта. И в целом так оно и есть. Но, как говорят в твиттере, есть нюанс.
Для любого грейда нужно знать и уметь ряд вещей, это понятно, но в большей степени он зависит от уровня уверенности в задачах с минимальными вводными. А этот скилл приходит с опытом.
Вот допустим, джун. Ему нужно уметь пользоваться базовым инструментарием, иначе он просто ничего не сможет сделать (а это уже стажёр или что-то из этой серии). Вот джун получает таску (обычно это какие-то не сложные вещи, типа выгрузки и очистки данных). Т.к. у джуна мало опыта, он может неосознанно наделать ошибок, считая свою логику верной. И она, конечно, может быть верной, но в аналитике можно легко изменить выводы, если упустить какую-то неочевидную деталь, например, из-за недостаточного погружения в данные. Поэтому обычным флоу работы джуна будет отправка работы на ревью более опытному коллеге.
Чем больше ты погружаешься в нюансы, тем чаще твои ревью проходят быстро с комментариями “всё ок”. Ты начинаешь брать задачки более неоднозначные, например, исследования. Когда ты точно не знаешь что нужно сделать, но имеешь вектор, например, разобраться с какой-то фичей. Ты изучаешь её, прикидываешь как она влияет на продукт, общаешься с заказчиками, формируешь представление. И вот уже вырисовывается план действий. Незаметно джун стал миддлом.
Ключевое отличие сеньора, в этой иерархии, это не только и не столько хард скиллы, сколько умение работать по абстрактным задачам, когда ты понимаешь что нужно бизнесу и как этого добиться.
На картинке пример как обычно ставят одну и ту же простую задачу разным грейдам 🙂
Давайте разберёмся с грейдами. Что это вообще такое и какие у них требования.
Тут мы опустим грейдирование разработки, т.к. у них там своя атмосфера, у нас своя.
Много раз сталкивался с мнением, что грейд можно вычислить по количеству лет опыта. И в целом так оно и есть. Но, как говорят в твиттере, есть нюанс.
Для любого грейда нужно знать и уметь ряд вещей, это понятно, но в большей степени он зависит от уровня уверенности в задачах с минимальными вводными. А этот скилл приходит с опытом.
Вот допустим, джун. Ему нужно уметь пользоваться базовым инструментарием, иначе он просто ничего не сможет сделать (а это уже стажёр или что-то из этой серии). Вот джун получает таску (обычно это какие-то не сложные вещи, типа выгрузки и очистки данных). Т.к. у джуна мало опыта, он может неосознанно наделать ошибок, считая свою логику верной. И она, конечно, может быть верной, но в аналитике можно легко изменить выводы, если упустить какую-то неочевидную деталь, например, из-за недостаточного погружения в данные. Поэтому обычным флоу работы джуна будет отправка работы на ревью более опытному коллеге.
Чем больше ты погружаешься в нюансы, тем чаще твои ревью проходят быстро с комментариями “всё ок”. Ты начинаешь брать задачки более неоднозначные, например, исследования. Когда ты точно не знаешь что нужно сделать, но имеешь вектор, например, разобраться с какой-то фичей. Ты изучаешь её, прикидываешь как она влияет на продукт, общаешься с заказчиками, формируешь представление. И вот уже вырисовывается план действий. Незаметно джун стал миддлом.
Ключевое отличие сеньора, в этой иерархии, это не только и не столько хард скиллы, сколько умение работать по абстрактным задачам, когда ты понимаешь что нужно бизнесу и как этого добиться.
На картинке пример как обычно ставят одну и ту же простую задачу разным грейдам 🙂
👍8😁6🔥3
📌 Нейросети заменят аналитиков?
Обсудим холиварную тему? 😈
Я в работе часто использую нейронки, в основном это GPT и Copilot, а иногда под узкую задачу можно и свою написать. Они, в большинстве случаев, хорошо справляются с генерированием несложного кода, а иногда даже и сложного.
Удобно закинуть им образец датасета и провести какую-то базовую обработку — поменять типы данных, трансформировать в long-формат, или накидать функцию для очистки выбросов. С этим они, как правило, справляются быстро и почти без косяков.
Ещё использую как их как взгляд со стороны, иногда задача бывает настолько унылая, что мозг блокирует возможность включиться в неё. Тут тоже удобно скормить её сетке и построить план анализа. С этой задачей они справляются хуже кода, так как не в курсе контекста и ограничений. Но иногда их поток бредовых рассуждений может натолкнуть тебя на какие-то мысли, а это уже победа.
Но самое больное, это их попытки тебе угодить, когда ты спрашиваешь про теорию. И это прям опасно:
Да, это просто стадия развития пока такая, и когда-нибудь они начнут отрабатывать верно с первого раза (но это не точно). Кроме того, нейронки пока не умеют выполнять код, а значит и понимать результаты.
Но у аналитиков есть козырь, который вообще не перекрывается — понимание контекста анализа. Написание кода — это малая часть полноценного анализа. Чтобы сетка сделала то что нужно, ей нужен грамотный пилот, который сам понимает чего хочет. Без пилота вся эта мощь бесполезна, а с ней она не закрывает и половины работы.
К сожалению или к счастью, кроме аналитика, мало кто может взять на себя эту роль.
Обсудим холиварную тему? 😈
Я в работе часто использую нейронки, в основном это GPT и Copilot, а иногда под узкую задачу можно и свою написать. Они, в большинстве случаев, хорошо справляются с генерированием несложного кода, а иногда даже и сложного.
Удобно закинуть им образец датасета и провести какую-то базовую обработку — поменять типы данных, трансформировать в long-формат, или накидать функцию для очистки выбросов. С этим они, как правило, справляются быстро и почти без косяков.
Ещё использую как их как взгляд со стороны, иногда задача бывает настолько унылая, что мозг блокирует возможность включиться в неё. Тут тоже удобно скормить её сетке и построить план анализа. С этой задачей они справляются хуже кода, так как не в курсе контекста и ограничений. Но иногда их поток бредовых рассуждений может натолкнуть тебя на какие-то мысли, а это уже победа.
Но самое больное, это их попытки тебе угодить, когда ты спрашиваешь про теорию. И это прям опасно:
— Эй, GPT, для t-критерия нужно равномерное распределение?
— Да, всё верно, нужно.
— Но ведь не нужно, это миф из-за косяка перевода источника.
— Да, вы правы, оно не нужно.
— Но ведь нужно равномерное распределение выборочных средних!
— Да, простите за ошибку, оно всё же нужно.
Да, это просто стадия развития пока такая, и когда-нибудь они начнут отрабатывать верно с первого раза (но это не точно). Кроме того, нейронки пока не умеют выполнять код, а значит и понимать результаты.
Но у аналитиков есть козырь, который вообще не перекрывается — понимание контекста анализа. Написание кода — это малая часть полноценного анализа. Чтобы сетка сделала то что нужно, ей нужен грамотный пилот, который сам понимает чего хочет. Без пилота вся эта мощь бесполезна, а с ней она не закрывает и половины работы.
К сожалению или к счастью, кроме аналитика, мало кто может взять на себя эту роль.
👍11😎4🔥3👎1😁1
📌 Взаимодействия внутри команды
Итак, мы потихоньку строим портрет продуктового аналитика.
Мы уже понимаем что он умеет и какие задачи выполняет. Давай поговорим про его интеграцию в команду.
Есть две популярные структуры внутри IT-компаний:
1️⃣ Горизонтальная — когда у вас есть обособленный отдел аналитики, который обслуживает интересы остальных команд. Плюсы такой структуры в том, что каждый аналитик может взять разные задачи и быть в контексте всей работы всех департаментов. Минусы — экспертиза не глубокая.
2️⃣ Вертикальная — более популярная, и как по мне, более оптимальная — когда у вас есть отдел аналитики, но он номинальный, в основном юниты раскиданы по своим командам. Т.е. продуктовый аналитик состоит в команде разработки продукта, маркетинговый в маркетинге и т.д. Из плюсов — глубокая экспертиза, из минусов — такой чел становится единственным источником знаний своего куска продукта (документация ахахаха, не слышал).
В вертикальной структуре аналитик полностью сосредоточен на своей части продукта, исследует её, улучшает и тестирует. Его главные союзники тут — продакт менеджер команды, проджекты, дизайнер и лиды разработки.
Почти всё общение сводится к продакту. Он генерит идеи, ставит таски и рассказывает о грядущих планах. С ним ты обсуждаешь свои идеи и планируешь всю работу. Хороший продакт всегда будет за тебя топить, ты его прикрытие для защиты задницы перед оунерами. Обсуждение идей продакта, подкрепленных твоими цифрами редко вызывает долгие дискуссии.
Дизайнер и лиды разработки для тебя больше консультанты. В любом исследовании тебе сначала нужно собрать как можно больше контекста задачи, а у этих ребят он самый полный.
А ещё хорошие отношения с разработкой гарантируют тебе приоритеты в задачах на разметку, а как мы раньше обсуждали, это никому, кроме тебя, не нужно.
Итак, мы потихоньку строим портрет продуктового аналитика.
Мы уже понимаем что он умеет и какие задачи выполняет. Давай поговорим про его интеграцию в команду.
Есть две популярные структуры внутри IT-компаний:
1️⃣ Горизонтальная — когда у вас есть обособленный отдел аналитики, который обслуживает интересы остальных команд. Плюсы такой структуры в том, что каждый аналитик может взять разные задачи и быть в контексте всей работы всех департаментов. Минусы — экспертиза не глубокая.
2️⃣ Вертикальная — более популярная, и как по мне, более оптимальная — когда у вас есть отдел аналитики, но он номинальный, в основном юниты раскиданы по своим командам. Т.е. продуктовый аналитик состоит в команде разработки продукта, маркетинговый в маркетинге и т.д. Из плюсов — глубокая экспертиза, из минусов — такой чел становится единственным источником знаний своего куска продукта (документация ахахаха, не слышал).
В вертикальной структуре аналитик полностью сосредоточен на своей части продукта, исследует её, улучшает и тестирует. Его главные союзники тут — продакт менеджер команды, проджекты, дизайнер и лиды разработки.
Почти всё общение сводится к продакту. Он генерит идеи, ставит таски и рассказывает о грядущих планах. С ним ты обсуждаешь свои идеи и планируешь всю работу. Хороший продакт всегда будет за тебя топить, ты его прикрытие для защиты задницы перед оунерами. Обсуждение идей продакта, подкрепленных твоими цифрами редко вызывает долгие дискуссии.
Дизайнер и лиды разработки для тебя больше консультанты. В любом исследовании тебе сначала нужно собрать как можно больше контекста задачи, а у этих ребят он самый полный.
А ещё хорошие отношения с разработкой гарантируют тебе приоритеты в задачах на разметку, а как мы раньше обсуждали, это никому, кроме тебя, не нужно.
👍10❤1
This media is not supported in your browser
VIEW IN TELEGRAM
В который раз натыкаюсь, но всегда смешно)
😁12😢3😐1
Предлагаю на следующей неделе плотно пройтись по типам задач продуктового аналитика. Что было бы интереснее разобрать в первую очередь? (можно несколько выбрать)
Final Results
49%
Продуктовые рисерчи
36%
Разметка
54%
АБ-тесты
26%
Юнит-экономика
28%
BI, графики, дашборды
3%
Меня вообще другое интересует, ща напишу!
📌 Корреляция и причинно-следственная связь
Перед тем, как мы нырнём в долгий разговор про АБ, закину небольшую мысль, которую всегда нужно помнить.
В исследованиях, датамайнинге и анализе тестов часто применяется метод поиска корреляций (это взаимоотношение переменных, когда изменение одной ведёт к изменению другой).
Продакты и не очень опытные аналитики любят интерпретировать корреляцию как причинно-следственную связь. Иногда это, скорее всего, так и есть — мы увеличили цену товара и его стали реже покупать. Звучит логично.
Но так бывает не всегда. Чаще как раз причинно-следственные связи не очевидны. Статистика и аналитика в целом не так уверенно справляется с поиском причинности, как бы это сделал, например, твой астролог.
Если твой банк никогда не грабили, вряд ли хорошей идеей будет уволить охранников ради экономии бюджета 🧐.
В контексте АБ это стоит помнить при выборе метрик оценки (про дизайн теста и выбор метрик мы отдельно поговорим дальше) — нельзя просто взять точку на корреляционной кривой и менять одну её составляющую, в надежде поменять вторую. А вот сформировать гипотезу на её основе можно, и даже рекомендуется.
В аналитике “официально” эта идея закреплена в законе Гудхарта:
И замечании Лукаса:
Да, существуют специальные методы, направленные на решение этой задачи, например, мой любимый вектор Шепли, но когда твой продакт пытается вынести причинность из корреляции, всегда добавляй “но это не точно”.
И сам так никогда не делай, а то можно очень далеко уйти по ложному следу.
Перед тем, как мы нырнём в долгий разговор про АБ, закину небольшую мысль, которую всегда нужно помнить.
В исследованиях, датамайнинге и анализе тестов часто применяется метод поиска корреляций (это взаимоотношение переменных, когда изменение одной ведёт к изменению другой).
Продакты и не очень опытные аналитики любят интерпретировать корреляцию как причинно-следственную связь. Иногда это, скорее всего, так и есть — мы увеличили цену товара и его стали реже покупать. Звучит логично.
Но так бывает не всегда. Чаще как раз причинно-следственные связи не очевидны. Статистика и аналитика в целом не так уверенно справляется с поиском причинности, как бы это сделал, например, твой астролог.
Если твой банк никогда не грабили, вряд ли хорошей идеей будет уволить охранников ради экономии бюджета 🧐.
В контексте АБ это стоит помнить при выборе метрик оценки (про дизайн теста и выбор метрик мы отдельно поговорим дальше) — нельзя просто взять точку на корреляционной кривой и менять одну её составляющую, в надежде поменять вторую. А вот сформировать гипотезу на её основе можно, и даже рекомендуется.
В аналитике “официально” эта идея закреплена в законе Гудхарта:
Когда мера становится целью, она перестаёт быть хорошей мерой.
И замечании Лукаса:
Взаимосвязи, наблюдаемые в исторических данных, не могут считаться структурными или причинными.
Да, существуют специальные методы, направленные на решение этой задачи, например, мой любимый вектор Шепли, но когда твой продакт пытается вынести причинность из корреляции, всегда добавляй “но это не точно”.
И сам так никогда не делай, а то можно очень далеко уйти по ложному следу.
👍9🤯2🔥1
Фан-факт:
Это тебе мотивашка на будущее, когда ты будешь проводить тесты и переживать что они какие-то не правильные. Это нормально, у всех так, с тобой тоже всё ок.
И помни: не найти полезной информации в данных — это найти полезную информацию о её отсутствии.
#funfact
8 из 10 АБ-тестов не показывают статистической значимости.
Это тебе мотивашка на будущее, когда ты будешь проводить тесты и переживать что они какие-то не правильные. Это нормально, у всех так, с тобой тоже всё ок.
И помни: не найти полезной информации в данных — это найти полезную информацию о её отсутствии.
#funfact
❤8👍5
📌 1. Интро
По результатам опроса, в ближайшие 2 недели мы поговорим про АБ-тесты:
- обсудим как к ним готовиться,
- откуда брать идеи,
- как документировать дизайн эксперимента,
- затронем основные статистические понятия по теме,
- рассмотрим реализации самых популярных тестов,
- и в теории пробежимся по менее используемым, про которые тоже хорошо бы знать.
⚡️ В конце, при желании, порешаем реальный тест.
И в качестве введения в тему, немного теории — что это вообще такое и зачем оно надо⬇️
Смысл АБ довольно прост: мы делим юзеров на несколько групп (этот процесс называется сплитование), в одной ничего не трогаем — это наш контроль, в других что-то меняем. Сравниваем, и принимаем решение как лучше.
АБ-тесты пока являются лучшим и самым популярным решением для проверки гипотез. Каждая, уважающая себя, продуктовая команда использует тесты.
Доставай тетрадочку, на курсах тебе такого не расскажут 🙂
#ABtest
По результатам опроса, в ближайшие 2 недели мы поговорим про АБ-тесты:
- обсудим как к ним готовиться,
- откуда брать идеи,
- как документировать дизайн эксперимента,
- затронем основные статистические понятия по теме,
- рассмотрим реализации самых популярных тестов,
- и в теории пробежимся по менее используемым, про которые тоже хорошо бы знать.
И в качестве введения в тему, немного теории — что это вообще такое и зачем оно надо
Смысл АБ довольно прост: мы делим юзеров на несколько групп (этот процесс называется сплитование), в одной ничего не трогаем — это наш контроль, в других что-то меняем. Сравниваем, и принимаем решение как лучше.
АБ-тесты пока являются лучшим и самым популярным решением для проверки гипотез. Каждая, уважающая себя, продуктовая команда использует тесты.
В этой серии постов мы опустим нюансы разработки платформы для тестирований, т.к. обычно этим занимаются дата-инженеры или команда разработки продукта. Обсудим только нашу часть.
Доставай тетрадочку, на курсах тебе такого не расскажут 🙂
#ABtest
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉9👍7🔥3
📌 2. Дизайн теста, ч.1
Тест, по определению, проверяет какую-то идею. По умному эта идея называется гипотезой.
📎 Гипотезы могут появляться просто как идеи или их может приносить команда (продакты, проджекты или дизайнеры), но чаще гипотезы вытекают из твоих рисёрчей. Когда ты исследуешь какую-то проблему или анализируешь фичу, хорошим тоном считается в выводах описать идеи по решению проблемы или улучшению фичи. Вот эти идеи — уже гипотезы.
Когда гипотеза ясна, первым шагом в подготовке теста является документирование. В аналитическом сообществе мы называем этот артефакт дизайном теста (ДТ).
ДТ должен включать в себя несколько важных пунктов. Обычно, в новой компании я приучаю заказчиков заполнять свою часть ДТ, если гипотеза от них.
Эту часть заполняет заказчик гипотезы⬇️
1️⃣ Гипотеза.
Тут мы описываем суть идеи, что хотим поменять и зачем.
2️⃣ Описание вариантов.
Что меняем в тестовом варианте. Иногда, в зависимости от твоей системы, нужно проставить id вариантов перед стартом, это ты уже потом в доку добавишь.
3️⃣ Чего ожидаем от теста.
Ожидаем больше заказов или хотим увеличить возвращаемость, повысить средний чек и т.д. Эта инфа тебе понадобится чуть дальше, при выборе метрик.
4️⃣ Ограничения.
Если есть, тут стоит указать. Проводим только на определённом гео или платформе и т.д.
#ABtest
Тест, по определению, проверяет какую-то идею. По умному эта идея называется гипотезой.
Кстати, генерирование гипотез по итогам рисёрча отличает хорошего аналитика от не. Новички, как правило, вообще не заморачиваются с выводами. Итак таблицы есть — заказчик разберётся (спойлер — не разберётся).
Когда гипотеза ясна, первым шагом в подготовке теста является документирование. В аналитическом сообществе мы называем этот артефакт дизайном теста (ДТ).
ДТ должен включать в себя несколько важных пунктов. Обычно, в новой компании я приучаю заказчиков заполнять свою часть ДТ, если гипотеза от них.
ДТ все заполняют по разному, кто как. Структура, которую я покажу здесь, моя авторская, я начинал её делать года 4 назад, она постепенно эволюционировала, и вот финальная версия на сегодня. Моим командам нравится, пользуйтесь и в своих 🙂
Эту часть заполняет заказчик гипотезы
Тут мы описываем суть идеи, что хотим поменять и зачем.
Что меняем в тестовом варианте. Иногда, в зависимости от твоей системы, нужно проставить id вариантов перед стартом, это ты уже потом в доку добавишь.
Ожидаем больше заказов или хотим увеличить возвращаемость, повысить средний чек и т.д. Эта инфа тебе понадобится чуть дальше, при выборе метрик.
Если есть, тут стоит указать. Проводим только на определённом гео или платформе и т.д.
#ABtest
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20
📌 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 выборка считается функцией
1️⃣ 1️⃣ Расчёт сроков теста.
На основании рассчитанных объёмов выборки и средних показателей трафика можно прикинуть сроки проведения теста. Есть нюансы — тест не должен быть короче 1 полной недели, чтобы включить выходные. Если тест слишком долгий, попробуй увеличить MDE.
1️⃣ 2️⃣ Добавление в трекинг.
Если нужно, можно добавить новые ивенты в разметку, особенно когда тестируем новую фичу. Как минимум нужна индикация, что юзер увидел фичу. Ивенты на новой фиче ещё могут помочь понять воронку и прибавить ещё гипотез, даже если тест не даст положительных результатов. Например, можно будет понять ошибки в дизайне фичи, и перезапустить тест после их исправления.
Вот здесь можно посмотреть пример заполненного дизайна: ПРИМЕР ДИЗАЙНА ТЕСТА
#ABtest
Дальше ты берёшь наработки заказчика и напильник, и начинаешь детализировать:
По началу будет достаточно просто выбрать метрику, на которую тест должен повлиять сильнее всего. Конверсия в регу, в покупку, средний чек, общий доход и т.д. Выбирай вдумчиво, это важный шаг. Со временем, вместо одной ключевой метрики ты придёшь к ОЕС (overall evaluation criterion), это такая штука, которая получается при взвешивании переменных. Об этом потом поговорим, тема немного сложнее чем кажется.
Укажи пару-тройку дополнительных метрик, которые тоже нужно мониторить, но они чуть менее важны чем ключевая. Не перебарщивай с набором метрик, бери только важное, иначе утонешь в интерпретации ☝️
Как базу обычно берут среднее, а вариативность это стандартное отклонение. Не бери большой период, 2-4 недели истории будет достаточно. Нужно чтобы значения были свежими.
Наши ожидаемые изменения ключевой метрики по итогам теста. Это никак не вычисляется, обычно на опыте просто 🙂
Например, мы хотим провести тест на конверсию, мы верим в гипотезу, она разрывная. Наша конверсия обычно 5%, мы хотим поднять её тестом до 7%. Вот эта разница и есть MDE. Указывать можно как в % так и в п.п. (проц. пунктах). Чем ниже MDE, тем дольше проводить тест, но тем выше вероятность получить стат. значимый результат. Если мы слишком завысим MDE, то тест будет быстрым, но скорее всего, не значимым.
Так как понять какой MDE брать? Обычно эффект никто не валидирует (потому что далеко не во всех компаниях развита культура тестов), но я поклонник метода через сигмы — MDE не должен быть выше 2-3 стандартных отклонений, это снижает реалистичность, MDE ниже одного отклонения, возможно, слишком мал и тест может затянуться. Тут надо балансировать. Вернемся к этому в п.11
У нас есть всё что нужно для расчёта размеров теста: базовая метрика и MDE. Ещё в настройках указывают доверительный уровень (0.05), мощность (0.8) и направление (”two.sided”). Обычно их редко меняют без серьезных оснований, чаще ставят дефолтные. В R выборка считается функцией
power.prop.test(), в Python statsmodels.NormalIndPower(). В конце поста ссылка на пример.На основании рассчитанных объёмов выборки и средних показателей трафика можно прикинуть сроки проведения теста. Есть нюансы — тест не должен быть короче 1 полной недели, чтобы включить выходные. Если тест слишком долгий, попробуй увеличить MDE.
Если нужно, можно добавить новые ивенты в разметку, особенно когда тестируем новую фичу. Как минимум нужна индикация, что юзер увидел фичу. Ивенты на новой фиче ещё могут помочь понять воронку и прибавить ещё гипотез, даже если тест не даст положительных результатов. Например, можно будет понять ошибки в дизайне фичи, и перезапустить тест после их исправления.
Вот здесь можно посмотреть пример заполненного дизайна: ПРИМЕР ДИЗАЙНА ТЕСТА
#ABtest
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍7