Since this is the technical side of Appozite, I’ll take a second here to talk about the technology behind ZiteFight. It’s written in Ruby on Rails with MySQL as the database. Since we’re planning to handle tons of votes, I put a lot of work into making sure the process of saving results from fights wouldn’t get out of control. As they’re received, votes are put in a queue table which uses the MySQL Memory storage engine so they don’t actually have to touch the disk when the user’s voting request comes in. They’re then saved to an intermediate queue table every few minutes in a background job which also updates some stats like fighter records, etc. Finally, every hour they get archived off by another background job that calculates rankings and does some other housekeeping. So far it seems to be working quite well.

On another note, I’ll mention that it’s hosted by SliceHost. I highly recommend them so far. They’ve got tons of documentation on all sorts of sysadmin topics. Performance has definitely been good as well.

Jenn started this conversation over on Appozitegeist and makes a great case for how RSS can replace annoying bulk marketing emails from retailers. She also has quite a bit to say about how difficult it’s been to get uptake of RSS from the general population. Like cold fusion or the hydrogen car, it appears to always be just over the horizon. I won’t repeat those topics here but I do want to discuss what a great fit RSS is for the standard e-commerce data management model as well as for its business model.

One place where RSS has undeniably found a home is on blogs and news sites. There’s hardly a news site left that doesn’t offer a feed of at least top stories, if not a section-by-section breakdown of headlines. This is perfect for RSS because there’s frequently updated content as new posts and stories are added. Though news sites seem worlds away from selling products, I think e-commerce sites are actually very similar. To bring people back to a store, retailers must offer fresh content in the form of new products or promotions.

In both news and e-commerce applications, the data is highly structured. Just like blogs and news sites which use content management systems to continually update posts/stories containing headlines, by-lines and text which exist in categories; most e-commerce sites of any size have administration software for updating product data consisting of names, descriptions, prices, inventory quantities and other attributes. Products are, of course, also segmented into categories. In short, what works in the news business should also work in the shoes business. (And, look at that, Zappos does offer a “latest styles” RSS feed.)

From a technical perspective, it’s pretty straightforward to take a structured data system like this with discrete update events and efficiently generate feeds for products and categories as the data changes. One interesting (and architecturally more complex) extension to this would be feeds generated based on a user search term. Users searching a site for something but aren’t quite ready to buy can subscribe and be notified when new products that match that term are added or changed.

From a marketing perspective, this ought to be a no-brainer. Targeted subscriptions chosen by users (especially around search terms) certainly seem like they would have high click through rates. So what about the issue of RSS and feed reading not being mainstream? Pheedo, an RSS marketing agency, broke down RSS reading data back in 2005 and noted that many readers were in the 18-24 demographic. It’s unlikely that those users have changed their habits drastically since then and it probably is likely that younger users have continued to read feeds. That probably means we’re now looking at an 18-27 demographic of heavy internet users (which tend to be better educated and more affluent than average) who would potentially be interested in feeds. This starts to look ideal for many retailers. Yahoo! also noted in a white paper on RSS usage that quite a large number of people use RSS without realizing it on home pages like my.yahoo.com and iGoogle.

Of course I’m doing a lot of handwaving here. There are plenty of details about measurability that need to be covered and more research to do on whether or not there really are enough RSS users out there who want to include e-commerce feeds in their shopping arsenal to make it worth the technology investment. However, I think e-commerce providers should take another look at RSS to help them get better, stronger and faster.

PS: In the course of researching this blog post, I found a lot of interesting stuff about RSS uptake but it’s somewhat outside the scope of this post. I thought I’d provide a bit of a link dump here in the hopes it would be useful to people:

1) Two of the most popular online feed readers (a good proxy for RSS usage), Bloglines and Google Reader, are both growing fairly rapidly but from a small base. Compete shows Bloglines traffic increased by 172.8% year on year to May.

2) Mobispine and FeedBurner have a few things to say about the state of the RSS market in 2007.

Generally people are able to find products by searching for and reading product pages on e-commerce sites.  Humans, of course, perform this miraculous feat because we’re very good at looking at a page consisting of images, some bold text and a few lists and determining most everything they need to know about a product. Software, however, is terrible at this. If you look under the hood at the HTML on these pages it’s all tag soup and basically impossible for software to understand. It might look good to us, but to a piece of software, it’s total static.

Luckily, people are working on the issue of making it possible for software to understand what’s going on. Loosely, the efforts to do this are grouped under the heading of “the semantic web“. This is a pretty broad topic and extends from the complex subject-predicate-object statements of RDF to the much more simple html approach of Microformats. Though RDF and its more complex ilk can and will probably aid in product discovery in the future, I want to focus on the Microformats approach. So what’s a Microformat? I think the prize for best description goes to Drew McLellan on the Microformats wiki:

Microformats are a way of attaching extra meaning to the information published on a web page. This extra semantic richness works alongside the information already presented, and can be used for the benefit of people and computers. This is mostly done through adding special pre-defined names to the class attribute of existing XHTML markup.

So, basically it’s a standard way of using HTML to describe a particular thing that you’re displaying in a web page. This thing might be a person, an event or a relationship between people. It might also be… you guessed it, a product.

With that in mind, I wanted to do a quick review of the work being done over at microformats.org on product related Microformats that we think can contribute to better shopping, reviewing and recommendation experiences for everyone by making data more avaialble to software that helps you find cool stuff. These are hReview, hListing and the currently moribound hProduct.

hListing

hListing is a proposal for a format describing items listed by a seller for sale to a buyer. The focus of hListing is on properly describing a  classified ad; more of a Craigslist or EBay listing than a product for sale on a traditional e-commerce site. With this frame of reference in mind, hListing requires the the formatted listing include a listing action (such as sell, rent, trade, etc).

hReview

hReview is one of the older Microformats and is in version 0.3 (which passes for old in MF land). Though technically a draft specification, it’s been adopted fairly widely “in the wild“. The concept behind hReview is simple; provide a format for describing what a user thought of something (product, service, event, etc). hReview requires a pointer to an item being reviewed in the form of a URI, hCard (for a person being reviewed) or hCalendar (for an event being reviewed).  All other aspects of an hReview are optional but the key ones are reviewer, rating, dtreviewed and description. Together these describe a pretty standard “3 out of 5 stars + description” review that we see on most sites providing product review capabilities.

hProduct

Of the three, hProduct has seen the weakest effort at official specification. In fact, it’s on the Microformats.org list as “moribound” and the Microformats folks would probably say that the term “hProduct” shouldn’t even exist as it has not officially advanced beyond the research stages according to their process. That said, hProduct has the noble goal of describing a product itself outside the context of a classified-style listing of that product for sale (hListing) or a user’s feelings about that product (hReview). The rough draft proposal for hProduct combines the standard attributes you would expect such as name, (text) description, image and uri with a more elaborate product description capability using extensible property-value pairs. Anyone who’s ever worked with Amazon’s extensive product property-value taxonomies will see that this methodology is a fairly resonable approach to describing products. However, it seems that the Microformats community is not very enthusiastic about hProduct and generally suggests people consider hListing instead.

So where does all this leave those of us who want to discover cool stuff online? Of course if sites don’t use Microformats, the tag-soup situation doesn’t improve. We’re going to do our part at Appozite by making sure we support hReview and hListing where approriate in our software. We’re also going to work with the Microformats folks to see if we can help revive hProduct because we think it has a lot of potential for cleaning up the tag-soup of today’s e-commerce sites. We also hope any of you reading out there will join us and the rest of the Microformats community to encourage their use. So, next time you stop into your local e-commerce store to pick something up, see if they’re supporting microformats on their pages. If they don’t, tell them they should!

I’m pretty sure I’ve bought something because someone on Twitter “endorsed” a product. If they liked the product so much as to announce it on Twitter, I knew it must be a great product. There are 2 other factors that built credibility. I knew that they weren’t being compensated for it. And I liked that there was not any “system” for providing this recommendation; it was just organic through Twitter.

This comment preceded a post on Mashable this past week about a spammer site called Tweet2Win (and no, I’m not linking to them) promoting themselves by asking Twitterers to include their domain in tweets for a chance to win prizes. They even offer helpful suggested tweets such as:

www.tweet2win.com Has anyone heard of this site? You can register free and win prizes for Twitter status updates.

Pseudo-realistic sounding tweets for spam schemes like this could do a fair amount of damage to Twitter as a platform for authentic and valuable product recommendation experiences like Steve’s. Though people are pretty good at sniffing out a paid statement, less blatant references could slip in under our collective spam radars. At least Robert Scoble had the decency to precede his semi-infamous Seagate advertisement tweet with “ADVERTISEMENT:”.

As social software services like Twitter cast about searching for a business model to go along with all that VC money, there’s going to be more of this toeing the line between the organic and the paid. On Twitter at least, most of the experimentation (excluding Twitter Japan) is being done by somewhat sketchy third parties. However, Facebook’s beacon was an example of the company behind a social service turning its user-base into (largely unsuspecting) endorsers. Look for more tension (and hopefully some compromise) between the free social software Utopians and the “hey, I’d like that 10x return now” business guys as we collectively try to figure out how to do this right.

Update 6/14/2008 @ 6:30 PM CDT: Scoble discusses how he’s not paid by anyone except Fast Company to pimp anything.

Here’s what I’d like to see: a friend endorsement system and the creation of a new advertising category named, “social advertising”. Here are the basics on how the program would work. You enter the products you’d be willing to endorse to your friends into the system. Your friends do the same. When you are ready to purchase an item, you check the friend endorsement system and review your friend’s product endorsements in the category you are interested in purchasing within.

I think we have to be very careful about this. Endorsements from friends are more about the authenticity derived from real trust between people. We’re willing to accept that celebrities get paid to say things. However, any system for social product endorsements or advertising has to be extremely careful not to come across as spammy. No one wants someone essentially selling Amway in their social network. This means that things like payments for endorsement become extremely tricky. (Allen’s not directly suggesting payments, but it seems implied.) Any perceived conflict of interest on the part of the endorser and you lose the authenticity on which this system depends. I think this means that endorsements need to be more of a by-product of other interactions and less the focus of the system.

I also think any system that provides this needs to add value on top of our normal real-world endorsements where we mention a product we like in casual conversation with friends. Part of this is providing a way for people to find out about products their friends like that they wouldn’t necessarily sit down and talk about. This sort of serendipity + a trusted recommendation from a friend is a powerful way to discover products you’ll like. There is definitely potential here.

At Appozite, we’re working on a system with some of the elements that Allen describes. However, we’re always very aware of the issues above. Here are our guiding principals:

1. Never compromise user trust
2. Create something that uses the unique aspects of the web to provide an experience people couldn’t otherwise have in the real world

We believe that if you don’t do those things you should pack up your servers and go home because you won’t have users.

So, can we all become mini Kelly Rippas (sans the irrepressible chipperness and with a heavy dose of authenticity) in our own circle of friends? Should we? How can an online system of friend endorsement improve upon what we already do in normal conversation? I’d love to hear what you think.

So what can you expect from dev.appozite? Look for some hardcore algorithm stuff about recommendation systems as well as thoughts on building scalable internet services. You can also expect occasional philosophical musings and comments on the important stuff going on in social software today like data portability and the nascent social layer of the web. I’ll also talk a lot about emerging standards like microformats, OpenID, oAuth and OpenSocial. There’ll be a few comments here and there about our business and the business of social software as well.

In short, if it’s pretty geeky and it has to do with social software, I’m here to talk about it. I hope you’ll join in the conversation.