I recently had a question come up of how one could do A/B Testing in Tridion. There are some old Tridion plugins out there, and it would certainly be possible to develop an Alchemy extension for one today. But there is an easy way that you could optionally show/hide components, that could be implemented in just a few hours? Yes, there is.
The parts of an A/B test
Let’s start with all of the parts of an A/B test that you may want:
- A way to associate two components together
- A mechanism to decide whether to show A or B
- A mechanism to show A or B
- The ability to send data about which item, and which page, has been shown
Associate two components on a page
An easy way to do this is with metadata. Especially if you’re looking at DD4T, metadata is in the model of a component. So create a field called test_against
in the metadata for your schema. Let it be a plain text field, where the content author can input the TCM-id of the other component that this is tested with.
Then, go to each component to test, and fill in your “test_against” field.
Component | Component’s TCMID | test_against field in metadata |
---|---|---|
A | tcm-12345 | tcm-54321 |
B | tcm-54321 | tcm-12345 |
A Mechanism that can decide whether to show A or B
For this example let’s make that mechanism a slight change to your URL.
Instead of fancysite.com/buy/our/fanciest.aspx, let’s add a parameter to to the url:
fancysite.com/buy/our/fanciest.aspx?test=12345
So, whenever we send out that particular URL, what we want is for only a component with TCMID tcm:12345
to be visible.
So what we’re suggesting is that content authors and campaign managers are making a conscious decision, somewhere in their materials, to send out a link to the A page, or the B page, or otherwise they’re linking to A or B pages within Tridion.
A Mechanism to show A or B
This comes in two parts
Tweak the Component Template
In your view or component template, you want to add a data-attribute
to your container, in the markup.
Our goal is to add data attributes called data-testagainst
and data-test
to the container:
@model IComponentPresentation @ { var c = Model.Component; var compId = c.Id.Replace(":", "-"); }
Add some JavaScript to the page
What we want is a few lines of JavaScript that, on page load, will hide one of the two components.
We do this in a few steps:
- Extract Parameters from the URL (urlParams)
- Find the element that we want to display by querying for an element whose
data-test
value matches what’s in the URL ( elementToShow) - Find the element to hide by searching based on elementToShow‘s
data-against
attribute ( elementToHide) - Hiding the element
function runABTest() { const urlParams = new URLSearchParams(window.location.search); const elementToShow = document.querySelector(`[data-test="${urlParams.get('test')}"]`); const elementToHide = elementToShow ? document.querySelector(`[data-test="${elementToShow.dataset.testagainst}"]`) : undefined; if (elementToHide) elementToHide.style.display = 'none'; } window.addEventListener('load', runABTest());
What we’re also doing is putting in a small amount of logic, via a ternary operator and an if
statement, to make sure that the code only ever gets executed when we find an elementToShow
Sending Data about the item shown, and the page
As long as you’ve got Google Analytics or Adobe Analytics installed, then you’re set. The parameter in the URL will show up in your analytics and tell you that a user went to a page where a test was shown.
Put it all together
The final step for this is to put both components on a page, and then publish it.
Then the content author/campaign manager shares out one of two urls:
- fancysite.com/buy/our/fanciest.aspx?test=tcm-12345
- fancysite.com/buy/our/fanciest.aspx?test=tcm-54321
The JavaScript takes care of hiding the component, and the analytics that are already on the page captures the results!
Caveats and Whatnots
This is the cheap, affordable, easy-to-deliver, approach to A/B testing. A/B testing is ideally done server-side, and the best A/B testing works without parameters to the URL. But, for a quick test of which two components might be most effective for a page, this could work.
Permalink
I’ve probably seen most of the ways to manage variations of content for personalization or show/hide functionality from Experience Optmization to Profiling & Personalization to variations in pages, content on a page, metadata, or linked items..
I’d be interested in seeing how you felt about Experience Optimization’s Content Experiment feature.
https://docs.sdl.com/LiveContent/content/en-US/SDL%20Web-v5/GUID-A0271A4E-CDE9-49F5-9ED1-5DBD45628AB7