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.

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

Well, it’s 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.

Why Do the Search Engines or I Care about My URL Structure?

Whether static or dynamic, the URL addresses of the web pages that make up a website are the direct connection between them and the outside world: they are used to advertise, share and even access the pages and their content. If direct page URLs did not exist, we would always have to enter a website at the homepage level and follow one or more usually repetitive steps every time to get to the page in mind. A not-so-well-thought-out real-life analogy would be that of having one community doorbell for all apartments in a building, which creates extra steps–and in this case even chaos–every time that one tries to access one of the units.

The tangible, even monetary, value of the public URL structure of an e-commerce website can be realized in the revenue generated from the organic, hard-to-obtain, free search engine traffic that is brings, amongst many other things such as return and referral visits by customers, social bookmarks, etc. Not to get into the granular details of search engine ranking algorithms, as search engines visit a website, they paint a picture of its URL structure in the search index they use to determine what web page is most suitable for a given keyword. They analyze the siblings, parents and children of URLs to determine a context for them and needless to mention they use those very URLs to retrieve the content that also weighs in on relevance to a search term.

It is not hard to imagine that changing or removing a URL that search engines have come to know–as explained in the previous paragraph–over time, is quite similar to pulling the proverbial rug from under the rankings that the URL in question enjoys at the discretion of the search engines. I hardly think there is the need to justify that organic search engine traffic–as compared to Pay-Per-click (PPC) search advertising–holds quite a high ROI value for any online business, but the need to change the URL structure of a website is real and sometimes unavoidable.

If Change is Unavoidable, but Search Engines Do Not Like It, then What to Do?

Most importantly, one must always leave the burden of proof on the “URL change.” This will automatically guide any migration at least towards the right path: if compromises are required, they’ll be pushed on to the correct side; if work-arounds are explored, they’ll be to save the right thing.

If it is determined that the URL structure must indeed change due to a different hardware or software infrastructure (e.g. new platform, different programming language, change in operating system or web server), or perhaps to improve web usability or even search engine placement (e.g. more memorable URLs, less duplicate URLs), then there are certain ways to help mitigate the risk of losing your organic search engine rankings.

A URL’s Identity: What Exactly Am I Protecting?

By now, you have realized that your URLs–or at least some of them–deserve attention prior to being tossed about violently and left to their own devices to survive a website move. This attention is aimed at retaining as much of the URLs identity as possible from the following angles:

1. The URL Itself: The address can either be kept as it is or redirected with a server-side 301 redirect to the new destination of the URL. A less-universally-accepted approach is allowing the old URL to deliver the same content as the new URL, but instead of redirecting old to new, using a canonical URL meta tag that tells the search engines to only treat the new URL as the main URL of the page. This tag is generally not ignored by most major search engines, but the approach hasn’t shown to add any value as compared to the 301-redirect method, and is not appropriate use of the canonical meta tag in comparison, since 301-redirect is specifically meant for “permanent moves.”
2. The URL’s Page: The URL itself is seldom the only thing changing during a website migration. Most changes are within the page that the URL points to, such as the title, content, images, design (i.e. HTML). Close attention has to be paid not to dramatically increase the HTML-to-text ratio of pages, which is not a difficult matter these days with universal use of CSS and better HTML coding standards than ever before. After all, notifying search engines that you have moved but showing them an entirely different page than they are used to, is not really going to score the vote of confidence you’re looking for from them; they’ll want to reconsider everything since you will seem to be offering entirely new pages. If this seems limiting, you just need a better web designer or developer, as virtually any improvement can be made to a page while maintaining its search engine identity. More detailed discussion is beyond the scope of this article, but will hopefully be covered in future ones.
3. The URL’s Context: Imagine moving your organic locally-sourced cafe business according to protocol and notifying your customers of the new address, and maintaining your menu and ingredient choices, but relocating from a serene country-side into the food court of a heavy commercialized shopping mall. The very change of venue is upsetting, but the lack of familiarity between your business and its surroundings means that even your loyal patrons will need to rebuild their confidence in your business. This is precisely the same with URLs: you need to make sure important URLs have the same or similar parents (URLs that link to them), children (URLs they link to) and siblings (URLs that their parents link to, and URLs that link to their children). This might seem complicated, but unless you move a category URL to the customer service section or a product review article to the shipping policy section, you should be covered. Just be mindful of the overall place of your URLs within the link structure of your website.

Go into It Prepared: Compile Lists.

Prepare for the decision by aggregating factual and statistical data into actionable lists. Do not delve into the actual remedy yet, as you’ll read later on that sometimes it is easier to fix everything at once than treat URLs one by one. Some important lists with brief usage explanations are below, but not all may be available or even needed in different scenarios. However, the more data that is gathered, the easier it will be to make a case for each compromise and work-around.

• List of URLs listed by search engines for your highest-ranking organic keywords in Google, Yahoo and even Bing, as well as any niche search engines that may be sending you a lot of traffic. These URLs will not only have to be either maintained or carefully redirected, but also the pages they deliver need to be carefully examined from an SEO standpoint and meticulously reconstructed within the new website. Some things to watch out for are meta title changes, HTML-to-text ratios, in– and out-bound links (count, anchors and URLs), and of course content itself.
• List of URLs with highest non-search-engine referral traffic from social networks such as Facebook and Twitter, bookmarking sites such as Digg and Del.icio.us, and any website that somehow has linked to your website and is sending traffic to it. These URLs will have to be handled as delicately as the ones in the previous list; however you may have more freedom in changing content as long as the overall value and message for the visitors is retained.
• List of URLs (if any) you provide on your website for direct bookmark creation i.e. “add to favorites.” Just remember to provide your new URLs for manual bookmarking and redirect the old ones to their new destinations.
• List of your site’s external in-bound links with destinations to determine which URL these links point to. If able to compile this list, you may sometimes find URLs that add value to your website rankings but did not appear in the first two lists mentioned above. Treat them the same way you would an organically ranking URL.

Once you have these lists, and remember how similar changing the URL of a well-ranked or –linked page is to shutting down your business and moving without notifying your customers, you will already feel more certain that you are well-equipped to make a decision in either side’s favor. If the lists are meager and unimportant–for example because most of your business is due to paid advertising or offline traffic generation venues–you’ll confidently change your URLs to the most optimized state as mandated by the new requirements; you might even go far enough to implement mere best-practice recommendations to avoid any further changes in the URL structure for as long as possible. However, far more often than not, the lists and traffic related to your current URLs are substantial and need more consideration and attention.

Quick-and-Dirty Or Thorough: How to Actually Make the Move with the URLs.

Now that you know why and what to protect, the path to it will be more easily trodden. In general there are two different approaches: Static or Dynamic–this is my wording for it, and can definitely be improved. The former calls for directing each old URL to a new one often individually, while the latter pushes all URLs through a filter that will find a new home for them dynamically based on patterns programmed into it.

• Static URL Mapping: Unlike its name may suggest, this can be done both manually or using some scripting and a database, but what makes it static is the fact that each URL is mapped to its new counterpart by patterns invisible to the application that runs the new website. For instance, a human editor may have decided that all category pages now point to a new URL where some parameters are re-ordered, the name of the category is used instead of the ID, and unnecessary data such as sort-order is dropped from the URL. This logic may have then been applied in a spreadsheet to a large list of URLs, but the end result fed to the website application allowing it to know where each of the old URLs are supposed to point to. This is sometimes desirable when the number and exact format of URLs being handled is mostly known. It is very quick, but lacks scalability and requires redoing if a new batch of old URLs are discovered to have been ignored initially.
• Dynamic URL Mapping: Just as in the previous method, patterns in URL sets are detected and then used to map the old to the new. However, the difference is that these patterns are programmed into a filter within the website application instead of the mind of a human being. This means that the website can map all URLs that match the programmed patterns. Furthermore, mapping any new set of URLs is as simple as telling the program what pattern to look for. The website application usually used for this is either some type of URL re-writing module (e.g. Apache Mod_Rewrite or IIS ISAPI_Rewrite) or small scripts written in the language the website was developed in (e.g. Perl, PHP, Java). For more complex URL infrastructures both are used, the former to funnel URLs that match a certain pattern to the latter where they get paired with their new destinations. The patterns themselves are usually written in some type of Regular Expression format–a means used for pattern matching by many popular website development and programming languages. While this method requires more programming and certainly access to layers of the website application that some shared web hosts will not provide, it does save large amounts of manual editing time for larger sets of data such as the URLs of an e-commerce website or news portal.

Whichever method you choose, it needs to be sensible when considering your budget and possible adverse impact of ignoring the matter as a whole. Choosing the dynamic approach when programming resources are scarce can cause the shutting down of the idea, and leave you with orphaned URLs, while choosing the manual static method in the face of a large set of URLs can increase the error margin and be costly in time to return and fix errors.

Real Life Example: URL Rewriting when Migrating to Magento Enterprise Edition

Since this article has turned into a virtual run-away that I only hope you were able to follow along with some sense of coherence, I am providing a quick overview of the most recent migration to Varien’s Magento E-commerce platform from a proprietarily-designed PHP platform in a simple ordered list:

1. We knew that we needed to address the major URL change and there was no avoiding it since our current URLs were meaningless, long and over-duplicated.
2. Due to the sheer amount of URLs but limited patterns (i.e. top-level category, sub-category, product detail, other content) we decided to employ the dynamic method.
3. We reviewed the URL structure and determined the patterns that matched each group of similar URLs listed in the previous step, and turned these patterns into regular expressions.
4. Since almost all URLs in Magento are fed to a central filter that decides where they point, we simply had to feed these regular expression patterns to that filter.
5. Then we had the filter pass on each URL that matched any of our patterns to a small script that determined where to point it based on the pattern it matched. For instance, an old URL with ProductID=x in its query string would now point to the new URL for this product after the small script looked up the new URL for product “x” in the database.
6. We did have one extra step, which I have eliminated from this article due to its detailed nature: our Product and Category IDs had also changed. The solution was quite simple, we added a new attribute for each product and category (very easily done in Magento) and told the mapping script to first lookup the new ID for the old ID passed by the old URL, and then find the new URL for the new ID, which became the new URL for the old URL. Try that for a tongue-twister.

Well I hope this lengthy and somewhat discombobulated article helps at least consider URL rewriting or some other method of URL identity retention during any website migration. Talk to your developers and force them to pose viable solutions for it, there, almost always, is one.

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

The APS template mechanism was one of the main issues with that product as it only allowed the recurring appearance of an individual cell in the showcase block to be edited. It would then multiply that by as many horizontal and vertical cells as assigned, fitting them inside of a preset table structure. While still possible through hacks, this prevented the easy implementation of more advanced presentation methods such as DIV tags with CSS, JavaScript Showcases, etc.

The new platform remedies this in the most primitive manner by eliminating the dynamic size through cell multiplication and requiring the template to cover the whole showcase block with the number and position of cells hard-coded within. I have recently joined the Omniture Recommendations Customer Advisory Board (CAB), where I hope to influence the road map to include more advanced methods of manipulating the presentational templates that allow even non-technologists to set up and use them. However the current method puts the raw power in the hands of the designer to mold the product data into any possible presentation, from HTML and JavaScript to XML and even Flash. Of course, the inclusion of hard-coded cells means that there always have to be enough recommended entities to fill the whole template. This is taken care of by including global default recommendations—currently set by your account manager—which have much room for improvement to allow for separate default lists for different entity types and more.

There is also a nifty list of all possible variables that can be used in the template to the right of the edit window.

Omniture Recommendations Template Edit Page

SiteCatalyst™ Integration

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.

Omniture Recommendations Algorithms — SiteCatalyst Metric Popularity

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.

Omniture Recommendations Algorithms — Based On

Omniture Recommendations Algorithms — Item

Omniture Recommendations Algorithms — Category

Omniture Recommendations Algorithms — Last Purchased Item

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.

Omniture Recommendations Algorithms — Inclusion Criteria

Omniture Recommendations Algorithms — Attribute Weighting

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.

Omniture Recommendations Testing Reporting — Algorithms X Templates

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.

Omniture Recommendations Testing Reporting — High-Level

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.

Per my post on migrating to Magento, we have chosen the enterprise edition of this platform as the next generation of our e-commerce platform. While the decision was quite easy when comparing to platforms such as ATG, Fry and GSI as explained in their respective comparative post, there was more to consider with Novator, Broadvision and Prosodie, three more realistic solutions to enterprise-level e-commerce platforms for viable e-commerce businesses. These platforms bring valuable factors to the selection process, that are only offset by Magento’s relatively low cost and access to community edition traffic volume contributing to its enterprise product road map.

Below is a summary of my personal opinion on each of these platforms based on several sales meetings, demonstrations and dinners.

Novator

This platform aligns most closely with my idea of the perfect solution, since it integrates a data permeation model they call Retail data Model. Their staff is more than open to discussing every small detail at stages of sales and all understand their RDM as well as other features of their platform as if they wrote the code. The offering also includes a great support service model at a premium that could be appealing to very large e-commerce departments interested in outsourcing a large portion of daily operations to the provider. The cost-difference between Magento and Novator is quite large, but will diminish considerably for such larger e-commerce enterprises with several application instances and servers.

Broadvision

Amongst the oldest providers, they have a very customizable system that unlike Novator’s requires heavy involvement of technologists and developers to use to the fullest. That is not to say, that they are not capable of providing the human resources to fulfill all such needs, but the associated cost quickly renders the platform impractical for many businesses. However, their extremely well-trained and obliging sales staff is only matched by Novator and Prosodie, and can be very helpful in guiding a large board of directors and group of executives in making a “big-ticket” decision.

Prosodie

Seemingly the smallest of the three, this French e-commerce platform provider has a friendly and well-informed approach to expanding to the United States. While the actual application seemed to have room for beautification to add to its enterprise appeal, there were many specialized features that exuded attention to usability and customer-centered design. One particularly notable module was a very easy-to-use product family builder to populate product families with children using attributes using a visual attribute multiplication matrix similar to what I have designed internally before, but more polished.

The pricing of Prosodie’s platform makes it particularly appealing, since it is far lower than the rest of the providers at this level, making it more of a contender for Magento. However just as Novator and Broadvision, the lack of vast world-wide development and user communities paired with great entry price—that of having a no more than a few servers—makes Magento the obvious choice to be given the chance to prove its commercial open-source model in a production environment.

As explained in the post about the decision to migrate to Magento, there were many other enterprise-grade e-commerce platforms included in the selection process. While we moved quite far into the sales pipeline with most, GSI Commerce, ATG & Fry are amongst the platforms that were not scrutinized as thoroughly.

These platforms have a long list of enterprise clients that include such top brands as BestBuy™, Levi’s™, QVC™, RadioShack™. This allows these providers to have very up-to-date development road maps with most of the latest and greatest features of the e-commerce industry available in a relatively short period of time after being proven ROI-friendly. However, the very clients that facilitate this, mandate heavy customization and specialization of features. This results in the costly development of highly-specialized features to serve needs such as order management, reporting, testing and personalization. I believe it is this approach that forces them to project a need for a la carte and fully-customized approach to e-commerce platforms—at least during my sales-level interactions with them—that may prove too expensive and sometimes even wasteful for many small business as well as larger enterprises.

In my opinion, this inflates the final price of implementation as well as the recurring cost of maintenance for years to come. However, until now, the alternative was to settle for modules and customizations by development firms with a fraction of the traffic exposure of these larger platforms, which translates into more buggy, less efficient code and user interface.

Even with open-source platforms and their considerable traffic exposure, the development power was never well-harnessed into a central entity not only skilled in the platform’s development but also fiscally able to structure and offer enterprise-grade service and support on a large scale.

GSI, Fry, ATG and other high-end platform providers have features to salivate over, however Magento brings the popular aspects of these features to most businesses at considerably lower cost and is able leverage its community edition traffic to direct the enterprise edition road map, hence not falling short in platform feedback due to lack of large enterprise customer base. Furthermore, as Varien continues to lure more monster clients to its enterprise edition, I hope to see even more features comparable to the giants in the industry.

After over a year of e-commerce platform selection research, conference and exhibit attendance, and countless demonstrations, meetings and negotiations, I have decided to migrate to the Magento open-source platform. The main reasons are:

Time-Saving & Cost-Effective Scalability

There are many free and commercially-available extensions for administrative, usability and even design features as well as a vast world-wide development community with backgrounds in various industries and business technologies from drop-shipping with no inventory for affiliate stores to tightly integrated ERP-Website models.

Ever-Expanding Rich Standard Feature Set

The base community edition (free version) includes features such as:

1. Guided navigation (also known as faceted search) which is very helpful in improving conversion rates since it allows the marketers to empower the visitors to find what they want more easily. Read more about it by clicking on faceted search.
2. Multi-store data permeation model that allows the management of different websites in one back-end as well as the same catalog across multiple websites considerably lowering the administrative costs associated with product management and order processing.
3. Granular promotion management tools allowing marketers (i.e. non-technologists) to run complex conditional promotions, improving conversions and Average Order Value.

Relatively Low Cost

Some of the aforementioned usually come at a very high cost, while portions of it such as a world-wide development network do not even exist in a commercial (non-open-source) model. The free cost of the community edition, as well as the ~$8,900 (as of the date of this posting) annual per-instance license fee of the enterprise edition–which includes technical and customer support–are quite justifiable when taking all of the above into account.

Pre-Sale Hands-On Demonstration Access

This is not as important when comparing to other SMB platforms, but it gets exponentially harder to have access to a demo front– and back-end on one’s own time to “play about” and “get the feel” of a application, as one delves into enterprise-grade platforms. Such vendors usually provide a sales or technical staff member to conduct demonstrations, which forces one to fit all questions and concerns into a limited number of socially-acceptable pre-scheduled demonstration meetings. It is just so much easier to throw one’s whole e-commerce department at the Magento enterprise edition demo (freely and promptly available to anyone who requests it) and have them come up with questions and concerns on their accord.

Of course, there are many more reasons specific to our situation that drove the decision. However, with the proliferation of the Magento e-commerce platform in the past year across the world amongst small, medium and large businesses, there have been many negative reviews stating the following as the top reasons to avoid or think twice before moving to Magento:

Complex Code Structure:

Critics: Complex and large codebase makes the platform very hard to design and develop for.

I: That may be an issue for non-technical small-business owners planning on developing and designing their website themselves. However, the following reasoning helped me disprove this as an obstacle and see it more as a feature:

1. There is no shortage of high-school-aged savvy hobbyists to professionally-certified development partners at all price points to satisfy all design and development needs.
2. The same complexity of the code base, allows for very unobtrusive development of external modules that can be installed and maintained with little headache in most cases. This translates into several pre-packaged well-developed modules called “Magento Extensions” that are there to address more popular development needs such as drop-shipping and minimum advertised price policies.
3. Again the very same complexity ensures complete separate logic and presentation layers, in fact even more segregated layers within each i.e. separate layouts and templates for design. This also translates into various widely-different scalable and modifiable pre-packaged themes that can be installed and maintained with not much hassle.

Resource-Hungry Application:

Critics: It requires more expensive servers and web-hosting services to keep page load time in acceptable range.

I: Compared to faster platforms Magento provides out-of-the-box features that not only offset the initial development costs, but also for many small– and medium-sized businesses define the line between taking advantage of these features and not even being able to afford to think of them due to added setup and maintenance costs—faceted search being one. For these businesses, the improved conversion rate associated with such features would never be realized with some other platforms. This, in my opinion completely justifies the not-always-extra cost of better hosting.

Recurring Enterprise License Pricing Model:

Critics: Annually-recurring per-instance (i.e. per running instance/copy of application on an operating system on a physical or virtual server) pricing model is too expensive and comparable to better enterprise platforms with perpetual license pricing models.

I: Depending on the business and its e-commerce technology needs and goals as well as available capital this can be true. However, in my experience with many high-end perpetually-licensed platforms I have never seen such a vast network of inexpensive pre-developed modules and custom development talent. While not always the case, closed proprietary development is inherent with most commercial-only (non-open-source) software, regardless of its licensing model. In plain terms: Pairing open-source with enterprise makes Magento an orange stuck in a comparison with apples!

Given the above, it was not a very hard decision to migrate to Magento hoping for the cost-efficient scalability appeal to prove to be true. My logistical approach to choosing Magento over the following platforms¹ will be detailed more in posts to follow in this series:

• GSI, Fry, ATG, Broadvision: While great platforms, most business cannot even get past the initial stages of their sales pipelines as they come in at very high price points but there are some other factors to consider as explained in the ATG, Fry & GSI comparison to Magento post.
• Prosodie, iCongo: Again, while these are great platforms for the right business, I could not compare their even more limited customer-base and inherently slower platform road map.
• Novator: This is my most favorite, feature-rich and service-oriented platform with a great answer to my data permeation model called Retail Data Model. I have nothing bad to say about them, but read how I believe they stack up against Magento together with Prosodie and Broadvision.

1. I must clarify that my opinions are based merely on sales and selection processes, and not actual use of many of these platforms

This usually means that one must install Apache, FTP servers and webmin if desired manually. But simply running these services after setup will not allow outside clients to access them if you have a firewall such as iptables active–and most basic boxes will have some type of one running, most probably iptables on RHEL, CentOS, Ubuntu, etc.

To allow access to your services, you must add rules to your iptables firewall rule table telling it what ports to open to whom (what ip addresses). I am not going to rewrite a full tutorial on opening ports on iptables, as a very good basic one is available at Ubuntu iptables Basic How-To plus many more advanced ones through the forums and linux communities.

However, most of the tutorials out there, do not stress the fact that “Appending” a new rule to the list using “-A” will not work in most cases since the default rule, the one listed at the end of iptables list, is usually one to deny everything that reaches it. Since iptables processes rules in sequential manner, if your rule is appended to the end of the list, the default rule will “DENY” all requests before they even approach your newly inserted rule. Below is the usually suggested approach to open the webmin port in the “INPUT” chain which does not work for our setup.

iptables -A INPUT -p tcp --dport 10000 -j ACCEPT

To remedy this, you must “INSERT” your rule use the “-I” option followed by the chain and the slot to insert the rule in. To determine this run the following command and count the slots starting with 1.

iptables -L

Making sure that you select the right chain, which you will after reading some tutorials carefully, you should then be able to add your desired rule in a slot (e.g. 3 in the example below) before the default one, as follows:

iptables -I INPUT 3 -p tcp --dport 10000 -j ACCEPT

I hope this helps reduce some aggravation while trying to get a vanilla linux box launched.