Maintainers

Classifiers

Have you ever wanted to A/B test multiple code paths on your backend? Consider
the following: management wants you to cut down on server costs. You come to
terms with the fact that you really don’t need a 128 GB memory 32 core beast
for your coconut store — but how low can you go? Let’s test how a slower
coconut catalog page affects conversion! (First, without tracks.)

Now, this kinda works, but it’s already a bit messy and can easily get out of
hand if you consider that right now:

The thing you test is really, really simple

You don’t lock a user’s version to make sure they always get the same test
variant, making your data more mushy with each page load.

You don’t exclude your most important users from testing to avoid hurting
conversion among coconut addicts in your initial test run. (Of course you
will need to include them later to make an informed decision.)

You already have a few more ideas about things you want to A/B test. Maybe
a hundred.

You can add another 5 engineers to the project and they will probably each
implement these tests slightly differently, and that’s no good.

The key will be serialized to a string and the variant to use will be derived
from that string. The key of course can be anything; in most cases it might be
the user ID, but you could use a combination of the user’s country and the
article ID for instance. (Not sure why you would want this specific example,
but you get the point.)

So, with that solved, list item #3, here we come! What if we’re worried about
our top customers being mad at us for testing things on them? Easy peasy.

classDelayTracks(tracks.SimpleTrackSet):@propertydefis_eligible(self):returnnotself.context['user']['is_vip']# code of variants trimmedresponse=render_coconut_catalog()withDelayTracks(context={'user':user_dict})astrack:track()# will always be control for VIPs (even with `add_control_group = False`)iftrack.is_eligible:cur.execute('INSERT INTO test_runs (user_id, variant) VALUES (%s, %s)',(user_id,track.name))returnresponse

And finally, let’s try running the delay and pricing tests at the same time!

So, with this, tracks will gather all tests the user is eligible for, and
choose one of them based on the given key. We could also set
DelayTracks.weight to 1000 to make that one ten times as likely to be used
as the pricing one (the default weight is 100.)