Доставка вашего продукта итерациями: руководство по проверке гипотез

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

Сегодня программные продукты поставляются итерациями для проверки предположений и гипотез о том, что делает продукт более удобным для пользователей. В любой момент времени такие компании, как booking.com (где я работал раньше), проводят сотни A/B-тестов на своих сайтах именно для этой цели.

Для приложений, поставляемых через Интернет, нет необходимости определять внешний вид продукта за 12–18 месяцев, а затем создавать и в конечном итоге поставлять его. Вместо этого совершенно практично выпускать небольшие изменения, которые приносят пользу пользователям по мере их внедрения, устраняя необходимость делать предположения о предпочтениях пользователей и идеальных решениях, поскольку каждое предположение и гипотезу можно проверить, разработав тест, чтобы изолировать эффект. каждого изменения.

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

Что такое проверка гипотез?

При отправке функции пользователям обязательно нужно проверить предположения о дизайне и функциях, чтобы понять их влияние в реальном мире.

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

Одним из ключевых аспектов проверки гипотез является изоляция различных переменных в опыте с продуктом, чтобы можно было приписать успех (или неудачу) внесенным изменениям. Таким образом, если бы у нашего менеджера по продукту Amazon была еще одна гипотеза о том, что отображение отзывов клиентов рядом с изображениями продуктов улучшит конверсию, было бы невозможно проверить обе гипотезы одновременно. Это приведет к невозможности правильно соотнести причины и следствия; следовательно, эти два изменения должны быть изолированы и протестированы по отдельности.

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

Различные типы проверки гипотез

A/B-тестирование

Наиболее распространенные варианты использования могут быть проверены с помощью рандомизированного A/B-тестирования, при котором изменение или функция выпускаются случайным образом для одной половины пользователей (A) и удерживаются для другой половины (B). Возвращаясь к гипотезе о том, что большие изображения продуктов улучшают конверсию на Amazon, половина пользователей увидит изменение, а другая половина увидит веб-сайт таким, каким он был раньше. Затем конверсия будет измеряться для каждой группы (A и B) и сравниваться. В случае значительного повышения конверсии для группы, показывающей большие изображения продуктов, можно сделать вывод, что первоначальная гипотеза была верна, и изменение можно распространить на всех пользователей.

Многовариантное тестирование

В идеале каждая переменная должна быть изолирована и протестирована отдельно, чтобы однозначно определить атрибуты изменений. Однако такой последовательный подход к тестированию может быть очень медленным, особенно при тестировании нескольких версий. Продолжая пример, в гипотезе о том, что более крупные изображения продуктов приводят к более высоким коэффициентам конверсии на Amazon, «большее» является субъективным, и может потребоваться несколько версий «большего» (например, 1,1x, 1,3x и 1,5x). пройти тестирование.

Вместо последовательного тестирования таких случаев можно применить многовариантный тест, в котором пользователи делятся не пополам, а на несколько вариантов. Например, четыре группы (A, B, C, D) состоят из 25% пользователей каждая, где пользователи группы A не увидят никаких изменений, тогда как в вариантах B, C и D изображения будут увеличены на 1,1х, 1,3х и 1,5х соответственно. В этом тесте несколько вариантов одновременно тестируются в сравнении с текущей версией продукта, чтобы определить лучший вариант.

До/После тестирования

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

Однако ограничением здесь является невозможность изолировать эффекты сезонности и внешних факторов, которые могут по-разному влиять на тестовый и контрольный периоды. Предположим, что в момент времени t было внесено изменение в логику, определяющую повышение цен на Uber, так что логика A используется до, а логика B — после. Хотя эффекты до и после времени t можно сравнить, нет никакой гарантии, что они вызваны исключительно изменением логики. Между двумя периодами времени могла быть разница в спросе или других факторах, которая привела к разнице между ними.

Тестирование включения/выключения на основе времени

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

Например, в сценарии использования Uber сдачу можно показать водителям в понедельник, отозвать во вторник, снова показать в среду и так далее.

Хотя этот метод не полностью устраняет влияние сезонности и внешних факторов, он значительно уменьшает их, делая такие тесты более надежными.

Дизайн теста

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

Дизайн теста — это просто последовательный план:

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

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

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

Выборка

При выполнении тестов важно убедиться, что два выбранных для теста варианта (A и B) не имеют предвзятости в отношении метрики успеха. Например, если вариант, который видит большие изображения, уже имеет более высокую конверсию, чем вариант, который не видит изменений, то тест необъективен и может привести к неверным выводам.

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

Значение и сила

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

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

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

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

• Аналитики данных и инженеры данных обычно хорошо разбираются в правильном дизайне тестов и могут направлять менеджеров по продуктам, поэтому обязательно используйте их опыт на ранних этапах процесса.
• Существует множество онлайн-курсов по проверке гипотез, A/B-тестированию и смежным статистическим концепциям, таким как Udemy, Udacity и Coursera.
• Использование таких инструментов, как Google Firebase и Optimizely, может упростить процесс благодаря большому количеству готовых возможностей для запуска нужных тестов.

Использование проверки гипотез для успешного управления продуктом

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

Такой подход помогает количественно оценить ценность новых изменений и функций, сосредоточить внимание на наиболее ценных функциях и выполнять дополнительные итерации.