We’ve been working behind the scenes to bring a new Buzzillions experience to the Apple iOS (previous version here), and as of this summer, it’s finally here!  With Buzzillions Reviews 2 for iPhone, iPod touch and iPad, you get all the best Buzzillions features – like product search, ratings histogram, pros & cons, review face-off, and of course, the *reviews* themselves – but with a cool new interface that highlights the clean Apple iOS experience.  In addition, we’ve added a new barcode scanning feature (powered by RedLaser) that quickly allows you to retrieve product reviews with the press of a button – perfect for in-store shopping!

Buzzillions Reviews 2 In Action

Already know the product name?  Search from over 2 million products on Buzzillions.

Need quick answers?  Skim the ratings histogram, pros & cons and review face-off.

Shopping in the store?  Scan a barcode and read from over 16 million product reviews.

Buzzillions Reviews 2 also features browsing products by category, checking prices, sharing by email and managing your favorite products list.

Available in the iTunes App Store

Try Buzzillions Reviews 2 for iPhone, iPod touch, and iPad, available in iTunes now – we think you’ll love it.

“16 million product reviews in your pocket!”

For those of you who may not know it, Buzzillions makes its money in part from our users clicking through to retailer websites from various sections of our product pages. Users arrive on Buzzillions, select products, read reviews and continue on to one of our retailers to purchase. We want to satisfy the user by providing useful buying options when they are ready to buy and satisfy our merchants who are always desiring more of our above-average converting traffic. As part of an effort to maximize these clicks and conversion rate, we embarked upon Multivariate Testing using Google’s Website Optimizer, a framework that has many attractive features – chief among them being “its free”. Varying the content and measuring the success or failure of a tweak or series of tweaks to our user interface in attracting clicks is the name of the game.

Traditionally (in the web world that means in the last year or so), Website Optimizer is used to inject test content into a page dynamically via javascript. The content is served up from Google’s side after we set up our tests and tell it what to inject into our page. Could be a different-looking button or it could be an entire chunk of a page. This is tricky when you want to test a section of a page that is dynamic and has many repeating areas. From what I’ve seen most developers are working around it by serving up all the variations in their HTML and then using either css or javascript on the Website Optimizer side to either show or hide the content variations.

Problem is, page performance (size, speed) for users and keyword density for Google take a negative hit when you add the variations to the code. Doesn’t amount to much if the variations are small (button appearance, small text changes) BUT the toll could be very negative if your variations bloat your HTML by, say 25-50% like ours were. So we needed to come up with another way of doing things, especially since we had a lot of variations to test and very little time to test them in (sound familiar, software developers?).

After banging our heads against the wall for a few days, we came up with something that fit the bill (note that we did create an internal server side testing framework but it wasn’t multivariate and didn’t have statistically sophisticated reporting). Since our Where To Buy section is the one that is the most heavily tested and also the heaviest in terms of page weight and number of variations BUT is below the fold, we decided that we should try to AJAX the page section onto the page dynamically after the page loaded. The benefit being that it would have no negative impact on our site performance in terms of page size, speed or keyword density — all metrics that matter to our users and Google, especially during the busy holiday season for us. To accomplish this, we would need to create a backend web service and hook it up to several javascript components – the YUI Javascript Library which we use to create and retrieve our AJAX call, our own javascript for manipulating the AJAX’d data once returned, and the Trimpath Library for some front-end templating to make it all look pretty and seamless.

This combination of technologies allowed us to use a free and sophisticated tool such as Google Website Optimizer, retain the dynamic complexity of our page delivery all the while preserving page speed, size and keyword density. The team consisted of one backend engineer to create the web service, a designer to work up the variations, a business owner to shepherd the project and winnow the variations to a manageable size and a front end engineer to glue it all together and set up the Google Website Optimizer test itself.

Leading up to the 2009 Holiday season, we tested over 200 versions of our product page to maximize buying options for our users and clicks to our merchants. We were able to create a variation (variation #86 to be specific) that showed a DOUBLING of the click through rate to our merchants (without any sacrifice to the conversion rate). The click through rate growth was actually 60% once we installed variation #86 permanently before the Holidays started (we assume this discrepancy is due to the statistical wobble inherent in the multivariate reporting). Still, a 60% increase in click through rate was great news for our users (who found more buying options) and great news for our merchants (who received more traffic at the same above average conversion rate).

Here are some more details about how to integrate the above technologies into your site:

Since Google’s Website Optimizer code is required at the very top of the HTML to work effectively and because (for performance reasons) we load all of our javascript at the very end of the page just like any other website that is aware of performance’s impact on the user, we had to come up with a way of making Website Optimizer aware of what our javascript components were doing. To do this, we came up with the idea of having Website Optimizer poll for our components. The code that went inside of Website Optimizer was super-simple:

<script>

function poll() {

if (typeof BZGWOREADY==”undefined” || !BZGWOREADY) {

setTimeout(‘poll()’, 1000);

} else {

bZ.wtb.gwo.fetchData(‘variation1′, ‘variation3′, ‘variation9′);

}

}

poll();

<script>

This simple javascript function basically tells Website Optimizer to look for a javascript object called “BZGWOREADY” that lives at the very end of the javascript on our side of the fence; if it doesnt find it, it waits for one second and then looks for it again. Pretty basic actually.

Then, at the very end of the page after all of our javascript has loaded which deals with the AJAX call, the Trimpath templating and all the other javascripted parts of our test content, we instantiate the object that Website Optimizer is looking for simply like this:

var BZGWOREADY = {};

Instantiating the BZGWOREADY object like this tells the Website Optimizer code that we are ready to make our AJAX call and get the ball rolling – fetching and formatting the data and telling our javascript which variations to use (in the example above, the 3 parameters passed to the function bZ.wtb.gwo.fetchData which lives inside of the javascript on “our” side tells our code which variations to use).

Using this technique can be time-consuming in terms of development, but if you are concerned with page bloat and keyword density, you might want to check it out. Might be worth it for you. Have fun.

Hey folks, 

Thanks for a great session and cheers to the “ghost” voice that brought you all back to life halfway through. Keep in touch. http://twitter.com/buzzillions

Here’s the Jira Greenhopper presentation:

http://bit.ly/buzzjira

Good luck to JC and family in your move to Australia!

Cheers, Jim

This Endeca-centered blog post is the first in an occasional series where we’ll discuss how we’re using Endeca. One of our engineers was mentioning how finding Endeca tips using Google wasn’t very easy. So here goes.

We’ve got enough machines in various development and production environments that standardizing installations and being able to bring new machines online quickly has become a business necessity.

So during this upgrade to version 6.1, we opted to run the whole install from Puppet , an open source server provisioning software project. We already use it to provision most of the other major software in our infrastructure.

I generally tell people that it takes about 4 times as long to automate a process as it does to “just do it” manually. That’s a hard pill to swallow when time spent on infrastructure has to be balanced with time spent innovating. For us, Endeca has long been one of the installs that’s done by the software engineers and not the systems team. But upgrading from 5.1.3 to 6.1.1 was the right time to automate the whole thing. So we grabbed our wiki pages, our journal entries and telnet session logs and sent them to our brave but persistent systems admin. He figured out the test cases, asked questions and probably installed Endeca over 50 times on the way to success.

The good news is that he can get the whole thing from a blank machine to a machine running forge/dgidx and dgraphs that have yesterday’s data and config files in about 15 minutes using Puppet.

Note that it helps to have all necessary files in a code repository system that Puppet has access to. We use Subversion.

If you’ve ever installed Endeca, the steps are usually included in 3 to 6 different PDF files that are in various “docs” directories. Though we’re partial to the CommerceSuiteQuickStartGuide.pdf these days. The migration steps are where it gets complicated. You generally need to work with Support to find out which files are critical and which ones are unnecessary. The various Migration Guides are fairly incomplete for a real migration.

Here are our steps for Migration from 5.1.3 to 6.1. Note that these steps will be slightly different than your specific steps. Really, the hardest part about the automated install is to formalize the exact ordering and dependency of all the install elements and the migration elements. The way puppet works is that at each step, you need to specify a “test” so that Puppet doesn’t run a step that it has already run before (it might be the existence of a directory or a file or the response code from the emgr_update calls). I think the phrase is making an “idempotent operation”. Also note that we use Red Hat Linux 5.

1. Create a user account specific to the version of endeca you’re installing.
   •  Don’t just use a username that is generic. Using one that is specific per version allows you to upgrade on the same server since you may want to add new software to a server where you’re already using Endeca. The environment variables for different versions are different so we opted to have different users since our inittab scripts run as this special version specific endeca user.
   • Puppet creates the endeca version specific user along with its profile environment variables file.
2. Standard install steps
   • Create a shortcut UNIX alias to change directories to the base /endeca directory, call it $ENDECA.
   • Create a shortcut alias for your application name, call it $APPNAME
   • As the endeca version specific user,
     • Install the MDEX software using the silent install option. Easy. No config file needed.
     • Install the PlatformServices software using the silent install option. Here you need to decide whether it’s a FULL install (for Forge/Dgidx servers) or an AGENT ONLY install (MDEX/Dgraph only servers). Silent install file is simple.
     • Install the Merchandising Workbench software using the silent install option (or your appropriate Workbench package). Silent install file is simple.
     • Install the ContentAssembler API basically by unzipping into the $ENDECA
     • Install the DeploymentTemplate 3.0 using a silent install file. This silent install file can be quite complicated but we just use the simple options (anybody know where the documentation for the advanced options is located?). NOTE that since Endeca uses relative paths during deployment deploy, we had to write a shell script to call their shell script to get these relative paths to work in Puppet. The other installs seem to use the path that you pass in.
3. Migration steps
   • State files
     • To keep your N values stable between instances, you need to grab the two files located in $ENDECA/$APPNAME/data/state and move them to your new deployment application in the same directory. We keep update these files in our Subversion repository after every Forge run.
       • autogen_dimensions.xml.external.gz
       • autogen_dimensions.xml
   • Pipeline files
     • The pipeline is divided generally into two parts: Dev Studio files and Web Studio files.
       • The Dev Studio files are files that users DON’T change in Web Studio. They are generally located in $ENDECA/$APPNAME/config/pipeline and you can just copy them to the new deployment application in the same directory.
       • The Web Studio files are kept in the “ether” so you have to extract them using the “emgr_update” application. You set which files are “Web Studio maintained” by changing the “ConfigUpdate” section of the AppConfig.xml. Make an empty directory $ENDECA/$APPNAME/temp and extract the files using the emgr_update command and then copy to the pipeline directory in the new deployment application.
         • emgr_update –host localhost:8006 –action get_ws_settings –app_name $APPNAME –prefix $APPNAME –dir $ENDECA/$APPNAME/temp
       • Once you’ve copied the Dev Studio files and then the Web Studio maintained files to the new pipeline then you can stuff the files into the new Web Studio.
         • emgr_update –host localhost:8006 –action update_mgr_settings –app_name $APPNAME –prefix $APPNAME –dir $ENDECA/$APPNAME/config/pipeline
         • If you have externally managed dimensions, you will need to ignore a warning like “warning, cannot find <file>, proceed anyway?” . Just say yes, it doesn’t actually need the externally managed dimension files.
   • Data files
     • In preparation for the baseline update, we move our data files to the $ENDECA/$APPNAME/test-data/baseline directory. We mainly use XML files as our pipeline source files.
   • Web Studio usernames and preferences
     • Copy the “webstudio” directory in the 5.1.3 $ENDECA_CONF/state
     • Remove the existing “webstudio” directory in your new deployment application in $ENDECA_TOOLS_CONF/state
     • Turn off the Endeca processes. Paste the “webstudio” directory from above into $ENDECA_TOOLS_CONF/state. Turn Endeca processes back on.
   • Before you baseline, here are some miscellany:
     • By hand, migrate your AppConfig.xml from 5.1.3 to 6.1.1 (not many material changes)
     • In AppConfig.xml, change “pipeline.epx” reference to “Pipeline.epx”
4. Run the $ENDECA/$APPNAME/control/initialize_services.sh to setup the servers and modules explained in the AppConfig.xml
5. Run $ENDECA/$APPNAME/control/load_baseline_test_data.sh
6. Run $ENDECA/$APPNAME/control/baseline_update.sh
7. At this point, via Puppet, with NO human intervention we have installed a new Endeca master server (Forge/Dgidx). The Puppet installation for an MDEX/Dgraph server is just the user creation, MDEX install, PlatformServices AGENT ONLY install and an inittab script. Then you start the process and include the server and port into the AppConfig.xml which will configure the server the next time you run any EAC command. 

Send us your comments and hopefully other Endeca users will start to blog/write about the ways they make life easier on themselves or the cool things they do. The Encyclopedia (read “wiki”) part of the Endeca documentation system is also a great place to make updates and share tips.

Cheers, The Buzzillions Team

The Buzzillions Team

New Television page. Here’s the screen of the OLD Televisions page:

The other day I was in Target looking for air beds for a visitor coming in town.  While it’s easy these days to find product reviews on things like digital cameras and televisions, it’s a little trickier when you’re looking for other products.  As I stood there blinking at the choices, (varying price ranges, familiar and unfamiliar manufacturers etc.) I thought…if only there was a way I could get some advice here.  Did I need the $100 air bed with the foot pump, or would the $39 one do just fine?  While it was tempting to go home, get on the computer and see what Buzzillions had to say about it, I ended up choosing blindly.  Now I (and YOU) don’t have to.  With our new Buzzillions iPhone app, you can (if you have one of these handy phones OR the ipod touch) download the app and be on your way to having millions of product reviews at your fingertips.

So the next time you’re at a retailer, scratching your head as you mull over the options, you can whip out your iPhone, type in the product name and get a little guidance from reviewers like you.  Best of all…it’s FREE. We’d love to hear what you have to say about it, things you like, things you don’t, so we can work to improve the application to make it even more useful.

I know we’re biased, but Buzzillions.com is the best place for top rated products with ratings from other parents like us!  Buzzillions.com allows us to read reviews from real parents on everything from the best baby bottles and the most reliable baby diapers to trendy gift ideas for our 3-year-old’s upcoming Birthday.

However, sometimes we need specific answers to questions and don’t have time for in-depth research.  That’s where AnswerBox comes in.  What do other parents think about using BPA-free baby bottles and which ones do they recommend?   What are the best sources for “official” car seat and booster seat safety information?  How well do gDiapers work?  We love the fact that the inserts are flushable and compostable, but do the reusable diaper shells really keep it all in (yes, they do)?

As you can see, we’ve got a lot of questions.  The local baby boutique is good for some answers, but who has the time these days and how do we know that they aren’t just trying to get us to buy their products?  Baby books are great for one-way information, but not specific answers.  There must be a lot of other parents out there with answers!

With this in mind, PowerReviews created AnswerBox.  Our newest feature enables your customers to ask questions about specific products and tap into a large online community of active shoppers for answers.