tag:blogger.com,1999:blog-34368959.post5554044122861412984..comments2024-03-25T04:32:02.396-04:00Comments on Customer Experience Matrix: SiteSpect Does Web Tests without TagsDavid Raabhttp://www.blogger.com/profile/03489754392712536104noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-34368959.post-4963339449004866942007-03-14T15:25:00.000-04:002007-03-14T15:25:00.000-04:00Thanks for the clarification. What really counts ...Thanks for the clarification. What really counts is that you're pleased with the product--and that comes through loud and clear.David Raabhttps://www.blogger.com/profile/03489754392712536104noreply@blogger.comtag:blogger.com,1999:blog-34368959.post-74849731275616825302007-03-13T21:30:00.000-04:002007-03-13T21:30:00.000-04:00The difference in schedule flexibility is not beca...The difference in schedule flexibility is not because QC is lighter for the experiments themselves, but because the experiments do not have to be worked into our main codebase release schedule (as page template changes would). We have a lot of active code projects going on at any given time, and they compete to get into each SW release cycle. Allowing UI A/B testing to proceed independently has been a big win for us. <BR/><BR/>I have not used other testing products, but did review a number before we settled on SiteSpect.Anonymoushttps://www.blogger.com/profile/14395671656818980850noreply@blogger.comtag:blogger.com,1999:blog-34368959.post-28639899933843062882007-03-13T18:43:00.000-04:002007-03-13T18:43:00.000-04:00Thanks Claude. Always good to hear from a happy u...Thanks Claude. Always good to hear from a happy user. I do wonder, though--is your quality control work on tests through SiteSpect really less rigorous than the same QC you'd do with changes via Javascript tags? Seems to me you have to do the same things either way. Do you have experience with products other than SiteSpect for this sort of thing?David Raabhttps://www.blogger.com/profile/03489754392712536104noreply@blogger.comtag:blogger.com,1999:blog-34368959.post-45511744568308911512007-03-13T18:19:00.000-04:002007-03-13T18:19:00.000-04:00As a SiteSpect user, I can speak to the difference...As a SiteSpect user, I can speak to the difference between SiteSpect's system and page tagging. My site is a vertical search portal for <A HREF="http://www.courseadvisor.com" REL="nofollow">online degrees and programs</A>. The site is 100% dynamic, with all pages built using custom business logic, a relatively sophisticated content management system, and a range of page templates. We do extensive testing of page variations to optimize both user experience and conversion.<BR/><BR/>To perform testing on items on a specific page or page category using the Javascript approach, one of the following must be modified with page-specific tags: the codebase that implements the CMS, the page content itself, or, typically, the templates that organize the pages. This poses two problems. <BR/><BR/>First, those alterations impact the site itself - it requires change to set up the test and change again to tear it down, even if the result of the test is that no change is desired. An axiom of development (software and content alike) is that every change offers the chance to introduce error. So this approach carries implementation <B>and rollback</B> risk to the production site.<BR/><BR/>Second, we implement a development queue and follow a strict release process to control all changes to the codebase and page templates, as any error in those elements can impact performance across significant areas of the site. Testing using Javascript tags has to be inserted into this flow and managed in concert with the main flow of site development - leading to less flexibility and more rigid timelines.<BR/><BR/>Contrast this to the proxy approach. Tests are set up <I>on the SiteSpect proxy</I> using URL and page-level pattern matching to define pages and elements to change. When a user becomes part of an experiment, our production site serves unaltered pages to the proxy. The proxy alters each page as required per the experiment rules and forwards it to the user, tracking information in the process. The benefits are exactly the problems above. First, absolutely no change is made to our codebase, templates, or content. Second, test development and QA can proceed independent of site development, with checkpoints as appropriate to the level of change being made.<BR/><BR/>The potential disadvantage to the SiteSpect approach is loss of control over the network path between your server and your users. Although we were initially concerned about this, it has not proven a problem in our implementation to date.Anonymoushttps://www.blogger.com/profile/14395671656818980850noreply@blogger.com