Archive for October 2006

Will Fickle Audiences Doom Social Networking Sites?

Recent articles worth reading in The Wall Street Journal and The Washington Post comment on the fickle audiences of the Web’s most high-profile social networking sites like MySpace and Facebook. Young people explain that the bad experiences they’ve had on the sites — excessive spam, unwanted contacts, lack of privacy — are adding up, and, coupled with a general sense that the sites are a fad, they are moving on. One high school sophomore even goes so far as to predict that people will get sick of social networking altogether and decide to “spend more time together” (gasp!).

The big guns at News Corp, Google, and Microsoft, of course, see it a different way. They’re betting not only that social networking will continue to grow in popularity, but that the “brands” of today will be the ones of tomorrow. Will they be right? Here are some quick tips to them (and anyone else considering a social networking site):

Focus on niche markets. Facebook enjoyed success because it was “the student’s social networking site.” This made it feel exclusive and semi-private and kept out a lot of the spam and predator fears that plague MySpace. Facebook’s decision to open up has created a backlash and could be costly if it’s not managed properly. Other niche sites are popping up (for example, an old friend just launched hooah.com to focus on the military community) which could take root.

Support small, private groups. Recently launched Vox is betting that bloggers and social networkers don’t want to reach everyone and would much rather connect with just their friends and family. I think it’s a good bet, and their overall potential market of users is much larger than those who want to broadcast to the world. There’s no reason the large social networking sites can’t do more to better support more private groups.

Encourage real user investment. Not money, but time. Not time-consuming, but time-producing. It’s easy to kill a MySpace page with hundreds of inane comments on it. It’s harder to kill your Pickle.com account once you’ve uploaded, tagged, organized, and shared every photo you took in college.

Make it hard to leave. Closed sites are so Web 1.0; but, let’s be honest: you’re running a business. I won’t bail on LinkedIn when a copycat service comes along with a shinier logo because I’d need to convince all my contacts to jump too (much easier to do in high school). The best way to keep users is to offer things the competition can’t, and this rarely involves just features and functionality.

Make it easy to join. This is an old standby; but, it’s ever-evolving. The user experience is the front-line of the member acquisition battle, and bad design (of user interface, the sign-up process, or functional implementation) can be a killer. #1 rule: it just has to work. Once that’s down, collect data, study the data, and act on data to improve.

There’s plenty more to building and growing social networking sites; but, these basics cover some of the current challenges. One thing is for sure: the rate of change is dramatic and since millions of users can adopt and abandon these sites in a matter of months, there is no sure thing.

Add to Del.icio.us | Digg This | Leave a Comment

Testing Transactions in Rails

The standard framework for testing in Ruby on Rails is a thing of beauty; there are folders to drop your unit and functional tests into right off the bat, fixtures and mock objects are expected and encouraged, and when you use scaffolding you get stubs for the common CRUD tests for free. That helps make testing less onerous for developers and, as a result, applications are better tested.

Even Rails isn’t perfect, however, and there are some situations where the testing set-up created out-of-the-box just doesn’t work so well — and, unfortunately, one of those problem situations involves database transactions.

Read the rest of this entry »

Add to Del.icio.us | Digg This | Leave a Comment

The 2006 DC PHP Conference

I spent Thursday and Friday (Oct 19-20) at the DC PHP Conference with my co-director Patrick Reagan. Overall, the conference was well done, though some of the talks lacked technical depth, possibly because the intended audience was a grab bag of developers and managers from the public and private sector.

For most of the conference, Patrick and I attended separate sessions. He should be
summarizing his soon; but, for now, here is my take on the sessions that impacted me the most.

A nice surprise was how cool and down-to-earth Rasmus Lerdorf is in person. His talk was entitled “Get Rich with PHP”; but, the main focus was demonstrating how to optimize your PHP scripts. He has given this talk before, so I’ll just point you to a good summary. Forget about premature optimization, the tricks here are simple enough to use for every page, assuming you have access to the tools.

Another pleasant surprise was Eli White’s excellent talk about “High Volume PHP and MySQL Techniques” validating what I already knew about scaling PHP and MySQL. You can find his slideshow on his website in OpenOffice format.

Mike Ho’s talk was entitled “WebServices Integrating with other Agencies“; but, it was really a demonstration of how easy it was to create and integrate SOAP web services using his Qcodo framework and an MS Visual .Net application. Qcodo is still in beta, but looks very promising, especially after this week’s beta 3 release. Qcodo will automatically generate the WSDL file, and Visual .Net leverages it to make hooking into service a snap.

Chris Shiflett spoke twice about PHP Security Testing, specifically about XSS and CSRF. Both talks were very good and provided very useful and eye-opening information about the dangers of unfiltered user input. Rasmus references PECL::Filter as a good tool to help prevent these problems.

This was my first conference in quite a while, and both the conference and the people were great. Congratulations to the DC PHP Developers’ Group!

Add to Del.icio.us | Digg This | Leave a Comment

Click Fraud Concerns Emphasize the Need for Pay-Per-Conversion

Today’s Washington Post had a front-page article entitled “‘Click Fraud’ Threatens Foundation of Web Ads.” It’s a good overview of pay-per-click (PPC) advertising and the problems challenging the model. Some of the more interesting facts and stats mentioned in the article:

  • Google and Yahoo together handle more than 70% of all web searches in the U.S.
  • PPC ads generated $5 billion last year, which is about 40% of the Internet advertising market.
  • The PPC model is only about four years old.
  • The Yankee Group research firm estimates that 10% of clicks on text ads are fraudulent. Google claims it’s less, while others estimate it to be as high as 30%.
  • Google employs “about three dozen” people who monitor click fraud, 20 of whom respond to click fraud complaints from advertisers.
  • 39% of Google’s third quarter revenue ($1.04 billion) came from its affiliate network (text ads placed on other sites).
  • New York ad agency Carat Fusion says that “sixty percent of new customers come through Google.”
  • This summer, Google, Yahoo, Microsoft Corp., and Ask.com executives agreed to form a click fraud working group to develop industry standards.

Clearly, click fraud has the potential to be an enormous problem as the number of bogus companies and networks grows (and becomes more sophisticated). To help maintain advertiser confidence in PPC, Google and Yahoo tout their dedication to combating click fraud with expert staff and innovative, secretive technology (which they conveniently can’t say too much about since releasing details on exactly how they fight fraud will tip off the cheaters trying to stay one step ahead).

The solution to all of this is mentioned indirectly in the article when John Slade, director of Yahoo’s click-fraud protection efforts, says that “advertisers must help search engines thwart fraud by sharing more information about what visitors do on their sites after clicking on ads.” This is where Google’s 2005 acquisition of web analytics package Urchin (now dubbed Google Analytics) starts to make more sense. At the time, Google said their goal was, in part, to “help web site owners and marketers … generate a higher return-on-investment from their advertising spending.”

Online advertising started with a nice enhancement to a basic offline model: pay-per-impression. Rather than the wide estimates of how many people might see your ad in a magazine, online, you could know exactly how many times your ad was displayed and, presumably, seen by a potential customer. Pay-per-click was a big step in the right direction when advertisers said “I don’t care about people just seeing my ad, I want web traffic — and I’ll pay more for that.” The next obvious step? Pay-per-conversion (Google called it cost-per-action or CPA when they announced testing the new program in June). Advertisers are now saying what’s been obvious all along — that they’ll pay the most for an actual customer.

It’s not a new idea, nor is the technology all that advanced. Amazon’s affiliate program (and others like Commission Junction, LinkShare, and DoubleClick) has paid affiliate marketers based on actual purchases for years.

Part of the challenge, though, in combating fraud and implementing a pay-per-conversion solution is a technology one. Site owners need to be able to share data with Google about what their users do on their sites after arriving through a text ad. That becomes a lot easier when the site is using Google Analytics. Whatever the data sharing solution, it has to be a largely automated one. Google’s text ad success is a classic long tail example, which falls apart if the pay-per-conversion solution only targets the most advanced site owners and advertisers.

With massive amounts of money at stake, you can bet the problems around click fraud will be solved in the long run. Will it be by thwarting fraudulent clickers through automated technology or by advancing the advertising solution beyond paying for clicks at all? It may be too soon to tell.

Add to Del.icio.us | Digg This | Leave a Comment

Friendster Lesson: “Our Site Didn’t Work” (Technology Matters)

Friendster LogoThis week’s New York Times article on Friendster focused on their 2003 decision to turn down a $30 million acquisition offer from Google which, at the moment, appears to have been a very bad idea (had he taken it in stock, founder Jonathan Abrams could be worth $1 billion today).

I thought the more interesting insight was why Friendster saw copycat MySpace rocket past them in popularity. A combination of executive turnover and a lack of focus contributed; but, ultimately, it was bad technology, according to the article.

Referring to Friendster’s all-star board, Kent Lindstrom, an early employee, said “They were talking about the next thing … Yet we didn’t solve the first basic problem: our site didn’t work.

Shocking that the technology failed? No. Plenty of start-ups are built on shoddy technology that doesn’t scale. What’s more shocking is that what was painfully obvious to every user (40-second page downloads?) apparently wasn’t deemed important enough to fix. Had Friendster anticipated their architecture limitations and worked proactively to address them, they could have avoided the long-standing performance problems that scared off their audience.

My advice? Build your start-up with growth in mind. That could mean building a platform that will literally scale, presumably by adding (relatively) low-cost hardware as your traffic increases. At the very least, it means monitoring your growth and having a re-architecture plan in place when it’s needed. Having performance issues due to popularity is a good problem to have if you plan for it right and react accordingly when it happens.

Add to Del.icio.us | Digg This | Leave a Comment

Smart Application Messaging: The Email Reflector

When it comes to the topic of messaging in a web application, clients will often ask if they can send targeted emails to their site’s users with their preferred email client (usually Microsoft Outlook). This question starts to hint at the real functionality that a client wants. From their perspective, they need a solution that:

  1. Aligns with their current skill sets when it comes to messaging (e.g., using Outlook as the preferred email application).
  2. Allows them to deliver customized messages to every subset of their user base.
  3. Provides dynamic capabilities so that each time a new user is added, he or she will start receiving the appropriate messages.

Let’s look at the pros and cons of the traditional ways developers have solved these problems.
Read the rest of this entry »

Add to Del.icio.us | Digg This | Leave a Comment