У кого-нибудь есть хорошие стратегии для A / B-тестирования с Play Framework?

Question

Меня интересуют хорошие стратегии для A / B или сплит-тестирования с Play Framework.

Очевидным выбором будет использование оптимизатора веб-сайтов Google, однако я бы предпочел этого не делать по нескольким причинам:

• Позволяет только тестировать материал в слое презентации
• Сложно тестировать на основе таких вещей, как доход (а не бинарные события, такие как клики или конверсии)
• Пришлось испортить шаблоны с кодом Javascript
• Тесты должны быть дискретными, в то время как мне нравится постоянно тестировать новые варианты

Есть идеи?

Answer 1

Если вы хотите, чтобы контроллер решал, какую версию использовать, вы можете сделать это (по крайней мере, в Scala), выбрав один из двух разных шаблонов, например:

if (mode == "A")
  html.showA(product)
else
  html.showB(product)

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

Edit: Забыл упомянуть, что вам нужно два разных шаблона, showA.scala.html и showB.scala.html в этом случае.

Answer 2

1. firebase remote config (это бесплатно) в качестве поставщика опций тестирования AB.он позволяет вам определять группы A / B ... в процентах
2. в вашем проекте создать класс для получения значений конфигурации и предоставить интерфейс // для эксперимента 1 fun isButtonColorBlue (): Boolean fun textButton (): StringВозвращаемые значения зависят от вашего Remote Config
3. один совет для реализации A / B вариантов в вашем коде.Чтобы сохранить стабильность кода и не влиять на юнит-тесты (вы, вероятно, написали), создайте дочерний класс для класса, в который вы собираетесь вносить изменения, и переопределите метод, который вы собираетесь изменить, в соответствии с тестом AB.Затем замените определение в своем коде, чтобы использовать новую версию класса.В этом случае все тесты для старого класса находятся в безопасности.
4. Чтобы получить результат теста AB, используйте любой Analytics SDK.Когда вы получаете удаленную конфигурацию и определяете группу для пользователя, вам необходимо обновить информацию о пользователе (для Google mFirebaseAnalytics.setUserProperty ("эксперимент_буттон", "А"))

Answer 3

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

• Метод @Before, который генерирует случайное значение для сеанса (скажем, тестовое семя) или значение на основе выбранного вами параметра (доход и т. Д.)
• Некоторая логика вокруг значения начального числа на бизнес-уровне
• Теги для части пользовательского интерфейса, в которой тег показывает тот или иной текст (или изображение, или ...) в зависимости от значения начального числа
• Таблица в базе данных для хранения информации, связанной с сеансом (чтобы отслеживать движения пользователя, когда он заходит на ваш сайт)
• Некоторые отчеты по данным в таблице (я могу только порекомендовать Джаспер или Birt , не работают с другими)

Но это будет довольно много работы.

Честно говоря, я искренне верю, что использование существующих систем (веб-сайт Google) - лучшая идея. Подумайте, что все время, которое вы тратите на настройку среды для своего пользовательского A / B-тестирования, - это время, когда вы не разрабатываете свой продукт. И хотя A / B полезен для увеличения конверсии, вам понадобится много итераций, чтобы найти лучший выбор, поэтому, чем больше времени вы тратите на другие вещи, тем больше денег вы потенциально теряете.

На самом деле, из ваших жалоб на инструмент Google:

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

Так что из ваших 4 баллов я считаю, что 3 являются дискуссионными. Я бы посоветовал сначала использовать какой-нибудь существующий инструмент для увеличения производительности. Как только у вас будет наилучшее возможное преобразование, вы можете подумать о выполнении дополнительной пользовательской работы на основе других параметров.

---