Awesome
weebo
Define Google Analytics Content Experiments with ease.
Why the name? It's the little robot from the Walt Disney movie Flubber.
Usage
Setting up experiments consists of two steps:
- Create an experiment in Google Analytics
- Add the experiment in your application
- Add variations as views/partials
Example: Experiment for a product details page
Let's say you want to experiment with your product details page which is available as http://yourdomain.com/products/a-product-slug and has its code placed in your Rails application under app/views/products/show.html.erb
.
- Create an experiment in Google Analytics with the desired name (e.g.
Product Details
) - Google Analytics asks you for the URLs for the original and variation pages. Enter
yourdomain.com/products
as the original URL and?gace_var=var_1
for the first variation's URL. Don't worry about the warning that the previews aren't shown correctly. - Google Analytics gives you a JavaScript snippet. You only need the experiment key (e.g.
13371337-1
). - Add a file
app/experiments/product_details.rb
with the following code:
Weebo.experiment :path => /^\/products\/[\w-]+/, :name => 'product_details', :code => '13371337-1'
- Create a file
app/experiments/product_details/var_1/products/show.html.erb
with the appropriate code (e.g. copy and paste the original view's code and change the things you want changed for your experiment).
Experiment settings
Every experiment has the following mandatory settings:
:path
: a regex (recommended) or string that matches the original page. Example:/^\/products\/[\w-]+/
matches/products/a-product-slug
.:name
: the name of the experiment. This is used to look up the variations on the file system and is also used as a URL parameter so use only characters that can be used in the file system and URLs. Example:product_details
will add a URL parametergace_exp=product_details
and will look for variations inapp/experiments/product_details
.:code
: the code of the experiment, generated by Google Analytics. Note that this is not your Google Analytics tracking code. Example:13371337-1
.
Developing and testing variations
To develop and test variations, simply add the gace_var
parameter with the name of a variation.
Example: Let's say you want to look at the variation named var_1
of the product details page (http://localhost:3000/products/a-product-slug
). Just add ?gace_var=var_1
to the URL and you see the appropriate variation. To look at the original, remove the parameter.
Under the hood
Design goals
weebo was developed with the following goals in mind:
- The developer(s) should be able to set up Google Analytics Content Experiments with almost zero effort.
- The developer(s) should not clutter the original views with experiment-related code.
- Use Rails default mechanisms where possible instead of scary (and brittle) hacks.
How variations are triggered
weebo takes a few steps to make adding experiments painless:
- weebo uses the routing-filter gem to hook into Rails' routing and detect whether or not an experiment has been set up for the current URL (based on the
:path
setting). If it finds a matching experiment, it sets thegace_exp
parameter to the experiment name (e.g.gace_exp=product_details
). - weebo then checks if a variation has been requested by looking at the
gace_exp
parameter. If the parameter has been set, it prepends the given variation's path to the controller's view path so they get rendered instead of the original. - If weebo finds an experiment for the current URL but no (valid) variation has been requested, it injects a JavaScript snippet at the beginning of the response's
<head>
section to trigger Google Analytics' experiment handler. - When the original page is rendered, the JavaScript snippet may or may not trigger a client-side JavaScript-based redirect to variation page – this decision is actually up to Google Analytics.
Advanced usage
Replacing partials
Replacing partials works just like replacing whole views: Put the partial containing your change(s) in the same path as your original.
Example:
# in app/views/products/show.html.erb we render the partial app/views/products/_properties.html.erb:
<%= render 'properties', :product => @product %>
To experiment with the properties
partial, add an experiment (e.g. named product_properties
) and create your changed partial in app/experiments/product_properties/products/_properties.html.erb
.
Known issues
Forms don't include experiment variables
If you use forms on experiment pages that get re-rendered in case of errors, the variation gets lost. weebo currently doesn't handle this situation automatically. You can remedy the issue by explicitly adding the gace_var
parameter to the form URL, e.g.:
<%= form_for current_user, url: edit_user_registration_path(user, params.slice(:gace_var)) do |f| %>
Note that depending on how you've defined the :path
, you might also need to adjust your regex, e.g.
# This matches /products/1/edit but not /products/1 (which would be the target of the edit form by default):
Weebo.experiment :path => /^\/products\/[\w-]+\/edit/, :name => 'edit_product_form', :code => '13371337-1'
# This, on the other hand, matches both /products/1/edit and /products/1:
Weebo.experiment :path => /^\/products\/[\w-]+(\/edit)?/, :name => 'edit_product_form', :code => '13371337-1'
TODO
- Add tests :)
- Generators/rake tasks to facilitate development (generating experiments, using a variation as the new original etc.)
- Maybe add experiment name as CSS class to body tag for easier styling?
- Maybe implement as Rack middleware rather than before/after filters?
- Maybe use the deface gem rather than replacing whole views/partials?