Полезно сделать шаг назад и абстрагироваться от того, что пытается сделать A / B-тестирование, прежде чем углубляться в код. Что именно нам понадобится для проведения теста?
- Цель с условием
- По крайней мере, два разных Пути, чтобы выполнить условие цели
- Система для отправки зрителей по одному из путей
- Система регистрации результатов теста
Имея это в виду, давайте подумаем о реализации.
Цель
Когда мы думаем о цели в Интернете, обычно мы подразумеваем, что пользователь достигает определенной страницы или что он выполняет определенное действие, например, успешно зарегистрировавшись в качестве пользователя или перейдя на страницу оформления заказа.
В Django мы могли бы смоделировать это несколькими способами - возможно, наивно внутри представления, вызывая функцию всякий раз, когда цель была достигнута:
def checkout(request):
a_b_goal_complete(request)
...
Но это не помогает, потому что мы должны добавлять этот код везде, где нам это нужно - плюс, если мы используем какие-либо подключаемые приложения, мы бы предпочли не редактировать их код, чтобы добавить наш A / B-тест.
Как мы можем ввести Цели A / B без непосредственного редактирования кода вида? Как насчет Middleware?
class ABMiddleware:
def process_request(self, request):
if a_b_goal_conditions_met(request):
a_b_goal_complete(request)
Это позволило бы нам отслеживать цели А / Б в любом месте сайта.
Откуда мы знаем, что условия Цели были выполнены? Для простоты реализации я предполагаю, что мы знаем, что цель достигла своих условий, когда пользователь достигает определенного URL-пути. В качестве бонуса мы можем измерить это, не пачкая руки внутри вида. Возвращаясь к нашему примеру регистрации пользователя, можно сказать, что эта цель была достигнута, когда пользователь достигает пути URL:
/ регистрация / полная
Итак, мы определяем a_b_goal_conditions_met:
a_b_goal_conditions_met(request):
return request.path == "/registration/complete":
Дорожка
Размышляя о путях в Django, естественно перейти к идее использования разных шаблонов. Есть ли другой путь, еще предстоит выяснить. В A / B-тестировании вы делаете небольшие различия между двумя страницами и измеряете результаты. Поэтому рекомендуется определить единый базовый шаблон пути, из которого должны быть расширены все пути к цели.
Как визуализировать эти шаблоны? Декоратор, вероятно, является хорошим началом - в Django рекомендуется включать параметр template_name в ваши представления, чтобы декоратор мог изменить этот параметр во время выполнения.
@a_b
def registration(request, extra_context=None, template_name="reg/reg.html"):
...
Вы можете видеть, что этот декоратор либо анализирует упакованную функцию и модифицирует аргумент template_name, либо просматривает правильные шаблоны откуда-то (например, модель). Если мы не хотим добавлять декоратор к каждой функции, мы можем реализовать это как часть нашего ABMiddleware:
class ABMiddleware:
...
def process_view(self, request, view_func, view_args, view_kwargs):
if should_do_a_b_test(...) and "template_name" in view_kwargs:
# Modify the template name to one of our Path templates
view_kwargs["template_name"] = get_a_b_path_for_view(view_func)
response = view_func(view_args, view_kwargs)
return response
Нам также нужно было бы добавить какой-то способ, чтобы отслеживать, какие виды имеют A / B-тесты и т. Д.
Система для отправки зрителей по Пути
Теоретически это легко, но существует множество различных реализаций, поэтому неясно, какая из них лучше. Мы знаем, что хорошая система должна равномерно делить пользователей по пути - Нужно использовать какой-то метод хэширования - Возможно, вы могли бы использовать модуль счетчика memcache, деленный на количество путей - возможно, есть лучший способ.
Система для записи результатов теста
Нам нужно записать, сколько пользователей прошли по какому пути - нам также понадобится доступ к этой информации, когда пользователь достигнет цели (нам нужно иметь возможность сказать, по какому пути они прошли, чтобы выполнить условие цели ) - мы будем использовать какую-то модель (-и) для записи данных, а также сеансы Django или файлы cookie для сохранения информации о пути до тех пор, пока пользователь не выполнит условие цели.
Заключительные мысли
Я дал много псевдокода для реализации A / B-тестирования в Django - вышеизложенное ни в коем случае не является полным решением, но хорошим началом для создания многократно используемой платформы для A / B-тестирования в Django.
Для справки, вы можете посмотреть на Seminute A / B Пола Мара на GitHub - это версия ROR выше!
http://github.com/paulmars/seven_minute_abs/tree/master
Обновление
Что касается дальнейшего изучения и изучения Оптимизатора веб-сайтов, очевидно, что в приведенной выше логике есть зияющие дыры. Используя различные шаблоны для представления путей, вы нарушаете все кэширование в представлении (или, если представление кэшируется, оно всегда будет использовать один и тот же путь!). Вместо использования путей, я бы вместо этого украл терминологию GWO и использовал идею Combinations - это одна конкретная часть изменения шаблона - например, изменение тега <h1> сайта.
Решение будет включать теги шаблона, которые будут отображаться в JavaScript. Когда страница загружается в браузер, JavaScript отправляет запрос на ваш сервер, который выбирает одну из возможных комбинаций.
Таким образом, вы можете протестировать несколько комбинаций на странице, сохраняя при этом кеширование!
Update
Все еще есть место для переключения шаблонов - скажем, например, вы вводите совершенно новую домашнюю страницу и хотите проверить ее производительность по сравнению со старой домашней страницей - вы все равно хотите использовать технику переключения шаблонов. Имейте в виду, что вам нужно будет найти способ переключаться между X количеством кэшированных версий страницы. Для этого вам нужно переопределить стандартное кэшированное промежуточное программное обеспечение, чтобы увидеть, является ли оно A / B-тестом, выполняющимся на запрошенном URL-адресе. Тогда он мог бы выбрать правильную кэшированную версию, чтобы показать !!!
Обновление
Используя идеи, описанные выше, я реализовал подключаемое приложение для базового A / B-тестирования Django. Вы можете получить его с Github:
http://github.com/johnboxall/django-ab/tree/master