Vanity metrics: good for feeling awesome, bad for action. (photo source: UK Guardian)
This is a guest post by serial entrepreneur Eric Ries. He was most recently co-founder and CTO of IMVU, which has more than 20 million registered users and generates $1,000,000+ in revenue per month. Eric is also a venture advisor to Kleiner Perkins.
How do you get to $1,000,000 per month in sales? By testing the right things. Eric is a metrics man.
IMVU learned its way to product/market fit. They threw away their first product (40,000 lines of code that implemented an IM add-on) as they learned customers didn’t want it. They used customer development and agile software development to eventually discover customers who would pay for 3D animated chat software ($10M in revenue in 2007). IMVU learned to test their assumptions instead of executing them as if they were passed down from God.
Enter Eric Ries…
Vanity Metrics vs. Actionable Metrics
The only metrics that entrepreneurs should invest energy in collecting are those that help them make decisions. Unfortunately, the majority of data available in off-the-shelf analytics packages are what I call Vanity Metrics. They might make you feel good, but they don’t offer clear guidance for what to do.
When you hear companies doing PR about the billions of messages sent using their product, or the total GDP of their economy, think vanity metrics. But there are examples closer to home. Consider the most basic of all reports: the total number of “hits” to your website. Let’s say you have 10,000. Now what? Do you really know what actions you took in the past that drove those visitors to you, and do you really know which actions to take next? In most cases, I don’t think it’s very helpful.
Now consider the case of an Actionable Metric. Imagine you add a new feature to your website, and you do it using an A/B split-test in which 50% of customers see the new feature and the other 50% don’t. A few days later, you take a look at the revenue you’ve earned from each set of customers, noticing that group B has 20% higher revenue per-customer. Think of all the decisions you can make: obviously, roll out the feature to 100% of your customers; continue to experiment with more features like this one; and realize that you’ve probably learned something that’s particular valuable to your customers.
Unfortunately, most analytics packages are configured by default to provide mostly reports on vanity metrics. That makes sense, since they are the easiest to measure and they tend to make you feel good about yourself.
For example, here’s a pattern I’ve witnessed in companies large and small. The company launches a new feature or new product, and a few days later, traffic (or revenue, or customers) starts going up. Everyone involved with that product celebrates. In fact, I’ve noticed that people tend to believe that whatever they were working on that preceded the metrics improvement probably caused the improvement itself. So the product guys think it’s the new feature, the sales guys think it’s that new promotion — I’ve even seen customer service reps be convinced it’s due to a new customer-friendly policy. In many cases the fluctuations are random or caused by unrelated external events. Unfortunately, the same mental trickery doesn’t apply when the numbers come back down. Human beings have an unfortunate bias to take credit for positive results and pass the blame for negative results.
Take the example of a product that has a weekly seasonality pattern. For products “on the Disneyland calendar” they will see higher usage on weekends and holidays. As a result, new initiatives that are launched on Thursday or Friday are likely to be judged a success when people come to work on Monday. Yet products unfortunate enough to be launched on Sunday may be judged a failure by Tuesday or Wednesday — unless the company is focused on Actionable Metrics.
There are some tips to getting to more actionable metrics:
1. Split-tests.
A/B experiments produce the most actionable of all metrics, because they explicitly refute or confirm a specific hypothesis. Either way, you can use split-tests to take action on anything from minor copy tweaks to major changes in the product or its positioning. However, not all split-tests are created equal. There is some value in the linear-optimization type tests that are a useful tactic in growing conversions. But the real value of split-tests comes when you integrate them into your decision loop: the process of putting your ideas in practice, seeing what happens, and learning for your next set of ideas. The tests that drive the most learning are the ones to focus on. A good rule of thumb is to ask yourself, “if this test turns out differently from how I expect, will that cast serious doubts on what I think I know about my customers?” If not, try something bigger.
It’s important to remember, “Metrics are people, too.” Vanity metrics tend to take our attention away from this reality by focusing our attention on abstract groups and concepts. Instead, take a look at data that is happening on a per-customer or per-segment basis. For example, instead of looking at the total number of pageviews in a given month, consider looking at the number of pageviews per new and returning customer. Those metrics should be relatively constant — unless something interesting is happening with your product. So even a big rush of new customers shouldn’t change how many pages they each view on average, unless you’re getting a new kind of customer.
Similarly, if you’re increasing the engagement of customers with your product, that will tend to show up in the data for the returning customers. But if you just look at their aggregate data, you can miss important trends. I’ve often observed the following pattern: a big spike of customers joins thanks to a Digg or Slashdot mention. If a product has an average customer lifetime of two months, then after that period elapses, a huge number of customers can be expected to churn out all around the same time. But these effects are hard to keep track of, since customers are coming and going all the time. If you focus only on the number of pageviews, even if you limit it to returning customers, you might mistake a positive product change for something negative, because you launched it during a churn-dominated period.
Many analytics packages, including the much-maligned Google Analytics, have the ability to break down aggregates into per-customer or per-segment analyses. These can help make reports more actionable if you combine them with the Goal Tracking feature. For example, if you can tell which web referrers are driving the most traffic, that’s moderately useful. But if you can tell which are driving the most conversions, then you can start to make ROI-based decisions on where to invest your time in getting more traffic.
3. Funnel metrics and cohort analysis.
The best kind of per-customer metrics to use for ongoing decision making are cohort metrics. For example, consider an ecommerce product that has a couple of key customer lifecycle events: registering for the product, signing up for the free trial, using the product, and becoming a paying customer. We can create a simple report that shows these metrics for subsequent cohorts (groups) over time. Let’s say we create a weekly report. For each week, we then report on what percentage of customers who registered in that week subsequently went on to take each lifecycle action. If these numbers are holding steady from cohort to cohort, then we get clear feedback that nothing significant is changing. If one suddenly shifts up or down, we get a rapid signal to investigate.
The best thing about funnel metrics is that they allow you to boil down a large amount of information into a handful of numbers. If you don’t have the software to build these reports automatically, consider doing it by hand.
This is easy to do if the number of conversion events in relatively small — even if the number of customers is very large. For example, a typical website will have a 1% registration-to-purchase conversion rate. So even if you are registering 1000 new customers every day, those customers are going to result in something like 10 new purchases over their lifetime. So instead of getting fancy, use the good old index cards. At the end of each day, create an index card with that day’s date on it and the number of people who registered that day. Then, for each conversion that comes in, make a tally mark on the index card of the date that the person registered, not the date they purchased. For most products, this only requires you to maintain a week or two’s worth of index cards, since most products have customers that make purchase decisions relatively quickly. Then, on a weekly or monthly basis, gather up all the cards for a given cohort, and compute the conversion rate of the customers who registered in that period. That’s the number you want to focus on driving up.
4. Keyword (SEM/SEO) metrics.
SEM (Search Engine Marketing) and SEO (Search Engine Optimization) are great customer acquisition tactics, but they also can reveal important and actionable insights about customers, if we treat customers who were acquired with a given keyword as a segment and then track their metrics over time. For example, early on at IMVU we tried advertising for AdWords phrases that contained the name of a competitor’s product plus “chat.” We’d then take a look at key statistics for the cohort of customers that registered from each separate campaign. What we found were striking differences in signup and conversion rates depending on what competitor we brought the customer in from. That information is moderately useful in directing a marketing campaign. But it’s far more useful as an indicator of who the customer behind the numbers are. We eventually found that the highest conversion rates came from products that are primarily used by teenagers and young adults — a very different demographic than we thought we were serving. As a result, we started to adjust the mix of customers we were bringing in for usability tests, with dramatic results. For concrete examples of user feedback and testing, see the below video from an interview with Mixergy:
Here is a small sample transcript from the above video:
And so out of complete desperation, we were like, “Okay, fine, we’ll introduce a simple chat now feature.” It was a matching thing where you could push a button and you would be randomly matched with somebody else from around the world – the only thing you have in common is you both pushed that button at the same time.
And we did that, and all of a sudden people were like, “Oh, this is fun.” And then – then here’s what happened. So we bring them in and they do the Chat Now, maybe they meet somebody new who they thought was kind of cool. They’d be like, “Hey, that guy was neat, I want to add him to my Buddy List. Where’s my Buddy List?”
And we say, “Oh, no, no. You don’t want your own Buddy List. You want to use your regular AOL Buddy List” because that’s interoperability, network effects, all this nonsense.
And the customer’s looking at us like, “Well, that doesn’t make sense. What do you want me to do exactly?”
And we said, “Well, just give that stranger you just met your AIM Screen Name so you can put them on your Buddy List.”
And you can see the eyes go wide – they’re like “Are you kidding me?! A stranger on my AIM Buddy List?”
And we said, “But – but otherwise you’d have to download a whole new instant messaging client! And then you’d have to have your separate Buddy Lists.”
They’re looking at us like, “Do you have any idea how many instant messaging clients I already run?”
We said, “No, what, like two or three?”
And the teenager responds, “Duh! I run eight!”
They were already running, like, fifty clients! I mean, I had no idea how many instant messaging clients there were in the world. And we had this preconception like, “Oh, it’s a challenge to learn new software, and it’s tricky to move your friends over to the new Buddy List,” and all this other nonsense sitting in our heads that just, for our customers, looked at us like we were crazy.
Conclusion and Challenge
A common theme across all of these actionable metrics is the lack of really good action-oriented third party tools.
So I’d like to issue this challenge to all of you reading this post today: share your stories of actionable metrics and how you track them. If there are good tools that you have used, let us know. Most importantly, let us know how you customized off-the-shelf tools like Google Analytics to get more action-oriented. We’ll share the results in a future post. We’re looking for stories that embody these three principles:
1. Measure what matters. It’s tempting to think that, because some metrics is good, more metrics is better. That’s why vendors routinely list the thousands of reports they are capable of generating as a feature. The truth is, the key to actionable metrics is having as few as possible. Detailed reports are useful when we’ve diagnosed a problem and are looking for clues as to what’s gone wrong. But where does that diagnosis come from in the first place? Actionable metrics help us realize we have a problem and point us in the right direction to start solving it.
2. Metrics are people, too. Great metrics tools allow us to audit their accuracy by tracing reports back to the individual people who generated their data. This improves accuracy, but its more important effect is that it lets us use the same customers for in-depth qualitative research. Not sure what the numbers mean? Get the customers on the phone and ask them.
3. Measure the Macro. Lastly, even when we’re split testing the impact of a minor change, like a wording or a new button, it’s important not to get distracted by intermediate metrics like the click-through rate of the button itself. We don’t care about click-through rates, we only care about the customer behaviors that lead to something useful, whether purchase, retention for advertising CPM, or some other measurable “success” particular to your business model.
While when it comes to cloud computing, no one has entirely sorted out what’s hype and what isn’t, nor exactly how it will be used by the enterprise, what is becoming increasingly clear is that Big Data is the future of IT. To that end, tackling Big Data will determine the winners and losers in the next wave of cloud computing innovation.
Data is everywhere (be it from users, applications or machines) and as we get propelled into the “Exabyte Era” (PDF), is growing exponentially; no vertical or industry is being spared. The result is that IT organizations everywhere are being forced to grapple with storing, managing and extracting value from every piece of it -– as cheaply as possible. And so the race to cloud computing has begun.
This isn’t the first time IT architectures have been reinvented in order to remain competitive. The shift from mainframe to client-server was fueled by disruptive innovation in computing horsepower that enabled distributed microprocessing environments. The subsequent shift to web applications/web services during the last decade was enabled by the open networking of applications and services through the Internet buildout. While cloud computing will leverage these prior waves of technology –- computing and networking –- it will also embrace deep innovations in storage/data management to tackle Big Data.
A Big Data stack
But as with prior data center platform shifts, a new “stack” (like mainframe and OSI) will also need to emerge before cloud computing will be broadly embraced by the enterprise. Basic platform capabilities, such as security, access control, application management, virtualization, systems management, provisioning, availability, etc. will have to be standard before IT organizations are able to adopt the cloud completely. In particular, this new cloud framework needs the ability to process data in increasingly real-time and greater orders of magnitude -– and do it at a fraction of what it would typically cost -– by leveraging commodity servers for storage and computing. Maybe cloud computing is all about creating a new “Big Data stack.”
In many ways, this cloud stack has already been implemented, albeit in primitive form, at large-scale Internet data centers, which quickly encountered the scaling limitations of traditional SQL databases as the volume of data exploded. Instead, high-performance, scalable/distributed, object-orientated data stores are being developed internally and implemented at scale. At first, many solved this problem by sharding vast MySQL instances, in essence using them more as data stores than true relational databases (no complex table joins, etc.). As Internet data centers scaled, however, sharding MySQL obviously didn’t.
The rise of DNRDBMS
In response to this, large web properties have been building their own so-called “NoSQL” databases, also known as distributed, non-relational database systems (DNRDBMS). But while it can seem like a different version sprouts up every day, they can largely be categorized into two flavors: One, distributed key value stores, such as Dynamo (Amazon) and Voldemort (LinkedIn); and two, distributed column stores such as Big Table (Google), Cassandra (Facebook), HBase (Yahoo/Hadoop) and Hypertable (Zvents).
These projects are in various stages of deployment and adoption (it is early days, to be sure), but promise to deliver a “cloud-scale” data layer on which applications can be built quickly and elastically, all while having aspects of the reliability/availability of traditional databases. One facet that is common across these myriad of NoSQL databases is a data caching layer, essentially a high-performance, distributed memory caching system that can accelerate web applications by avoiding continual database hits. Memcached’s (disclosure: Accel is an investor in Northscale, parent company of Memcached) broad distribution (which is behind pretty much every Web 2.0 application) has become this de facto layer and is now accepted as a “standard” tier in data centers.
Managing non-transactional data has become even more daunting. From log files to clickstream data to web indexing, Internet data centers are collecting massive volumes of data that need to be processed cheaply in order to drive monetization value. One solution that was been deployed by some of the largest web properties (Yahoo, LinkedIn, Facebook, etc.) for massive parallel computation and distributed file systems in a cloud environment is Hadoop (disclosure: Accel is an investor in Cloudera, the company behind which provides commercial support for Hadoop). In many cases, Hadoop essentially provides an intelligent primary storage and compute layer for the NoSQL databases. Although the framework has roots in Internet data centers, Hadoop is quickly penetrating broader enterprise use cases, as the diverse set of participants at the recent Hadoop World NYC event made clear.
As this cloud stack hardens, new applications and services –- previously unthinkable -– will come to light, in all shapes and sizes. But the one thing they will all have in common is Big Data.
In January of 2008, dreading the idea of a cliche "prediction" post, I wrote a post that attempted to somewhat humorously outline seven businesses that would result from the then nascent cloud computing movement. As I look back at that post this year, I'm surprised to find myself thinking that most--if not all--of these should appear in one form or another in the coming year.
Here's the list, with my updated commentary from this year in italics:
SaaS<-->Enterprise data conversion practice: All those existing enterprise apps will need to have their data migrated to that trendy new SaaS tool; and should anyone actually decide they hate their first vendor, they'll be spending that money again to convert to the next choice. Perhaps they'll even get fed up and return to traditional enterprise software. Easy money.
This item was confronting the unfortunate truth that most SaaS options are built on proprietary (or "single platform", in the case of open source) database schemas. That fact alone means that getting enterprise data out of that highly customized on-premise HR application and into the cloud will take some real technical skill, as will changing or reversing that decision. I still believe that this will be a major portion of systems integrator revenue around SaaS adoption, especially for "commodity" functions like HR and finance.
Enterprise Integration as a Service: No matter how much functionality one SaaS vendor will provide, it will never be enough. Integration will always be necessary, but where/how will it be delivered? Go for the gold with a browser based integration option. Just figure out how to do it better/cheaper/faster than force.com, Microsoft, Google, Amazon, etc...
There have been some good attempts at moving EAI into the cloud (see Boomi), but I think this is the year that we will see enterprise class offerings from IBM, Microsoft, and others make their debut. I also wouldn't be surprised if Amazon or Salesforce.com didn't have something up their sleeves here. It's just too important a platform to ignore.
SaaS meter consolidation service: Given the problem stated in number two above, who wants five or six bills where its impossible to trace the cost of a transaction across vendors? Provide a single billing service that consolidates the charges of the vendor stable and provides additional analytic capabilities to break down where costs and revenues come from. Then get ready to defend yourself against the data ownership walls put up by those same vendors (see four below).
This is probably the offering I am least sure will appear in 2010, but there are some signs that people understand the challenge. If you have an application with its front end running on Google App Engine, its business logic on Force.com, and its data analysis on Amazon Web Services, will there be a way to track the costs of that application through a single invoice? I'd like to think the telecoms have an advantage here, but they seemingly remain blind to it.
(Cloud) Customer litigation practice: Given the example of Scoble's experience with Facebook, there are clearly a lot of sticky legal issues to be worked out about "who owns what." Ride that gravy train with litigation expertise in data ownership, vendor contractual obligations and the role of code as law.
As 2008 began, Robert Scoble had his Facebook account shut down for running an automated script to harvest his social network data from that service. The uproar that followed demonstrated one of the truly sticky subjects of cloud computing: who owns and governs the data residing in a public cloud service?
Unfortunately, that question remains unanswered, leaving me to believe there are still a few landmark court cases yet to appear in U.S., EU, and worldwide courts. Of course, today I would probably add cloud malpractice litigators to the mix...
SaaS industry (or SaaS customer) data ownership rights lobbyist: Given 4 above, each industry player is going to want their voice in Congress to protect/promote their interest. Drive the next set of legislation that screws up online equality and individual rights.
While some would argue with me, I think there is a huge policy battle around cloud waiting in the wings, and I know for a fact that several large cloud providers are already lining up lobbyists to drive policy beneficial to their businesses. I am not yet aware of consumer or enterprise focused lobbying, but I believe strongly it is only a matter of time.
Sys Admin retraining specialist: All those sys admins who will be out of work thanks to cloud computing are going to need to be retrained to monitor SLAs across external vendor properties, and to get good at waiting on hold for customer service representatives.
In point of fact, "retraining" of sys admins is already happening, though mostly through a combination of voluntary experimentation with cloud services, active projects, and the effects of virtualization on the data center. However, new technologies that make the cloud hum for a sys admin, like Puppet and Chef, will introduce opportunities to offer courses in advanced applications. Add to this the training in architectures and operations that developers now require to really excel at cloud computing, and you have a terrific business opportunity.
Handset recycling services: The rate at which "specialized" hardware will evolve will raise the rate of obsolescence to a new high. Somebody is going to make a killing from all those barely used precious metals, silicon, and LCD screens going to waste. Why not you?
Of course, there are already a variety of charities and businesses playing in this space. However, two facts are important to note: much of the charity work benefits developing countries, and the rate of obsolescence for cell phone technology hasn't slowed one iota.
Don't get me wrong. I'm not predicting that these businesses are a shoe-in. On the contrary, I think the form that ANY of these businesses take will likely surprise most of us. However, as I look ahead at 2010, it's amazing to me how many of the unsolved problems of 2008 are only just now getting addressed. To those of you addressing them, good luck in 2010.
James Urquhart is a seasoned field technologist with almost 20 years of experience in distributed systems development and deployment, focusing on service-oriented architectures, cloud computing, and virtualization. James is currently market manager for the Data Center 3.0 strategy at Cisco Systems, though the opinions expressed here are strictly his own. He is a member of the CNET Blog Network and is not an employee of CNET.
I thought this was a good one. If you fart in a wetsuit will it blow up with your gas? I already know the answer but I figured it would be a funny addition to the Scuba Myth category. While I admit that I have farted in my wetsuit, it has never blown up or expanded like the poor guy below. I do remember a few bubbles escaping into the water, but I don’t think that I was letting that much escape. Hmmm, makes you wonder. I have even farted in a dry suit without any altercations.
I wonder if anyone has done the number 2? That would be a scuba discussion for another time I suspect.
Zynga, one of the stars of the Scamville drama, has raised a big round of funding – $180 million. Digital Sky Technologies, Tiger Global, Institutional Venture Partners and Andreessen Horowitz all participated in the round. The company has now raised $219 million in total.
DST, which has invested $300 million in Facebook this year, led the round. As with Facebook, some of DST’s investment will be used to buy shares directly from employees.
The NYTimes notes that one of DST’s major shareholders, Alisher Usmanov, spent six years in an Uzbek jail for fraud and embezzlement in the 1980s. Usmanov says he was jailed for political reasons, and Zynga investor Kleiner Perkins says there’s no problem with DST.
That won’t stop people making cracks about the Russian Mafia investing in Mafia Wars, one of Zynga’s popular social games, though.
Zynga is clearly on a roll, and some people have speculated that their revenue may be greater than Facebook’s. One thing is clear, Facebook and Zynga are very, very close. Zynga is Facebook’s largest advertiser, say multiple sources. And they now share DST as a major shareholder. And Marc Andreessen, now a Zynga investor, sits on Facebook’s board of directors.
Investors and financial advisers are preparing to take advantage of a new tax law that makes it easier to gain access to Roth IRAs—even if it means breaking a sacrosanct rule about Roth conversions.
Starting, Jan. 1, the $100,000 income limit disappears for converting traditional individual retirement accounts and employer-sponsored retirement plans to Roth IRAs, one of the biggest changes on the IRA landscape in years. Roths, of course, have long been viewed as one of the best deals in retirement planning; after investors meet holding requirements, virtually all withdrawals are tax-free.
Just how many investors will make the leap is unclear. Converting to a Roth can be expensive; it requires paying income tax on all pretax contributions and earnings included in the amount converted. What's more, financial advisers have long argued that converting makes sense only if an investor can pay the tax from funds outside the IRA itself - an admonition that seemingly limits the strategy to the very wealthy.
That said, some financial advisers say growing numbers of their clients are leaning toward a Roth conversion, even if they have to tap their traditional IRAs to pay the taxes. The primary reasons: new, contrarian analyses of taxes and conversions—and a desire to gain more control over nest eggs in the years ahead. With a traditional IRA, investors must begin tapping their accounts after reaching age 701/2, which increases taxable income. With a Roth, there are no required distributions, giving retirees more flexibility in managing their investments and cash flow.
For many investors, "the required minimum distribution makes them sick," says John Neyland, president of JCN Financial Group in Baton Rouge, La. "They don't want the government to tell them when to take the money out."
Although only 5% of the country's $3.7 trillion IRA assets currently are held in Roths, about 13 million households holding more than $1.4 trillion in retirement assets will become newly eligible next month for conversions, says Ben Norquist, president of Convergent Retirement Plan Solutions LLC, a Brainerd, Minn., consulting firm. Vanguard Group predicts that 5% of its customers will do Roth conversions in 2010, up from a typical 1.5% rate. Charles Schwab & Co. found that 13% of 400 households with adjusted $100,000-plus incomes are considering converting at least part of their IRAs.
The income tax due on assets being moved to a Roth from a traditional IRA is a non-starter for many people, because few—including those with incomes of $100,000 or more—have the assets outside their tax-deferred accounts to pay the Internal Revenue Service. Others, who do have the money, are reluctant to part with it; such funds, often, are set aside for emergencies.
But some financial planners, after running projections involving retirement savings, withdrawals and taxes in coming decades, have concluded that it's worthwhile for many in this group to convert at least some of their IRA assets to a Roth—and pay the tax with funds inside the IRA.
"I have a case where my client is 60, and I was surprised to find that she comes out ahead whether she pays the tax with cash \[outside the IRA\] or the assets inside the IRA," says Deborah Linscott, a financial adviser in Dublin, Ohio.
Here's why: Even though individuals who convert and who decide to pay the tax bill with funds inside their IRA are lowering their overall IRA balance, their new Roth account eliminates the requirement to make taxable withdrawals after age 701/2. For some people, that means they can stay below the threshold at which much of their Social Security checks would be taxed. Others can avoid higher Medicare premiums (which are tied to income levels). And a few could wind up leaving larger legacies down the road, since inherited Roth IRAs aren't subject to income tax, either.
Bob Phillips, a 64-year-old retired engineer in suburban Cleveland, plans to covert his traditional IRA valued at $552,000 to a Roth. He has only about $8,000 in cash, so he plans to pay the tax from his IRA assets, which will reduce his retirement savings. But when Mr. Phillips turns 701/2, he won't have to make any taxable withdrawals, meaning the $35,000 in Social Security benefits that he and his wife receive annually shouldn't become taxable.
If the Phillipses can avoid losing about 20% of their Social Security to taxes, their Roth withdrawals—should they need them—will be smaller, as well. That, in turn, gives the Roth a better chance to grow with time, says Mark Tepper, the couple's investment adviser.
Mr. Tepper used 10,000 "Monte Carlo" simulations (designed to estimate the odds of reaching financial goals) and found that, without doing a Roth conversion, they have only a 50-50 chance of making their funds last across their life expectancies. With a Roth conversion, even using assets from the account itself to pay the tax, they have an 88% chance of not outliving their savings.
Some additional points to consider:
— Investors weighing Roth conversions may want to run their plans by a local accountant: At least one state, Wisconsin, didn't drop the $100,000 income limit, meaning unwitting residents over that limit face a penalty for Roth conversions.
— IRA owners with Medicare Part B who convert to a Roth may subject themselves for a year or two to higher premiums (which, again, are tied to income).
— Investors under age 59 1/2 who convert to a Roth would pay an early-withdrawal penalty on IRA assets used to pay tax.
— Using IRA assets to pay the tax man reduces the amount you could later "recharacterize": If the converted Roth assets fall in value, you are allowed to recharacterize the account as a traditional IRA and no longer owe the tax. "But if you take $100,000 out of your IRA and you only roll $80,000 into a Roth, you only have $80,000 to recharacterize, not the whole thing," says Ed Slott, an IRA consultant in Rockville Centre, N.Y.
The Four Viral App Objectives (a.k.a., “Social network application virality 101″)
January 15, 2008 — yeeguy
A lot of folks have asked for more details on the way we measured and optimized viral app growth in the Stanford class I co-taught recently. So here’s a bit more info on methodology for measuring virality and what it means for an app to “go viral.”
K-factor and R-zero
Terms like “K-factor” (contagion) and “R-zero” (reproduction rate) are often used to describe the growth rate of viral apps. These terms come from the fields of medicine and biology — they’re originally intended to describe the spread of of viral diseases, but they’re nice analogies for how web/SN apps grow. Some would even describe widgets and apps as “diseases” that have “corrupted” popular social networks like MySpace and Facebook! Of course, having worked at Slide and authored someFBappsofmyown, that’s clearly not my belief… So, read on if you’re interested in viral apps!
Whether we’re talking about apps or diseases, the key factors in determining virality are the same:
Distribution: how many people, on average, will an “infected” host make contact with while the host is still “infectious”?
Infection: how likely is a person, on average, to also become “infected” after contact with a viral host?
If you multiply these factors together, that’s your viral growth rate (or “K” or “R-zero” or “viral coefficient”). The product of these factors answers an important question:
“How many people will be infected by a single viral host while the host remains infected?“
With real-world viruses, the infectious period has very dramatic outcomes. E.g., a host remains infectious until either the virus kills the host or until the host’s immune system fights off the virus. If K=1, then the host basically passes the virus on to one new person before either the host dies or the virus is expelled. Either way, if K=1, then the host exactly replaces him or herself in the population of infected people before becoming non-infectious.
Hopefully, the growth of social apps will never involve physical death or illness! [Disclaimer: No readers were harmed for the writing of this post.] Instead, we would consider a host to be “no longer infectious” if they either uninstall the app or stop actively using the app. Using that definition, an app with a K-factor of 1 will have a userbase in steady-state – no growth, no decline, just flatline; where every current user replaces themselves before leaving the userbase. K>1 means an app is growing its userbase virally (exponentially). And, conversely, K<1 means an app’s userbase is exponentially decaying.
With these factors in mind, designers of viral applications have four levers to pull on in order to increase virality:
The Four Viral App Objectives
Increase the percentage of “active hosts” who actively make contact with uninfected people
Increase the contact rate for each active host (average number of contacts per time period)
Increase the duration of each active host’s infectious time period
Increase the likelihood that contacts turn into infections (i.e., infection conversion)
Sidenote on app metrics
Note that this also implies that in order to affect any of these, you, as an app developer, need to be able measureeach of these stats for your userbase. You can’t tell if you’re driving any of these numbers up (or down) until you know how many contacts/invitations each of your users sends out per day/week/month that they have the app installed; how many days/weeks/months each of your users tends to keep the app installed; and what the conversion rate from a contact/invite into a new infected user is.
Collection and analysis of metrics for social apps is a meaty topic in and of itself, so we’ll leave that for another day. But for now, it should suffice to say that it’s really important to have an effective way to collect statistics on what your users are doing with your app!
Assuming that we’ve got a reliable way of collecting metrics, here’s a quick list of some techniques for achieving each of the four viral app objectives.
Some example methods for optimizing virality
Active Hosts
Require users to invite more people to join the app before they can view/use the app. Typically paired with premium or high value content. E.g., “Invite 10 friends in order to unlock this pr0n video in high-definition” or “Invite 15 friends to see how who has a crush on you.” Some users complain about this tactic, but you may be surprised at how many users will effective. (just kidding about the pr0n, kiddies — that stuff doesn’t fly on most social networks.
Opportunism — you can’t always predict how people will utilize an application, so give your users multiple ways to share your app. Ideally, every app pageview should contain one or more ways for a user to share the app (and thereby become an active viral host).
Contact Rate
Create incentives for inviting more people. E.g., “invite 10 more friends to level up and become a Black Belt Ninja”
Specific requests tend to work better than vague encouragements. E.g., don’t just ask users to “please invite friends”, specifically ask for a number, “invite 10 friends” (don’t laugh, it actually works!)
Simplify, simplify, simplify. If your #1 goal is to go viral, then that should be the #1 action-request that “pops” out to a user. Make it easy to invite more people. Utilize address book importers. Auto-select large(r) distribution lists for invitations. Basically, minimize the amount of hunting-and-clicking it takes to get a user through your invitation process. Ideally, it should just be 1 click.
Activity Duration
User-to-user messaging is a great way to keep users coming back to an app. If pokes, walls, comments or private messaging fit into the context of your app, you should seriously consider building those in.
User generated content and media — in general, apps that have some form of UGC/media built into them (music, photos, videos, drawings, etc.) do a better job at drawing repeat visits. I’d also group collaborative filtering functionality in this bucket — e.g., ratings, rankings, top playlists, “most viewed” lists, etc.
Infection Conversion
Social context — when you’re writing the content/copy for your app invitations, be sure to keep in mind the fact that all your app invitations are occurring in the context of a social relationship between two friends. Use that knowledge as you phrase every call-to-action and craft each sentence to reinforce the social relationship and play on influence mechanisms between these two friends.
Images and buttons — beyond writing the actual content/copy, app authors should also experiment with design and layout of their invitations. Some top tips include: use buttons instead of plain text links; and use images of people to draw the eye.
Of course, the list above is not exhaustive, it’s just a sampling of top-of-mind viral engineering techniques. If you have other favorite/top tips for tweaking virality, please post a comment below.
A note on prioritization:
In general, all other things equal, it’s most effective to pull on the Contact Rate and Activity Duration levers first — followed by the Host Activation and Infection Conversion.
By definition, your Host Activation and Infection Conversion rates are capped at 100% — the best you can do is to get 100% of hosts to invite other people, or 100% of contacted users to become infected. In contrast, the Contact Rate and Activity Duration are theoretically unbounded. (Well, I guess all human users must eventually expire, but I haven’t seen any Facebook apps that specifically optimize on age of users, yet!!) In any case, for our purposes, the total number of viral contacts initiated by your userbase is theoretically unbounded.
So as an app developer, you should explore the upper limits of how rapidly you can grow your viral contacts before circling back to optimize conversion rates. E.g., if you think of each of your current users as an “infected host”, then your first priority should be to get a maximal number of invites/contacts sent out by each of your hosts while you have them on the app.
Benchmarks
Just for comparison, I’ve included some common ranges for Host Activity, Contact Rate, Activity Duration, and Infection Conversion below. These are derived from my own experience with Facebook apps, observations of my Stanford Facebook class’es apps in Fall 2007, and also observations from companies that I have worked at or advised.
Active Hosts
App age is an important consideration — newly launched apps will tend to have more active hosts
Anything above 50% is pretty good for early-stage apps
Single-step funnels perform best for maximizing host activation (e.g., select and invite friends from a single page, ideally the FIRST page that a potential new host sees)
In general, minimize the number of steps/pages that you ask hosts to go through in order to invite their friends. Each additional page/step in a funnel will drop 50% to 60% of users, so each step in a funnel carries a very steep penalty. (Note this is a LOT steeper drop off than the rule of thumb 33% dropoff for page-to-page conversion rates that ecommerce or content sites see!)
Contact Rate
For Facebook apps, 15+ total invitations per user is very good (Note that Facebook imposes a daily limit of 20 invitations per app per user)
Activity Duration
Activity rates and user tenure will vary widely, depending on the purpose and design of app.
Healthy ranges are typically between 5% and 40% of an app’s userbase will be active on any given day. (Starting high for young apps and then decaying over time for older apps)
Good retention practices should generate 8+ repeat visits per month per user
Infection Conversion
Expect net conversion rates from invites-to-infections in the range of 5% to 8%
K-Factor / R-zero / Viral Coefficient
Ranges between 1.4 – 2.1 (or higher) are typical for apps experiencing “hot” viral growth
Summary
OK, so good luck to all you app developers out there seeking app virality! As you can see, none of this stuff is “secret sauce” or anything — you can readily view all of these techniques in action on Facebook, MySpace and other social network sites today. Still, I hope that summarizing this stuff in one place is useful and many apologies in advance if I’ve misrepresented anything, especially the biomedical stuff. (Is there a doctor in the house?!) Please leave comments or corrections below!
And, of course, if you’ve got some viral ideas or would like to collaborate on viral apps, drop me a line: yeelee at gmail (or connect to me on Facebook, LinkedIn, etc.)
While when it comes to cloud computing, no one has entirely sorted out 
Managing non-transactional data has become even more daunting. From log files to clickstream data to web indexing, Internet data centers are collecting massive volumes of data that need to be processed cheaply in order to drive monetization value. One solution that was been deployed by some of the largest web properties (Yahoo, LinkedIn, Facebook, etc.) for 
James Urquhart is a seasoned field technologist with almost 20 years of experience in distributed systems development and deployment, focusing on service-oriented architectures, cloud computing, and virtualization. James is currently market manager for the Data Center 3.0 strategy at Cisco Systems, though the opinions expressed here are strictly his own. He is a member of the CNET Blog Network and is not an employee of CNET.
Zynga
, one of the stars of the Scamville drama, has raised a big round of funding – $180 million. Digital Sky Technologies
![[ROTHTAX]](http://s.wsj.net/public/resources/images/MI-BA295_ROTHTA_NS_20091211182100.gif)
Of course, having worked at 