We have just finished the first stage of migrating product suggestion blocks—showcase boxes for top-sellers or products bought by people who viewed a certain product—from Test & Target™ APS (Advanced Product Suggestion) to the now separate Omniture™ Recommendations. Since the day I was notified of their intent to extract APS from Test & Target, I was very hopeful that this would prove to be a great logistical decision and so far everything points to the same. I hope to paint a high-level user-oriented picture of how this “newly-emancipated” tool works. Many low-level technical details have been spared for the sake of breadth of coverage; however do feel free to ask any question.
As a whole
Overall, the more focused application has a simpler interface, especially as compared to its parent: Test & Target, which even with the recent release of a newly revamped user interface, is still justifiably far more complex than the product recommendation service. This simplicity does come at the price of lack of targeting and advanced testing functionality. But not to worry, as most Recommendations™ campaigns are also available for more advanced editing, segmentation and targeting in Test & Target for customers with both products in their Omniture Suite.
Furthermore Omniture is trying to morph the image of this tool from the product-specific nature of the suggestions into a more versatile one that could cover any type of analytical business-logic-based recommendation. Having changed the basic unit of suggestion from product to entity seems to fit this goal well as a first step and allows one to think of uses far beyond product suggestions. However, there is much left to do to allow the efficient handling of multiple entities in one Recommendations™ account, hence the word “product” in the title of this article.
New Whole-Block Templates: A Simple but Necessary Change
There is also a nifty list of all possible variables that can be used in the template to the right of the edit window.
There is also a vast array of new algorithms that can base recommendations on metrics in any SiteCatalyst Report Suite. This integration not only allows for more metrics to be used in constructing a recommendation customized to each website’s specific needs, but also reduces the dependence on “mboxes” for recording product or entity data to be used in the recommendations through both an XML API and a very simple CSV upload interface to feed entities into the application. In turn this virtually eliminates the need to wait for mboxes to gather enough data to recommend correctly, as SiteCatalyst report suites can be leveraged retroactively, making data that was recorded prior to the Recommendations launch available to the application.
One issue we faced here was the lack of a custom setting to map entity IDs to a SiteCatalyst eVar. This is preset to consider the “s.products” variable, the primary key for all entity-related metric lookups in SiteCatalyst. And since we record the most granular piece of data in our “s.products” i.e. the SKU and yet base recommendations on the product family ID, a higher-level piece of data, we are not easily able to leverage SiteCatalyst data for recommendations in one of our report suites.
New Recommendation Algorithms: People Who Viewed This Viewed That & More
Another largely missing feature in APS was the ability to display “people who viewed this viewed that” offers. While such offers might not be as helpful to website that convert most of their traffic online, they are crucial to a website such as ours where about 60% of the orders are placed offline due to high value or customizations, since a Product View is the next best metric after Orders in our situation. We used to have to settle for “most popular in this category” recommendations by passing the category ID of the product being viewed to show others that were viewed in that category by most visitors. However, the new application includes an algorithm for exactly what we need in addition to other advanced functionality such as basing the suggestion on a visitors last purchased item instead of the item being viewed. Below are screenshots of some of the possible product recommendation algorithms in the current version, most of which were added a few days ago in the new release of this rapidly evolving product.
Highly Customizable Algorithms
Just as their predecessors, these algorithms are further customizable using inclusion criteria that a recommended entity must meet—limited to the price range, inventory and one custom attribute. However, much more flexibility is added by custom attribute weighting capabilities allowing for entities with certain values for any attribute to be given more or less priority in the algorithm. Currently, this is done through a simple weight slider with five possible values, which can be considered the equivalent of 1-through-5 numerical scale.
Paired with entity data uploads and SiteCatalyst integration, this means that one can give high-profit-margin entities precedence over the rest, or push entities with lower conversion rates down in the list. The possibilities of fine-tuning algorithms can be quite limitless, but unfortunately the current version is limited to exact equations e.g. entities with a margin exactly equal to 40%. More conditional statements without complicating the user-interface are another set of features I hope to discuss at the CAB meetings.
For even more control, using simple XML APIs one can create a custom algorithm that suggests entities based on a custom list of recommendations uploaded for any given key.
Below are some screenshots of example customizations.
Global Exclusion Criteria & Default Recommendations
While most algorithms can be tailored to fit almost any business need or goal, there are global rules to exclude certain entities from the whole application as well as a set of default entities to be recommended when there are not enough entities to fill the template. The latter cannot be set by the user at the time being, and the former is available in the admin settings area through exact-equation criteria only. As you can imagine, this is quite basic in the current version and has room for much improvement that I have no doubt will come in the future.
Recommendation List Download and Preview
One of the most crippling problems with APS was the lack of an easy way for a non-technologist to test the waters before launching a campaign or even keep the recommendations in check while the campaign was running by reviewing what is being recommended for what. This is exactly what the download recommendation feature available in every campaign and through a REST API call allows one to do. With the simple click of a mouse, one can download a list of all entities and their respective top 10 recommendations in order. This eliminates the need to frantically surf one’s website in hopes of seeing as many different recommendations as possible to ensure their consistency and catch any that need to be excluded or modified. The list is broken down by algorithm to allow for a complete overview of how entities are recommended in a given campaign.
Of course, the ever-so-buggy Omniture OnSite™ preview tool is also available as inherited from Test & Target and in some browsers allows for a visual preview of campaigns and recipes.
Some Testing Capabilities
Even though the testing functionality is much richer in Test & Target, there are sufficient measures inherited by Recommendations. This quite basically boils down to testing multiple recommendation algorithms and different layout templates in the same mbox. One can add additional algorithms for any recommendation block as well as extra display templates. These are then multiplied by one another to produce recipes for the campaign—just like a small multivariate test. There is no need to do anything else to start testing, as this is part of the default behavior.
The recipes cannot be targeted by percentage or other criteria like they can in Test & Target, but the percentage of visitors seeing default content (what is statically in the mbox before any recommendations are generated) can be adjusted, which for most campaigns is senseless since comparing recommendations vs. no recommendations is usually not what we are after due the large difference between the reasons and logistics of having either on a web page. This is the same reason for which we usually do not test the same recommendation in different mboxes—this can sometimes be a legitimate test.
In the screenshot below you can see that three algorithms and two templates added to the campaign, which creates 6 recipes in addition to the default one and reports on them.
Rawbox: Raw HTML Delivery for Emails
Somewhat like Test & Target’s AdBox that is used to deliver dynamic content to off-site locations, the Rawbox method is supposed to deliver raw HTML to be included in emails. however, this is more complex than it seems. Your email service provider (ESP) must dynamically call the Rawbox URL for each subscriber and include the returned HTML in the message being sent. But most advanced ESPs have such functionality at a cost. If implemented correctly, the engine will report on the email recommendations as it would on normal ones and continue tracking on-site.
Reporting Cursory but Actionable
As visible in the screenshot above, the reporting is quite simple and lacks the segmentation and other features that both Test & Target and SiteCatalyst offer. However, it communicates important information about the different recipes in the campaign quite efficiently. We conduct further tracking in SiteCatalyst and Discover using a campaign ID attached to the URL string of the recommended entities, but hope for SiteCatalyst -Recommendations reporting integration that will eliminate a lot of the manual labor in setting up this type of tracking.
An even higher-level report is available on the main campaign list as shown in the screenshot below that displays the most-converting recipe and the default recipe with such high-level prime metrics as number of visitors served, click received and orders placed, as well as the calculated metric RPV (Revenue per Visit, $/Visit) together with the percentage of lift compared to the default content. More customization in this part of the application can be quite useful, for instance allowing the selection of the metric to be used for comparison and lift calculation or including more recipes.
Overall, this is a very positive move on Omniture’s behalf and I hope to post many progress reports and deeper feature reviews as I find the time.