Posts

Продуктовая аналитика: влияние продуктовых фич на ретеншн

Image
Предыдущих три поста были в сущности о том, как можно было бы разделить наши продуктовые фичи на несколько групп: core , power и casual . И делали мы это разными способами: (1) сравнивали популярность фичей с их ежедневной повторяемостью (2) сравнивали дневную интенсивность фичей с их ежедневной повторяемостью (3) применили кластеризацию к интенсивности. Давайте остановимся на минутку и спросим себя - а зачем нам вообще разделять продуктовые фичи? На самом деле, мы не случайно делили их по популярности и особенно по интенсивности. Мы хотели понять, какие фичи создают привычку повторного использования. С одной стороны, если мы посмотрим на популярность фичи (например, % MAU) мы легко можем разбить этот показатель на "новых" и "вернувшихся". Если доля вернувшихся будет условно большая и не будет падать со временем, значит можно сделать вывод, что клиенты регулярно возвращаются за этой фичей. С другой стороны, дневная интенсивность и особенно ежедневная повторяемос

Продуктовая аналитика: кластеризация интенсивности использования продукта

Image
Итак, в прошлом посте мы с вами построили Матрицу Интенсивности по двум измерениям: ежедневная повторяемость и дневная интенсивность использования.  Сегодня мы попробуем усилить этот анализ двумя способами.  Первый способ - это происпользовать персентили. Из моего опыта персентили могут быть очень мощным инструментом отделения выдающегося поведения от обыденного. И хотя Amplitude имеет опции деления матрицы по среднему или по медиане, я рекомендую делать несколько иначе.  Вы можете разбить ваше пространство фичей по измерениям интенсивности на 9 "квадрантов" по следующей логике: ключевые фичи ( Core ): все, что выше 80-й персентиля по обоим измерениям продвинутые фичи ( Power ): все, что от 50-го до 80-го персентиля по одному измерению и выше 80-й персентиля по второму измерению  казуальные фичи ( Casual ): все, что от 50-го до 80-го персентиля хотя бы по одному измерению Intensity Matrix with 50/80 percentiles (кликните, чтобы увеличить картинку) Второе, о чем хотелось бы у

Продуктовая аналитика: Матрица Интенсивности

Image
Сегодня мы продолжим тему продуктовой аналитики и обсудим вопрос интенсивности использования продуктом.  В прошлом посте я сказал, что степень вовлеченности можно измерять интенсивностью использования. И привел пример с отправкой сообщений: Клиент за месяц сгенерировал 293 события message_send_text. Клиент пользовался этой фичей 14 дней в месяц - avg_days_cnt . В среднем, он отправлял 21 сообщение в день - avg_hits_per_day . Очевидно, что общее количество событий является производной от количества дней пользования фичей и количеством совершенных действий в день. Поэтому дальше мы будем рассматривать только эти два базовых измерения. Эти 2 измерения говорят нам об абсолютно разных паттернах поведения: каких-то действий нам нужно сделать много в день, а какие-то действия нам нужно повторять много дней.  Рассматривать их отдельно не рекомендуется. Более того, только вместе они позволяют нам приоткрыть занавес и посмотреть как именно клиенты пользуются нашим продуктом.  Для этого давайте

Продуктовая аналитика: Матрица Вовлеченности

Image
Продуктовая аналитика это постоянный процесс поиска инсайтов о том, как и когда твой продукт приносит (или наоборот - не приносит) ценность клиенту. Но, оцифровать ценность это совсем нетривиальная задача и поэтому часто продуктовый анализ начинают с анализа использования продукта.  Для того, чтобы запустить в компании поведенческую аналитику очень важно собирать подходящую информацию о поведении клиентов. Здесь есть два возможных подхода: собирать сессионные данные (отслеживать визиты на страницы/экраны, отслеживать клики/нажатия) собирать событийные данные (генерировать события при пользовании функционалом продукта) Перечисленные выше подходы имеют как плюсы так и минусы, как с точки зрения скорости запуска отслеживания поведения, так и с точки зрения глубины возможных инсайтов.  Из того, что я вижу в последнее время - аналитические системы на основе событий доминируют в сегменте продуктовой аналитики (например, Amplitude, Heap). Итак, допустим вы работаете в продуктовой компании,

Drill-down: или как найти перспективную точку роста?

Image
Аналитика - это постоянный поиск сигналов. Часто аналитику приходится делать десятки срезов, прежде чем какой-то один из них окажется перспективным или хотя бы любопытным. А значит неплохо было бы найти способ, когда такой поиск можно сделать более управляемым, а в идеале - оптимальным. Недавно я наткнулся на одну статью , где описывался простой, быстрый способ находить перспективные срезы. Более того, при желании, такой подход можно автоматизировать. Любой бизнес так или иначе работает с воронками. Например, у вас есть лэндинг с формой регистрации и такой конверсией: Overall Conversion Rate. Сама по себе конверсия уже может нам что-то рассказать. Например, используя свой опыт или benchmarks мы можем сказать - мала она или велика. Также мы могли бы сравнить конверсию этого лэндинга с конверсиями других наших лэндингов.  Но, если мы хотим улучшить конверсию, нам определенно нужна другая (дополнительная) информация.  Подумав с минутку, можно прийти к мысли, что внутри этого лэндинга впол

BI-системы: ограничения или возможности?

Image
Недавно наткнулся в соц. сети на мнение (к слову весьма расхожее в последнее время), что: Python - это основной инструмент аналитика и что Аналитические системы - это негибкие инструменты На мой взгляд, чтобы разобраться в этих вопросах их стоит детализировать.  Python - основной инструмент аналитика? Python (как и R) это язык программирования. В нем есть набор функций, которые идут с дистрибутивом и есть механизм пакетов, который позволяет элегантно расширять возможности такого языка.  С этой точки зрения Python, R или любой другой язык программирования будет всегда давать больше возможностей, он априори будет более универсален.  Но, универсальность всегда имеет свою цену...  Конечный результат Для меня аналитика это процесс, который начинается всегда не с инженерии, а с описания боли заказчика, которую аналитик надеется решить. Как только заказчик озвучил свой вопрос, разумно перефразировать его своими словами, чтобы убедиться в том, что вы правильно поняли заказчика. Проделав такое

h2o - лучший друг маркетолога в машинном обучении

Image
Часто маркетологи сталкиваются с неопределенностью: им нужно оценить вероятность какого-то события, имея под рукой набор признаков относящихся к этому событию. Такая задача обычно сводится в бинарной классификации т.е. прогнозированию одного из двух возможных исходов: да или нет (1 или 0). Сегодня мы рассмотрим платформу машинного обучения  h2o . Для меня эта платформа давно уже стала эталоном того, как с минимальными усилиями (как по предобработке данных так и по моделированию и пост оценке) можно быстро делать качественное прогнозирование на данных любого масштаба. Итак, у нас есть датасет клиентов со следующими характеристиками:  Age (Возраст) Income (Доход) Subscribe (флаг: 1 - подписан, 0- не подписан) Сырые данные выглядят вот так: raw data И мы хотим построить модель машинного обучения, которая позволит: предсказать флаг Подписки, а также  оценить качество такой модели машинного обучения. 1. Что такое h2o? Это Java-платформа и веб-интерфейс для работы с задачами машинного обучен

A/B-тестирование: 3 важных принципа

Image
A/B-тестирование это мощный инструмент для роста бизнеса. Но, как и любой инструмент, в нем есть свои нюансы. Сегодня поговорим о 3-х фундаментальных принципах, которые стоит держать в уме, когда вы планируете запустить очередной эксперимент. Большие vs малые цели В вашей команде всегда есть разные идеи (гипотезы) о том, что можно было бы улучшить. Очевидно, что ресурс у вас ограничен. Вы не сможете протестировать ни одномоментно, а часто даже последовательно, все идеи вашей команды. А значит стоит подумать с чего начать.  Давайте внимательно посмотрим на картинку выше. По виду кривой нам становится понятно, что практически в любом А/B-тесте мы оперируем двумя важными понятиями: вдумчивость (когда мы хорошенько думаем и затем выбираем цель) размер выборки Если у вас малый размер выборки - тщательно обдумываете, что вы хотите протестировать.  И наоборот, если у вас очень большая выборка, то вы могли бы себе позволить тестировать какие-то мелочи.  Например, Google в свое время тестировал