Сплит-тестирование - это метод определения того, какой вариант приложения лучше подходит для данной цели.
Множественные варианты или варианты поведения приложения распределяются случайным образом. После сбора и анализа статистики мы определяем, какая версия работает лучше.
Цель этой статьи - предоставить простой способ структурирования и организации вашего приложения для получения чистого и масштабируемого кода iOS при использовании сплит-тестирования.
Предоставляются практические советы и примеры, чтобы эта статья оставалась руководством для реальных сценариев приложений.
Общие проблемы
Используя сплит-тестирование (также известное как A / B-тестирование), у нас есть бесконечные возможности для тестирования. Но в целом мы можем сгруппировать изменения, необходимые для сплит-теста, в следующем порядке:
- Изменения содержания: изменение только определенных частей в данном представлении или добавление / удаление определенного содержания на основе данного теста.
- Изменения дизайна. Проверка того, как такие изменения, как цвета, типографика или макет, могут повлиять на поведение наших пользователей.
- Поведенческие изменения: изменение поведения кнопки или представления на экране в зависимости от разделенной группы.
Проблема в том, что во всех этих категориях может возникнуть огромное дублирование кода.
Нам нужен способ создания легко поддерживаемой структуры кода для тестов - это потому, что у нас будут постоянные требования для добавления новых тестов и удаления или изменения старых. Следовательно, мы должны проектировать с учетом масштабируемости.
Создание менеджера сплит-тестирования
Мы постараемся создать универсальное решение многократного использования, которое можно было бы использовать для описанных выше категорий изменений.
Сначала мы создадим протокол, который определяет правила, которым должен соответствовать объект, чтобы представить сплит-тест:
Поле value будет представлять общее значение, которое будет реализовано конкретным объектом тестирования разделения. Он будет соответствовать цвету, шрифту или любому атрибуту, который мы тестируем для достижения нашей целевой цели.
Наш identifier будет просто уникальным идентификатором для нашего теста.
Наш group будет представлять, какое значение теста в настоящее время проверяется. Это может быть a и b или red и green. Все это зависит от наименования значений, которые определены для данного теста.
Мы также создадим менеджера, который будет отвечать за получение значения нашего сплит-теста на основе группы, хранящейся в нашей базе данных, связанной с идентификатором тестирования:
Изменения содержания
Предположим, мы работаем над приложением для чтения и решаем дать пользователям бесплатную электронную книгу.
Наша маркетинговая команда решила создать сплит-тест для предоставления книги, сначала попросив пользователей:
Поделитесь нашим приложением в социальных сетях
or
Подпишитесь на нашу новостную рассылку
В обоих этих двух случаях используется один и тот же контроллер представления, но часть дизайна изменяется в зависимости от данного случая. В нашем контроллере представления мы создадим область просмотра содержимого, в которую будем добавлять различные представления содержимого.
В этом случае нам нужно создать два разных представления: одно для публикации в социальных сетях и одно для информационного бюллетеня, и добавить их соответственно в определенную область содержимого нашего контроллера представления.
Давайте сначала создадим объект, который содержит стиль нашего контроллера представления, и передадим его в инициализатор контроллера представления:
По сути, объект стиля в настоящее время содержит имя xib для представления содержимого нашего PromotionViewController.
Мы можем создать наш тестовый объект, который соответствует нашему SplitTestProtocol:
Теперь мы можем легко представить наш контроллер представления либо информационным бюллетенем, либо контентом социальных сетей на основе нашего сплит-теста:
Изменения в дизайне
Обычно в приложениях для электронной коммерции популярно менять дизайн кнопки призыва к действию, то есть кнопки add to cart или purchase, чтобы сделать ее более привлекательной для пользователей и получить больше кликов.
Мы всегда можем использовать любой объект, который нам нужен для нашего менеджера разделения. В этом случае предположим, что нам нужен объект, который содержит в качестве значения цвет кнопки покупки:
и мы можем использовать его просто с нашей точки зрения следующим образом:
Точно так же можно протестировать любые другие атрибуты, такие как шрифты и поля или любой другой атрибут, который необходимо изменить на основе нашего тестирования.
Поведенческие изменения
Предположим, мы решили разделить пользователей на две группы по подпискам в нашем приложении:
Мы хотим либо
Отображение диалогового окна скидки при открытии окна "Покупка в приложении"
or
Представить вид по умолчанию без диалогового окна
В этом примере мы будем использовать шаблон стратегии для обработки базы представления скидки в нашей стратегии.
Шаблон стратегии - это шаблон проектирования, используемый для создания взаимозаменяемой группы алгоритмов, из которых во время выполнения выбирается требуемый.
Поскольку наш SplitTestProtocol содержит общее значение, мы можем создать объект сплит-тестирования, который будет содержать стратегию в качестве своего значения:
Затем мы можем инициализировать и представить наш контроллер представления в зависимости от конкретной стратегии:
Теперь мы можем легко передать ответственность за скидку объекту DiscountStrategy и масштабировать его в соответствии с нашими потребностями, не меняя ничего в коде нашего контроллера представления:
Общие советы
При проведении сплит-тестирования важно всегда проявлять осторожность в отношении следующих моментов:
- Всегда используется кеширование для тестовых значений, чтобы приложение оставалось согласованным для пользователя.
- Очистите код после завершения одного конкретного теста. Удалите представления, шрифты, изображения и все ресурсы, которые вы добавили в проект для сплит-теста.
- Убедитесь, что если что-то пойдет не так, вы можете отключить тест A / B.
В заключение
Сплит-тестирование (также известное как A / B-тестирование) - мощный и эффективный инструмент для наших приложений, но он может легко создать беспорядочный код, если мы не будем осторожны с дизайном нашего кода.
В этой статье мы создали общее решение, которое может управлять нашей логикой сплит-тестирования. Мы дали несколько примеров реальных приложений и практических советов, чтобы эта статья использовалась в качестве руководства при реализации сплит-тестирования для ваших приложений iOS.
Если вам понравилась эта статья, обязательно хлопайте в ладоши, чтобы выразить свою поддержку.
Следуй за мной, чтобы просмотреть множество других бесплатных статей, которые поднимут твои навыки работы с iOS на новый уровень.
Если у вас есть какие-либо вопросы или комментарии, не стесняйтесь оставить заметку здесь или напишите мне по адресу [email protected].
Примечание редактора. Heartbeat - это онлайн-публикация и сообщество, созданное авторами и посвященное предоставлению первоклассных образовательных ресурсов для специалистов по науке о данных, машинному обучению и глубокому обучению. Мы стремимся поддерживать и вдохновлять разработчиков и инженеров из всех слоев общества.
Являясь независимой редакцией, Heartbeat спонсируется и публикуется Comet, платформой MLOps, которая позволяет специалистам по данным и группам машинного обучения отслеживать, сравнивать, объяснять и оптимизировать свои эксперименты. Мы платим участникам и не продаем рекламу.
Если вы хотите внести свой вклад, отправляйтесь на наш призыв к участникам. Вы также можете подписаться на наши еженедельные информационные бюллетени (Deep Learning Weekly и Comet Newsletter), присоединиться к нам в » «Slack и подписаться на Comet в Twitter и LinkedIn для получения ресурсов, событий и гораздо больше, что поможет вам быстрее и лучше строить лучшие модели машинного обучения.
