Блог про аналитику

Итак, в прошлой статье мы разбирали как концептуально рассчитывается Quick Ratio . Quick Ratio полезный показатель роста продукта, но он не самодостаточный. Он позволяет определить текущий темп роста и фокусировать команды на поддержании нужного темпа роста продукта. Но, чтобы по-настоящему управлять ростом, нужно погрузиться в детали: нужно понять как правильно считать компоненты Quick Ratio, как начать мыслить развитием клиентов: кого нужно развивать, кого лучше не трогать, кого возвращать из других сегментов обратно, кого отпускать. Итак, сегодня мы начнем разговор о таком инструменте как Transition Matrix . Чтобы ввести вас в контекст я немного расскажу о бизнес-модели для которой я строил Transition Matrix. Это бизнес-модель, в которой клиент: выбирает репетитора, оформляет заявку на обучение (лид),  пополняет свой баланс (клиент),  планирует уроки на определенные даты и собственно занимается с репетитором в эти даты. Если (1) действие удачное (репетитор подходящий),

Сегодня мы продолжим тему роста и обсудим такой важный момент как рост продукта . С одной стороны, стартапы часто оценивают рост через финансовые метрики, такие как Revenue, MRR, или LTV. Это действительно важные метрики, и мы не будет здесь поддавать сомнению их важность и объективность. С другой стороны, финансовые метрики это всегда lagging indicators . Их просто посчитать, но узнать, что произойдет в будущем с их помощью затруднительно. Продукт в этой системе координат роста, обычно, не рассматривается как нечто, что можно оцифровать и объективно растить. Сегодня я поделюсь с вами несколькими идеями о том, как можно было бы оценивать рост продукта. Начнем с единицы измерения. Продукт не существует в вакууме. Чтобы продукт проносил ценность, у него должна быть точка приложения. И эта точка - клиент.  Если клиент воспользовался продуктом, то у продукта появилась возможность продемонстрировать свою полезность. Поэтому, возможно, лучшее, что мы можем сделать - это оцениват

В этом году я дважды публично рассказывал про расчет A-ha moment , до этого проходил Retention + Engagement Deep Dive от Reforge, ездил на мастер-класс North Star Metric от Amplitude. В целом, в последнее время меня волнует только один вопрос: на чем фокусировать продуктовую команду, чтобы продукт в любой момент времени приносил максимальную ценность клиенту. Ответ на этот вопрос часто лежит на стыке нескольких дисциплин, команд и ролей. С одной стороны, продуктовая команда, как правило, смотрит далеко вперед и стратегически развивает продукт. Наличие функционала, его связанность с другими фичами и общая работоспособность продукта это, как правило, основные задачи продуктовых команд. С другой стороны, команда роста (если таковая есть) сильно зафокусирована на улучшении конверсий на пути пользования продукта клиентом. Здесь акцент смещен в стороны growth hacks, A/B-тестов и других подходов, которые позволяют расширить воронку. При этом обе команды не всегда имеют время на то,

Когда-то давно, когда я только начинал разбираться со статистикой, я столкнулся с термином "p-hacking". Так как понимания базовых принципов у меня тогда еще не было, то и сама проблема "подглядывания" мне казалась весьма надуманной. Сегодня я поделюсь своим опытом того, что профессиональные статистики вкладывают в "p-hacking", почему он реален и как я вижу себе выход из этой ситуации. Начну с того, что дам ссылку на  отличную презентацию , которая обширно и подробно описывает эту проблему в статистике. Откуда берется p-hacking ? Итак, в работе с A/B-тестами у нас возможны 4 исхода: Source: www.dummies.com/education/science/biology/type-i-and-type-ii-errors-in-hypothesis-testing/ Как мы видим, в двух исходах мы принимаем верные решения, а в двух других  - нет. Т.к. при A/B-тестировании мы очень хотим не ошибиться с принимаемым решением по результатам A/B-теста, то нам важно понять, что же может пойти не так: мы можем " увидеть "

Итак, недавно у меня возникла следующая ситуация. Планировался запуск A/B-теста. Так как тест высокорисковый , то появилась мысль минимизировать риск за счет того, что в группу B направить не 50% трафика, а лишь 5%. Действую по протоколу проведения A/B-тестов нам следует  до запуска теста  выполнить два предварительных действия: оценить лифт целевого показателя оценить размер минимально необходимой выборки С первой задачей справиться несложно. Моя базовая конверсия (с1) = 2%. Лифт, который я хочу обнаружить (lift) = 5%. Итого, моя новая конверсия (с2) = c1 * (1 + lift) = 2.1%. А вот со второй задачей справиться уже несколько сложнее. Обычно для решения таких задач я использую статистический калькулятор : Sample Size Calculator; www.evanmiller.org Как мы видим, под числом 309,928 четко написано - per variation - что означает, что такой объем должен набраться для каждой группы. Дело в том, что большинство онлайн-калькуляторов делают расчет минимально необходимой

Недавно, пока я разбирался с тем, какой размер минимально необходимой выборки должен быть набран при неравномерном сплите , я наткнулся на весьма интересную статью . Дело в том, что когда мы запускаем A/B-тест, мы обычно попадаем в две крайности: мы либо вообще не берем в расчет статистическую значимость результата либо слепо равняемся на статистические догмы: p.value < 0.05 confidence level = 95% statistical power = 80% С одной стороны, в использовании статистики нет ничего плохо. Она действительно позволяет нам уйти от субъективной оценки результата, быть уверенным в том, что результат воспроизводим и не является случайностью.  С другой стороны, бизнес не существует в вакууме. И каждое принятое нами решение имеет два дополнительных параметра: время стоимость Причем, как правило, чем больше стоимость решения, тем больше времени мы готовы ждать. А на количество времени, необходимого для получения надежного результата, напрямую влияет какой confidence level м

Недавно меня пригласили на одну конференцию, где я выступал с необычной для себя темой: анализ  платных рекламных компаний. Я решил поделиться несколькими мыслями о том, как ppc-менеджеру (или его руководителю) атаковать проблему оптимизации рекламных кампаний. Хотя я сам не крутил рекламу ни в Google Adwords, ни в Яндекс.Директ, но я курировал ребят, которые занимаются этим ежедневно. А потому у меня регулярно возникали одни и те же вопросы: какие рекламные кампании стоит масштабировать ? для каких рекламных кампаний недостаточно данных (и нужно продолжать  их "крутить")? какие рекламные кампании стоит останавливать ? Итак, для простоты изложения я возьму небольшую выборку (35 рекламных кампаний).  Обычно, ppc-менеджер начинает свой анализ с рекламных кампаний, которые "съедают" больше всего бюджета. Он сортирует список рекламных кампаний от самых больших по бюджету к самым маленьким.  Как мы видим, ТОП3 рекламные кампании соответствуют 30.5% рекл

Маркетинг баз данных это мощный подход, который позволяет e-commerce бизнесам быстро понимать, что реально происходит с ростом их клиентской базы. Я часто использую подходы оттуда, чтобы сделать диагностику и выдать первые рекомендации ребятам, которые просят помощи. Ярким представителем маркетинга баз данных является RFM подход. Вы ранжируете каждого клиента по R ecency, F requency и M onetary и таким образом понимаете, какую ценность клиент принес вам на сейчас, а также, какую ценность он смог бы вам принести в будущем. Для реализации RF(M) подхода достаточно только данных о транзакциях и это его огромный плюс. Обычно с этой таблицей у бизнеса меньше всего проблем. Для оптимизации LTV (в частности - количества покупок) этого часто достаточно. Пример RF-матрицы показан ниже: RF-matrix. Из чарта выше видно, что 35.8% всех клиентов сделали свою последнюю покупку в диапазоне от 0 до 60 дней. И это отличный результат, когда одна третья базы очень свежая. Подробнее об этом

Итак, я решил продолжить транслировать решения задач показанные Алексеем Куличевским на языке  Python . В этот раз мы будем заниматься трансляцией на R задач по  агрегации и построению когорт (ссылка на оригинал поста с кодом Python) . Датасет будем использовать тот же, что и в первом посте . Original dataset. Начнем с простых агрегаций. Давайте ответим на вопрос: сколько продаж и покупок было сделано в магазине? Simple aggregations and distribution charts. Итак, первый кусок кода делает простые агрегации. Я решил сразу добавить больше агрегаций (mean, median, max) т.к. в e-commerce крайне важно понимать насколько наша аудитория чувствительна к цене . Средний чек (AOV) у нас $459. Неплохо! Но в тоже время медиана (MedOV) = $152, а это значит, что 50% всех чеков намного ниже среднего. С другой стороны, это указывает на то, что должно быть также некоторое количество чеков, которые сильно выше медианы. И такие чеки есть - максимальный чек (MaxOV) = $23661 Интересно, а с

Обычно, когда я пишу очередной пост в своем блоге, я не вставляю туда код, потому как исхожу из того, что аналитикам и маркетологам важнее новые идеи и возможные инсайты. И вот недавно крутой маркетолог и аналитик  Alexey Kulichevsky  сделал большую и интересную шпаргалку (ссылка на пост с оригинальным кодом) для аналитиков про Python. Я зачитывался блогом Леши еще в далеком 2013 году и могу с уверенностью сказать, что он один из немногих, на кого я равнялся. Леша, проделал отличную работу показывая основные конструкции на Python, которыми аналитик будет оперировать на ежедневной основе. И мне пришла в голову идея показать, как задачи описанные Лешей, можно было решить на R. Прежде, чем мы начнем я сразу скажу, что фактически существует два мира R: классический современный, который строится на философии и наборе библиотек tidyverse   Я никогда не писал на классическом R, так как мне он НЕ кажется выразительным, компактным и быстрым.  Также я отмечу, что намного удобне