Книга: «Тюнинг систем: экспериментирование для инженеров от A/B-тестирования до байесовской оптимизации»25.06.2024 16:15

Привет, Хаброжители!

Работает ли программа так, как следует? Изменения сделали систему лучше или хуже? Стоит ли заниматься повышением производительности вместо разработки нового функционала? На подобные вопросы можно ответить только с помощью экспериментов. «Тюнинг систем» раскроет секреты современных экспериментальных практик, разработанных и проверенных мировыми индустриями с самой высокой конкуренцией. Предложенные практики помогут усовершенствовать разработку программного обеспечения, системы машинного обучения и количественного трейдинга.

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

СОСРЕДОТОЧЬТЕСЬ НА БИЗНЕСЕ

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

Не оценивайте модель

Итак, вы инженер в компании-стартапе. Ваша компания разрабатывает приложение, которое показывает пользователям короткие видеоролики. Чтобы выжить, компании нужен оборотный капитал, который она рассчитывает получить от инвесторов. Как выясняется, инвесторы сильно заинтересованы в том, сколько активных пользователей в день (daily active users, DAU) набирает такая система, как ваша. Чем выше DAU, тем выше вероятность получить инвестиции. Кажется (по крайней мере пока), что вам нужно оптимизировать именно DAU.

Вы добавляете в систему инструменты для измерения DAU и обнаруживаете, что у вас не самое низкое значение DAU, но чтобы убедить инвесторов, желательно улучшить этот показатель. На данный момент пользователи открывают приложение и видят ролик, который был загружен в систему последним. Вы предполагаете, что если вы поймете, какие ролики нравятся пользователям, и будете показывать им именно такие, то скорее всего, завтра пользователи тоже откроют ваше приложение и DAU увеличится.

Как вы поймете, что пользователю нравится видео? В любой момент, пока видео воспроизводится, пользователь может прокрутить ленту и переключиться на другое видео. Вы полагаете, что если пользователь смахнул вверх («свайпнул») видеоролик, то скорее всего, этот ролик ему не понравился. Бинго! Вы сканируете логи системы и видите, какие видео смахнул каждый пользователь. Вы создаете модель машинного обучения, которая предсказывает вероятность смахивания видео P{swipe}, основываясь на таких признаках, как автор видео, продолжительность и какой-то другой сводной статистике, которую вы получили ранее.

Далее вы запускаете первый А/В-тест. В версии «В» вы генерируете оценки P{swipe} с помощью новой предсказательной модели и первым показываете видео с наименьшим P{swipe}, вторым — видео с P{swipe}, следующим после наименьшего, и т. д. Ваш А/В-тест имеет ошеломительный успех. Показатель DAU версии В значительно лучше, чем версии А.

Вдохновленные своим успехом, вы расширяете набор признаков и улучшаете предсказания модели. Вы измеряете качество предсказаний модели с помощью перекрестной энтропии на данных, которые не участвовали в расчете модели, данных «вне выборки» (метрика машинного обучения, которая рассчитывается на основе некоторой части сохраненных данных). Вы запускаете еще один А/В-тест. И снова успех. Вы получаете немного инвестиций, нанимаете небольшую команду инженеров и даете им задание улучшить показатель перекрестной энтропии «вне выборки», насколько это возможно.

Вы делаете несколько итераций улучшения модели и обнаруживаете кое-что удивительное и… огорчающее. С каждой новой версией перекрестная энтропия модели уменьшается, но при этом рост DAU замедляется (рис. 7.1) и в последнем А/В-тесте останавливается совсем. Что случилось?

Рис. 7.1. DAU увеличивается с ростом качества предсказаний модели машинного обучения P{swipe}, но скорость роста DAU намного меньше скорости роста качества предсказаний

Если ответить коротко, то ваша команда сосредоточилась не на той метрике. Они улучшали перекрестную энтропию — общую, техническую меру качества модели, вместо метрики DAU, необходимой бизнесу. В самом начале вы предположили, что DAU и перекрестная энтропия предсказаний как-то связаны между собой, но у вас не было никаких доказательств, что эта связь действительно существует. Можно рассуждать следующим образом: есть много вариантов бизнес-метрик (DAU, время, затраченное за сессию, количество просмотренных видео за сессию и т. д.), и есть много прогнозных целей (вероятность смахивания видео, вероятность нажатия «нравится», вероятность того, что пользователь поделится видеороликом, и т. д.). Почему улучшение предсказаний для какой-либо из этих целей должно гарантировать улучшение
какой-либо бизнес-метрики?

На практике ваша догадка о корреляции между улучшением некоторой модели и улучшением некоторой бизнес-метрики может быть и верна (особенно если у вас есть знание предметной области), но угадать, насколько сильна эта корреляция, очень сложно. Существует множество аспектов вашей системы, которые влияют на значение бизнес-метрики, — код, модели, железо, пользователи (каждый из которых сложен сам по себе!), конкуренты и т. д. Вы не сможете предсказать, измерить или даже выявить все эти аспекты. Ваше предсказание P{swipe}, даже если оно очень точное, это только один из факторов, определяющих DAU.

Полезно провести аналогию с оптимизацией времени работы программного кода. Есть проверенный способ ускорить работу кода: (1) найти в коде хот-споты (то есть места, в которых код выполняется дольше всего); (2) ускорить работу кода в хот-споте; (3) повторить все сначала. Если скорость работы кода — это аналог бизнес-метрики, то удаление хот-спота — это аналог улучшения P{swipe}: как только код в хот-споте начинает работать достаточно быстро, это уже не хот-спот. Дальнейшее улучшение работы кода в этой точке не повлияет на общую производительность.

Кроме того, часто обнаруживается, что по мере развития системы корреляция снижается, то есть дальнейшее улучшение технических метрик, таких как P{swipe}, не приводит к столь же значительным улучшениям бизнес-метрик, в данном случае DAU. Возможно, дело в том, что как бы ни были хороши предсказания, найдутся и другие ограничения поведения пользователей.

Возможно, у вас отличные предсказания P{swipe}, но лучшее видео, которое у вас есть, имеет P{swipe} = 0.75. Другими словами, то, что вы можете предсказать просмотры видеороликов, не означает, что в вашем реестре найдутся интересные ролики. Даже если они найдутся, пользователь может не запустить их, а закрыть приложение и пойти куда-то еще. На DAU влияет много факторов, которые не зависят от P{swipe} и которые нельзя отследить с помощью улучшения предсказаний.

Однако это не означает, что вы не должны строить модель P{swipe}. Построить модель полезно, но не стоит смещать фокус оптимизации с DAU на P{swipe}. В следующем разделе мы обсудим более удачный подход.

Оценивайте продукт

Мы только что рассмотрели, что переключиться на технический показатель, не относящийся к бизнесу, очень просто. Решение этой проблемы легко описать словами, но чтобы воплотить его в жизнь, потребуются некоторые усилия. При каждой итерации инженерного рабочего процесса (см. главу 1, рис. 1.1 и рис. 7.2 в этом разделе) во время запуска эксперимента вновь фокусируйтесь на бизнес-метрике, рассматривайте все способы, которыми вы можете улучшить ее, выбирайте наиболее перспективный способ и дальше работайте над ним. Это то, что инженеры называют переключением контекста: вам нужно перестать думать о технической стороне того, над чем вы работаете, и переключить внимание на нужды бизнеса.

Рис. 7.2. Рабочий процесс инженера. (a) Во время запуска эксперимента вернитесь к бизнес-метрике и (b) рассмотрите все возможные способы ее улучшения Вы можете рассмотреть не только P{swipe}, но и другие цели прогнозирования.

Может быть, вы будете предсказывать вероятность того, что пользователь нажмет кнопку «нравится» или поделится видео. Может быть, вы будете сочетать несколько предсказаний в единой системе ранжирования.

Может быть, ваши пользователи заскучали, потому что видеоролики с минимальным P{swipe} слишком похожи друг на друга. Например, пользователь может открыть приложение и увидеть несколько видеороликов с рецептами гуакамоле. Даже если пользователи любят гуакамоле и хотят приготовить его к обеду, им надоест смотреть эти рецепты несколько роликов подряд. Может быть, вам нужно добавить вариативность.

Может быть, пользователи ценят хорошие видео только на контрасте с плохими. (Или хотя бы с видео среднего качества. Вы же не хотите, чтобы пользователи ушли из приложения из-за плохих видео.) Возможно, вы отложите видеоролики с минимальным P{swipe} и будете показывать их только изредка, с перерывами.

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

В этом разделе выбор метрики DAU был мотивирован требованиями инвесторов. В следующем разделе мы более подробно рассмотрим процесс выбора бизнес-метрик.

ВЫБОР БИЗНЕС-МЕТРИК

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

Ориентируйтесь на конкретные цели бизнеса

Ваш бизнес уникален. Даже если у вас есть конкуренты, вы отличаетесь от них. Их бизнес только похож на ваш. Бизнес-метрики должны отражать вашу уникальность.

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

Чтобы определить цели бизнеса, вам необходимо участие всех заинтересованных лиц (стейкхолдеров), которые включают в себя (но не ограничиваются ими):

• Инвесторов — они хотят получить выгоду в долгосрочной перспективе и (все чаще) пытаются избегать бизнеса, негативно влияющего на общество и окружающую среду.
• Пользователей — им нужен продукт, качественно удовлетворяющий их потребности. Это может означать, что продуктом легко пользоваться, он недорогой, придает статус и т. д.
• Членов вашей команды — они знают, каких целей реально достичь, и хорошо знакомы с проблемами, существующими в системе на данный момент.
• Другие команды — их работа может зависеть от изменений, которые ваша команда внесет в систему.
• Органы контроля — они представляют общественные интересы в сфере безопасности и использовании государственных ресурсов.
• Рекламодателей — они хотят, чтобы пользователи видели их собъявления и реагировали на них.

Допустим, ваша компания стала более зрелой, и теперь у вас высокий и стабильный показатель DAU. Вы готовы показывать рекламные объявления. Реклама, скорее всего, понравится инвесторам, которые увидят возможность получить доход от своих инвестиций, и рекламодателям, которые хотят продавать товары вашим пользователям. Но реклама не понравится пользователям, потому что она будет отвлекать их от видеороликов и ухудшать общее впечатление от использования системы. Команда, ответственная за дизайн приложения,
вообще воспринимает рекламу как изъян на той красоте, которую они создали.

В идеале каждый стейкхолдер может оптимизировать свою бизнес-метрику, отвечающую его интересам. Ваша задача — выбрать одну или несколько метрик (см. раздел 7.3), которые помогут найти компромисс. Например, вы можете одновременно измерять доход от объявления и DAU. Если в следующем А/В-тесте доход увеличится, а DAU не уменьшится, то скорее всего, и пользователи, и инвесторы, и рекламодатели останутся довольны. Если при этом дизайнеры смогут интегрировать рекламу в интерфейс приложения так, как им понравится, и не вызвать снижения DAU или дохода, то, возможно, вообще все будут довольны.

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

Периодически пересматривайте бизнес-метрики

Бизнес растет, а значит, будут меняться и бизнес-метрики. Необходимо периодически пересматривать и обновлять их, отражая изменения в бизнесе.

Компания меняется. Сменяются кадры. Приходят и уходят инвесторы. Меняются вкусы пользователей. Сами пользователи становятся старше, и их потребности тоже меняются. Меняются социальные нормы. Меняется экономика. Бизнес-метрики определяются мнением стейкхолдеров, а значит, они будут меняться так же, как меняются сами стейкхолдеры и их мнение.

В предыдущем разделе мы остановились на том, что компания начала продавать рекламу, и теперь вам нужно пересмотреть бизнес-метрики. Допустим, ваше приложение стало очень популярно, и многие начали обращать внимание на ваш бизнес. Родители пишут злобные письма и посты в блогах, жалуясь, что их дети проводят слишком много времени за вашим приложением. Кажется, оно вызывает зависимость. Органы контроля звонят вам и просят принять меры.

Из-за негативного отклика в прессе рекламодателям не нравится, что они ассоциируются с вами. Как вы можете изменить приложение, чтобы исправить ситуацию? Скорее всего, вам придется внести много изменений, но прежде всего вам нужно определить цель этих изменений, то есть бизнес-метрику. Например, вы можете измерять «время, проведенное пользователем в приложении, за сессию» или «время, проведенное пользователем в приложении, за день». Когда вы анализируете А/В-тест, вы должны стремиться уменьшить эти метрики до какой-то разумной границы. Уменьшив среднее время, проведенное пользователем за вашим приложением, вы можете угодить заинтересованным лицам: рекламодателям, инвесторам и… обществу в целом.

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

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

Время действия метрики

Нет никакого смысла выбирать бизнес-метрику, которую вы не можете измерить с помощью эксперимента. Бывает так, что бизнес-метрику невозможно измерить просто потому, что она плохо определена (например, «средняя красота видеороликов», «средняя привлекательность постеров» и т. д.), но чаще всего метрику сложно измерить, потому что ее измерение занимает слишком много времени.

Вспомните: когда мы запускали А/В-тест, мы делали усредненные измерения, которые являлись средним от num_ind отдельных измерений, при этом num_ind >= (2.48 * sd1_delta / prac_sig)**2 (см. главу 2, раздел 2.3.2). Здесь имеют место следующие ключевые моменты:

• чем больше времени занимает отдельное измерение, тем дольше будет идти эксперимент;
• чем больше num_ind, тем дольше будет идти эксперимент;
• чем больше стандартное отклонение отдельных измерений (sd1_delta), тем больше num_ind. Чем более «зашумлены» отдельные измерения, тем более длительным будет эксперимент;
• чем ниже prac_sig, уровень практической значимости, тем больше num_ind.

Более точные измерения займут больше времени.

Все эти утверждения лучше проиллюстрировать примерами.

Временные рамки отдельных измерений

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

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

Шумы отдельных измерений

Квадрат количества отдельных измерений N, необходимых для А/В-теста, растет с ростом величины sd1_delta. Если sd1_delta удваивается, то N увеличивается в 4 раза. В качественном выражении это означает, что num_ind чувствительно к уровню шума.

Уровень шума для отдельного измерения зависит от многих факторов. Шумы и помехи в измерении могут быть вызваны, например, следующим:

• тепловым шумом (холодная вычислительная техника работает стабильнее перегретой);
• помехами в сетях передачи данных;
• помехами, обусловленными человеческим фактором;
• помехами, обусловленными динамикой финансовых инструментов.

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

Практическая значимость

Высокие требования к точности измерений (то есть меньшая практическая значимость) приведут к длительным экспериментам. N чувствительно к уменьшению PS точно так же, как оно чувствительно к увеличению sd1_delta.

Как правило, по мере развития бизнеса вам будут требоваться все меньшие и меньшие значения PS, при этом добиваться значительных улучшений системы станет все сложнее и сложнее. К тому же когда у вас появится много пользователей, небольшие изменения таких метрик, как «время, проведенное в приложении», в долгосрочной перспективе могут сильно повлиять на другие метрики, например доход от объявления. Следовательно, имеет смысл точнее измерять «время, проведенное в приложении» и следить за тем, чтобы случайно его не снизить.

При встрече с серьезной конкуренцией вам тоже могут потребоваться меньшие значения PS. Например, в высокочастотном трейдинге очень маленькие изменения в задержках могут превратиться в большие изменения прибыли, поскольку вы можете обогнать конкурентов. В онлайн-рекламе кликабельность обычно находится в пределах 10%, так что изменение меньше чем в 0.1% может повлечь за собой значительный рост отклика на объявления ваших рекламодателей.

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

СОЧЕТАНИЕ НЕСКОЛЬКИХ БИЗНЕС-МЕТРИК

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

Снижение негативных побочных эффектов

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

Среди инженеров ходит немало историй о неожиданном поведении систем, которые оптимизировали с помощью одной метрики. Статья Дж. Лемана (J. Lehman) и др. (https://arxiv.org/abs/1803.03453) собрала множество забавных примеров из области обучения с подкреплением. Здесь мы приведем еще несколько обыденных примеров.

Если мы говорим о торговле на бирже, то первая бизнес-метрика, которая приходит в голову, — это «прибыль», то есть ваша торговая система должна максимизировать прибыль. Преследуя эту цель, вы, вероятнее всего (и быстрее всего), обнаружите, что берете на себя слишком много риска. Так что на самом деле вам нужно не только максимизировать прибыль, но и минимизировать риск. Если вы торгуете на высоких частотах, то можете также обнаружить, что если отправлять заявки на биржу слишком быстро, то биржа попросит вас остановить торговлю.
А значит, следующая бизнес-метрика — это количество заявок в секунду. Скорее всего, вам придется отслеживать намного больше метрик.

При запуске системы подбора рекламных объявлений можно начать с такой бизнес-метрики, как доход. В конце концов, вы занимаетесь бизнесом, и если вы будете чаще показывать объявления, то скорее всего, доход увеличится, по крайней мере краткосрочно. Но через некоторое время пользователи могут разлюбить ваш продукт и уйти куда-то еще просто потому, что у вас слишком много рекламы. Из-за этого ваш доход может снизиться. Следовательно, чтобы убедиться в том, что вы пока не замучили пользователей своими попытками увеличить доход, вы должны отслеживать еще и метрику DAU, или «ежедневное время, проведенное пользователем на сайте», либо другую похожую метрику.

Если вы разрабатываете систему ранжирования для социальной сети, то в качестве бизнес-метрики можно использовать «количество постов, просмотренных за сессию». Пытаясь улучшить эту метрику, вы можете построить сложную модель машинного обучения, которая будет управлять алгоритмом ранжирования и которую трудно интерпретировать. Что, если эта модель понизит рейтинг постов о суициде? Скорее всего, «количество постов, просмотренных
за сессию» увеличится, потому что тема суицида может быть настолько неприятна пользователям, что они закроют приложение. С другой стороны, кто-то из друзей автора мог бы увидеть этот пост, написать автору и предложить помощь. Что, если мы упустим возможность помочь человеку из-за низкого рейтинга постов о суициде?

Еще одна хорошая метрика для социальной сети — это «количество лайков от пользователя за день». Если пользователи часто кликают «лайк» (или «большой палец вверх», или »+», или «сердечко» и т. д.), значит, скорее всего, они видят приятный контент, так? Возможно. Хотя они могут «лайкать» посты, которые шокируют их или которые активно выражают мнение, основанное на эмоциях. Повышая рейтинг такого контента (с помощью модели машинного обучения, которая просто замечает, что подобный контент получает отклик), можно увеличить бизнес-метрику — «количество лайков/пользователь/день», —, но также можно наполнить продукт шокирующим содержанием и оставить о нем крайне неприятное впечатление. Вы также можете рассмотреть такие метрики, как «взаимодействия между слабо связанными пользователями», «процент грубых слов/ругательств в комментариях» и т. д.

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

Оценка нескольких метрик

К этапу анализа эксперимента у вас будет измерено несколько метрик. Чтобы решить, стоит ли принять новую версию системы (например, версию В в А/В-тесте или лучший набор параметров в байесовской оптимизации) либо отклонить ее и остаться на текущей версии, вам нужно сопоставить результаты измерений ваших метрик.

Вы можете сделать одну бизнес-метрику оптимизирующей метрикой, а все остальные — ограничивающими метриками (или «барьером»). Например, для А/В-теста системы подбора рекламы в качестве оптимизирующей метрики можно выбрать доход, а DAU и «время, проведенное на сайте, в день» — в качестве ограничивающих метрик. Если версия В дает больший доход, чем версия А, и при этом DAU и «время, проведенное пользователем на сайте, в день» у версии В не снизилось, тогда вы можете принять версию В. Как правило, если оптимизирующая метрика улучшилась, а ограничивающие метрики не ухудшились, то можно принять новую версию в систему.

Другой подход — более сложный — это сочетать метрики в одной суперметрике с помощью линейного выражения, например: C1 x revenue + C2 x DAU + C3 x [time spent/day], где C1, C2 и C3 — это константы, которые определяют относительную значимость каждой метрики. Для этих констант очень сложно подобрать хорошие значения. Эти значения зависят от мнения всех стейкхолдеров и являются абсолютно субъективными. Фактически вам нужно ответить на вопрос: «Можем ли мы потерять одного пользователя в день, если при этом мы получим на C1/C2 долларов в день больше?». При этом чем больше метрик вы сочетаете, тем сложнее подобрать коэффициенты. Кроме того, вы снова оптимизируете всего одну метрику (суперметрику), а следовательно, появляется вероятность негативных побочных эффектов.

Нечего и говорить, что я не рекомендую оптимизировать линейную комбинацию метрик. На самом деле я не рекомендую оптимизировать вообще. Лучше обозначьте границу для каждой метрики. Например, вы можете сказать, что ваша цель — увеличить доход на $1000 в день, и, чтобы достичь этой цели, вы готовы потерять 5 минут от времени, проведенного на сайте, в день, но не готовы потерять нисколько от DAU. Тогда ваши критерии принятия решения будут
выглядеть примерно так:

• revenue/day>=$1000
• timespent/day>=currentvalue–5m
• DAU>=currentvalue

Если версия В отвечает всем этим критериям, вы можете принять ее. Обратите внимание, что вы должны задать столько же значений границ (три), сколько коэффициентов для суперметрики (C1, C2 и C3). Однако задать границы гораздо проще, потому что каждая граница применяется только к одной метрике, тогда как коэффициенты C сравнивают каждую метрику с остальными. На вопрос об одной метрике легче ответить, например: «Хочу ли я, чтобы доход вырос на $1000 в день?». Но сравнивать метрики сложно. Например, будет сложно определить, сколько долларов в день вы готовы заплатить, чтобы получить плюс один к DAU и 30 секунд ко времени, проведенному на сайте, в день.

Наконец, границы позволяют вам понять, когда остановиться. Например, если вы добились увеличения дохода на $1000 в день, то вы можете завершить задачу оптимизации дохода и переключиться на что-то другое. Если ваша задача была определена как «увеличить доход за день, насколько это возможно» (то есть оптимизировать), то даже если вы улучшите доход на $1000 в день, вам все равно придется продолжить работу по росту дохода.

Улучшение системы до «достаточно хорошего» уровня (вместо поиска оптимума) называется принципом разумной достаточности. Идея разумной достаточности заключается в том, что когда вы принимаете решение (принять или отклонить версию В), вы учитываете как значение бизнес-метрики, так и стоимость ее измерения.

ИТОГИ

• Сосредоточьте внимание на бизнес-метриках, а не на технических показателях.
• Создавайте уникальные метрики, важные для конкретного бизнеса.
• Периодически пересматривайте бизнес-метрики, учитывая мнения всех стейкхолдеров.
• Задайте и используйте несколько бизнес-метрик.
• Определите границы для каждой бизнес-метрики и используйте эти границы в качестве критериев принятия новой версии системы.

Более подробно с книгой можно ознакомиться на сайте издательства:

» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Тюнинг

Habrahabr.ru прочитано 1836 раз