ProgramingTip

Django 기반 프로젝트의 A / B 테스트에 대한 의견이 있으십니까?

bestdevel 2020. 12. 15. 19:40
반응형

Django 기반 프로젝트의 A / B 테스트에 대한 의견이 있으십니까?


이제 Django 기반 프로젝트에 대한 A / B 테스트를 시작했습니다. 이 A / B 모범 사례 또는 유용한 테스트에 대한 정보를 얻을 수 있습니까?

이상적으로 추가의 새 테스트 페이지는 Gmail과 단일 매개 변수로 구별됩니다. mysite.com/?ui=2는 다른 페이지를 제공해야합니다. 따라서 모든 뷰에 대해 'ui'매개 변수 값을 기반으로 다른 템플릿을로드하는 데코레이터를 작성해야합니다. 그리고 데코레이터에서 어떤 템플릿 이름도 하드 코딩하고 싶지 않습니다. urls.py URL 패턴은 어떻게 될까요?


코드에하기 전에 한 발 뒤로 물러나 A / B 테스트가 수행하려는 작업을 추상화하는 것이 좋습니다. 테스트를 수행해야 할 필요가 있습니까?

  • 조건이있는 목표
  • 목표 조건을 추천하기위한 두 개 이상의 경로
  • 단일를 경로 중 하나로 보안 시스템
  • 테스트 결과를 기록하는 시스템

이를 염두에두고 구현에 대해 생각해 보겠습니다.

목표

웹에서 목표에 대해 생각할 때 일반적으로 특정 페이지에 도달하거나 특정 작업을 완료했음을 의미합니다 (예 : 사용자로 사용자로 등록하거나 결제 페이지에 도달).

Django에서 우리는 몇 가지 방법으로 모델링 할 수 있습니다 .- 아마도 순진하게 뷰 내에서 목표에 도달 할 때마다 함수를 호출합니다.

    def checkout(request):
        a_b_goal_complete(request)
        ...

하지만 필요한 모든 곳에 해당 코드를 추가해야하기 때문에 또한 플러그 형 앱을 사용하는 경우 코드를 편집하여 A / B 테스트를 추가하는 것을 선호하지 않습니다.

뷰 코드를 직접 편집하지 않고 A / B 목표를 어떻게 도입 할 수 있습니까? 미들웨어는 어떻습니까?

    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":

경로

Django의 경로는 생각할 때 다른 템플릿을 사용하는 아이디어로 이동하는 것이 당연합니다. 탐구해야 할 다른 방법이 있는지 여부. A / B 테스트에서는 두 페이지간에 작은 차이를 만들어 결과를 측정합니다. 따라서 모든 목표 경로가 확장되어야하는 단일 기본 경로 템플릿을 정의하는 것이 가장 좋습니다.

어떻게해야합니까? 데코레이터는 아마도 좋은 시작일 것입니다. 데코레이터가 template_name실행 에이 매개 변수를 설명 수있는 뷰에 매개 변수 를 포함 하는 것이 Django에서 모범 사례입니다 .

    @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 세션 또는 쿠키를 사용하여 사용자가 목표 조건을 선택할 때까지 경로 정보를 유지합니다.

마무리 생각

Django에서 A / B 테스트를 구현하기 위해 많은 의사 코드를 제공했습니다. 위의 내용은 완전한 솔루션은 Django에서 A / B 테스트를위한 추가 가능한 프레임 워크를 시작합니다.

참고로 GitHub에서 Paul Mar의 Seven Minute A / B를 볼 수 있습니다. 위의 ROR 버전입니다! http://github.com/paulmars/seven_minute_abs/tree/master


최신 정보

Google 웹 사이트 최적화 도구에 대한 추가 검토 및 조사에서 위의 논리에 빈틈이있는 것이 분명합니다. 경로를 나타냅니다. 내기 위해 다른 템플릿을 사용하면 뷰의 모든 캐싱이 중단됩니다 (또는 뷰가 캐시 된 경우 항상 경로가 제공됩니다!). 대신 경로를 사용하는 대신 GWO 용어를 훔쳐서 사이트 Combinations<h1>태그를 변경하는 것과 같이 템플릿 변경의 특정 부분 이라는 아이디어를 사용합니다 .

솔루션에는 JavaScript로 처리되는 템플릿 태그가 포함됩니다. 페이지가 브라우저에로드되면 JavaScript는 가능한 조합 중 하나를 가져 오는 서버에 요청을 보냅니다.

이렇게하면 캐싱을 유지하면서 페이지 당 여러 조합을 테스트 할 수 있습니다!


최신 정보

여전히 템플릿 전환의 여지가 있습니다. 예를 들어 완전히 새로운 홈페이지를 도입하고 이전 홈페이지에 대해 성능을 테스트하려는 경우 템플릿 전환 기술을 계속하고 있습니다. 명심해야 할 점은 페이지의 캐시 된 버전 중 X 개 사이를 전환하는 방법을 찾아야 것입니다. 이렇게 비용이 많이 드는 표준 캐시 된 미들웨어를 재정렬해야하는 요청 된 URL을 확인해야합니다. 그런 다음 표시 할 올바른 캐시 버전을 선택할 수 있습니다 !!!


최신 정보

높은 아이디어를 사용하여 기본 A / B 테스트 Django를위한 플러그 형 앱을 구현했습니다. Github에서 찾을 수 있습니다.

http://github.com/johnboxall/django-ab/tree/master


Django lean은 A / B 테스트를위한 좋은 옵션입니다.

http://bitbucket.org/akoha/django-lean/wiki/Home


제안 ( ?ui=2) 과 같이 GET 매개 변수를 사용하는 경우 urls.py를 전혀 터치 할 필요가 없습니다. 데코레이터는 request.GET['ui']필요한 것을 검사 하고 있습니다 .

템플릿 이름을 하드 코딩하지면보기 함수에서 반환 값을 래핑 할 수 있습니까? render_to_response의 출력을 반환하는 대신 튜플을 반환 (template_name, context)하고 데코레이터가 템플릿 이름 을 엉망으로 만들 수 있습니다. 이런 건 어때? :이 코드를 테스트하지 경고합니다.

def ab_test(view):
    def wrapped_view(request, *args, **kwargs):
        template_name, context = view(request, *args, **kwargs)
        if 'ui' in request.GET:
             template_name = '%s_%s' % (template_name, request.GET['ui'])
             # ie, 'folder/template.html' becomes 'folder/template.html_2'
        return render_to_response(template_name, context)
    return wrapped_view

이것은 정말 기본적인 예이지만 아이디어가 전달되기를 바랍니다. 템플릿에 많은 정보를 추가하는 등 응답에 대한 몇 가지 다른 사항이 있습니다. 예를 들어있는 시나리오 변수를 사용하여 Google Analytics와 같은 사이트 분석과 통합 할 수 있습니다.

보너스로 GET 매개 변수 사용을 중단하고 쿠키 등을 기반으로하는 것으로 이동하기로 결정한 경우 나중에이 데코레이터를 리팩토링 할 수 있습니다.

업데이트 이미 많은 뷰를 작성했는데 모두 수정하고 싶지 않은 경우 render_to_response.

def render_to_response(template_list, dictionary, context_instance, mimetype):
    return (template_list, dictionary, context_instance, mimetype)

def ab_test(view):
    from django.shortcuts import render_to_response as old_render_to_response
    def wrapped_view(request, *args, **kwargs):
        template_name, context, context_instance, mimetype = view(request, *args, **kwargs)
        if 'ui' in request.GET:
             template_name = '%s_%s' % (template_name, request.GET['ui'])
             # ie, 'folder/template.html' becomes 'folder/template.html_2'
        return old_render_to_response(template_name, context, context_instance=context_instance, mimetype=mimetype)
    return wrapped_view

@ab_test
def my_legacy_view(request, param):
     return render_to_response('mytemplate.html', {'param': param})

저스틴의 대답이 옳습니다. 그가 처음이었던 것처럼 저스틴에 투표하는 것이 좋습니다. 그의 접근 방식은이 A / B 조정이 필요한 여러보기가있는 경우 특히 유용합니다.

그러나 몇 개의 뷰만있는 경우 데코레이터 나 urls.py를 변경할 필요가 없습니다. urls.py 파일을 그대로 두었다면 ...

(r'^foo/', my.view.here),

... request.GET을 사용하여 요청 된 뷰 변형을 확인할 수 있습니다.

def here(request):
    variant = request.GET.get('ui', some_default)

개별 A / B / C / etc 뷰에 대한 템플릿 이름을 하드 코딩하지 않으려면 템플릿 이름 지정 체계에서 규칙을 지정하면됩니다 (Justin의 접근 방식에서도 권장 됨).

def here(request):
    variant = request.GET.get('ui', some_default)
    template_name = 'heretemplates/page%s.html' % variant
    try:
        return render_to_response(template_name)
    except TemplateDoesNotExist:
        return render_to_response('oops.html')

Justin Voss의 코드를 기반으로 한 코드 :

def ab_test(force = None):
    def _ab_test(view):
        def wrapped_view(request, *args, **kwargs):
            request, template_name, cont = view(request, *args, **kwargs)
            if 'ui' in request.GET:
                request.session['ui'] = request.GET['ui']
            if 'ui' in request.session:
                cont['ui'] = request.session['ui']
            else:
                if force is None:
                    cont['ui'] = '0'
                else:
                    return redirect_to(request, force)
            return direct_to_template(request, template_name, extra_context = cont)
        return wrapped_view
    return _ab_test

코드를 사용하는 예제 함수 :

@ab_test()
def index1(request):
    return (request,'website/index.html', locals())

@ab_test('?ui=33')
def index2(request):
    return (request,'website/index.html', locals())

여기서 일어나는 일 : 1. 전달 된 UI 매개 변수가 세션 변수에 저장됩니다. 2. 동일한 템플릿이 매번로드되지만 컨텍스트 변수 {{ui}}가 UI ID를 저장합니다 (템플릿을 수정하는 데 사용할 수 있음). 3. 사용자가? ui = xx없이 페이지를 입력하면 index2의 경우 '? ui = 33'으로 리디렉션되고 index1의 경우 UI 변수가 0으로 설정됩니다.

3을 사용하여 기본 페이지에서 Google 웹 사이트 최적화 도구로 리디렉션하면 적절한? ui 매개 변수를 사용하여 기본 페이지로 다시 리디렉션됩니다.


이 답변은 오래된 것 같습니다. 요즘 Google Analytics는 대부분의 사이트에서 가장 인기 있고 최고의 무료 옵션 일 것입니다. 다음은 django와 Google Analytics를 통합하기위한 몇 가지 리소스입니다.

플러그인 :

방법 :


Django-lean은 멋져 보입니다. 나는 그것을 알아 내려고 노력할 것입니다. 나는 내가하려는 일에 충분한 내 자신의 솔루션을 롤링했습니다. 나는 그것을 멋지게 포장하고 초보자가 사용하기 쉽게 만들려고 노력했습니다. 매우 기본적이며 시도해보십시오.

https://github.com/crobertsbmw/RobertsAB


나는 이것을 보는 사람이 도움이 될 수 있도록 django에 대한 분할 테스트 예제를 작성했습니다.

https://github.com/DanAncona/django-mini-lean

당신이 그것에 대해 어떻게 생각하는지 듣고 어떻게 더 도움이 될 수 있는지 듣고 싶습니다!

참조 URL : https://stackoverflow.com/questions/752919/any-thoughts-on-ab-testing-in-django-based-project

반응형