in reply to Refactoring webcode to use templates
In a previous comment on your quests (I will later find a reference) I suggested that template files must be fine-grained, performance allowing. I did not have A-B testing in mind but now that you mention A-B, this plan sounds appropriate for it.
Without thinking too much about it, the idea is that a webpage consists of several areas. You want to test your site's CR by changing any of these areas's design and see the effect it has. A fine-grain-template website means that you have a lot of "knobs" you can change and see where CR goes. Replace that template with this, in combination with the other, etc.
To make it a bit more concrete, let's say you have a site which advertises houses for rent. And you want to test whether showing picture of the house, instead of describing it in text, increases the CR. So get the house template and break it at the point where showing house pictures or text description. Eventually House (H) template which used to be solid now consists of H=Rest+Pictures-or-Text. The "fine-grain" templates means that P and T reside in different templates and that your web-serving controller which sends html to your client browsers picks any of them at random, builds a complete page and sends to the client browser. More formally, if your web page consists of areas A(let's say title),B(let's say house description),C(let's say price) and A has 3 templates, A1,A2,A3. And so does B and C. Then your controller must put a page together by choosing one of (A1,A2,A3) for A, and one of (B1,B2,B3) for B and similarly for C. Which can lead to combinations like A1,B3,C2 or A2,B2,C1 etc, all of these combinations form a complete html page which shows OK. Clarification: B1 let's say has pictures of houses but B2 has only text and B3 has both and the part 'B' is the template for showing a house. 'C' could be the template for showing prices, etc. So now you can create 3x3x3 combinations of webpages to serve to your client-browsers when they hit your site and collect back some feedback - ultimately the CR, but also time-of-stay, making-an-enquiry etc. Keep track of what you served to client-browsers and what their behaviour was. Analyse it and you can find some guidelines to enhancing the site.
Caveats: The more breakpoints you have in a single webpage (i.e. the more "knobs" you have to play with) the bigger the Space for exploring. Don't split your page in 1000 parts each with 2 options, meaning 2^1000 combinations, to serve to 5 customers per year and expect to get sound statistical results! Analysis will be rubbish. Actually given the number of your customers a statistician can tell you the maximum number of different combinations you can have.
To recap: identify in each webpage places which you can have optional layouts (show pictures or not, prices or not, even using font A or font B). Each of these layouts will be a sub-template. Picking one of each of the sub-templates an putting them together will give you a complete web-page to serve. Use your web-serving application (CGI, Mojolicious, etc.) to make the choosing and then to track the user with cookies. Quantify behaviour and when you have enough do some statistical testing of hypotheses : "Showing house pictures and hiding prices yielded most email enquiries" is this significant?
Again, a CPAN module should be most useful here ... and of course a lesson to what our life amounts to: A-B rats.
bw, bliako and clear those cookies often
|
|---|