Test and Target Redirects + Audit Data

In a post about using Test&Target's HTML offer type to handle content redirects, I talk about how I prefer to build my own redirect logic over using T&T's available "redirect" offers.  There are many reasons for this preference, but I think they can all be summed up in one word:  Flexibility.

To me, flexibility is important.  Being able to create the right solution for the situation is a must, and without flexibility, the right solution isn't always possible.  This post outlines at least one example of how we can use the flexibility of an HTML offer to provide the right solution where a "redirect" offer might be considered.

The Problem

For a recent client request, we were faced with a situation that required redirecting visitors from a page where making code changes was not an option.  The good news was that an mbox already existed on the page.  The bad news, however, was that we were not allowed to make any changes to the code on that page.  At least we had something to latch onto!

To add a fair amount of complexity, there was the potential of dozens (maybe hundreds) of different hostnames being used with an equal number of redirect destinations.  The potential of this becoming a campaign management/maintenance/architecture nightmare was quite real.

The Solution

Once the scope of the situation was apparent, we came up with a fairly creative solution that involved use of the following:

• Query string parameters
• Because all traffic would be coming from a series of emails, we had the option to use custom query string parameters.  We took advantage of this by passing the ultimate redirect destination to the page as a parameter.
• The existing mbox
• Using the existing mbox, we had an entry point for the test.  This also meant that we had access to anything that was passed to the page via the query string, which was a major blessing that we took full advantage of as noted above.
• A single HTML offer 
• Obviously, the standard "redirect" offer was not an option here.  We needed something more flexible and capable.  We needed something that could serve as a dynamic interface for the campaign by reading the URL and identifying the redirect destination on the fly.  It also needed to keep track of each unique hostname along the way.
• A dynamic mbox call
• Due to the potentially overwhelming number of hostnames we might have to deal with, we needed a way to easily segment the results.  Manually building segments in the campaign interface was not a workable option.  Instead, we settled on the idea of dynamically generating an mbox call from within the HTML offer.  This made it possible for us to segment the data by hostname using T&T's Audit feature.  
• T&T's Audit data feature
• By taking a creative approach, we were able to capture each and every hostname thrown our way.  We simply passed the hostname into the dynamic mbox called noted above using the purchasedProductId parameter name, assigned random order ID's and a static purchase amount and we had everything we needed to segment the data by hostname.  This turned out to be a great way to use the Audit data feature.

To sum it all up, we simply passed the redirect destination to the page through a query string parameter and parsed the URL for the necessary information.  Once we had the information we needed, we generated a dynamic mbox call that that passed the hostname (to populate the Audit data) before ultimately initiating the redirect.

In the end, we accomplished this all with no code changes on the existing web page and a single HTML offer with a few lines of JavaScript and a dynamic mbox call.  This was made possible because of the flexibility HTML offers provide.  

How have you used Test&Target's Audit feature in the past?  Have you faced similar challenges in the past?  How have you addressed them?  Let us know in the comments.

~ b