тех пор, пока не увидим, насколько значительно можно улучшить значение метрики и каких усилий это потребует.
Выбор НЗМ для улучшения
Я решил сосредоточиться на увеличении среднего количества приглашений, посылаемых одним пользователем, главным образом из-за гораздо большего потенциала роста этой метрики. Второй причиной было то, что улучшение данного показателя не обязательно предполагало попытки изменить человеческое поведение. 15 % наших пользователей уже рассылали приглашения своим друзьям; мы просто собирались сделать так, чтобы они посылали еще больше пригласительных писем. Если бы мы попытались увеличить процент приглашающих пользователей, это потребовало бы усилий, направленных на изменение поведения тех пользователей, которые ранее не занимались рассылкой приглашений. Ведь по каким-то причинам 85 % пользователей решили не приглашать своих друзей присоединиться к сети, несмотря на все наши попытки заставить их это сделать. Поэтому было сложно представить, каким образом можно улучшить ситуацию в этом направлении. Кроме того, я видел, что существующий пользовательский интерфейс функции, отвечающей за приглашения друзей, требует от пользователя совершения слишком большого числа дополнительных действий, и был уверен, что мы сможем существенно упростить эту процедуру.
Цикл оптимизации метрики
Теперь, когда я выбрал наиболее значимую метрику для улучшения, можно было перейти к следующему шагу в процессе анализа бережливого продукта. На этом этапе происходит запуск цикла оптимизации метрики, показанный в правой части Рисунка 14.1. Вместе с командой мы провели мозговой штурм с целью генерации потенциальных идей по улучшению выбранного целевого показателя. Затем каждую из выдвинутых идей оценили с точки зрения того, насколько она может повлиять на улучшение метрики, и каких ресурсных затрат потребует ее реализация. После этого мы пришли к выводу, что наилучшей по показателю своей рентабельности является идея с импортом адресной книги. Сейчас наличие в приложениях функции импорта адресной книги является привычной, но в то время это было редкостью. Многие из наших пользователей хранили адреса электронной почты своих друзей в адресной книге, которая была привязана к их учетной записи у почтовых провайдеров, таких как Gmail и Yahoo!Mail. Наша новая функция должна была позволить пользователям, введя учетные данные для доступа к своему электронному почтовому ящику, импортировать во Friendster хранящуюся в почтовом сервисе контактную информацию своих друзей. Разработанный нами импортер адресной книги отображал список перенесенных контактов и позволял пользователям выбирать из него тех, кому они хотели бы направить приглашение. Мы предполагали, что реализация данной функции приведет к значительному увеличению среднего количество приглашений, посылаемых одним пользователем.
Что касается технической реализации, несмотря на то что часть функционала была общей для всех почтовых провайдеров, все же требовалось проделать определенный объем работы, чтобы интегрироваться с каждым конкретным почтовым сервисом. На этом этапе я понял, что было бы полезно разбить разрабатываемую функцию на более мелкие части (как это описано в главе 6), выделив в отдельные блоки задачи по интеграции с каждым из провайдеров. Чтобы протестировать нашу гипотезу, затратив на это минимальное количество усилий, я решил использовать MVP, функционал которого позволял импортировать адресную книгу, но работал пока только с одним из почтовых сервисов. Проанализировав профили наших пользователей, я обнаружил, что наибольшей популярностью у них пользуется «почтовик» Yahoo!Mail. Соответственно, разработка именно этого функционального блока должна была обеспечить наиболее высокую рентабельность инвестиций. Следующим шагом в этом направлении стала разработка и внедрение программного решения. На выполнение этой работы менеджеру по продукту и разработчику потребовалось около недели.
«Волшебная пилюля» или нет?
Мы запустили разработанную функцию и перешли к следующему, самому захватывающему шагу в процессе анализа бережливого продукта: отслеживанию изменений ключевой метрики. На Рисунке 14.6 показана динамика изменений метрики до и после запуска функции, позволяющей импортировать адресную книгу. Вертикальная ось показывает среднее количество посылаемых приглашений в расчете на одного отправителя, а горизонтальная – даты фиксации наблюдений. Характерной особенностью социальных приложений, и в этом смысле социальная сеть Friendster не была исключением, является довольно сильная зависимость активности пользователей от дня недели. Поэтому для большинства показателей мы учитывали их средние значения за семь дней, чтобы можно было более точно выявлять тренды. Каждая точка данных на графике, представленном на Рисунке 14.6, фактически отображает среднее значение показателя за последние семь дней.
На графике отчетливо видно, что изначально значение метрики колебалось незначительно, оставалось в узком диапазоне между 2.2 и 2.4. То место, где плавная горизонтальная линия разворачивается и устремляется вверх, соответствует дате запуска функции импорта адресной книги. Поскольку мы использовали 7-дневную среднюю, потребовалось несколько дней на то, чтобы линия графика пришла в полное соответствие с текущими дневными значениями метрики. Новое усредненное значение количества приглашений, посылаемых одним пользователем, продолжало расти с каждым днем и добралось до отметки 5.3. Я был в полном восторге!
Идея сработала как «волшебная пилюля»: всего за неделю работы ключевой показатель удалось улучшить более чем в два раза (5.3 ÷ 2.3 = 2.3x)! Если вспомнить соответствующее уравнение для улучшения бизнеса, то увеличение данной метрики в 2.3 раза означало, что число наших новых клиентов выросло также в 2.3 раза за счет вирусного привлечения. И это притом, что созданная нами функция импорта умела работать пока только с одним из почтовых сервисов. Получив количественные статданные, столь однозначно подтвердившие нашу гипотезу, мы немедленно приступили к разработке усовершенствований, необходимых для интеграции нашего приложения с другими почтовыми провайдерами. В конечном итоге это привело к дополнительному улучшению ключевой метрики.
Рисунок 14.6. Среднее количество приглашений, посылаемых одним пользователем: до и после запуска
В течение некоторого времени мы продолжали повышать среднее количество приглашений, посылаемых одним пользователем, до тех пор, пока не исчерпали запас идей по повышению рентабельности в этом направлении. Достигнув высшей точки, мы вышли из цикла улучшений для этой метрики и переключили свое внимание на другой показатель вирусного цикла, имевший на тот момент более высокую потенциальную рентабельность инвестиций.
Приведенный пример показывает, насколько простым и эффективным может быть использование аналитики в деле улучшения вашего бизнеса. Вы можете достичь аналогичных результатов, применяя процесс анализа бережливого продукта. Как и в случае с MarketingReport.com, описанным в главе 11, я не делал ничего экстраординарного; просто следовал процессу и принципам, описанным в этой книге.
Оптимизация с применением A/B-тестирования
Как уже обсуждалось в главе 7, A/B-тестирование, также известное как сплит-тестирование, представляет собой количественный метод исследования, в ходе которого вы проводите испытание двух (или более) альтернативных варианта одновременно, чтобы затем сравнить их эффективность. В то время, когда я работал
