Привет всем, мы недавно написал о том, как мы научились управлять данными с помощью симулятора GoPractice! В этом выпуске мы продолжим тему анализа данных и поговорим о построении процесса работы с аналитикой в команде Plesk. Plesk — сложный продукт с 20-летней историей, и нам не всегда удавалось эффективно собирать необходимую статистику.
Долгое время мы смотрели на данные только ретроспективно и принимали решения, основываясь на субъективных ощущениях того, «как должно быть».
У нас уже были печальные последствия такого подхода в прошлом — в 2012 году мы изменили дизайн, желая сделать как лучше, но получили волну негативных отзывов, отказ в обновлении до последней версии продукта и отток клиентов.
Поразмыслив над этим печальным опытом, мы сделали выводы и решили двигаться к тому, чтобы стать Data Driven компанией.
На этом пути мы столкнулись с трудностями разного рода.
В целом их можно разделить на две основные группы — системные и процессные, и в этой статье я остановлюсь именно на задаче построения процесса работы с аналитикой.
Системные проблемы, связанные со спецификой коробочного продукта, достойны отдельной статьи, поэтому я не буду здесь подробно останавливаться на них, перечислю лишь наиболее существенные.
- Множество событий, большие объемы использования.
Если мы говорим только об отслеживании действий пользователей в панели, то по нашим расчетам это 60 млн событий в месяц, а платить $150 тысяч за Advanced Google Analytics жалко.
Другая сложность заключается в том, что для работы с GA необходимо явно обрабатывать каждое пользовательское действие; мы хотели получить единый механизм, не требующий вручную отмечать события или действия для каждой новой функции.
- Из-за объёма и формата коробки (выкатка любых изменений требует времени) аналитик не может работать в режиме реального времени.
Пользователи используют 8 различных версий продукта, 4 из которых уже прошли EOL. Даже на последних версиях в первые две недели после релиза новые изменения получают только 60% пользователей.
- Сложный продукт. Plesk поддерживает 14 операционных систем семейства Linux, 4 ОС Windows, 150 сторонних компонентов, несколько веб-серверов, почтовых серверов, веб-почтовых клиентов, визуализаторы статистики, антивирусные решения и т. д. Большое количество возможных конфигураций в первую очередь влияет на сложность и возможности.
тестирования и делает практически невозможным использование A/B-тестов.
- Специфика B2B2C. Лицо, принимающее решения, не всегда является «реальным пользователем панели».
- GDPR — необходимость соблюдения буквы закона требует дополнительных усилий по обезличиванию данных и усложняет задачи сегментации пользователей, а также лишает нас возможности легко и быстро связаться с клиентами, используя их контактную информацию.
До недавнего времени у нас процесс сбора аналитики был полностью оторван от процесса разработки — в конце запоминались трекинг и метрики, вкручивалось разовое решение и так до следующей фичи.
Кроме того, за годы работы в Plesk накопилась куча источников данных – что повлекло за собой затраты на поддержание согласованности и актуальности данных, необходимость держать в голове, откуда все берется, при каких условиях попадает в базу данных и почему одни и те же метрики в разных местах различаются (например, количество лицензионных ключей и физических установок).
В эти источники было записано очень много информации (ежемесячные снимки из базы данных из 270 тысяч ключей и отчеты, поступающие в два раза чаще с 300 тысяч серверов), но лишь немногие люди знали, как работать с этими данными и находили время.
Я присоединился к Plesk в 2015 году, и мои первые задачи были связаны с извлечением разнородных статистических данных из куба OLAP и базы данных MongoDB. «Как сделать» к этой базе представляла собой страницу с логином и паролем от хостера и текстовый файл с js-скриптом из последнего популярного запроса.
Множество источников означало множество инструментов и сервисов, каждый из которых должен уметь использовать каждый менеджер программы.
Ощущения в первые дни работы были примерно такими: 
Что мы наделали?
Решение было следующим: около полутора лет назад мы начали тотальную реструктуризацию процесса сбора данных — теперь мы разрабатываем аналитику так же, как и саму фичу, на каждом этапе задействована вся команда (feature Crew).
, от PM и разработчика до QA-инженера.
Гипотеза
Все начинается на этапе планирования фичи: PM формулирует гипотезу, на основе которой на следующем этапе будет выбрана метрика.Например: в Plesk есть система рекомендаций Advisor, которая помогает пользователю улучшить состояние сервера, выполнив предложенные действия (добавьте сертификат SSL, включите обновления, обновите версию PHP и т. д.).
Выпуская Советник, мы предполагаем, что пользователь будет следовать рекомендациям, рейтинг «здоровья» сервера повысится, а благодаря геймифицированным «достижениям» пользователь будет вовлечен во взаимодействие с Советником на постоянной основе.
Метрики
На следующем этапе для каждой гипотезы выбирается метрика: для Советника это количество переходов по ссылкам в рекомендациях, процент сайтов, защищенных сертификатами, показатель рейтинга и т.д. Вся эта информация (гипотеза + метрики) заносится в видение — документ с требованиями к функции.На этом этапе в процесс включаются аналитики данных — их задача — помочь сделать метрику измеримой, простой в сборе и однозначной.
Важны даже такие детали, как структура будущего поля в базе данных или отчете — поскольку человек, отвечающий за функцию ПМ, чаще всего будет обращаться к этой информации, в его интересах определить, как удобнее это сделать, не так ли? вплоть до нужной структуры запроса к базе данных.
Благодаря такому подходу, кстати, всем стало проще в том плане, что необходимость лазить по 100500 источникам существенно снизилась - теперь вы сами решаете, в каком формате будут собираться данные и как это удобнее для ты, чтобы получить это.
Исправив логику подсчета в Vision, ПМ также получает возможность в любой момент вернуться к документу и вспомнить, по каким критериям была введена база/увеличен счет/факт отправки и т.д. Это решает проблему понимания логика отчетов.
Выполнение
Когда гипотеза сформулирована и метрика выбрана, наступает время реализации.Разработчики реализуют как саму функцию, так и механизм сбора ее статистики.
Как уже говорилось, использовать готовые решения типа GA нам сложно по разным причинам, поэтому 2 года назад наши инженеры реализовали собственный механизм отслеживания действий пользователей в панели.
Помимо действий пользователя, также могут представлять интерес различные технические подробности, настройки конфигурации и т.п.
— все это отправляется в уже упомянутую базу данных MongoDB.
Тестирование и предварительный просмотр
Как и любой продукт, механизм сбора данных необходимо тестировать — в нашем случае QA-инженер проверяет, чтобы рекомендации отображались и открывались, рейтинги отслеживались, а информация обо всех этих событиях собиралась в базе данных.Часто сценарии использования, выбранные для отслеживания и анализа, становятся новыми тестовыми сценариями для проверки функциональности самой функции.
После того, как QA-инженер проверил все сценарии, PM вместе с разработчиком посмотрели первые данные и убедились, что фича 1) ничего не сломала и 2) работала как положено, а статистика собрала то, что его интересовало.
- все готово к релизу в релизе.
Жизнь функции
Когда функция выпущена, начинается самое интересное — ее «жизнь» в продукте.Больше не нужно метаться: «Вы случайно не знаете, в каком поле нашей базы данных хранится информация об отображении рекомендаций? никто? блин…» Аналитик данных не получает сообщений в Slack: «Можете еще раз посчитать, сколько показов на последней версииЭ» — для этого на дашбордах есть графики с настроенными оповещениями, которые отправляют письма, если отслеживаемое значение резко упало/увеличилось/изменилось/не обнаружено записей в базе.
Но это еще не все понимание того, что счетчик увеличился или упал на величину.
n% не всегда достаточно, чтобы с уверенностью сказать, что это существенное изменение, а не сезонный скачок или колебание в пределах погрешности.
Один из членов нашей команды разрабатывает систему измерения статистической значимости изменения показателя.
аппарат математической статистики, он рассчитывает минимальную выборку (количество пользователей/установок/событий), необходимую для оценки значимости изменений, выбирает сегменты, между которыми можно проводить сравнения, и определяет доверительный интервал, который с наибольшей вероятностью содержит реальное значение метрики Этот фреймворк уже был протестирован и дал интересные результаты буквально на прошлой неделе: мы выяснили, что после того, как мы начали показывать цены в каталоге расширений внутри панели Plesk, люди стали реже и чаще покупать годовые лицензионные ключи — ежемесячные лицензионные ключи для этих продуктов.
Прямо сейчас наши коллеги рассчитывают прогноз LTV, после чего станет понятно, что значат для нас эти изменения в долгосрочной перспективе и какой вариант нам следует продвигать в логике отображения цен.
Конец поддержки
Итогом жизни любого продукта или функции является прекращение его поддержки в случаях, когда это связано с невостребованностью или другими причинами (например, соображениями безопасности в случае прекращения поддержки устаревшей операционной системы или версии PHP).Здесь нам также приходит на помощь аналитика: например, когда мы решили стимулировать пользователей переходить на новые версии PHP, первое, что мы сделали, — собрали статистику использования версий среди пользователей Plesk. Мы узнали, что процент пользователей, использующих PHP 7, достигает всего 20% пользователей и поняли, что потенциальные издержки принудительного перехода в виде миллионов сломанных сайтов перевешивают риски от возможных уязвимостей в старых версиях.
В итоге мы решили пойти на более мягкие меры и начали с уведомления о желательности апгрейда в панели.
Другим примером могут служить многочисленные истории прекращения поддержки операционных систем — в случае, когда мы обнаруживали, что определенная ОС использовалась одним из крупных клиентов с десятками тысяч установок Plesk, мы общались напрямую с этим партнером и, если быстрый переход был невозможен, мы предложили ему так называемый lazy drop — прекращение поддержки новых установок и возможность продолжить работу над существующими после обновления до последней версии Plesk.
Заключение
Подводя итог, хотелось бы еще раз озвучить то, что мы считаем самым важным — теперь работа с аналитикой для нас является неотъемлемой частью работы над каждой фичей.Но налаженный процесс – это еще не конец.
На собственном опыте мы убедились, что контроль качества данных не менее важен, чем сам процесс.
Все теряет смысл, если на каком-либо этапе сбора данные теряются или искажаются.
Чтобы этого не произошло, на каждом этапе мы стремимся добавлять проверки на полноту и корректность данных, а также протоколировать каждый этап обработки.
И последнее.
Не зацикливайтесь на метриках только потому, что можете :) четко сформулируйте, зачем вам нужна эта информация, а когда она будет получена, спросите себя, несет ли она в себе вывод, ведущий к действию.
Ведь понимание того, что делать, это именно то, ради чего все затевалось :) Теги: #Управление продуктом #аналитика #управление продуктом
-
«Теперь Каждый Может Стать Инвестором»
19 Oct, 24 -
Пять Презентаций Webgl, Которые Поражают
19 Oct, 24 -
Amd Opteron 6000: 12 Серверных Ядер
19 Oct, 24 -
Знаете Ли Вы Иностранный Язык?
19 Oct, 24 -
Дистанционное Обучение Или Немного О Moodle
19 Oct, 24
