A Social Life

What are the personal benefits of tagging? (Part 2) May 18, 2006

Posted by Steve in : enterprise, tagging , trackback

The most common statement I read about the benefits of tags is that publishers should tag posts so they can be found more easily by searchers. I can see why people would think that, but I don’t really buy into it myself.

I’ve already mentioned that I rarely use tag search, so maybe I’m missing some hidden value. But my reasoning is this: if tag search were really working and delivering lots of click-throughs to web pages, wouldn’t there be more tag spam? It’s incredibly cheap to add any number of tags to your posts. Yet there’s no apparent problem on well-established social bookmarking apps like del.icio.us and in tag-trackers like Technorati. (Has Technorati introduced any advanced “PageRank”-like algorithms to keep spam out?) This can only be because tag search hasn’t been adopted by anyone but power users yet.

There probably is some search benefit around tagging “hot topics.” After a conference, product release, etc. you would expect to see a lot of activity around tags relating to that event. Use of these tags would increase for a while, and either establish a new common search term, or slowly fade out. But in this case, I’m not sure it’s the tags themselves that make such a difference – rather the date-ordering of tag search results probably helps the most. And overall, this seems like a minor benefit that’s only useful after tagging has already been generally accepted.

I don’t mean to completely dismiss tag search, but it doesn’t seem like a killer app that will gain enterprise adoption by itself, especially in the face of competition from regular search. So why else might publishers tag their content?

In my opinion, the real benefit is a counterpart to tag search: the ability to easily organize and publish collections of content. Instead of (or in addition to) using tags to be found in search, it’s possible to use them to push content to interested people through integration and syndication. While this may cause most readers to think of RSS feeds, that’s not the only way that data can be syndicated. In fact, it probably doesn’t even register in the enterprise yet - the most common form of syndication in today’s enterprise is sending documents and links in e-mail, a low-tech solution that works pretty well for sending single items.

When you need to publish a set of related content, though, it’s actually quite difficult to do. Sure, we’ve been using databases, content management apps, file shares, etc. for a long time to distribute collections of information. Maybe soon there will be larger enterprise adoption of blogs and wikis. But in all of these, the typical sharing model is to copy a bunch of content into the application (or create it there originally), and then send people there to find it. The user has to overcome a lot of barriers just to start a new content collection, much less keep it updated over time.

Everything changes when you’re able to easily add tags to content at its original source. The use of tags introduces a separation between content’s repository and the collections it’s in. Tags can be used to collect content from multiple repositories, just like a federated search engine indexes keywords across several sources. New collections can be created with no more effort than thinking of a new tag term. After the collection has been created, bookmarking services allow you to send entire sets of links, usually providing nice compact URLs to ease the process. Even when the feed is primarily designed for your own consumption, it can just as easily be shared with others should the need arise. Better yet, the collections keep updating as you continue tagging.

This can often be done without any special integration work, as long as repository content is addressable through an URL or something like it. But there’s no doubt that integration into the content’s native environment helps adoption, as evidenced by the number of bookmarklets and browser extensions used by frequent bookmarkers.

Even deeper integration is available through service APIs. For instance, a small plugin I wrote replaces links to del.icio.us tags with an inline list of the most recent articles I’ve tagged with that term.

In the end, whether or not users understand that they are creating “syndication feeds” by tagging, the unmatched simplicity of tag-based aggregation is a huge benefit to publishers! (I’ll address feeds in more detail in an upcoming post.)

Still, to reach a larger audience, you can’t count on always pushing. You have to figure out how to be where your potential readers are looking. Unlike a consumer’s tagging, there’s much more incentive for publishers to try to use a public vocabulary when tagging. Even if tag search doesn’t work so well yet, publishers are still much more likely to connect to users with similar interests via common tags. In fact, since people will use terms from their own vocabulary to browse and search, publishers should attempt to tag using the specific vocabulary of their audience.

This means not just using commonly accepted terms, but digging deeper into synonyms, misspellings, misunderstandings, and the like in an attempt to reach readers who might not even know those common terms. Unfortunately, this often leads to an incredible mess of tags, further diluting the value of tag search. Here’s how to clean up that mess!