To be fair, I have not read the book version of ‘The Long Tail’.  I do, however, feel like I have if only because the title finds its way into many strategy sessions for online products and services in which I have participated.   The argument, as I have understood it from Chris Anderson’s own writing on the subject, purports that Brick & Mortar stores are not and cannot meet the demand of the market by only shelving known hits.  The physical limitations of shelf space are removed in online markets and should result in greater diversity of product selection. Online retailers should expect that diversity to translate into longer purchasing curves from their customers as untapped demand beyond those hits start to become fulfilled.  That customers will begin to spend money on niche areas is what is meant by the long tail of products sold in a new marketplace.  The Harvard Business Review has a good writeup here.

The Harvard Business Review also published an article which investigated possible markets which should exhibit this behavior to see if they followed the long tail curve.  Their findings are interesting, if not conclusive in my opinion.  The data shows that blockbuster products, those products which are both highly publicized and in high demand, are still a solid marketing technique in the online retail space and that stores should not underfund or abandon support for popular products in lieu of diversified selection. While this flirts with the fringes of obvious, it is supported by what looks to be solid research numbers which is always a sound practice when analyzing popular pet theories in the business community.  It further infers that the ‘Long Tail’ is greatly helped by having these popular titles in the inventory and possibly acts as a catalyst for more diversified sales.

Starting on page 4 of the report the author has given the online retailers and websites (presumably the reader of the article as well) a wonderful list of suggestions drawn from her research.  Visit the HBR site for more details.  Techcrunch’s Erick Schonfeld also has a good write-up on the article here.

My personal take on the article has more to do with the presumption of availability.  Both the Long Tail and this article make clear the need for an inventory to not languish in the back unseen.  How easily your customers can find the niche products has a huge impact on those sales graphs and it is brought up as an aside in the article.  The requirement for businesses to connect customers with relevant, niche inventory is not limited to retail.  Digg just implemented a recommendation engine that has been largely covered in the press.  The simple act of bringing uncommon or less popular content to a visitor based on their viewing patterns is every bit as much about the Long Tail of content consumption as is Amazon’s product recommendor.  Bringing in the customers with the Blockbusters is half the dollar you can earn.  The rest comes from connecting that customer to other products you have and getting those products in their shopping cart.

You may have heard that websites built in Flash or as Rich Internet Applications (RIAs) are invisible to search engines and are not a great idea for search engine optimization (SEO). This is not entirely true as sites which are built properly may enable search engines to reach a great deal of their content. However, this usually requires that the developer really knows what they are doing and may require special coding just for the search engines - even that is not a guarantee that search engines can reach everything (or anything depending on the content).

Today, Adobe (the makers of Flash and many other RIA products) announced that they are working with search engines to make the content in Flash and RIAs more visible to searches (or indexing). Yippie! Let’s code all our websites in beautiful Flash, right?

Well, hold on. The problem is much more complex than just working to get the content searchable (which in itself is quite complex). As Hank Williams discusses, the way RIAs are created inherently makes the information in them very difficult to display to a search engine. He uses the example of Microsoft Word where the type of information that is available to search engines is the menus and what is in the menus, which is not particularly useful. Much of the information that is available in RIAs requires a person to make some type of interaction (choosing to see all the red shoes for example), which then displays a specific set of information - very difficult to reproduce for a search engine and even more difficult to make meaningful to a search.

This is certainly the first step in having information in RIAs available to search engines, but there is much work yet to be done. Flash and RIAs can be used to provide great customer experiences, just don’t bet on them to provide search engine traffic to your website (yet).

More coverage:

• Official Google Webmaster Central Blog - Improved Flash indexing
• TechCrunch - Once Nearly Invisible to Search Engines, Flash Files Can Now Be Found and Indexed
• ReadWriteWeb - Adobe Makes Flash Searchable - The Holy Grail of Website Usability?

Technorati Tags: Adobe, Flash, RIA, rich internet applications

What does ABC, NBC, CBS, ESPN, Comedy Central, MSNBC, CNN and your website all have in common?  Well, they are all content providers who are fully or partially ad funded (I’m guessing you are too).  Oh, and you are all experiencing a viewer revolt over your advertisements.

Tivo and DVRs have made ad skipping within your TV shows commonplace.  The growing number of DVR users has forced networks into a scramble to find new ways to reach their viewers with targeted marketing.  Likewise, viewers online are using technology to ‘block’ ads from showing above, below, besides and within a site’s content.  While the number of people using ad blocking software is still small, little is standing in the way of massive adoption.

An ad blocker typically works by selectively ignoring requests within your sites HTML or JavaScript to contact a 3rd party and download an advertisement.  The software knows to ignore a request because someone has added it to a list, such as EasyList.  The method used by the software and its list is crude but effective.  Since most ads are served by 3rd party ad networks, the list need only identify the IP addresses or domains of major ad distributors to effectively block most of the ads on the web.  It is worth noting here that ads that fail to be downloaded also fail to register an impression, effecting your ad revenue directly.

While tools such as ad blockers have a head start in the race, sites are now ramping up their countermesures.  Knowing that they lose money by hosting ad-free content to visitors with ad-blocker, some sites are using a tool developed by hackers to identify ad blockers.  Once located, those visitors can be sent special messages requesting that they turn off the blocking on your site.  Some sites may even deny visitors with ad blockers access to their content.

One low-tech method to combat these ad blockers is to host ads within your own domain and from randomly generated urls.  This takes both the predicability and the top level location out of the equation for most ad blockers.  Still another suggestion, posted by the guy behind EasyList, is to create interstissile text ads within your content, much like what is done in the Radio industry as well as ad supported Podcasts.

Technorati Tags: advertising, ads, ad blockers, online advertising

Have you saved your paper sketches from that million-dollar idea you had while drinking at the bar?  You know, the one you wrote on the back of a napkin? It turns out that many web sites have had a paper phase.  Its actually a common theme that connects our humble web efforts with software projects throughout a quarter century.

Deeplinking has posted a short gallery of some early stage drafts of web sites you may be using today.

Included in their selection was this impressive video on how to interactively paper prototype.

This video is paper-based prototype for Daum’s web mail service, Hanmail.net made by Ajax.

For anyone who has run multiple instances of Rails on the same server, as is common within the frugal budgets of corporate IT departments, then you will have run into a limitation of resource allocation, typically memory.  The Ruby community likes to defend their language’s performance tradeoffs by reminding us all that hardware is cheap, or at least cheaper than your developer’s time.  While I agree that hardware is cheap, cheaper still is not buying more hardware than necessary and instead find new ways to use your limited resources efficiently.  The folks at Phusion have similar concerns, which is why they have developed the Ruby Enterprise Edition.

Ruby Enterprise Edition is a forked version of the Ruby on Rails web framework.  For those not familiar with the software practice, forking is taking existing source code, usually open source, and branching off your own version in your own direction.  Programming communities discourage excessive forking because it waters down the developers focused on the original project.  However, when a group has different goals than the original, it can be the quickest and least painful way to accomplish that goal.

The goal of the Phusion group who created Ruby Enterprise Edition was to directly address the memory sharing practice of multiple instances on the same hardware.  Technical details can be found here For those business users who have issued one server to be their company’s ‘Rails Application Server’, this fork may become a standard deploy.  It purports to save 33% of the memory typically allocated with the parent version of Rails. As the fork is compliant with 1.8.6, you can run all of your recently created web applications unless they were developed against edge rails for the very recent release of 2.0 or 2.1  Forks typically lag behind parent source code in feature support, but there is no reason to doubt Enterprise Edition will not support 2.0 soon

Phusion has not rested on this solution for improved corporate rails hosting.  They have already also developed a module for Apache called Passenger (also called mod_rails).  Apache Modules like this have made languages like PHP a brain-dead easy solution for developers and programmers to get web apps up and running.  As I have said earlier, Rails suffered from a complex set of options for hosting.  Mod_Rails really takes that issue out of the equation.  Couple Passenger with Enterprise Edition and you have a well thought out corporate solution for your growing number of Rails applications

Personally, we are looking to use the Enterprise Edition / Passenger combination on an web application we developed internally.  It is exactly what we need to expand deployments of unique instances without overcompensating with more hardware investments.

Technorati Tags: ruby on rails, ROR, ruby, ruby enterprise edition, Phusion, Passenger

If three of the four words in that title apply to you (and one of them isn’t ‘for’) then you may want to check out eRubyCon

The guys over at EdgeCase are very talented Ruby consultants.  I have had the pleasure of working with them on a few projects and I can tell you their hearts are wholly into the Enterprise Ruby space. That kind of passion for their craft should translate into an engaging conference.  Certainly, the speakers they have lined up are first rate

My personal opinion is that if you are not using the best tool for a job, you are using a second rate tool. You can be in a .Net shop or a Java shop and still not have the right solution for every problem an Enterprise can throw at you.  If you have been at all impressed by what Ruby can do for you in the Web Framework arena with Rails and Merb, you should really check out the other places it can make a difference in your company.

Technorati Tags: ruby on rails, ROR, ruby, eRubyCon, EdgeCase

Web Analytics World discusses some web analytics tools (free) to take a look at, including Woopra, Crazy Egg, Enquisite, 4Q, and ClickTale - 5 Great (Free) Web Analytics Tools You May Not Know About Yet.

Without knowing it, my father has skillfully summed up a crisis we are facing online. ‘I have too many $#@%ing passwords’ he told me the other day ‘Just email them to me’. We had just uploaded our latest series of pictures starring his granddaughter. ‘Dad, its real easy. All you need to do is get a Flickr account. Tell me the account name and I’ll share my pictures with the account. Then you can login and look at them online’ I said as if I had just solved all of his problems. But, as I mentioned earlier, he has too many passwords. Too many accounts to remember. Too many places that want the same pieces of personal information over and over again. When he visits he brings his own camera.

The issue is one of those big, nasty problems that would have been solved already had their been an obvious solution. In the internet’s infancy the World Wide Web was just that, a web of interconnected, hypertexted documents. Plain old text-heavy Web Pages which were free to any browser who could connect and request them. Back then, who you were was a very uninteresting question to ask. Web sites didn’t care much what your username was or what street you live on or what your phone number is or who’s in your address book. It is back in this era that the Authentication and State models were developed for the simplest of cases where a sensitive document may have a basic password protecting it. This is years before online Shopping Carts, Home Banking, Corporate Intranets, Web Applications and Social Networks. We are today banging our heads against the limitations of past decisions.

Over time sites started implementing “login” methods as a way to validate users. They all asked the same personal information because no independent website talked with any other. Programmers typically call this a ‘Share Nothing’ approach. As more and more and more and more websites became important in our lives, this share nothing attitude was cause for a growing concern. Your information was being used as currency upon which you were granted services online, grossly inflating the chances of that information becoming misused or abused. Online user accounts were completely disjointed from your actual identity, to where on different sites you may be referred to as “aaronworsham” or “worshama” or “aaronw” or “IndyMusicFan56″ or “MgoBlue1997″ depending solely on what name was free and available at the time. Worse yet, many sites are using your email address for a username, forcing most of us to setup dummy accounts that we must now maintain for password reset requests.

So what is to be done about this? Scary as it may sound, we need to pull away from our “Share Nothing” architecture and start interconnecting these web services. What if my Father had an account at Google for his mail. If Yahoo trusted Google, it could ask Google to “log in” my father so that he could get into the Yahoo owned Flickr site and see his granddaughters pictures. His personal information, including his password, would be housed on Google only. The identity he uses to login could be his Google account or can be related back to his personal blog account or his personal domain name. His identity would remain static. This is the basic idea behind OpenID

The OpenID initiative was started by Brad Fitzpatrick of LiveJournal as a way to start distributing trust relationships for sites like his. In theory it works when one company agrees to be a provider and many companies trust that provider for their authentication. To date many more companies are agreeing to be providers of OpenID than sites willing to trust them. This is still early on, so I feel that this will change over time as more sites start out with the decision that their users do not want yet another place to store their personal information.

Authentication usually has a “on or off” connotation. You are either allowed in or you are not. That need not be the case. Taking the idea of trust relationships further, we imagine using the OpenId model to ask for permission to use services on another site. Take, for example, My father logged into Flickr through his Google OpenID. Now Flickr wants to email out a picture to each of his friends on his email address book. My dad could put all those email addresses into Flickr, but he wouldn’t like it. What if Flickr could use the OpenID trust relationship to ask Google to share dad’s address book. As long as Dad was prompted to provide his password, Flickr itself could be granted limited authorization into google to use dad’s Gmail address book. This is the idea behind OAuth.

The OAuth was a group project between the main engineer at Twitter and some engineers in the OpenID community. The official OAuth site has a good analogy to help get the concepts behind limited system authentication straight

Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything.

These concepts of OpenID and OAuth are even easier to apply to closely controlled interconnected systems like within a company. Sure, most companies have standardized on an LDAP solution by now, but as more applications become web-enabled, it becomes advantageous to consider supporting the standards that the web is using on the outside. Once you try interconnecting your internal applications with outside, 3rd party systems that do not have access to your LDAP repository, you will want that trust relationship model OpenID and OAuth brings.

Technorati Tags: OpenID, OAuth, authentication

Text ads come in several different forms, including link ads, contextual ads, pay-per-click and online directories. These ads have several advantages & disadvantages to consider before purchasing them to promote your website, products or services.

Advantages

• Cheap - Since these ads are just text they are usually the cheapest type of online advertising you can purchase.
• Search Engine Friendly - These ads are often are embedded right in the webpage which gives search engine ranking to your site. This is not always the case and many websites will demand that these ads go into their ad serving systems for tracking and security reasons.
• Attention - Since they are only text, these ads are less annoying to readers, so they are actually more likely to read and click on them, especially contextual ads. Readers are less likely to classify them as ads which need to be ignored.
• Easy - Creating a text ad is as easy as thinking of the text. Creating engaging text within the character limits can be a bit more challenging.

Disadvantage

• Limited - Most text ads have character limits which restrict the amount of information you can convey. Text ads by their very technology convey less information than rich media ads and some display ads.
• Little Information - Information collected about text ads is usually limited to impressions, clicks and possibly some information about who clicked on the ad (if the site has registration tied to their ad serving - more on analytics in a future post).
• Not Accepted - Some websites do not accept text ads since they can demand higher rates for display ads.

If you’re new to advertising, text ads are a great place to start for ease-of-use and budget.

Technorati Tags: advertising, ads, text ads, online advertising

Continuing the web advertising thread, we are going to look at an Ad Hosting service provider.

ThruPort Technologies, the company behind the AdJuggler ad hosting service, was started in 1999 by Bruce Waldack of digitalNation fame. Bruce founded digitalNation in ‘91, which was early enough in the dedicated server space to gain market share and grow it to one of the largest players in dedicated hosting at the time. In 1999 he sold digitalNation to Verio and started ThruPort the same year. AdJuggler was launched as one of ThruPorts first named services. As ad hosting services go, AdJuggler is well known in community. There are a few competitors to AdJuggler on the market, mainly because hosting ads itself is not a high technical feat to accomplish. That having been said, reliability and reputation carry a ton of weight in the advertising game and AdJuggler currently seems to have both.

AdJuggler offers up its service in three flavors. For the Enterprising web provider, Adjuggler will sell a license to run their code at your hosting location on your equipment. Ill get into why that is a great option later on. They also offer the traditional Turnkey service where all hosting and storage remains within their location, you simply link up a JavaScript tag on your site to pull the ads down. Lastly, they are available as consultants and API solutions for the roll-your-own crowd. Having worked with the guys at AdJuggler on integration projects with their API, I can say that they do know a thing of three about serving up web ads.

The technology behind their service is, as I said before, basic stuff. Basic is not a bad thing, especially when you have a solid foundation of hosting experience backing you up through ThruPort Technologies. While hosting ads is the foundation, reporting clicks and impressions is where the real work is done. They do a nice job of providing many reporting options for you at the web application. For that extra special reporting itch, the API is available through authenticated SOAP. I like to combine my AdJugger statistics with my registered user information from my web app and my traffic logs from the Apache server. The API lets me pull that information down easily and store it locally in an aggregated format. The Enterprise solution is a cool option for sites that are big enough to conduct pre-processing on their ads before sending them out to the reader which can increase cache-worthiness of the page as well as compression and optimization of the media files. It also makes the stats and the workflow a whole lot easier to tie into your system.

Price: AdJuggler charges by the impression. They do not provide pricing information publicly on their web site though Jonathan Rivers, Executive Vice President of Ad Juggler, has indicated to me that their contracts start at a $.04 CPM range (CPM is cost per Thousand impressions, think Roman Numeral M).

Technorati Tags: AdJuggler, thruport, advertising, ads, display ads, online advertising