abingo project modified to work with Rails 2.2.2 and the basic memcache api
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



Rails A/B testing.  One minute to install.  One line to set up a new A/B test.
One line to track conversion.

For usage notes, see: http://www.bingocardcreator.com/abingo

Installation instructions are below usage examples.

Key default features:
  -- Conversions only tracked once per individual.
  -- Conversions only tracked if individual saw test.
  -- Same individual ALWAYS sees same alternative for same test.
  -- Syntax sugar.  Specify alternatives as a range, array,
       hash of alternative to weighting, or just let it default to true or false.
  -- A simple z-test of statistical significance, with output so clear anyone in your organization
       can understand it.

Example: View

<% ab_test("login_button", ["/images/button1.jpg", "/images/button2.jpg"]) do |button_file| %>
  <%= img_tag(button_file, :alt => "Login!") %>
<% end %>

Example: Controller

def register_new_user
  #See what level of free points maximizes users' decision to buy replacement points.
  @starter_points = ab_test("new_user_free_points", [100, 200, 300])

Example: Controller

def registration
  if (ab_test("send_welcome_email"))
    #send the email, track to see if it later increases conversion to full version

Example: Conversion tracking (in a controller!)

def buy_new_points
  #some business logic
  bingo!("new_user_free_points")  # could have been just "bingo!" if that is your only test -- I like syntax sugar

Example: Conversion tracking (in a view)

Thanks for signing up, dude! <% bingo!("signup_page_redesign") >

Example: Statistical Significance Testing

=> "The best alternative you have is: [0], which had 130 conversions from 5000 participants (2.60%).
    The other alternative was [1], which had 1800 conversions from 100000 participants (1.80%).
    This difference is 99.9% likely to be statistically significant, which means you can be extremely
    confident that it is the result of your alternatives actually mattering, rather than being due to
    random chance.  However, this doesn't say anything about how much the first alternative is really
    likely to be better by."


1)  REQUIRED: You'll need to generate a DB migration to prepare two tables, 
then migrate your database.  (Note: slight edits required if you use the table names
"experiments" or "alternatives" at present.)

ruby script/generate abingo_migration
rake db:migrate

2)  REQUIRED: You need to tell A/Bingo a user's identity so that it knows who is
who if they come back to a test.  (The same identity will ALWAYS see the same
alternative for the same test.)  How you do this is up to you -- I suggest integrating
with your login/account infrastructure.  The simplest thing that can possibly work

#Somewhere in application.rb
before_filter :set_abingo_identity

def set_abingo_identity
  if (session[:abingo_identity])
    Abingo.identity = session[:abingo_identity]
    session[:abingo_identity] = Abingo.identity = rand(10 ** 10).to_i

3)  HIGHLY RECOMMENDED: All the A/Bingo methods are accessible from the class Abingo (note capitalization!).
However, you can get some nice syntactical sugar by doing the following

#Within ApplicationController
  include AbingoSugar

#Within ApplicationHelper
  include AbingoViewHelper

3)  RECOMMENDED: A/Bingo makes HEAVY use of the cache to reduce load on the
database and share potentially long-lived "temporary" data, such as what alternative
a given visitor should be shown for a particular test.  You SHOULD use a cache
which is shared across all Rails processes -- that probably means MemcachedStore,
although you can get away with MemStore if you only have one Rails process.

You PROBABLY SHOULD use a persistent cache in case you need to restart your
machine.  This is an amazingly good use case for MemcacheDB, so if you want to
try playing with that, Google it.  (Sets up VERY easily on the newer Ubuntu distros.)

If you can't use a persistent cache, you're probably still OK if Memcached very
rarely needs to be restarted.  If the cache gets flushed, you will double-count
entrants to a particular experiment and possibly double-count conversions, but
that may not be the worse thing in the world.

A/Bingo defaults to using the same cache store as Rails.  If you want to change it

Abingo.cache = ActiveSupport::Cache::MemCacheStore.new("cache.example.com:12345") #best if really memcacheDB

Copyright (c) 2009 Patrick McKenzie, released under the MIT license