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

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

Вы спокойно работаете, и тут к вам приходит продакт с вопросом по A/B-тесту, который запустили две недели назад. «Ну что, мы уже набрали достаточно трафика? Можно подводить итоги?».

И всё бы ничего, но есть нюанс: на встречу по дизайну этого эксперимента вас позвать забыли. Длительность никто не считал, MDE (Minimum Detectable Effect) не фиксировал.

Чтобы ответить на вопрос продакта, вам нужно посчитать MDE с учетом текущего размера выборки и дисперсии, а затем сравнить его с порогом практической значимости. Выгружать сырые данные только ради того, чтобы посчитать дисперсию в моменте — занятие довольно муторное, особенно если речь идет о неконверсионных (непрерывных) метриках. Даже на highload-проектах, где данных море, тратить время на лишние ETL-операции ради промежуточного чека совсем не хочется.

Но, к счастью, у вас под рукой есть A/B-платформа, которая уже услужливо посчитала доверительный интервал. Например, она показывает вам отложенный эффект: 2% ± 1.5%.

Держите лайфхак: берем половину ширины доверительного интервала (те самые 1.5%), умножаем на 1.43 и получаем наш текущий MDE.

Давайте разберем математику, которая за этим стоит.

Что такое дерево метрик и зачем оно нужно?

Привет, меня зовут Денис. Я старший продуктовый аналитик, и больше 5 лет строю системы метрик в крупных IT-компаниях, включая Тинькофф. Одна из самых частых и болезненных проблем, которую я видел — когда у команды есть цель (скажем, «увеличить выручку»), но нет единого понимания, за какие именно рычаги тянуть и как действия одного отдела влияют на результат другого.

Привет! Меня зовут Денис. Уже более 5 лет работаю Senior Product Analyst в крупнейших IT-компаниях России, включая Тинькофф. Разрабатывал системы аналитики с полного нуля, провёл огромное количество A/B тестов и знаю всю внутреннюю кухню больших корпораций изнутри.

Ко мне на карьерные консультации часто приходят с запросом в духе: «Я уже 2 года работаю, почему я всё еще джун?» или «Как прыгнуть в мидлы, если на работе дают только скучные выгрузки?».

Грейды — это не про то, сколько библиотек в Python ты выучил. Это про то, насколько сильно у твоего лида и продакта болит голова, когда они отдают тебе задачу.

В идеальном мире продуктовый аналитик запускает тест и через три дня получает статзначимый результат. В реальности мы часто видим прогноз: «Для достижения мощности 80% вам нужно крутить этот тест 45 дней». Но математику можно «обмануть» (точнее — оптимизировать), не теряя в качестве выводов.

Каждый продуктовый аналитик или менеджер рано или поздно сталкивается с A/B-тестированием. На первый взгляд всё кажется простым: разделили трафик, показали разные кнопки, сравнили цифры. Но на практике 80% успеха теста закладывается ещё до его старта — на этапе дизайна.

В этой статье мы разберем, что такое «карточка теста», почему это не про картинки и какие 8 пунктов спасут ваш эксперимент от провала.

За последние 5 лет в аналитике я прошел путь от «напишу любой джоин на салфетке» до Senior Product Analyst. А еще я менторю ребят и веду телеграм канал.

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

Как не потеряться в сотнях графиков и найти реальные рычаги влияния на бизнес? В статье представлен подробный разбор Дерева метрик на примере FoodTech-сервиса (доставки еды). Мы уходим от простого мониторинга цифр к системной декомпозиции North Star Metric.

АБ-тесты — это дорого. Как проверять гипотезы, если у вас нет времени или трафика. АБ-тестирование давно закрепилось как «золотой стандарт» проверки гипотез. Но у него есть обратная сторона: это дорого, долго и требует огромного трафика для достижения статистической значимости. Иногда бизнес просто не может позволить себе ждать месяц, чтобы узнать, что кнопка «Купить» должна быть синей.

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

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

Привет! Меня зовут Денис. Уже юолее 5 лет работаю Senior Product Analyst в крупнейших IT-компаниях России, включая Тинькофф. Разрабатывал системы аналитики с полного нуля, провёл огромное количество A/B тестов и знаю всю внутреннюю кухню больших корпораций изнутри.

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

A/B-тесты давно стали стандартным инструментом в продуктовой и маркетинговой аналитике. Но на практике большинство ошибок происходит не на этапе запуска эксперимента, а при анализе результатов. Чаще всего причина в том, что статистический метод выбирается «по привычке», без учёта типа метрики и свойств данных.

В этой статье я собрал практическую логику выбора методов анализа A/B-тестов. Без углубления в теорию, но с пониманием, почему в одном случае работает χ², а в другом t-test может привести к неверным выводам.