24 E-commerce development tips

This is part of my ever-growing list of tips for developers building e-commerce sites. I cover a lot of territory in one list, so be gentle folks.

1. Use SSL only within your cart. There’s a hell of a lot of debate around this. But one fact is clear: SSL page requests require more server cycles than non-SSL page requests. If your site gets tens of thousands of page and file requests per day, it adds up. Plus, if your whole site’s in SSL, things like Google Webmaster Tools won’t work. So only use SSL for pages that need it: Your checkout process, and any other pages where a customer has to enter confidential information.
2. Don’t use SSIDs in your page URLs. Ever. EVER. SSIDs are ugly things like ?sid=asdfweroi120398123582745 that end up on the end of URLs on some sites. They’re used to uniquely identify a user session, for purposes of tracking stuff like your cart contents. They’re also unnecessary until you put something in your cart. So don’t use them, at all, on the site unless someone’s added something to their shopping cart.
3. Use good validation. When the designer asks you to check if someone forgot to type in their address, don’t make some smartass remark about how you don’t want them as a customer anyway. Practice good defensive design: Regardless of what someone does wrong, be sure you give them clear guidance to correct it. Forgot to fill out a field? Reload the page with a note indicating the problem. Someone used a weird escape character? Fix it for them.
4. Use friendly validation. When you reload a page because someone screwed up and left a field empty, reload it with all their information included. Please. Read Defensive Design for the Web for tons of great tips.
5. Cache everything you can. Cache pages. Cache images. Cache shopping cart data. If you can’t cache a whole page, cache regions of the page. Cache in memory and on disk. Cache, cache, cache. Otherwise great success will mean a lot of late nights and angry calls from your CEO demanding a faster-running site. Do it now, and save the pain later.
6. Minimize database hits. Caching does some of this. But you should also keep a close eye on round trips to and from the database. If you’re loading product options, inventory and 10 images from 3 different tables and 3 different queries, why not load them all using a single query? If you really want to optimize, create a view.
7. Use stored procedures. Hopefully I don’t have to explain this one. if I do, well, Google is your friend. And so are stored procedures – they make your database faster, provide a layer of security and make maintenance a lot easier.
8. Give your database and your website separate homes. Put your database on one server and your website on another.
9. Set up your database server to handle the kind o f read/write-heavy operations it’ll have to support. That means RAID 5 or 10, lots of storage, and lots of RAM. You want at least as much RAM as the eventual maximum size of your database. Note: For some non-ecommerce applications, you may only need RAID 10 for your transaction logs, and can save a little cash by putting the actual database files on a less expensive array of disks. If you can’t afford this fancy stuff, invest, at least, in a basic SATA array and buy the fastest drives you can afford.
10. Set up your web server to handle the kind of throughput- and cache-heavy operations it has to handle. That means lots of RAM, maybe a really fast processor, but don’t worry about the hard drive speed. Unless you really screwed something up, you shouldn’t need a zippy hard drive set up.
11. Build for redundancy in all things: Multiple hard drives with multiple copies of your database; same thing on your web server. That way, if one hard drive fails, you’re still OK. I used to snort at dual power supplies, but they’ve saved my butt numerous times now, and they don’t cost much. If you’re really paranoid, store an up-to-date copy of your site on a service like Amazon S3, so you can switch over in a hurry in case a comet hits your hosting facility.
12. Plan for coupons. Make sure the shopping cart can handle coupons, even if you haven’t build the front-end functionality for it yet.
13. Plan for bizarre discount structures. At some point, the head of sales or marketing will come into your office and request a 15% discount for all orders over $40 that include something blue. Or for one specific set of products. Etc.. Might as well make sure the flexibility is there now.
14. Plan for product reviews. At some point, someone will say “we need to be customer-focused” and ask for a product review functionality on the site. At that point, you can slug them for saying ‘customer focused’ or you can suck it up and add reviews. If your database is already designed to accept them, you can take
15. AJAX is fine for checkout, not for product browsing. Don’t load products or product previews in DHTML windows or an AJAX widget. Search engines won’t be able to find them. Which means you won’t sell anything. Which means you’ll go from full time to part time to contract to unemployed. Use AJAX to smooth out the checkout process, instead.
16. Document. Yeah, I know. Coders hate documentation. Until you’re the coder who picks up someone else’s mess after they’ve left for the Bahamas. All you have to do is save the database layout and write maybe 2 lines at the top of each code snippet explaining what they do. You could even do a flow diagram. You’ll be a hero.
17. Document, 2. Also, provide some basic guidance for your marketing team. Stuff like “Don’t set inventory to 0” is a great start.
18. Build in analytics. Make sure your whole site is set up for analytics. That includes the usual stuff, like tracking pageviews and visits. It also includes goal tracking and order tracking. Ask the marketing team what analytics package they want, then implement it. If they don’t know, try Google Analytics, since it’s free and pretty damned complete to boot.
19. Build in an XML sitemap.
20. Get ready for fulfillment. You may end up with a great, super-competent fulfillment house. Or you may end up having to integrate with one that still uses steam power and thinks punch cards are innovative. In either case, the more you do to support stuff like inventory updates via file transfer and XML feed, the better off you’ll be.
21. Build in an automatic product feed, because it’s just easier to do it now. Plus, think how good you’ll feel when you point it out to the marketing team in the next meeting?
22. Make it easy for non-geeks to update products, inventory and everything else. It’s easy to skimp on the administrative tools. But the more complete the admin system, the less you’ll end up being the phone support team for the entire company. Make sure they can do everything, including republish your XML sitemap and edit the product feed.
23. Automate customer contact. When a customer places their order, send them a confirmation e-mail. When the order ships, send them a shipment confirmation and shipping code. A month later, send them an e-mail seeing how they like their product. Oh, and make sure the marketing team can edit the e-mails themselves, unless you want to add e-mail copywriting to your resume.
24. Use good canonicalization practices.

That’s all folks. I’m writing this at 36,000 feet, thanks to inflight wifi, so I have to publish before the flight attendant duct-tapes me to my seat.

Related reading

• The developer’s guide to internet marketing
• Canonicalization 101