For now, let’s stick with the traffic component. Can a social bookmarking site direct significant traffic to your site, and is it worth your trouble to use them?

Case One: Digg

I’ve used a variety of social bookmarking sites while promoting this site – Digg being one of them. Although some people have had tremendous success with Digg, I haven’t. Most of the articles I Digg end up falling off the recently submitted page without too many Diggs.

In the past two months, I’ve had a dozen or so articles go up on Digg and I’ve only gotten 230 visits in return. Most of those articles fall off the page after I’ve gotten a handful of visits.

Two articles were moderately successful. One article I didn’t submit myself – a reader Dugg it and it promptly gained about 20 Diggs. Despite its relative popularity, it didn’t bring in a whole lot of traffic.

Many of my articles are designed to garnish search engine traffic, so that may be why they don’t appeal to users scanning a bookmark list. I did write another article that focused more on an attention grabbing topic and less on search engine juju, and it did ok on Digg (~100 visits).

For whatever reason, Digg hasn’t been tremendously helpful for me. I still leave it on the toolbar at the bottom – so that users can Digg an article they like – but I don’t actively submit many articles hoping for traffic.

Case Two: dZone

While browsing through social bookmarking sites to promote this site, I stumbled on dZone.

At first I was excited. It’s geared towards programmers and web developers, so my technically oriented articles should have done well. Not so much.

Perhaps I haven’t found the right approach to take. Some articles were probably too rudimentary for the savvy audience, while the more advanced articles didn’t have attention grabbing topics.

I’ve gotten a little bit of traffic from dZone – slightly less than from Digg – but it’s nothing to write home about. I continue to use it every now and again to gain some backlinks, but I don’t count on it for traffic either.

Case Three: Stumblupon

Unlike Digg and dZone, Stumble Upon has done a great job.

One day I looked at my Google Analytics data, and I thought the thing had broken. An average day at the time was about 2-300 visits – and this day showed as over 2,000 visits.

I went into the data and found out that one of articles was bringing in a ton of traffic from Stumble Upon. The same article that brought in about 100 visits on Digg brought in over 2000 visits from Stumble Upon.

I wish I knew why it did that well, and how I could repeat it, but it just kind of happened.

Within the last few days, I’ve also noticed another page bringing in a decent amount of Stumble traffic. For the past several days, it’s brought in 50+ visits each day. I’m wondering how long that’ll last before the page gets shuffled out of the index.

Bottom Line

In terms of traffic, social bookmarking sites can be effective but they seem to be out of your own control.

I haven’t had a lot of luck with Digg and dZone, but I have had some good luck with StumbleUpon.

The best performing articles were submitted by other people, though – not me. Maybe those people had fans that followed their bookmarks, leading more traffic to my site. Or maybe it’s just luck of the draw.

My advice would be to leave a selection of “Share This” icons at the end of your article to encourage users to submit it to their favorite bookmarking sites. However, don’t hold your breath and wait for a ton of traffic to come in.

In the meantime, consider the SEO benefits of social bookmarking sites. We’ll come back to that another time.

As others have pointed out, this can be counter-productive. People don’t like to read articles that have just one Digg – they seem unpopular.

So here’s a solution: use the Conditional “Digg This” WordPress Plugin to only show the Digg Badge for articles that have a certain number of Diggs.

Why Shouldn’t You Show the Digg Badge on Every Article?

It’s easy enough to plaster the Digg Badge in your template or use a plug-in to add it to every post. Most of your posts aren’t going to be popular though. You’ll get at most one or two Diggs… nothing to write home about.

When a user opens your article, he or she might be impressed by “100 Diggs.” He or she definitely won’t be impressed by “1 Digg.” That’s a hint that your article wasn’t anything special – so why should the reader keep going?

Using the Plugin to Only Show the Badge on Popular Articles

The Conditional Digg This plug-in was designed to address this issue.

All you need to do is download the source code, upload it to your plugins directory, unpack the tar.gz, and click “Activate.” You don’t need to modify any settings or insert anything into your template. It’s all automated.

How Does It Work?

The basic concept behind the plugin is this:

• Load a story in your WordPress Blog
• Check the Digg API to see how many diggs the article has
• If the article has 10 or more diggs, show the badge…
• Otherwise, leave it alone.

Originally, I coded the plug-in to use a php function to access the API and check the number of Diggs each article had as it loaded. This worked perfectly – but it took a while. Sometimes, the API is slow to respond. If the API took 8 seconds to spit back a response, that meant your page would take 8 extra seconds to load up.

Even if the API was responding quickly, this was a problem for the front page and category pages. At best, the API takes about .25 to .5 seconds to respond – and with 10-15 checks on a page… you’re still waiting a good long time for the page to load.

Load First, Check the API Later

The solution I came up with was to use some nifty AJAX to perform the API checking behind the scenes.

The plug-in creates an AJAX request for each article. It sends information to a php script which accesses the Digg API behind the scenes. The page loads up instantly and AJAX will quietly do its thing. When the response is ready, it’ll change the page to include the Digg This badge if necessary.

So, the next time you want to display a “Digg This” badge on your article, think about how many diggs your article has already. Or, use the Conditional “Digg This” WordPress Plugin to automatically add a badge to your popular articles.

There is a ton of cool stuff you can do with this. Basically, you send a request to the Digg server and it sends back whatever kind of information you want – category names, recent diggs, recent stories, archived stories, etc. You can read through the API to see everything you can do.

For now, we’ll focus on one nifty little trick – grabbing a random story from a given topic.

Digg API Basics: How It Works

Before we can build our script, we need to know the basics of how the Digg API works.

Your script sends an HTTP GET request to the Digg server. This has three major parts. If this is valid, the server sends you a response in one of several designated formats. You can then parse it into use-able information and display it on your site.

The basic parts of the request are…

• Base Digg URL: http://services.digg.com
• An Endpoint: i.e. /stories/topic/programming – this determines the type of information you’re getting back
• A query string: i.e. ?count=5&offset=20

For this tutorial, we’ll be working with the “Programming” topic because, well, it works with my site. You can look at the list of topics on the API page and tailor this to your needs.

Therefore the URL we’ll be accessing is: http://services.digg.com/stories/topic/programming

What Goes In the Query String

To go along with this, we’re going to have to build a query string. There are a few required elements (appkey, type) and some optional ones that we’ll also use (count, offset).

“appkey” is basically an ID tag associated with your application. Digg uses this for statistical purposes. You can set this equal to the URI of your website.

“type” describes the type of response you’ll get. There are four response types, of which two are applicable for use in a PHP script. We’re going to focus on the XML response and use SimpleXML to parse the information. Therefore type should be set to ‘xml.’

“count” tells the server how many stories we want to fetch. “offset” tells the server how many stories to skip before it starts fetching them. The “offset” is going to allow us to fetch a random story.

Building the Query String

So how do we build the query string? First, we need to turn each of our values into a parameter in the format key=value. The value must also be url encoded. Here’s how we do that in php.

$appkey = 'http://www.earn-web-cash.com';
$appkeyParam = 'appkey=' . urlencode($appkey);

We can then string together all these variables with ampersands (&) in between. We then place a ? in the beginning of the query string, attach it to our URL, and we’re good to go.

I wrote a short function I use to automatically build the query string from an array of values. I create an empty array, store the value with a key equal to its parameter name, and then pass it through the function. The function returns the full query string for me to use.

// Example array:
//    $params['appkey'] = 'http://www.earn-web-cash.com';
//    $params['type'] = 'xml';
 
function buildQuery ($args) {
  $query = '?';
  foreach ($args as $key => $val) {
    if ($query != '?') {
      $query .= '&';
    }
 
    $query .= $key . '=' . urlencode($val);
  }
  return $query;
}

One other minor task we need to do is set up a “user_agent” for PHP. The Digg server wants to know who’s accessing it, so you need to define a “user_agent” value for your instance of PHP with the ini_set command. You can call your application whatever you want, but it usually follows the format – Name/Version.

ini_set('user_agent', 'RandomDiggStory/1.0');

Firing Off the Request and Getting a Response

We should now be able to send our request, get a response, and use some information.

To get a random story, we’re actually going to have to send two requests. The first is going to allow us to find out how many stories exist in the topic. The second will actually fetch a random story.

To find out how many stories exist in the topic, we’re going to create our request with the following information. The appkey doesn’t matter, the type will be xml, the count will be 0, and the offset doesn’t matter.

Once we build the entire url with the query string, we open that location with simplexml_load_file – and the response will automatically be placed in a SimpleXML object for us.

$params = array();
 
$params['appkey'] = 'http://www.earn-web-cash.com';
$params['type'] = 'xml';
$params['count'] = 0;  //  We don't need an offset for this one
 
$query = buildQuery($params);
$url = 'http://services.digg.com/stories/topic/programming';
$reqUrl = $url . $query;
 
$xml = simplexml_load_file($reqUrl);
$total = (int) $xml['total'];  // Need to typecast, or it'll be an object
 
echo $xml->asXML();  // Look at the source code to see what you fetched

The last line (echo $xml->asXML()) isn’t necessary – it’s just to give you an idea of the information you just fetched. It isn’t a whole lot – but we didn’t ask for a whole lot.

The piece of information we wanted was the total number of stories in our topic. That’s the ‘total’ attribute of the ‘stories’ element. We fetched it with $xml['total'] and stored it in the $total variable.

Last Step: Fetching the Random Story

With this information in hand, we can craft a new request and get our random story. You can copy and paste the same information we used before, but make these changes to the $params array.

$params['count'] = 1; // We want one story
$params['offset'] = rand(0, $total);

By generating a random value for offset between 0 and the maximum, we’re effectively choosing one random story from the available list.

Now run the script again. At the end, $xml should have one random story stored in it. The story information is stored in the story child element, and we can access some of the information like this.

echo $xml->story['link']; // the URL
echo $xml->story['submit_date']; // timestamp when it was submitted
echo $xml->story->title;
echo $xml->story->description;

If you browse through the source code of the xml you outputted, you’ll find all of the essential information about the story. Now you can format it nicely and add it to your website.

In case you ran into trouble along the way, here’s the complete source code of the script. You’ll need to go in and change the topic to your desired topic and set your own appkey, but otherwise it should be all set to go.