📌 Как я "вкатился"

Кулстори как я врывался в этот ваш ИТ.

Присаживайтесь поудобнее, мы тут надолго 😅

Мой карьерный путь начался после ухода со специальности “Электростанции” Энергетического факультета, в качестве электрика в 2010-м. В электрике я задержался недолго, и по какому-то стечению обстоятельств меня занесло в монтаж оптоволокна к одному подрядчику Ростелекома. Там меня определили спайщиком. Работа была интересная, Fujikura в сердечке ❤️

Но как-то, сидя зимой на какой-то крыше и распаивая кросс, за 15к рублей в месяц, я подумал о работе в офисе. А чё, сидишь там, кофе пьёшь в тепле. Кайф. Погуглил что там доступно у нас в городе, и принял решение попробовать этот ваш ИТ. В то время диковинный.

В коммерческую аналитику я пошёл не сразу, до этого начинал с фронт-энда, который в те времена назывался просто вёрсткой. Учился я на это дело по видосам и статьям в интернете, не долго, месяц может. Это вам не современные реактивные фреймворки, тогда самой крутой технологией был jQuery, а для крепкого фуллстека было достаточно знать HTML, CSS, JS и PHP.

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

Как-то я смотрел какой-то видос из блога AIC, это был ролик с Виталиком Черемисиновым. Он там дико грузил терминами и до меня дошло — аналитическое сопровождение вашего сайта! Гениально. Это ж не продукт полноценный, подумал я, че там делов-то, прикрутил метрику, конверсии туда-сюда, изи. И так, в общем-то и было. Клиенты знать не знали про такие чудеса, а когда мы просто прокатывали рандомные АБ-тесты через калькуляторы, да ещё и умудрялись растить там какие-то циферки, они были довольны.

Меня это всё дело увлекло и я решил разобраться предметнее. Нагуглил что вообще надо знать (отдельным квестом было собрать такую инфу, медийных аналитиков было полтора человека, а структурированных статей не было вообще) и начал со статистики. Первым был какой-то учебник по курсу универской статистики, дико душный, но основательный. По метрикам я читал Красинского, и в целом следил за блогом Черемисинова. Кучу всякой ненужной фигни впитывал, очень много уделил времени качественным исследованиям, которые в дальнейшей практике применял всего пару раз 🙂

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

Меня приняли тут же. Оказалось, мой отклик был у них вторым за 2 месяца, а первым был дизайнер, который спросил что такое CJM.

На работе никто понятия не имел зачем я нужен. Да и я тоже не особо. Пилил какой-то дашборд в амплитуде, ходил по офису с важным видом, сыпал терминами типа “выборка” и “распределение”, ловил за это восторженные взгляды и учил R по книге великого Хэдли Уикема. За бешенные деньги тогда, 50к рублей.

О питоне в то время и речи не шло, он не был привычным языком аналитиков на Руси. Да, всякие numpy-scipy появились в 2006-2008, но популярными у нас они стали сильно позже. Я так и вообще не слышал о таких, хотя целенаправленно копался в той части интернета.

А потом начали набирать популярность всякие курсы. Мне очень помог в своё время курс скиллбокса “UX-аналитик”, он вышел одним из первых. Вели его нынешние отцы EXPF — Искандер Мирмахмадов и всё тот же Виталик Черемисинов. Не то чтобы курс был крутым и полным, наоборот, одна тема — один видос на 10 минут. Но он задавал вектор. Видишь тему — гуглишь книгу.

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

#кулстори

📌 12. Метод доверительных интервалов

Разберём ещё один метод расчёта АБ и потихоньку будем завершать вводную часть по этой теме.

Классический метод, который на практике я встречал не часто — оценка через доверительные интервалы (CI, confidence intervals). Он простой, хоть и не самый надёжный такой реализации.

Да, технически, интервалы в расчётах АБ заложены везде. Мы же поговорим о классике, когда построение CI это самоцель.

🧐 CI — это диапазон значений, в котором, с определённой вероятностью, находится истинное значение параметра.

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

Ограничение: CI предполагают нормальные распределения выборок и теряют в точности на малых выборках.

Пример реализации метода:

# Заводим функцию для расчёта CI
calc_ci <- function(df, cl = 0.95) {
  mean_metric <- mean(df$metric) # считаем среднее
  std_error <- sd(df$metric) / sqrt(nrow(df)) # считаем стандартную ошибку
  error_limit <- qt(cl / 2 + .5, df = nrow(df) - 1) * std_error # считаем предел погрешности
  lower <- mean_metric - error_limit # считаем нижнюю границу интервала
  upper <- mean_metric + error_limit # считаем верхнюю границу интервала
  return(c(lower, upper))
}

# Считаем CI для групп
ci_A <- calc_ci(df %>% filter(var == "A"))
ci_B <- calc_ci(df %>% filter(var == "B"))

# Заводим функцию для расчёта CI
def calc_ci(df, cl = 0.95):
    mean_metric = np.mean(df['metric']) # считаем среднее
    std_error = np.std(df['metric']) / np.sqrt(len(df)) # считаем стандартную ошибку
    error_limit = stats.t.ppf(cl / 2 + 0.5, df = len(df) - 1) * std_error # считаем предел погрешности
    lower = mean_metric - error_limit # считаем нижнюю границу интервала
    upper = mean_metric + error_limit # считаем верхнюю границу интервала
    return lower, upper

# Считаем CI для групп
ci_A = calc_ci(df[df['var'] == 'A'])
ci_B = calc_ci(df[df['var'] == 'B'])

#ABtest

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

— Формулировка закона Тваймана от К. Марш и Д. Эллиотт

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

Я раньше часто так делал, наверное, чтобы показать свою ценность. Со временем всё реже и реже, пока в голове окончательно не улеглась мысль о том, что у меня нет цели гоняться за прорывами. Суть моей работы не в том, чтобы порадовать заказчика, а в том, чтобы предоставить ему объективную картину. И лучше дважды перепроверить, чем ошибочно обнадежить 🙂

#funfact

🔗 Руководство по проведению анализа и продуктовых исследований

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

Хоть и получилось объёмно, всё равно в теме очень много нюансов и мест для манёвра. Но основной флоу описать получилось.

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

Приятного прочтения 🍿

https://habr.com/p/781466/

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

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

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

Делаем? 🙂

📌 За деньги — да? Этичность сфер.

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

Так ли важно аналитику, в какой сфере он работает (в отрыве от личных предпочтений)?

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

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

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

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

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

А насколько вам принципиально работать в социально-одобряемых продуктах? Или х2-х3 оффер от условных криптовиков интереснее? 🙂

Ровно месяц каналу 🙂

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

Специализации аналитиков
Типы продуктовых задач
Необходимые навыки
Грейды
Взаимодействия внутри команды
АБ-тесты
Испытательный срок
Продуктовые исследования

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

Если есть какие-то вопросы, по которым можно сделать пост, самое время накидать, пока январь не спланирован 🙂

#дайджест

С наступившим! 🎄🎀

Как настроение? Много новых планов на год?

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

🔗 Разметка событий

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

Приятного прочтения 🍿

https://telegra.ph/Razmetka-01-03

Я тут задумал небольшой пет-проект по поднятию простой системы аналитики только под веб пока. Суть в чем, нужно скрафтить небольшой сайт, на него повесить трекер ивентов, оттуда по API стянуть данные для ETL и сложить в БД, потом её натянуть на какой-то BI. Всё просто, но я таким не занимался никогда чтобы прям с нуля 🙂

План пока такой:

1. Взять трекер типа GA или Segment
2. Даги написать на Airflow
3. Как БД поднять Clickhouse
4. Ну с базовым BI там всё просто, тот же Redash залетит

Есть тут инженеры, насколько такой выбор оптимален? Затрат там пока видится максимум на 120$ за КХ на минимальном тарифе. Или имеет смысл хранить данные отдельно в каком-нибудь Redshift? В идеале потом ещё трекер сменить на самописный, но его сначала надо написать 😅

📌 Что значит “знать SQL”?

В одном чатике возник такой вопрос. Спектр ответов был от “знать оконки” до “писать трехэтажные запросы”.

Давай разбираться 🧐

В русскоязычном комьюнити очень сильно смещён фокус на хард скилы. Но что такое SQL по сути? Это прикладной навык, инструмент, с помощью которого ты решаешь часть задачи. Точнее — всего лишь добываешь данные для анализа.

Разгоним музыкальную метафору. Вот есть барабанщик. Его задача играть ритм в композиции. Для этого он использует палочки, которыми стучит по сету. Эти палочки и есть его SQL. Он может понять как их держать и как извлекать звук, а потом перейти, собственно, к музыке. А может годами оттачивать трюки, подкидывать их, крутить и т.д., к музыке так и не приступив. И когда он приходит в группу с таким крутым скиллом — его не берут. Потому что группе надо ритм держать, а не палочками выпендриваться.

В работе тебе никто не говорит: “достань мне из базы вот такие данные по таким колонкам и чтобы запрос был пожирнее”.

Говорят: “мы выкатили фичу, и она, кажется, не работает”.

Твоя задача намного, намного глубже — нужно определиться с критериями, что вообще значит “не работает”? А как понять что работает? Есть ли у неё перспектива? Надо ли переделывать? Тут намного больше тонкостей в аналитическом мышлении.

Все эти вопросы нужно переводить на язык данных. “Посчитаем, значит вот это, это и вон то” — можешь достать эти данные из базы, не потратив на это неделю? Поздравляю, у тебя нормальный рабочий уровень SQL 🥳

Да, некоторые вещи используются чаще — например подзапросы или CTE, джоины и оконки. Некоторые реже — какой-нибудь локальный мэппинг, lead/lag и т.д. Но это ты со временем сам обнаружишь.

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