If you wanted to go with a homemade solution instead of existing services (e.g. Optimizely, experimently, or convert) I'd suggest the following:
Generate the code
Your server side code generates the recipes (layouts) for the user based on whatever metrics you want . This is commonly just a % of traffic split. Don't forget to include the unaltered version to compare your data to.
Give it an identifier
When your server side code generates the recipes, it should include the a specific value for a custom variable for that page. This unique value should include an identifier to each recipe displayed on the page. E.g. if you have menu A, headline D, and body image G you'd have A:D:G
. If you had menu C, headline E, body image I, you'd have C:E:I
.
The type of custom variable depends on your test. Session level would allow you to see how that specific recipe affected the user within a visit. A more standard method would be to set it to a visitor level would allow your recipes to have attribution on returning visits.
Run the test & analyze the results
From there, run the test, gather your data. Once you feel you have statistically significant results, you can stop the test and start to fully analyze your data.
Notes
- The names of the recipes should be unique. For instance, I used A - C for the menu, D - F for the headline, and G - I for the body image. This allows you to create segments based off of that recipe.
- Don't forget to include the control recipe IDs in your test!
- If you're running multiple tests (even if not at the same time), I'd strongly suggest prefixing the custom variable value with the test name / identifier.
This is essentially what Google Experiments does with A/B testing on their backend.