A traditional Test&Target deployment requires individual mBoxes to be added to specific site content that has been identified for optimization.
Example:
[javascript]
[/javascript]
This approach makes swapping in test content really easy, I just need to create an HTML Offer that contains a different image that I want to test:
Sample Offer:
[javascript]
[/javascript]
However, this approach forces you to know ahead of time what content you want to test. What happens 3 months later when you have new content you want to optimize? If you are like most organizations, you place a request into IT to have the new code deployed and they respond how happy they are to include your code in the next release that is scheduled to go out in 6 weeks.
Now what?
This is where a Global mBox Strategy becomes your friend. A Global mBox is really nothing more than an mBox deployed to every page of your site (or specific pages on which you are focusing your optimization efforts). This mBox is different than the one we described earlier in this post in that it doesn’t wrap or define any specific content on the page to be tested.
Global mBox Example:
[javascript]
[/javascript]
Now that we have our Global mBox deployed, we can test any page content we want without having to identify that content ahead of time. The method of creating your test offers will be a bit different, you will write script to manipulate the page rather than just coding in standard HTML. Once you are confortable with this approach, your ability to test when and where you want will be greatly increased.
The following video tutorial will walk you through the basics of how to execute a test using a Global mBox Strategy:
Nice suggestion! You can also pass in a parameter to the global mbox, such as the page name to help target a campaign using the global for a specific page easily. One word of warning though – depending on your mbox call allotment, global mbox calls can add up pretty quickly. To combat this, we have more actively used the location management feature within the Test & Target interface to deactivate/activate mboxes when not in use. Thanks for posting this!
Great feedback, Angie. I completely agree. I’ve recommended that my clients deploy Global mBoxes at the template or site section level (i.e. a home page global, a search global, a product global, a checkout global, etc.). This minimizes costs, as you have described, by only enabling Global mBoxes for the specific site sections being tested.
Jason –
Just want to make sure I’m understanding the inline styling concept…
You suggest hiding the content in the div first, allowing the test content to load, then undoing the inline styling to make the content appear again. And by doing this, you aren’t disabling the fail-safe in case the content doesn’t load, just switching when the content is allowed to be visible (in this case, milliseconds after whatever is going to load, test or default content).
In the video, it looks like there is a delay loading the picture. Is that due to this inline styling? And if so, is that really better than the flicker?
Thanks for the comment, Randy. You are correct, this doesn’t override the fail-safe because once you get to this point in the process, you have already activated the test offer code.
As far as the delay, this is due to the fact that the test content isn’t injected until the page has fully loaded, being within the document.ready function. As to the question if this is better than the flicker, that would be left up to each individual to determine. Of all the clients I have worked with using this solution, everyone of them has been ok with the delay in loading the content and none of them have been ok with a content flicker.
Super helpful stuff. As we have moved from a component mbox strategy to more of a global one the flicker issue had become more noticeable sitewide. Thanks for taking the time to put this together and share.