As an Internet Professional who works with both Consumer & B2B Products, I’ve been keeping a growing list of issues with Facebook. I figured it was worth publicly sharing them — maybe others have thought this way.

Top 5 Product Quirks I Hate About Facebook , Part 1

1- Consumer Product : The messages that accompany a “Friend Request” are lost once you accept a Friendship

Let’s say someone sees your profile, realizes you know each other because of X/Y/Z to be a friend. Facebook has a great feature that gives them a chance to add a ‘qualifying message’ to their FriendRequest… you know, something like “Hey, Jonathan! It’s been years. My phone number is 555-123-4567. Call me!”

This is a great feature, right? Absolutely. There’s just a little problem though- once you become friends with that person, the message disappears. Since it’s not a real “message” ( in their world ), it doesn’t get archived in your message center history.

What Facebook should do: if a FriendRequest is accompanied with a message, turn it into a user-to-user message upon Accepting or Rejecting the request.

2- Consumer Product : When sending a FriendRequest to another User , the requesting first User doesn’t expose their Profile to the requestee

How many times have you gotten a FriendRequest, thought “Hmm, how do I know this person?”, and then clicked their profile ? I’d wager a lot. When you’re unsure of who someone is, it’s a normal reaction to check-them-out.

Here’s the problem – when Facebook first introduced their privacy settings, they gave users the option to make all ( or portions of ) their profiles “Friends Only”. It’s a great feature, but there’s a bit of a caveat — if this setting is turned on, the recipient of a FriendRequest can’t see the sender’s details. In many cases, the only information shown is a name & photo.

This user interaction is one of the most troubling and annoying to me – in order to find out exactly WHO sent me a FriendRequest, I need to accept their Friendship. This isn’t something that I really want to do — I don’t want to expose my activities, contact information, or network to someone that I don’t necessarily know or trust.

This is what it unfortunately looks like:

1. The Friend Request Pane

1. The requesting person’s profile. Who are they?!?!?

What Facebook should do: ProfilePermissions for “Friends” should apply to “outgoing FriendRequests”. There is an implicit intent to have a Friendship and share this information.

3- Consumer Product : Application Permission Dialogs show the name of the Application, not who is responsible for the Application.

All too often I see an interesting Post / Application and click on it to potentially add it to my own Profile.

Here’s an example – this Application promotes the song that was #1 on your birthday. “Hey, I want to find that out myself!”

When the Application requests an Authorization from me though, I see that I’m sharing my information with the App — which is great. What I don’t see, however, is exactly who I’m sharing my information with.

In an era where people get their Facebook accounts hacked, or viral apps pop out of nowhere only to get permissions they later abuse, I’m worried about who the developers/companies are. How do I know that “Some Random Application” is backed by solid, upstanding people – and not some foreign hackers that are trying to turn my account into a spamming node or mine it for personal info for identity theft?

Take a look at this screen and think about if you would feel comfortable granting whomever made this access :

What Facebook should do: list the main developer/company/etc on the authorization page. Facebook makes a huge point about being based on “real names” – even going so far as to quarantine accounts that use ‘common’ names instead of legal ones ( if you haven’t read his tirades, Salman Rushdie wrote some great stuff on his own struggles here).

It’s also worth noting that this was a really awkward App to profile , because finding the install/auth screen was near impossible.

4- Business Product : Data about the origin of Linked content is nebulous or cryptic – and worthless for metrics

Links shared in Facebook aren’t direct links to content – they’re intercepted by a proxy at “http://facebook.com/l.php”. Basically, there’s a bit of javascript that rewrites an external link on a webpage into an internal link, which is used by Facebook to track performance and display within their own analytics suite. This is great and fine. “l.php” seems to take two parameters: a url encoded version of the destination, and a unique corresponding hash — which I think is a) just the a digest of the link with a ‘site secret’, and b) exists to ensure that the “l.php” script isn’t abused by non-facebook traffic. I could be wrong on both parts, but if the exact unique hash doesn’t appear with the corresponding link… Facebook throws a 404 instead of a redirect to the url parameter.

Because of the way this linking works, if you look within your own analytics suite you’ll see that ALL traffic from Facebook.com appears as if its from “l.php”. The only way to see how your referral traffic performs from Facebook is to use their own, limited, analytics program — and that can’t roll up into your existing analytics reporting tools AND only applies to “pages”.

If you embed a “Like” button on a page you can specify a “ref” label, into which Facebook will toss information back to your site with. However – this isn’t a default action, and applies to “Like” stories only, not organic shares. This is confusingly documented too – at a major publisher I was working with, earlier versions of the docs suggested that we would be able to note where on the site that button was placed, and we would then be able to access the information… nope.

What Facebook should do: append information about the outbound links into query strings on the redirect (e.g. “?fb:context=user.newsstream” ) or create intermediary dummy redirects that have that information and will appear in referral logs ( e.g. “/l.php” -> “/l/user.newstream.php” ), thereby letting publishers access that information within their own analytics programs. The information could even be coerced into the “utm_” namespace that Google uses, as Omniture can work with them by default — easily supporting two of the top analytics packages at once.

Additionally, the behavior of the “ref” tool should be on by default — affecting all links — and control for fine-tuning can be offered on a per-domain basis.

5- The internal Insights/Analytics app has a lot of data, but does little with it. There are some key metrics that could be shown now – and others that should be expanded upon.

Facebook is great about telling me how much content is shared, but is pretty bad at telling me HOW it is shared. As a publisher, I want to know WHERE the share is coming from and WHY – is it from within Facebook ? If so, is it as people “share” on each other’s walls or another mechanism? Is it happening from a “user to user” newsfeed story, or a “page to user” newsfeed ? Where did someone “Like” my story – on my website, on a newsfeed, on my brand’s profile page? As the Facebook Comments system is used more: I want to know if people are posting responses on Facebook , or on my own site. Most importantly, I want the ability to slice and dice all these bits of data on a “per post” or “per url” basis — it’ll help me figure out how to spend my internal resources in promoting stories. I need to figure out which types of stories do best as user-to-user vs brand-to-user, and which ones are being spread on Facebook vs those where offsite likes merely show an affinity for the stories.

For generic users this might sound silly, but as someone responsible for the digital growth of a brand this stuff is really, really, really important. As someone who is debating how much of a yearly budget to allocate to Facebook development, advertising, and internal staffing – this is information I really need to know. This is the type of information that tells me what I’m doing right, what I’m doing wrong, and guides my next steps. I want to know which Headlines performed the best in terms of “Likes” and which had the highest percentage of clickthroughs. Today, I only see the clickthrough data on my analytics suite and the aggregate of all activity on Facebook’s. This data is simply not substantial enough to base sound decisions on.

What Facebook should do: Surface the data. Repeat. Surface the data.

These are pretty basic things I want to know — but I can’t know them, because Facebook’s data collection and reporting just aren’t that great.