Can Zemanta Generate Revenue?
Zemanta is getting a lot of attention lately. And why not? This fascinating blog/e-mail enrichment tool adds new and surprising features on an almost daily basis. But I’ll leave the discussion about their features and products to others right now. What interests me is the business model behind Zemanta.
Exit Strategy
I am not sure what the initial goal of Zemanta was when they were founded, but the moment they accepted VC funding, they had to adopt the idea of an exit on the horizon. Making an “exit” is not necessarily a function of the company’s ability to generate revenue or show a sustainable business model. Sometimes, the acquiring company simply sees a great value in the startup that is not expressed through its financial reports. Google, for example, acquired Youtube before it showed any significant income. Youtube brought something more relevant to them – a significant search volume.
Is Zemanta headed for such an exit? I don’t think so. I see the great value in Zemanta, but at this time I can’t see any synergy between Zemanta and a larger corporation that is already monetizing in the field where Zemanta is currently operating.
Moreover, Zemanta exposed a for-pay service when they introduced their public API. Make more than 10,000 daily API calls, and you are now a paying customer. A few days ago, they exposed a second for-pay product – a per-site installation for a subscription-based fee.
With all this in mind, we can assume that Zemanta does have plans to start generating revenue, and prove their concept with some green lines in their financial reports. But are their current offerings sufficient for providing those green lines? I am not so sure. Let me explain why:
Possible Revenue Streams
There are three type of actors in the Zemanta show:
- the bloggers/writers
- the service providers that operate the blogging/writing platforms
- and the content consumers.
Each one is a candidate to become a revenue stream for Zemanta.
Bloggers/Writers
Zemanta hasn’t yet attempted to monetize their bloggers. But they did not completely close the door to this concept either. Download their browser extension and you are asked to agree to this:
“Our basic service is free, and we offer paid upgrades for advanced features such as customization and guaranteed service levels.”
However, even if they do try to monetize this front at some point in time, they need to have a huge user base for this monetization effort to show significant results. They wouldn’t charge bloggers for more than $5.00/month – would they? and for so little, they need 200,000 paying customers in order to make $1M/month. Assume a generous conversion rate of 1% from free user to a paying one, and Zemanta needs 20M registered users to be successful if they choose this path.
Feedburner jumps to my head now (same audience: bloggers; and same VC invloved): their efforts to monetize their user base by providing for-pay added-value services has failed. Google acquired them not for their paying clients – rather for their feed advertising network. Their “Pro” program’s revenue had probably been such negligible that when Google acquired Feedburner it opened up the “Pro” plan to anyone for free…
Service Providers
Most chances are that Zemanta will keep it’s service for bloggers/writers free for good, and maybe this is why they started their monetization efforts on the service providers front.
At first glance, their chances in this front seem much better. Service providers tend to be willing to pay for service if it is business wise: Let the service users use Zemanta, have them producing content of better quality, and have this translated into better revenue. I can understand that.
However, take any of the two payment scheme Zemanta offers, do some calculations and you still won’t understand how they are going to make some serious money.
Their SaaS offering values their API at a $0.66 – $4.00 per 1,000 calls. Even if they charge at the higher end of their scale, they need to be serving 250M API calls in order to make $1M. Where will they get those numbers from?
WordPress.com reports about 4M monthly posts. Add up all the posts from all other leading blogging platforms and you’ll get to how much? several tenths of millions per month maximum. Only if you add some 200M emails you may start be nearing the goal. But is this feasible? They need to be converting so many huge service providers for that to happen. This sounds far fetched.
Same goes for their second offering of $2,500/month per site installation. Where are they intending to find 400 paying service providers to pay this price, when their SaaS is so better priced?
The Consumer End
And that brings us to the last possible income stream – the content consumers. Zemanta is not showing any intention here yet, but I think this is where they are headed. Simply because charging their bloggers/writers or service providers can never work for them.
Now, I don’t claim that they will charge content consumers – not at all. That would be ridiculous. But they will need to use the content consuming point to make significant revenues only because this is where the numbers will be big enough. Think about it – each post that utilized a single Zemanta API call can be viewed by several to thousands of readers. An email that is written once with the help of a Zemanta feature can be sent to a lot of people and then be forwarded on, hence being read tenths, hundreds or thousands of times.
In the point of content consuming, numbers get a magnitude of order higher. Here Zemanta can start talking billions. And when you have billions of events, a small transaction fee can be multiplied to generate significant income. How? I don’t know. An advertising network based on Zemanta’s contextual abilities and huge network of publishers? Semi-organic paid link inclusions offered by Zemanta to the bloggers, maybe with a revenue share scheme? an innovative type of another commercial inclusions in blog posts and emails that no one else can yet think about other then Zemanta?
We can only guess the answer – or wait until time (or Zemanta) will tell.
Stop Programming, Start Integrating
A few months ago I interviewed a web developer who applied for a position in my company. At that time he was still employed by another company and wished to change a position. I asked him what made him look for another job, and he said that the reason was professional – he further explained that up until then they were maintaining their own in-house developed CMS, and were starting migration to Drupal in order to get things done more efficiently. He claimed that working with Drupal was boring, since it merely involves integrating some existing modules into an application, and he prefers to do it the old low level programming way. He said that with a pride of a brave programmer, ready to fight them bits, bytes and bugs, and smiled with satisfaction. The poor dude thought he was impressing me… Of course I did not hire him.
This event took me back in time to 1999. I was then the CTO of Tikal Knowledge, a super PowerBuilder developer who was handed the responsibility of developing a web based knowledge management system from scratch. Driven by the internet hype of the late 90’s, our team just spinned off a software services company, and had no idea about developing web applications. We started to program the thing from scratch, in Java programming language – mainly because the only other alternative we could think about was Microsoft and we didn’t want to pay any license fees. We were so novice that we actually started programming an entire in-house web server. We realized we were doing something wrong when we had to figure out why no data is being actually written into the database. It turned out we forgot to code the “commit” statement…
At that point the company was nearing some great business opportunities. A bunch of high profile enterprises showed interest in our product. It was quite a neat product and I guess we had a good marketing team as well. However, the more promising the business future seemed to be, the more frightening the development process became. The product was fragile, strict, and had no friendliness whatsoever for the future professional services team to come. Our greatest fear was that the product will sell but the application will never be able to hold it from falling apart – should we keep developing it the way we did – and that the failure will be a tech one.
After a year and a half of development, with a major install at the first big enterprise client’s site few months ahead of us, we decided to switch to a completely different approach, junk all the old code, and start all over again – second time from scratch. We decided that this time we will be basing as much as we can on existing open source projects. It was a very frightening stage. We needed to accomplish a lot in a very short time and we had to trust other people’s code to perform for us. We never had a similar experience before and had little trust in it. But there was no other choice.
So we jumped on the J2EE wagon in its very early days – EJB specification was only version 1.1 old at the time – used JBoss on production back on the days when it was still called EJBoss and was quite immature and questionable, packages such as Apache Velocity (where is it today?), Ant and various others.
The result? After less than 3 months we were able to get back at the same point in the product road map from which we “branched”, this time with a robust product that was flexible enough, configurable and with much less bugs. We also had great development communities supporting us. We knew that we are ready to take the application further to wherever its clients will want to take it.
Then the NASDAQ collapsed and our opportunities all wiped off one after the other. Tikal Knowledge itself was not shut down however. CEO Lior Kanfi had wisely used our open source religion to shift the company focus towards providing cost effective open source solutions for the enterprise, and the company today is very successful.
As for myself, I learned a very valuable lesson at that time, a lesson I implement somewhat fanatically in my current ramblings: When it comes to developing applications, if you’re finding yourself programming too much, you must be doing something wrong. At this point, what you have to do is simply stop programming. Start integrating instead.
WordPress Theme as a Communication Protocol
One of the nicest things that a publisher gains by using WordPress (and any other open CMS like Joomla, Drupal and the likes) is the elimination of what was once – and still is for those publishers who still don’t use open CMS – a tedious, exhausting and frustrating process – the process of designing your website.
Designing a website wouldn’t have been such a dramatic process if a human designer wasn’t involved. But that’s not usually the case. If you polled a group of publishers for the thing they dislike mostly about what they do, they would definitely vote for the process of communicating with a website designer to be number one.
The problem is usually that publishers and designers hold completely different approaches and while formally speaking the same language, be it English, French or Slovenian, they use different dialects. Moreover, while publishers look for the utility in the design, the designer will most likely look for the artistic aspect.
Publishers who ever found themselves trying to explain their designers about usability and utility will testify that always when they finally had the designer humming, there was a slight feeling of guilt hanging the air, saying something like “hey you publisher, you art killer.” At that point many publishers share a very shameful thought. They wish they could hand the design process to a computer… experienced to a certain extent with computers, having those as well not always functioning as expected, publishers appreciate the predefined communication methods of computers – also known as protocol.
Now getting back to WordPress, and what it has to do with all this. Well, WordPress covers so many aspects of CMSing, one of them is a set of rules for designing themes and templates. Any publisher who chooses to publish their websites with WordPress must obey those rules. And – any designer who wishes to design a WordPress website must also obey those rules. There you go. No more conflicts. No more guilty feelings. The publisher can be so much utility driven, and designer can go so far with their artistic aspirations.
I am not sure they meant it over at WordPress, but what they really did is creating a communication protocol for publishers and designers.