How Omniture Test & Target Works: High-Level Implementation, Administration & Use Review

Many visitors have written to me asking for a quick overview of Test & Target. So I decided to post this non-authoritative quick overview, which you should take at face value. Costs associated with Omniture Test & Target are implementation and monthly fees dependent on extent of use (i.e. number of calls made to the T&T servers to return content to a client’s website), even though the minimum fee structure covers millions of server calls quite affordably for the marketing budget of a successful website. That said, smaller websites may not be able to make a good ROI argument in favor of T&T.

In brief, one puts small pieces of JavaScript code on the website that need Test & Target implemented–think of these as placeholders. Then upon logging in to the T&T admin interface, these placeholders show up since the JavaScript code communicates with the T&T server as soon as the first page with the JS code is loaded in a browser. From there, one can assign different types of contents wrapped in testing and/or targeting logic i.e. campaigns. Now, every time that a page with T&T JS code (i.e. mBox) loads, the mBox calls the server to see what it should do (if anything at all) and the server consults the campaigns aimed at the mBox in question, decides what needs to be sent to the mBox, sends it, and the mBox processes the response. The response from the server could be simple HTML in which case it will be shown to the visitor, or it can be further JavaScript code which modifies things such as CSS (formatting and styles) or more even more complex code that alters other things on the page.

I have cut the above paragraph into further detail to cover implementation, administration, targeting and reporting. Best practices–at least in my opinion–are built in to the text.

Implementation: Tagging Web Pages & Creating mBoxes

This is very simple and straightforward:

  1. A main JS library is uploaded to the web server, usually called “mbox.js”. This includes all of the functions needed to turn a tagged area of a webpage into an mBox, as well as methods for these mBoxes to communicate with the T&T server bi-directionally.
  2. Then comes the hardest part of implementation, which is to figure out what parts of which web pages to tag for manipulation via T&T. Ideally this is based on web analytics (perhaps from SiteCatalyst or Google Analytics) as well as visitor input, and not as much executive gut feeling. Some things to consider are:
    • Start small, you can always add more mBoxes. But if one delays one’s implementation because one is trying to tag everything one could possibly test, then the ROI and perhaps level of approval for T&T drops before it even starts working.
    • Limited elements being tested in each test. Unless you have intentionally and very diligently devised a multivariate test, and even then, keep test elements limited to avoid cross-contamination affecting your results.
    • Isolate tests to get best results. Needless to say, keep tests separate, so that you can discern the outcomes from one another.
  3. Once mBox locations are decided, creating them is as simple as putting a DIV tag around the default content you want to swap out when testing and following it with a one-line JavaScript snippet, while having the following in mind:
    • Do not overload your pages with mBoxes. As non-intrusively as they are designed to work, they still require communication with a third-party server i.e. T&T to show some of the content of the page. The more of them on a page, the more chances of slowing down load or at least page render time.
    • Assign a header mBox used solely for JavaScript content. Unless you already have too many mBoxes, it is a good idea to assign one at the header to use for pushing content changes via JavaScript e.g. changing CSS classes, formatting, etc. Of course since mBoxes require DIV tags, header means somewhere towards the top of the BODY tag, NOT before it.
    • Default content within the mBox, will be displayed if there is a connection failure or T&T server issue. Therefore, do not entirely change the functionality of the default content when swapping it out for test content. The visitors should be able to use the website even if none of the mBoxes work.
  4. After visiting every web page with mBoxes on it at least once, they should be available in the Test & Target administrative interface to use as containers for testing and targeting. This is explained at a very high level in the next section.

Administration: Creating & Managing Campaigns

It is far beyond the scope of this article to explain testing or targeting principles, let alone the specific manner in which they are executed in T&T. However, at a high level, campaigns determine based on testing  parameters (e.g. 50% of the visitors get version A ) and targeting settings (e.g. visitors from Google get this content, or visitors that viewed a product get this cart color) what content needs to be served via which mBox. There can be multiple mBoxes involved in a single campaign, as well as the same mBox in multiple campaigns with each campaign assigned a priority.

There are several settings to fine-tune a segment of visitors in targeting campaign or test at all levels, from campaign, down to recipes (i.e. the different versions of content served) and mBoxes. Even inclusion in one campaign can be used to determine the segmentation in the next campaign, e.g. show this test only to people who have not seen the other test.

As said earlier, there is far too much on this topic to fit here. But I hope this provides a high-level overview of what T&T campaign are.

Why the “& Target” If It is Just for Testing?

It is not! The targeting capabilities can be used absolutely independently of the testing functionality. One can use the platform to serve something as simple as “Welcome Googlers!” to visitors referred by Google, “Welcome Bingers!” to people who came from Bing, and “Welcome Back!” to returning visitors–even though I would recommend using server-side functionality for such things, T&T does make it easier to deploy similar targeting campaigns by non-technologists.

However, one will quickly realize that testing and targeting go hand in hand and are inherently part of one another. When one tests, one inevitably targets certain user segments even if it is a basic 50% get version A and 50% get version B. And when one targets, one can see how differently every segment of visitors get affected by being served personalized content, even if it is a simple “Welcome Back!” vs. “Welcome!” for returning and new visitors.

Do I have to Be a Statistician to Interpret Test Results?!

Absolutely not! While awareness of common-sense practical mathematics (such as knowing that 30% + 30% + 40% = 100%) helps, Test & Target has built-in functionality to provide simple-to-read reports that outline the test results with a helpful–while not always safe to depend on–confidence gauge that indicates how probable the real-life accuracy of the report one is reviewing is. There are methods (official work-arounds) to integrate reporting into SiteCatalyst, but in my opinion none to the level of tight integration that some other Omniture tools have such as SearchCenter.

Competitors: Who Else Offers Such a Service?

There are many ecommerce platform with partial built-in testing functionality or means of targeting content to user segments (Magento has the latter one covered for most use cases) and Google Website Optimizer is a good free tool for this, but I have not used it and would only guess that just like Google Analytics–which I do use heavily–may have shortcomings in utilization of advanced custom metrics for targeting and segmentation. This does not mean that it Google Website Optimizer must be ignored as an option, particularly as a testing platform, as it is a viable option for many small, medium or even large businesses. If I do get around to using it, I will write an article on it.

I reviewed and tested SiteSpect™ in 2008 and found them to have a very desirable service with whole-page regular-expression-style find-and-replace for testing and targeting via their proxy servers. However, the proxy aspect of it was the main adverse issue for me since it meant the website’s IP address would change for a percentage of visitors and potentially all of them, including search engines; and unless their service or license was retained one would have to relinquish the IP address. They do offer an on-premise solution which would circumvent the IP address issue, but that is no longer a testing & targeting “service,” but an application installed on one’s own servers and not suitable for comparison to T&T as a hosted solution, not to mention being cost-prohibitive for most small- and medium-sized websites.

In Closing, I would like to say that I use to be a very strong opponent of client-side testing and particularly targeting (due it is more permanent nature) however the cons of using a server-side proxy-style testing platform such as SiteSpect™ (e.g. potential SEO issues due to IP changes, dependence on provider’s server for whole page content, lack of default fall-backs in most cases) far outweigh their pros, and Omniture T&T delivers high level of control into the hands of non-technologist marketers with relatively minimal implementation needed. Of course, it is wise to utilize server applications for more permanent targeting when available on one’s server platform, as it will nto only eliminate JavaScript calls to T&T servers, but also lower the cost of use.

Be Sociable, Share!