On Building a Data-Driven E-Commerce Site

It had been a long, hard week at work. I had my feet up when a friend called and popped the question: “Do you know how to build web sites?”

That was about a month ago and, after swearing to her that I spent my days helping other people build their web sites, so I should oughta know a thing or two about how to build one for her. After some very gentle requirements gathering (you don’t want a bad customer experience with a friend!), I set about designing and building bestcakebites.com, a real-world e-commerce site.

She didn’t need a ton of features, just some standard stuff:

·        Built on a technology I already knew so I could have the control I needed.

·        Listing a dozen or so products with pictures and descriptions.

·        A shopping cart along with, ideally, an account system so folks could check their order status or reorder easily.

·        Shipping, handling and tax calculation.

·        Taking payment.

·        Sending email notifications of successful orders to both the customer and the proprietor.

As it turns out, there are a bunch of ways to skin this particular cat, but because I was a busy fellow with a more-than-full-time job and a book I’m supposed to be writing, instead of falling prey to my engineering instinct to write my own website from scratch, I decided to see what was out there.

As it turns out, there’s quite a few e-commerce web site solutions in the world, several of them recommended by PayPal, as well as one that PayPal itself provides, if you don’t mind sending shoppers to their web site. And if fact, I did. Requirement #1 was that I needed complete control over the code and the look and feel of the site. I didn’t want to configure somebody else’s web site and risk going off of her chosen domain name or not being able to tweak that one little thing that meant the difference between #succeed and #fail. (Friend customers are so picky!)

The e-commerce solution I picked was the one I found on http://asp.net (I am a Microsoft employee after all): nopCommerce. It’s an open source solution based on ASP.NET and CSS, which meant that I had complete control when it wasn’t perfect (control I used a few times). It was far more than full-featured enough, including not only a product database, a shopping cart, shipping calculation and payment support, but also categories and manufacturers, blogs, news and forums, which I turned off to keep the web site simple (and to keep the administration cost low). Unexpected features that we ended up liking included product variants (lemon cake bites in sets of 8, 16 and 24 made up three variants, each with their own price, but sharing a description), product reviews, ratings and site-wide search.

The real beauty of nopCommerce, and the thing that has been the biggest boon, was that the whole thing is data-driven from SQL Server. To get started, I ran the template web site that was provided, it detected that it had no database from which to work and created and configured the initial database for me, complete with sample data. Further, not only was it all data-driven based on the products, orders and customers the way you’d expect, but also on the settings for the web site behavior itself.

For example, to get shipping working, I chose from a number of built-in shipping mechanisms, e.g. free, flat rate, UPS, UPSP, FedEx, etc., and plugged in my shipper information (like the user name and password from my free usps.com shipping calculation web service account)

With this configuration in place, the next order the site took, it used that shipper, pulling in the shipping information from the set of size and weight measurements on the ordered products (from the database), calling the web service as it was configured (also from the database) to pull in the set of shipping options from that shipper, e.g. Express Mail, Priority Mail, etc., augmenting the shipping prices with the per product handling changes, and letting the user pick the one they wanted. All I had to do was use the administration console, tag each product with size information and tell nopCommerce that I’d like USPS today, please.

Everything worked this way, including tax calculation, payment options (we chose PayPal Direct and Express so that folks with a credit card never left our site whereas folks with PayPal logged into their account on the familiar paypal.com), localization, whether to enable blogs, news, forums, etc. Most of the time when I wanted to make a change, it was just a matter of flipping the right switch in the database and not touching the code at all.

As one extreme example of where the data-driven nature really came through was on the order numbers generated by the site. During testing, I noticed that our order numbers were monotonically increasing from 1. Having ordered from a competitor’s site, their order number was only 103, clearly showing off what amateurs they were (and the order itself took a month to arrive after two pestering emails, so it was clear how amateur they really were). I didn’t want us to appear like newbies in our order-confirmation emails (which nopCommerce also generated for us), so I found the Nop_Order table, and used SQL to increase the identity column seed, which it was clear was the origin of the order number: 

DBCC CHECKIDENT (Nop_Order, RESEED, 10047)

From then on, every time an order came through, we protected experience simply because of the order number, which I changed without touching a line of code. If helping you “fake it ‘til you make it” isn’t enough reason to love a data-driven solution, I don’t know what is!