Приветики, меня зовут Пётр и я продуктовый аналитик с коммерческим опытом в ПА около 12 лет. В моей работе глобально задачи делятся на 3 типа — разметка событий, аб‑тесты и продуктовые рисерчи.

Про разметку я уже писал тут https://habr.com/ru/articles/785320/

Под аб‑тесты мы с корешами собрали коммерческий воркспейс. Было тут: https://habr.com/ru/articles/1064034/

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

Приветики, меня зовут Петр и я алкоголик работаю продуктовым аналитиком вот уже лет 12 наверное. Мои основные профили это продуктовые рисерчи и эксперименты, причём тестирования в последние годы получается сильно больше.

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

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

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

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

Пожалуй, чаще всего, мне приходится работать с разного рода исследованиями. В отдельную категорию можно выделить исследования интерфейсных решений, отдельных фичей или механик продукта. Это могут быть как новые релизы, так и старые фичи, до которых у команды раньше не дотягивались руки. Основной вопрос в таких задачах звучит примерно так: "Нравится ли юзерам то, что мы сделали, и приносит ли это нам деньги?"

Чем больше подобных задач я переделывал, тем яснее вырисовывались общие паттерны такого анализа. В итоге у меня сформировался небольшой “фреймворк”, который помогает наметить план детального исследования и не сложно адаптируется под разные продукты с разной спецификой.

Тут я расскажу о нём в общих чертах.

Привет, я работаю в сфере уже около 10 лет, преимущественно по специальности чистой продуктовой аналитики. Иногда я оглядываюсь назад и думаю — с текущим пониманием что и как устроено в работе, как бы я выстраивал свой процесс обучения с нуля?

Эта статья — мои мысли на эту тему. В каком порядке и какие материалы впитывать, чтобы потом комфортно себя чувствовать в любой продуктовой компании.

Из челленджей — все материалы должны быть бесплатными, или достаточно дешёвыми, чтобы была возможность бросить учёбу на пол пути (ну не зашло, бывает) и не жалеть о потраченных деньгах на мега-курс от %big_tech_name%.

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

По итогам всех усвоенных материалов, это будет уровень знаний примерно middle+, но фактически, грейды зависят больше от опыта (особенно в программировании), чем от объёма знаний.

И последнее — я тут не пытаюсь продать курсы, поэтому обещать что будет весело, интересно и быстро, а потом вас наймут на 300к/наносек я не буду. Будет долго, местами сложно, иногда душно, пару раз вы захотите слиться и бросить эту идею. Но… нет, тут не будет но 🙂

Ладно, пожалуй хватит предисловия, поехали.

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

Осложняет дело ещё и тот факт, что кроме вас это никому не нужно.

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

Погнали 🙂

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

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

Тут я хочу поделиться порядком действий, если хочешь — чек-листом, как я провожу аналитические исследования.

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

Так получилось, что за всё время, что я использую в работе R, мне не доводилось рендерить markdown-файлы в формат PDF. Иногда я хранил наработки просто в фалах .R, а исследования оформлял в Google Docs, накидывая туда скринов из viewer-а. Иногда это был рендер в .html, с интерактивной графикой, или проекты Shiny в облаке Posit. Да мало ли вариантов.

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

“Дело-то не хитрое, просто меняем формат вывода в markdown” — подумал я. Однако всё оказалось не так просто: и тексты и ggplot не видят кириллицу, движок xelatex не находит кастомные шрифты, LaTeX вообще всё бесит.

Каждая проблема отдельно худо-бедно гуглится или решается через chatGPT, но намного больше информации как посадить markdown-PDF на китайский, чем на кириллицу.

Рассмотрим на примере классического markdown, а в конце реализация для Quarto.