Facebook Developer Notes – Javascript SDK and Asynchronous Woes

I’m quickly prototyping something that needs to interact with Facebook’s API and got absolutely lost by all their documentation – which is plentiful, but poorly curated.

I lost a full day of time trying to figure out why my code wasn’t doing what I wanted it to do, trying to understand how it works so I could figure out what I was actually telling it to do. I eventually hit the “ah ha!” moment where I realized that by following the Facebook “getting started” guides, I was telling my code to do embarrassingly stupid things. This all tends to dance around the execution order , which isn’t really documented at all. Everything below should have been very obvious — and would have been obvious, had I not gone through the “getting started” guides, which really just throws you off track.

Here’s a collection of quick notes that I’ve made.

## Documentation Organization

Facebook has made *a lot* of API changes over the past few years, and all the information is still up on their site… and out on the web. While they’re (thankfully) still supporting deprecated features, their documentation doesn’t always say what is the preferred method or not – and the countless 3rd party tutorials and StackOverflow activity don’t either. The “Getting Started” documentation and on-site + github code samples also doesn’t tie together with the API documentation well either. If you go through the tutorials and demos, you’ll see multiple ways to handle a login/registration button… yet none seem to resemble what is going on in the API. There’s simply no uniformity, consistency, or ‘official recommendations’.

I made the mistake of going through their demos and trying to “learn” their API. That did more damage than good. Just jump into the [Javascript SDK API Reference Documentation](https://developers.facebook.com/docs/reference/javascript/) itself. After 20 minutes reading the API docs themselves, I realized what was happening under the hood… and got everything I needed to do working perfectly within minutes.

## Execution Order

The Javascript SDK operations in the following manner:

1. Define what happens on window.fbAsyncInit – the function the SDK will call once Facebook’s javascript code is fully loaded. This requires, at the very least, calling the FB.init() routine. FB.init() registers your app against the API and allows you to actually do things.
2. Load the SDK. this is the few lines of code that start “(function(d){ var js, id = ‘facebook-jssdk’;…” .
3. Once loaded, the SDK will call “window.fbAsyncInit”
4. window.fbAsyncInit will call FB.init() , enabling the API for you.

The important things to learn from this are :

1. If you write any code that touches the FB namespace _before_ the SDK is fully loaded (Step 3), you’ll get an error.
1. If you write any code that touches the FB namespace _before_ FB.init() is called (Step 4), you’ll get an error.
1. You should assume that the entire FB namespace is off-limits until window.fbAsyncInit is executed.
1. You should probably not touch anything in the FB namespace until you call FB.init().

This means that just about everything you want to do either needs to be:

1. defined or run after FB.init()
2. defined or run with some sort of callback mechanism, after FB.init()

That’s not hard to do, once you actually know that’s what you have to do.

## Coding Style / Tips

The standard way the Facebook API is ‘instructed to integrated is to drop in a few lines of script. The problem is that the how&why this works isn’t documented well, and is not linked to properly on their site. Unless you’re trying to do exactly what the tutorials are for – or wanting to code specific Facebook API code on every page, you’ll probably get lost trying to get things to run in the order that you want.

Below I’ll mark up the Facebook SDK code and offer some of ideas on how to get coding faster than I did… I wasted a lot of time going through the Facebook docs, reading StackOverflow and reverse engineering a bunch of sites that had good UX integrations with Facebook to figure this out.

// before loading the Facebook SDK, load some utility functions that you will write

One of the move annoying things I encountered, is that Facebook has that little, forgettable, line in their examples that read:

// Additional initialization code here

You might have missed that line, or not understood its meaning. It’s very easy to do, as its quite forgettable.

That line could really be written better as :

// Additional initialization code here
// (sorry for yelling, but you get the point)

So, let’s explore some ways to make this happen…

In the code above I called fb_Utils.initialize() , which would have been defined in /js/fb_Utils.js (or any other file) as something like this:

// grab a console for quick logging
var console = window['console'];

// i originally ran into a bunch of issues where a function would have been called before the Facebook API inits.
// the two ideas i had were to either:
// 1) pass calls through a function that would ensure we already initialized, or use a callback to retry on intervals
// 1) pass calls through a function that would ensure we already initialized, or pop calls into an array to try after initialization
// seems like both those ideas are popular, with dozens of variations on each used across popular sites on the web
// i'll showcase some of them below

var fb_Utils= {
	_initialized : false
	isInitialized: function() {
		return this._initialized;
	// wrap all our facebook init stuff within a function that runs post async, but is cached across the site
	initialize : function(){
		// if you wanted to , you could migrate into this section the following codeblock from your site template:
		// -- FB.init({
		// --    appId : 'app_id'
		// --    ...
		// -- });
		// i looked at a handful of sites, and people are split between calling the facebook init here, or on their templates
		// personally i'm calling it from my templates for now, but only because i have the entire section driven by variables

		// mark that we've run through the initialization routine
		this._initialized= true;

		// if we have anything to run after initialization, do it.
		while ( this._runOnInit.length ) { (this._runOnInit.pop())(); }
	// i checked StackOverflow to see if anyone had tried a SetTimeout based callback before, and yes they did.
	// link - http://facebook.stackoverflow.com/questions/3548493/how-to-detect-when-facebooks-fb-init-is-complete
	// this works like a charm
	// just wrap your facebook API commmands in a fb_Utils.ensureInit(function_here) , and they'll run once we've initialized
	ensureInit :  function(callback) {
		if(!fb_Utils._initialized) {
			setTimeout(function() {fb_Utils.ensureInit(callback);}, 50);
		} else {
			if(callback) { callback(); }
	// our other option is to create an array of functions to run on init
	_runOnInit: []
	// we can then wrap items in fb_Utils.runOnInit(function_here) , and they
	runOnInit: function(f) {
		if(this._initialized) {
		} else {
	// a few of the Facebook demos use a function like this to illustrate the api
	// here, we'll just wrap the FB.getLoginStatus call , along with our standard routines, into fb_Utils.handleLoginStatus()
	// the benefit/point of this, is that you have this routine nicely compartmentalized, and can call it quickly across your site
	handleLoginStatus : function(){
					if (response.authResponse) {
					} else {
						console.log('-not authenticated');
	// this is a silly debug tool , which we'll use below in an example
	event_listener_tests : function(){
		FB.Event.subscribe('auth.login', function(response){
		FB.Event.subscribe('auth.logout', function(response){
		FB.Event.subscribe('auth.authResponseChange', function(response){
		FB.Event.subscribe('auth.statusChange', function(response){

So, with some fb_Utils code like the above, you might do the following to have all your code nicely asynchronous:

1. Within the body of your html templates, you can call functions using ensureInit()

fb_Utils.ensureInit(function(){alert("I'm ensured, but not insured, to run sometime after initialization occurred.);})

2. When you activate the SDK – probably in the document ‘head’ – you can decree which commands to run after initialization:

window.fbAsyncInit = function() {
	// just for fun, imagine that FB.init() is located within the fb_Utils.initialize() function
	fb_Utils.runOnInit(function(){alert("When the feeling is right, i'm gonna run all night. I'm going to run to you.");})

## Concluding Thoughts

I’m not sure if I prefer the timeout based “ensureInit” or the stack based “runOnInit” concept more. Honestly, I don’t care. There’s probably a better method out there, but these both work well enough.

In terms of what kind of code should go into the fb_Utils and what should go in your site templates – that’s entirely a function of your site’s traffic patterns — and your decision of whether-or-not a routine is something that should be minimized for the initial page load or tossed onto every visitor.

OMG! Apple is trying to patent someone's app! [ no they're not ]

A tumblr posting just popped up on my radar about Apple trying to patent an app that is identical to one by the company Where-To [Original Posting Here]

The author shows a image comparing a line drawing in Apple’s patent to a screenshot of an application called “Where-To”. The images are indeed strikingly similar.

The author then opens:
>> It’s pretty easy to argue that software patents are bad for the software industry.

Well yes, it is pretty easy to argue that. It’s also pretty easy to argue that Software Patents are really good for the software industry. See, you can cherry-pick edge cases for both arguments and prove either point. You can make an easy argument out of anything, because it’s easier to do that and argue on black&white philosophical beliefs than it is to think about complex systems.

That’s a huge problem with bloggers though– they don’t like to think. They just like to react.

The author continues:

>Regardless of where you stand on that issue, however, it must at least give you pause when Apple, who not only exercises final approval over what may be sold on the world’s largest mobile software distribution platform, but also has exclusive pre-publication access (by way of that approval process) to every app sold or attempted to be sold there, quietly starts patenting app ideas.

> But even if you’re fine with that, how about this: one of the diagrams in Apple’s patent application for a travel app is a direct copy, down to the text and the positions of the icons, of an existing third-party app that’s been available on the App Store for years.

Believe it or not this happens ALL THE TIME. It’s not uncommon to see major technology companies have images from their biggest competitors in their patent diagrams. Patent diagrams are meant to illustrate concepts, and if someone does something very clear — then you copy it. So you might see a Yahoo patent application that shows advertising areas that read “Ads by Google” ( check out the “interestingness” application Flickr filed a few years ago ), or you might have an Apple patent application that shows one very-well-done user interface by another company being used as an example to convey an idea. This isn’t “stealing” ( though I wonder how someone can argue both against and for intellectual property in the same breath ) – it’s just conveying a concept. Conveying a concept or an interface in a patent doesn’t mean that you’re patenting it, it just means you’re using it to explain a larger concept.

The blogger failed to mention a few really key facts:

1. This was 1 image out of 10 images.
2. Other screenshots included a sodoku game, an instant message, a remote control for an airline seat’s console, a barcoded boarding pass, and a bunch of other random things.
3. The Patent Application is titled “Systems And Methods For Accessing Travel Services Using A Portable Electronic Device” — it teaches about integrating travel services through a mobile device. Stuff like automating checking, boarding , inflight services and ground options for when you land. The Where-To app shows interesting things based on geo-location.

You don’t need to read the legalese claims to understand the two apps are entirely unrelated — you could just read the title, the abstract, or the laymans description. If someone did that, they might learn this was shown as an interface to navigate airport services:

> In some embodiments, a user can view available airport services through the integrated application. As used herein, the term “airport services” can refer to any airport amenities and services such as shops, restaurants, ATM’s, lounges, shoe-shiners, information desks, and any other suitable airport services. Accordingly, through the integrated application, airport services can be searched for, browsed, viewed, and otherwise listed or presented to the user. For example, an interface such as interface 602 can be provided on a user’s electronic device. Through interface 602, a user can search for and view information on the various airport services available in the airport.

Apple’s patent has *nothing* to do with the design or functionality of the Where-To app. They’re not trying to patent someone else’s invention, nor are they trying to patent a variation of the invention or any portion of the app. They just made a wireframe of a user interface that they liked (actually, it was probably their lawyer or draftsman) to illustrate an example screen.

Either 2 things happened:

1. The blogger didn’t bother reading the patent, and just rushed to make conclusions of his own.
2. The blogger read the patent, but didn’t care — because there was something in there that could be controversial.

Whichever reason doesn’t matter — both illustrates my underlying point that 99% of people who are talking about software patents should STFU because they’re unable or unwilling to address complex concepts. Whenever patent issues come up, the outspoken masses have knee-jerk reactions based on ideology (on all sides of the issue), and fail to actually read or investigate an issue.

There was even a comment where someone noted:

> Filing date is December 2009….which means Apple’s priority date is December 2008. From what I can see, this app went on sale in mid 2009….going to be hard to argue it is prior art.

They didn’t bother reading the application either. On the *very first line* , we see:

> [0001]This application claims the benefit of U.S. Provisional Patent Application No. 61/147,644, filed on Jan. 27, 2009, which is hereby incorporated by reference herein in its entirety.

How the commenter decided that *December 2008* was a priority date bewilders me. The actual priority date is written in that very first line! They also brought up the concept of ‘Priority’ – which is interesting because that suggests they understand how the USPTO works a bit. “Priority” lets an applicant use an earlier date as their official filing date under certain conditions — either a provisional application is turned into a non-provisional application, or a non-provisional application is split into multiple applications. In both of these cases no new material can be submitted to the USPTO after the ‘priority date’ – It’s just a convenient way to let inventors file information about their invention quickly, and have a little more time to get the legal format in full compliance. A provisional application does have 1 year to be turned into a a non-provisional application — but there’s no backwards clock to claim priority based on your filing date.

I’ve been growing extremely unsatisfied with Apple over the past few years, and I’d love to see them get ‘checked’ by the masses over an issue. Unfortunately, there is simply no issue here.

*Update: The brilliant folks at TechCrunch have just stoked the fire on this matter too, citing the original posting and then improperly jumping to their own conclusions. They must be really desperate for traffic today. Full Article Here*

And the biggest Brand mistake of the month goes to — Target.

Congratulations to Target on being the dumbest Brand of the month — possibly the year.

After the Supreme Court decision that rendered corporate campaign contributions legal and limitless, Target made a contribution to a Minnesota politician named Tom Emmer. Emmer is against gay marriage — and while I disagree with his beliefs — he does have a right to them.

Target’s contribution, however, has created a serious issue for their brand that may snowball out of control. While many politicians are smart enough to avoid hot-button issues like marriage – for both electability and contributions – Emmer embraces them. Instead of making donations to a generic candidate , who happens to oppose Gay Rights, Target stupidly entered the fray of the Gay Marriage debate by funding someone who is actively campaigning against them. Brilliant.

To make things even worse, Emmer is a supporter ( both financially and personally ) of Bradlee Dean, an unconventional minister / rock musician with some fairly extreme views on homosexuality, including the supporting the practice of executing gays and lesbians.

So Target contributed money to Emmer, Emmer said some things that are offensive to many of their customers, and then Emmer gave some money in turn to Dean who said things are beyond offensive to even more of their customers. That’s a fine mess they’re in.

Target is going to be giving tons of money to hundreds of candidates , because we live in a society where cash contributions mean political access and favors. Few people will have the foresight, or ability, to figure out which of the people they need to support to get some patronage are – for lack of a better phrase – polarizing assholes. This is a sad fact, but its unavoidable.

Anyone in PR and branding with half a brain knows that mistakes happen and people can forgive. But instead of condemning the situation, saying “This is awful – as are the comments”, backstepping out of the situation, and then making a 10x contribution to a politically related yet entirely non-offensive charity ( like a halfway house for at-risk LGBT teens ), Target said nothing. Days later they issued a statement that basically says “So what? Deal with it. We’ll contribute equally to politicians on both sides as we see fit, and this isn’t our fault.”.

Sorry, that’s not good enough. In fact this is bad, downright stupid, and will hurt the Target brand dearly. Instead of distancing themself from hate-speech and a politicized situation, Target is defending their actions. Consumers are now becoming outraged not only at the politics of the situation, but the arrogance of the corporate stance.

In a few weeks, Target will probably be forced to make amends and have a press conference where they apologize to hurting customers but they did no real wrong, and then make some sort of token goodwill gesture or contribution. It will be a touching moment that is perfectly executed after being orchestrated by a PR fix-it consultancy along with a gay lobby group that makes them realize that they can severely hurt the brand and bottom-line. Unfortunately this will be a forced moment – and one that should have come much sooner.

Making contributions to candidates is a dangerous game; your brand can become tied up in political nightmares no one should face. Most large contributers are smart enough to donate to Political Action Committees (PACS) that are rather nebulous — Save the Earth, Save the Environment, Save the Puppies, etc — then let them deal with funneling money to political campaigns. In fact, many PACs are nothing but intermediaries and shell groups designed to make political contributions to candidates with controversial stances non-offensive. Contributions like this can ensure candidates get their payoffs, and contributors get their patronage. Why Target strayed from this puzzles me.

Target injected its brand into a heated political topic, and shouldn’t have. Target had a lot of opportunities to backstep and pull out and they didn’t – in fact, they made things much worse. The subject matter of the debate is irrelevant — this could have been healthcare, sick puppies, immigration, or really anything — a mass-market brand should always come across as politically neutral.

Don't Get Too Excited About the LOC's Copyright Decisions

Today the Library of Congress announced new laws ( perhaps more accurately interpretations of existing laws , as their rulings created ‘exemptions’ to the DMCA laws ) designed to strengthen the concepts of “Fair Use” in as it applies to the corpus of U.S. Copyright law.

The LOC’s decisions are both shocking and enlightening — few expected such an interpretation could ever be possible given the extensive amount of lobbying special interests spend before lawmakers.

Honestly, while I’d agree that their decisions are “correct” and within the spirit of the law, I’m completely fucking floored they had the balls to do the right thing. This is – undoubtedly – a HUGE day in U.S. law.

In a nutshell, the Library of Congress said that it does not violate the DMCA or Copyright Law to circumvent digital protections — that is to say that one is free to descramble a DVD for legal use, jailbreak a digital device (ie: iphone), or circumvent a hardware dongle for legally obtained software. For years people have said that a common-sense and fair interpretation of the law should allow for these things — but industry lobbies used highly paid lawyers with bizarre reasonings and countless campaign donations to influence the development of laws to suit their interests.

While I’m very excited about this win for democracy and fairness, I’m not entirely sure that the decisions are anything to be excited about in terms of ‘resolution’ to these issues.

While the Library of Congress has clarified the law to allow for these types of uses as *not* a violation of Copyright , they have not (nor are they probably able to) ensured that these are rights that may not be given up through contract law.

For decades, lawyers have relied upon contract law to make up for deficiencies in copyright law – creating new protections for their clients by sidestepping any arguments around copyright. For example, while it would not be a violation of US Copyright Law (under the new interpretations) for a user to modify Apple’s software, there could exist a contractual clause — like an End User License Agreement [EULA] or Terms of Service [TOS] between a consumer and Apple or their cellphone carrier to make modification of the device prohibited. Apple could then sue customers based not on Copyright, but on Contract Law.

If you don’t think these types of contracts would come into play, look at the full text of TOS and EULA of software that you buy… or websites that you use like Facebook or MySpace. You might note numerous passages that talk about who can access the servers and under what conditions — large media companies like these routinely use Contract law to chip away at access to fair-use content. Expecting industries to become more relaxed at this practice, while they lose certain copyright protections they believed they had, is nothing short of ridiculous.

It would have been truly remarkable if Congress were to ensure that people have irrevocable rights to circumvent copy protections and modify devices — rights that can not be given up or outlawed within any contract. Sadly we don’t have that yet. However, this decision also means that the numerous lawsuits that the media lobby might bring up in these areas would not be in federal courts and handled by federal investigative agencies — but that they would be in civil courts with the plaintiffs responsible for their entire bill. I’ll drink to that!

Everyone's talking about the need for a privacy oriented Open Source solution for an open social graph

And a lot of people are asking me “Weren’t you doing that four years ago?”

Well yes, I was. In fact I still do.

My company FindMeOn Open Sourced a lot of technology that enables a private and security based open social graph, in 2006

The [findmeon node standard](http://findmeon.org/projects/findmeon_node_standard/index.html) allows people to create ad-hoc links between nodes in an graph. Cryptographic key signing allows publicly unconnected links to be verifiably joined together to trusted parties.

Our commercial service manages node generation and traversing the graph. Even using an account linked to a third party, as ourselves, privacy is maintained .

– [A syntax highlighted example is on the coprorate site](http://findmeon.com/tour/?section=illustrated_example)
– [The way the commercial + open source stuff melds is explained in this image](http://findmeon.com/tour/?section=abstracted)

There’s also a bunch of graphics and images related to security based inter-network social graphs on my/our Identity research site. A warning though, half of it is about monetizing multi-network social graphs:

– [IdentityResearch](http://www.destructuring.net/IdentityResearch)

Twitter is worth a lot, Twitter advertising is not, Bad journalism is worthless

I set out to write a quick correction on a bad article that was discussed on the NY-Tech mailing list earlier this week, but this ends up being half about why Technology journalists and bloggers should just stop – as they rarely know what they’re talking about.

The article “How Much Are Twitter’s Tweets Really Worth?” on BusinessWeek.com has been gaining a bit of buzz across the industry this week. It’s a pretty good summation about how advertising works on Twitter – not because it’s a concise overview, but because it’s about as mindless and poorly conceived an article as the concepts that it speaks about. The writer, Spencer E. Ante, is an associate editor for Business Week. He has an impressive resume and articles behind him, so perhaps this was a postmodern experiment, or maybe he was just hungover from New Years eve. Whatever the explanation is, I’d love to hear it – as its the worst written article I’ve read in ages. The article is no longer online, so I’ll have to use quotes from a cached version in my criticism below. Let’s all take a moment and thank the “Fair Use” clause of US Copyright Law.

The article’s disappearance was not because of a paywall issue, but because it was – indeed – a steaming pile of shit. Businessweek now states:
> This story contained a factual error that rendered its premise incorrect. The story is no longer available. We regret the error.

I’m keeping this up, not to “rub it in”, but to note that the “factual errors” and “incorrect premise” are something that are pandemic to technology journalism. Writers at BusinessWeek, TechCrunch, Mashable, etc rarely know what they’re talking about – and giving them a podium to stand on is just… dangerous.

# Bad journalism is worthless , Twitter is worth a lot

The first half of Ante’s story is a schizophrenic overview of the recent search deals Twitter signed with Google and Microsoft. Ante starts:
> Google and Microsoft are paying Twitter $25 million to crawl the short posts, or tweets, that users send out on the micro-blogging service. It sounds like big money.

Sounds like big money? That **is** big money – Twitter is making $25 Million dollars to give two search engines a ToS license and access to index their data. In a world where Search Engine Optimization is a skillset or service, Twitter is getting paid by the major engines so they can optimize themselves. This is pretty much unheard of.

For whatever reason though, Ante then goes on to comment:
> But do the math and the payments look less impressive. Last year, Twitter’s 50 million users posted 8 billion tweets, according to research firm Synopsos, which means Google and Microsoft are paying roughly 3¢ for every 1,000 tweets. That’s a pittance in the world of online advertising.

This is where Ante shows that he must be drunk, hungover, or a complete idiot: This deal has absolutely nothing to do with online advertising. Google and Microsoft aren’t paying to advertise on Twitter, they’re paying to be able to show tweets in their own search engines. In fact, given how the integration of this deal works – where Tweets appear in the search engine results with a link back to Twitter – it should be Twitter who is paying the search engines. This is a syndication deal, not an advertising one. And this is to syndicate user-generated-content, not editorial! Twitter now has a giant ad, at the top of most search engine pages as syndicated content , and they got **paid** for it! Getting paid to advertise your brand, instead of paying for it, isn’t a pittance – it’s brilliant, revolutionary, and (dare I say) mavericky.

One of my companies is a media site. We’re not a “top media site” yet, but we’re hoping to grow there. Handling technology and operations, I deal with advertising networks from the publisher side a lot. Another one of my companies is advertising oriented, with a focused on optimizing online media buying and selling. Suffice to say, I know the industry well – which is why I find Ante’s next bit of information troubling:
> Top media sites often get $10 or $20 per thousand page views; even remnant inventory, leftover Web pages that get sold through ad networks, goes for 50¢ to $1 per thousand.

Here’s a quick primer. If you’re a media site with a decent enough brand or demographic, regardless of being at the “top” , you’re getting a fairly decent CPM. I don’t think Ante’s numbers are “right” for “top media sites” – in reality, top media destinations are a bit higher per inventory slot. Additionally, most web pages have multiple slots which together create a “Page CPM” that is the combination of the two. While each slot might get $10-20 , an average of 2 slots on a page would net $20-40. If you look at ad networks that publish their rates (like the premier blog network FederatedMedia.net) , or speak to a friend in the industry, you’ll get instant confirmation on this.

In terms of the remnant inventory, I think these numbers are even more off. Remnant inventory for random, run-of-the-mill websites and social networks will absolutely run in the 10¢ to $1 range. “Top” media sites are of a different caliber, and will monetize their remnant inventory at a higher range, usually in the $2-8 range, or utilize a behavioral tracking system that will net CPMs in that similar $2-8 range.

My main issue with this passage has nothing to do with numbers. What I find even more inappropriate, and wholly irresponsible, is that Twitter is not a “Top Media Site”. Twitter is undoubtedly a “Top Site”, however it is a social network or service. Twitter is not about providing media or content, it is about transactional activity and user-generated content. This is a big different in terms of online advertising. For a variety of reasons ( which mostly tie in to consumer attention span and use cases ) Social Networks have a significantly lower CPM – with most monetizing at a sub $2CPM rate, and a few occasionally breaking into a $2-8 range.

Ante’s comparisons just aren’t relevant in the slightest bit. Across the entirety of his article. But hey, there’s a quote to support this:
> The deals put “almost no value” on Twitter’s data, says Donnovan Andrews, vice-president of strategic development for the digital marketing agency Tribal Fusion.

Really? Really? A $25 Million Dollar deal to syndicate user-generated-content, puts “almost no value” on that data ? Either this quote must have been taken out-of-context, Donnovan Andrews has no idea what he’s talking about, or I just haven’t been given keys to the kool-aid fountain yet. Since Donnovan and I have a lot of friends in common (we’ve never met), and journalists tend to do this sort of thing… I’m going to guess that the quote is out of context.

# Twitter advertising is not (worth a lot)

The second half of Ante’s article is a bit more interesting, and shows the idiocy of Twitter advertisers:
> A few entrepreneurs are showing ways to advertise via Twitter. Sean Rad, chief executive of Beverly Hills-based ad network Ad.ly, has signed up 20,000 Twitter users who get paid for placing ads in their tweets. To determine the size of the payments, the startup has developed algorithms that measure a person’s influence. Reality TV star Kim Kardashian, with almost 3 million followers, gets $10,000 per tweet, while business blogger Guy Kawasaki fetches $900 per tweet to his 200,000 fans.

Using Twitter for influence marketing like “Paid Tweets” is a great idea – however these current incarnations are heavily favoring the advertising network, not the advertiser.

There is absolutely no way, whatsoever, to measure “reach” on Twitter – the technology, the service, and the usage patterns render this completely impossible. The number of Followers/Fans is a figure that merely represents “potential reach”; trying to discern the effective reach of each tweet is just a crapshoot.

When an advertiser purchases a CPM for an ad, they purchase 1000 impressions of the ad in a user’s browser. Software calculates the delivery of each ad to a browser, and those programs are routinely audited by respected accounting firms to ensure stability. Most advertisers, and all premium rate (as above) advertisers have strict requirements as to how many ads can be on a page (standard: max 2-3) and the position (require ads to be “above the fold”). 1000 deliveries roughly equates to 1000 impressions.

When an advertiser purchases a CPM on an email, they purchase 1000 deliveries of the email, featuring their ad, to users’ inboxes. When emails bounce or are undeliverable, they don’t count against this number – only valid addresses do. The 1000 deliveries are , usually, successful email handoffs. A term called the “Open Rate” refers to the percentage of those 1000 emails that are actually opened by the user, and load the pixel tracking software (this method usually works, it is not absolute but good enough). Typical Open Rates vary by industry, but tend to hover around a global 25%; with content-based emails around 35% , and marketing messages at 15%. With these figures in mind, 1000 email deliveries roughly equates to 250 impressions.

When an advertiser purchases a CPM on a Twitter, they merely purchase a branded endorsement (which is very valuable in its own right) that has a potential reach of X-Followers. This number of followers does not equate to the number of people who will see the tweet “above the fold”, nor does it equate to the number of people who will see the tweet on their page at all. Twitter has absolutely no offerings ( at the current time ) to count the number of people exposed to a tweet on their website – either at all, or in accordance with an optimal advertising situation. Twitter has itself stated that 80% of their traffic comes from their API – which makes those capabilities technically impossible for that traffic.

Gauging the number of Tweets sent out over the API won’t work either — Twitter applications built on the API tend to have “filtering” capabilities, designed to help users make sense of potentially hundreds of Tweets that come in every hour. When these client-side lists or filters are used, sponsored tweets may be delivered to the application- but they are never rendered on screen

Looking at common use-patterns of Twitter users, if someone is following a handful of active users, all Tweets that are at least an hour old will fall below the fold… and tweets that are older than two hours will fall onto additional pages. This means that twitter users would effectively need to be “constantly plugged in” to ensure a decent percentage of impressions on the sponsored tweets.

A lot of research has gone into understanding usage patterns in Twitter, as people try to derive what “real” users are: a significant number of Twitter accounts are believed to be “inactive” or “trials” – users who are following or followed-by less than 5-10 users; the projected numbers for “spam” accounts fluctuates daily. Even in the most conservative figures, these numbers are well into the double digits.

Social Marketing company Hubspot did a “State of the Twittersphere, June 2009” report. Some of their key findings make these “pay per tweet” concepts based on the number of followers even more questionable. Most notably, Hubspot determined that a “real” Twitter user tweets about once per day (the actual number is .97). Several different Twitter audits have pegged the average number of accounts followed by ‘seemingly real’ accounts ( based on number of followers, followings, and engagements with the platform, etc ) to be around 50 – so an average user should expect about 50 subscribed Tweets daily as well. The Twitter.com site shows 5 tweets “above the fold” ( which represents 20% of their traffic, and a quick poll twitter clients shows an average of 7 ). Assuming Tweets are spread out evenly during the day, an average user would need to visit Twitter about 9 times a day in order to ensure seeing sponsored Tweets. In the online publishing and social media world, expecting 9 visits per day, every day, by users is… ridiculously optimistic. Realistically, users likely experience a backlog of older, unseen, tweets on login – and sponsored tweets get lost in the mix.

As I stated before, the “celebrity advocacy” concept of a sponsored Tweet is very desirable concept for advertisers — and one that would decidedly command a higher rate than other forms of advertising. However, the concept of “Actual Reach” on Twitter is nebulous at best. A better pricing metric for Twitter-based advertising would be CPC (cost per click ) or CPA ( cost per action ) , where tweeters would be paid based on how many end-users clicked a link or fully completed a conversion process.

The "Bra Colors Facebook Status Meme" isn't really about Breast Cancer.

A bunch of Social Media Blogs and Journalists are reporting that there is a viral Social Media Breast Cancer Awareness Campaign, in which women post the colors of the bras as a Facebook status.

It’s a neat idea for a story, but its not true.

Aside from the fact that this viral campaign isn’t organized by any Breast Cancer Awareness non-profit or an advertising agency, and its a really bad idea for a Breast Cancer awareness campaign [ a) it’s more appropriate for lingerie designers, b) it dilutes the association with pink that the Susan G. Komen foundation has been fighting for ] one only needs to do a quick web-search to discover that this is really a weeks-old chain-letter meme that is constantly morphing and getting hijacked.

A week ago, someone posted a question on [Answers.Yahoo.com](http://answers.yahoo.com/question/index;_ylt=Ahbp.aJJpkF6aYN1JYX.rdIjzKIX;_ylv=3?qid=20091229223537AAHTqYE) , and a respondent copy-pasted the text as it appeared then:
> right girls let’s have some fun. write the color of the bra you’re wearing right now as your status on fb and dont tell the boys. they will be wondering what all the girls are doing with colors as their status. forward this to all the girls online

Several other respondents confirmed this was the letter in that posting, and this is only one of dozens of similar explanations of this across the internet dated last week.

At some point over the last few days, someone decided to hijack the meme and make it a little more socially responsible – and they added the Breast Cancer bit to it. It’s nice, and its sweet, and its a great way to turn around a stupid internet joke into something serious. If someone looks at a one of these Facebook status postings today, no matter the author’s intent, they’ll associate with a tie-in to Breast cancer, since that’s what current media coverage states.

Nevertheless, the meme is not necessarily about Breast Cancer awareness. It’s currently getting interpreted as such, but only some participants share that intent.

Use Case Scenarios are important for product development: The "Search" Feature

Whenever a new project starts, we do a few standard things:

– Identify the general product / idea
– Identify several classes of users it appeals to
– Draft Use Case Scenarios for each user class

If, for example, your project is a “game”:

– you might identify the general idea as a game played on a court where two teams each try to sink a ball into a basket;
– the user classes would be children, competitive sports – high school, college, professional , casual adults;
– a use case scenario might be an adult goes to a gym to work out and sees 5 other friends who want to play a game together.

Use cases can really help help you focus on specific product features — figuring out what have the greatest utility, broadest appeal, or largest differentiators against competitive goods and services. They’re often created both during team brainstorming sessions and as homework for the various client ‘stakeholders’ in a project. These stakeholders who best represent the end-consumers should create at least 1/3 of the Use Cases, and should sign-off on all of them. In a startup/corporate environment, that would mean the Product Manager and perhaps some C-Level executives; in an agency environment that would mean the Client and their team, not the internal strategist or team. Why? Because when the stakeholders drive the Use Case creation, you have better insight into the core business goals, market opportunity, and targeted user demographics.

Like everything else in your project, your Use Cases will shift with time as your product matures and you get a better idea of who your actual audience is — so you’ll always have to revisit them to update and add new scenarios. Despite this changing nature, it is unbelievably important to really think things through and create detailed use cases. In the past year alone, I’ve been part of three projects that all became seriously derailed and stressed because of bad Use Case Scenarios on the same exact product feature — the “Search” function — so I’ll use that as a paradigm.

In every situation, the original use cases described something very simple, like:

– I type in /chocolate/ and it shows me a list of recipes that match chocolate. like in the title.”

But then they progressed as the stakeholders used the first version:

– When I type in /chocolate/ it should show me a list of recipes that have chocolate in the title, or as an ingredient.”

And then they progress a little more:

– There is chocolate in the description of this item , and it’s not showing up in search. I meant for the description to be part of it too.”

And then…:

– “Someone commented and said this recipe could be good with chocolate, that should be in the search results. But it should go later in the results.”

Oh no:

– “Wait a second… why am I not seeing chefs/authors who write about chocolate. they’re most certainly relevant.”

And then, overload…:

– “This kinda works. But I should be able to narrow these results down, like in Yahoo or Google. And we should show more info from the recipe in here. What about a picture ? And misspellings / near spellings ? It should detect those. People spell certain ingredients differently. We have a lot of Europeans searching, how will é ç and other characters match in search or recipes ? This seems to be broken. It is broken. This sucks, you’re wasting my time and money.”

To the stakeholder , there is no difference between these requests — they specified a search function, and they expected it to work a certain way; the product team failed at each interval to deliver on their expectations. To the stakeholder, the search function is a “black box” — they don’t know and don’t care if the mechanics behind each iteration are different… it’s a search box!

To the product team though, each iteration was a completely different product and each one required vastly different amounts of resources.

The first iteration — searching on the title — was a simple and straightforward search on a single field… and described as such, a team would just search directly on the database. The resources allocated to this would be minimal – it’s literally a few lines of code to implement.

As the search use case gets refined, the product design moves from searching on a single field to searching on multiple fields — probably using joins and views — and calculating search results. By the end of the product refinement, its quite clear that a simple in-house search solution can’t deliver the experience or results the stakeholder actually wants, so we need to look into other solutions like Solr/Lucene , Sphinx or Xapian. These advanced options aren’t terribly difficult to implement — but they go beyond a single search function into running and maintaining separate search servers , configuring the engines, creating services to index documents, creating resultset rules for sorting, creating error-handlers for when the search system is down, etc etc etc. The simple “Search” button grew from a few lines of code into a considerable undertaking that requires dedicated people, days of work, and a constant tailoring of the resultset rules.

Eventually the product teams will scream “Feature Creep!” and a manager will flatly say “Out of Scope.” Items like this are unfortunately both — but they shouldn’t be. The intent and expectations of the stakeholder have rarely changed in this process, they just failed to articulate their wants and expectations. The blame, however, is shared: the client should have better described their needs; the product manager should have asked better questions and better managed the stakeholders “Use Case homework”.

With a properly written out Use Case Scenario — in which the stakeholder actually illustrates the experience they expect — the product team is likely recommended the latter scenario, and offer tiered suggestions leading up to the desired expectations with the resources/costs at each point.

Unfortunately the status quo is for stakeholders to half-ass the Use Case. Few product or project managers will pick up on the shortcoming , and the tech team will never pick up on it. So “Search” — and any other feature — gets reduced to a line item with little description or functional specification, and when development beings it becomes built in the easiest / simplest way to satisfy that request. This predictably and unilaterally results in expectations being failed and the project getting derailed. Not only are the simplest and most robust solutions to “search” built, but every single step in between — costing dollars and immeasurable team spirit and energy.

The old adage about medication — An ounce of prevention is worth a pound of cure — holds extremely well as a truth about product development. Articulating exactly what you want and need to accomplish before development begins will save dollars and countess hours of stress.

10 Startup / Interactive Lessons ( which I learned the hard way )

Over the past 12 years, I learned these 10 things the hard way.

# 10 You and your team are not your core audience.
You’re a super user, which probably corresponds to a 5-10% demographic of product traffic, and where you want your users to one-day be. You’ve got great insights and direction, but you can’t make a product that is only “for you”. Remember about that other 90%. Unless your business model suggests you can ignore them all! Generally speaking, 20% of your users will account for 80% of your traffic – so try to remember that other 10-15%. You should also track metrics every few weeks — see how your users break down into usage patterns, and see where your team falls in there.

# 9 If your team isn’t using your product on a daily basis – you need a new team, a new product, or both.
You’ve got a huge issue if your team isn’t using your product on a daily basis. They’re going to have different usage patterns than your core demographic, but if you’re not building something that they want-to or can use on a daily basis… you’ve either got the wrong team, the wrong product, or both. Don’t accept excuses, don’t try to rationalize behavior. The bottom line is that if your team isn’t full of passionate and dedicated users of your product, and you can’t sell them on it… how can you expect your team to convince consumers and investors ? You can’t.

# 8 “If you build it they will come” == bullsh*t
You need a solid marketing plan, for your site or your new features. Just putting something out there won’t suffice — people need to learn that your product is awesome. If you don’t have the resources to drive people to your product, rethink your resource allocations *immediately* — maybe you can scale back your vision to save some resources for marketing. People need to know that your product exists, and they’ll learn how to use it by good example — those are two tasks that your team needs to lead on. Also remember that despite what you think and how hard you work, whatever you build won’t be the most amazing thing in the world — so make sure you have resources budgeted to be nimble and respond to users…

# 7 Jack be Nimble, Jack be Quick…
If you’re a consumer oriented product, you’ll often need to change direction , add features, etc many many times after launching. You need a technology platform and internal process that lets you do that. People love to talk about getting their startup going by outsourcing and offshoring the development. This is such an incredibly bad idea. To illustrate, try to count the number of startups you know of that outsourced their product development and had a successful exit. I can count them all on a single hand — and still have fingers left.
Why? If you go the outsource route, it means you’ve decided “This is what our product MUST be” — but when your users help you realize what your product SHOULD be… you’re facing change orders, new contracts, and even trying to reserve some other company’s time. Then you have to deal with the transfer of knowledge and technology when you eventually need to move in-house — figuring out how you can have your internal team support and extend a product that someone else built. If you’re going to contract something out, do a prototype or a microsite or a feature — but don’t have someone else build your core product you, it’s a proven recipe for failure.
In simpler terms, you can’t outsource your core business competency.

# 6 Listen to your lawyers, don’t obey them.
It’s easy to forget that lawyers give legal advice, not legal rules — and that at their very cores, lawyers mitigate risk while entrepreneurs take risks. I don’t mean to suggest that you should be doing anything specifically “risky” or illegal, but that you remember your lawyers will always push you towards solutions approaching 0% risk – which means you may miss many marketing, product, and business opportunities. Good marketing and successful products often push the limits of what is allowed; opening up your company to some amount of liability may be a risk that offers a far greater reward than any penalty you can incur.

# 5 Product Management is not Project Management
This confusion seems to inflict folks in the East Coast and Advertising / Interactive fields. ( if you’re from a West Coast software background, you’re probably immune ). A Project Manager handles resource allocation and making sure that deliverables and commitments keep to a schedule. A Product Manager makes sure that the deliverables actually make sense, and represent/understand the Business Goals, Market Opportunity, Competitive Advantage, and End Users. Product Management is a role — Project Management is a task. Whether you’re working on a startup, online product, or interactive campaign : you need to have a capable Product Manager who is part of the day-to-day checkin process. You also need to make sure to make sure that the people who handle resource allocation understand the roles, responsibilities, and workflow of each person they’re managing — otherwise you have some departments slacking off while others are completely overloaded trying to meet deadlines that were either unreasonably imposed on them, or that they agreed to without understanding the full scope.

# 4 If you have a good idea, it’ll probably get stolen.
This is just how things work – people are often inspired by someone else, or they’re ruthless and copy it verbatim. The exception is when someone else had the same good idea on their own — but then you’ll probably have people trying to steal that idea too, effectively doubling the rampant thievery going on. Arrgh! If you’ve been out in the market for a while and no one is competing with you, you may want to ask yourself why ? Competition doesn’t just validate your idea, it also gives you the chance to better measure the market opportunity and how the audience responds by looking at your competitors. If you stole your idea from someone else you know all this already, so there’s no need to address you too.

# 3 Nothing is confidential. Trust is an arbitrary term. Respect is earned.
The only people that you can trust to keep a secret are your lawyers, because they’ll be disbarred and lose their career. Proving that someone leaked a secret, shared a “confidential” presentation, violated an NDA, etc is not only hard to do, but very costly — which is why people do that all time. If you’re honest and forthcoming in all your dealings, word will spread and you’ll increasingly meet more people who are similar. You shouldn’t expect that anyone will keep a secret just because you asked them to — and you should always be prepared for the worst and expect the opposite.
This isn’t to say that you shouldn’t bother with privacy contracts, but that you should be smart about what you share. The vast majority of potential partners and investors will scoff at an NDA in preliminary meetings, but as your relationship progresses and they need access to more proprietary information — your internal numbers, market research, bookkeeping, etc — negotiating for an NDA is commonplace. You should always ask yourself if you really think this group is serious about working with you, or trying to do market research of their own for another project or investment with a competitor.

# 2 When it comes to a market opportunity, you can trust your gut – the experts aren’t always right.
Two charming examples about how “I was right” and “they were wrong” involved music and net experts telling me that “there will only be MySpace, and no other sites will ever be relevant for music”, and internet experts mandating that social network walls will never come down so portable identity / users will never happen. I’m not trying to flatter myself with this — neither of those companies had a successful exits, just a series of patent applications and legal headaches on one of them trying to keep the products afloat. I do mean to suggest that this is a very common situation — and Bessemer Venture Partners has a quirky take on this, they maintain an “anti-portfolio” of successful projects they turned down. As a word of caution – while the experts may be wrong about your market opportunity… they may be right about the monetization / business viability. Any time someone shoots down your ideas, you should use their arguments to both try and build a better/stronger product, and also to disprove the viability — because they could be right and may have just saved you from a lot of headaches, grief and capital losses.

# 1 Listen to your users — but be smart about how you proceed.
These days everyone says “Listen to your users” — and you should, its a good mantra. However, please remember that you need to analyze what your users say , not just take it at face value. One of my companies makes a lot of product decisions based on user feedback, and we do extensive “User Acceptance Testing” and Focus Groups whenever we want to test out an idea, or launch something new. We always profile / qualify the users who give us feedback to determine what kind of user they are ( ie: super user, industry insider, mass market, etc ) , and make note of both what they say and what they do. It never ceases to amaze me how many people think that they’re a super-user — when they’re barely a casual/incidental user; or how many users say that they really love a particular feature, that it is the most important, and they want more things like it — while their usage patterns and other interview questions show a strong preference and reliance on another feature. Listening to your users isn’t just keeping track of what they say — it encompasses understanding what they mean, discovering what they forgot to say, and working with them to enrich their experience.

# Note

I didn’t learn these all at once, and I didn’t make all the mistakes myself. I did make some myself; others were imposed on my by management or partners. In every situation my life was complicated by these issues – and I can only hope others don’t repeat these mistakes.