Ответ 1
Полезно сделать шаг назад и отвлечь то, что A/B тестирование пытается сделать, прежде чем погрузиться в код. Что именно нам нужно будет провести?
- Цель, имеющая условие
- Как минимум два разных пути для достижения цели цели
- Система для отправки зрителей по одному из путей
- Система записи результатов теста
С учетом этого подумайте о реализации.
Цель
Когда мы думаем о цели в Интернете, мы обычно подразумеваем, что пользователь достигает определенной страницы или выполняет определенное действие, например, успешно регистрируется как пользователь или попадает на страницу проверки.
В Django мы могли бы моделировать это несколькими способами - возможно, наивно внутри представления, вызывая функцию всякий раз, когда достигнут Цель:
def checkout(request):
a_b_goal_complete(request)
...
Но это не помогает, потому что нам нужно будет добавить этот код везде, где он нам нужен - плюс, если мы будем использовать любые подключаемые приложения, мы бы предпочли не редактировать их код, чтобы добавить наш тест A/B.
Как мы можем ввести A/B Goals без прямого редактирования кода просмотра? Что относительно промежуточного ПО?
class ABMiddleware:
def process_request(self, request):
if a_b_goal_conditions_met(request):
a_b_goal_complete(request)
Это позволит нам отслеживать цели A/B в любом месте сайта.
Откуда мы знаем, что были достигнуты условия? Для простоты внедрения я предлагаю, чтобы мы знали, что цель достигнута, когда пользователь достиг определенного URL-адреса. В качестве бонуса мы можем измерить это, не загрязняя руки во взгляде. Чтобы вернуться к нашему примеру регистрации пользователя, мы могли бы сказать, что эта цель была достигнута, когда пользователь достиг пути URL:
/регистрация/полная
Итак, мы определяем a_b_goal_conditions_met:
a_b_goal_conditions_met(request):
return request.path == "/registration/complete":
Дорожки
Когда вы думаете о Paths в 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 Sessions или Cookies, чтобы сохранить информацию Path, пока пользователь не выполнит условие цели.
Заключительные мысли
Я дал много псевдо-кода для тестирования A/B в Django - выше это ни в коем случае не полное решение, а хорошее начало создания многоразовой структуры для тестирования A/B в Django.
Для справки вы можете посмотреть на Paul Mar Seven Minute A/Bs на GitHub - это версия ROR выше! http://github.com/paulmars/seven_minute_abs/tree/master
Обновление
При дальнейшем анализе и исследовании Оптимизатора веб-сайта Google очевидно, что в вышеприведенной логике есть щели. Используя различные шаблоны для представления Paths, вы разбиваете все кеширование в представлении (или если кэширование в представлении всегда будет служить одному и тому же пути!). Вместо этого, используя Paths, я вместо этого украл бы терминологию GWO и использовал идею Combinations - это одна конкретная часть изменения шаблона - например, изменение тега <h1> сайта.
Решение будет включать теги шаблонов, которые будут отображаться на JavaScript. Когда страница загружается в браузере, JavaScript делает запрос на ваш сервер, который извлекает одну из возможных комбинаций.
Таким образом, вы можете протестировать несколько комбинаций на странице при сохранении кеширования!
Обновление
По-прежнему есть место для переключения шаблонов - скажем, например, вы вводите совершенно новую домашнюю страницу и хотите проверить ее производительность на старой домашней странице - вы все равно хотите использовать технологию переключения шаблонов. Следует иметь в виду, что вам нужно найти способ переключения между X-кешированными версиями страницы. Для этого вам необходимо переопределить стандартное кэшированное промежуточное программное обеспечение, чтобы проверить, является ли это тест A/B на запрошенном URL-адресе. Затем он может выбрать правильную кешированную версию, чтобы показать!!!
Обновление
Используя описанные выше идеи, я применил подключаемое приложение для базового тестирования A/B Django. Вы можете получить его от Github: