# A/B testing using Django

DevFeed: [A/B testing using Django](<https://devfeed.tech/articles/a-b-testing-using-django-19998.md>)

Original publisher: [Read original article](<http://engineering.hackerearth.com/2016/01/29/ab-testing-using-django/>)

Published: 2016-01-29T00:00:00Z

Content type: tutorial

Language: en

Sources: [HackerEarth](<https://devfeed.tech/sources/hackerearth.md>)

Topics: [A/B Testing](<https://devfeed.tech/topics/a-b-testing.md>), [Django](<https://devfeed.tech/topics/django.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Framework](<https://devfeed.tech/topics/framework.md>), [Web](<https://devfeed.tech/topics/web.md>)

Tags: [a-b-testing](<https://devfeed.tech/tags/a-b-testing.md>), [analytics](<https://devfeed.tech/tags/analytics.md>), [code](<https://devfeed.tech/tags/code.md>), [django](<https://devfeed.tech/tags/django.md>), [framework](<https://devfeed.tech/tags/framework.md>), [testing](<https://devfeed.tech/tags/testing.md>), [web](<https://devfeed.tech/tags/web.md>)

## AI overview

This article explains how HackerEarth built a custom A/B testing framework in Django after existing third-party libraries did not meet its needs. It covers assigning users to buckets, routing users to different views or templates, supporting anonymous users, keeping assignments sticky, and tracking analytics.

## Source excerpt

Whenever we roll out an improvement on our platform, we at HackerEarth love to conduct A/B tests on the improvement to understand which iteration helps our users more in using the platform in a better way. Since the available third party libraries did not quite meet our needs, we wrote our own A/B testing framework in Django. In this post we will share a few insights as to how we accomplished this. The basics A lot of products, especially on web, use a method called A/B testing or split testing to quantify how well a new page or layout performs as compared to the old one. The crux of the method is to show layout 'A' to a certain set or bucket of users and layout 'B' to another set of users. The next step is to track user actions leading to certain milestones, which would provide critical data regarding the 'effectiveness' of both the pages or layouts. Before we began writing code for the framework, we made a list of all the things that we wanted the framework to do - Route users to multiple views (with different templates) Route users to a single view with different templates Make the views/templates stick for users A/B test visitors who do not have an account on HackerEarth (anonymous users) Sticky views/templates for anonymous users as well Support for A/A/B or A/B/C/D..../n/ testing (just for the heck of it!) Analytics We went out to grab some pizza and beer, and when we got back we came up with this wire-frame - A/B for Views A/B for Templates Getting the logic right To begin with, we had to categorize our users into buckets. So all our users were assigned a bucket number ranging from 1 to 120. This numbering is not strict and the range can be arbitrary or as per your needs. Next, we defined two constants - the first one specifies which view a user is routed to, and the second one specifies the fallback or primary view. The tuples in the first constant are the bucket numbers assigned to users. The primary view in the second constant will be used when we do not wan