Subscription Package Pricing: The Right Choice Makes All the Difference

The rush to adopt the subscription model to all kinds of businesses has become a frenzy. After all, what business wouldn’t want to make its revenue more dependable and automatic? But the subscription model needs to be fully understood and properly executed to reap its benefits. Let me explain.

When I recently made the move from a PC to a Mac, I knew I would have to buy some software over again. I dutifully went to the Adobe site to get the Mac version of Adobe Acrobat. Imagine my surprise when I discovered Adobe only sells software by subscription, in this case $12.99 per month, forever. Sorry, I just don’t make that many PDFs. Perhaps Adobe made a conscious decision to lose some of its customers as it shifted itself to a recurring revenue model, but forcing your customer base to buy on a subscription basis is a risky one.

Another company I looked at has a neat online product where you input raw data and it makes very impressive, high-end charts that you can download. I felt I could make regular use of this product, and was willing to pay some modest amount per month for it. But the company only offered three subscription options: a “free” plan that was so limited it wasn’t much more than a product demo; $14.99 per month for a “pro” version that still had annoying limitations (for example, the company’s name would appear in every slide), and an “organization” version for $1,000 per month – finally, all the features, but at a heady price. In short, these plans provided no option for a serious by low-volume commercial user. Sorry, no sale.

Poorly conceived subscription plans are everywhere. Here are four things to consider as you plan your subscription packages:

  • Free plans are meant to build loyalty and usage among low-volume users, some of whom will eventually move up to a paid plan with you. If you cripple your free offering to the point where nobody can get any real value out of it, you’ve shot yourself in the foot. A free plan is not the same as a product demo. It’s used to attract users and grow them over time into customers.
  • To maximize revenue, design a plan for serious but low-volume users. There are lots of people who want access to all your product features but won’t use your product every day. A plan that offers a low monthly fee but only offers half your features is not the same thing.
  • Limiting features in your mid-priced subscription plans in order to “force” users to buy your premium plan often will backfire. If I am a single user, I will never by a 5-user plan for a lot more money to get the features I want
  • Carefully consider price differentials between plans. I have seen products that offered three price points: free with limited functionality, $999 per year and $10,000 per year. Three sizes will rarely fit all user profiles.

The subscription model is a great model. But its success lies in how you choose to implement it. 



Blockchain: The Next Big Thing

We all lived through the heights of the social media craze when every new product needed a social aspect in order to succeed (success is defined as getting funding). My personal favorite was the backyard grill thermometer that posted the temperatures of what you were cooking to Facebook and Twitter. (Okay, there was a little more to it than that, but not much).

But as an Internet fad, social is starting to cycle down, meaning that another Internet fad needs to take its place. My nomination: blockchain.

You have doubtless heard of blockchain, although the odds are you don’t know exactly what it is or what it does. Most people don’t. My understanding of it is sketchy. But when it comes to the Internet, complexity is a benefit because everyone salutes when they hear about a new service using blockchain, without being able to ask any tough questions about how or why.

A great example of this is a restaurant review site called Munchee. Munchee plans to disrupt sites such as Yelp and Zagat in part by using blockchain technology. Think about that for a while. Or better yet, don’t think about it. You’ll get a headache.

Munchee has a few interesting twists to it. First, it’s meant to be more granular than sites like Yelp, by focusing on the individual dishes a restaurant serves, based on the belief that all dishes served by a particular restaurant are unlikely to be of equal quality. You might doubt the need, but it’s a plausible idea.

Munchee also wants to correct for sample bias in reviews. It’s well understood that people are more likely to post a review when they are dissatisfied. Munchee wants to get around this problem be rewarding all reviews with tokens that can be redeemed at restaurants or even sold to other Munchee participants for cash. If you are getting paid for every review, the reasoning goes, you’re as likely to create a positive review as a negative one. Again, an interesting idea.

To get even more accuracy, Munchee wants all reviews to be peer-reviewed by other Munchee users. Munchee intends to recruit peer reviewers by using (buzzword alert) machine learning to find the other Munchee users best qualified to pass judgment on the review. Still again, the notion of peer review is an interesting one.

So where exactly does blockchain come in? Does it, for example, somehow definitively tie the reviewer to the restaurant, in order to eliminate false reviews? Well, no. Instead, those award tokens that Munchee offers are actually crypto-tokens that are tied to the Ethereum blockchain. That’s it.

Munchee actually has some fresh approaches to review platforms, but it apparently couldn’t resist the temptation to bolt on a tenuous blockchain application to sound even cooler and more cutting-edge. Unfortunately, that works to obscure the more basic ideas it has that are likely to be where the real value is created. We all need to be careful not to fall into the trap of rushing to adopt new technologies just because they get a buzz around them. You’ll only end up confusing your customers … and yourself … about the true ways you offer value.



Data Marketplaces: Almost There

There has been much excitement about the recent launch of the Salesforce Data Studio, a new data-sharing platform within the Salesforce Marketing Cloud.

The idea of the Data Studio is simple: marketers can, on a fully automated basis, identify, order and integrate datasets that others are offering for sale. In its early implementation, the Data Studio seems mostly like a cool way for marketers to buy email lists. But the vision is much bigger and more interesting: to allow marketers to augment and overlay existing email lists with more data so that they become smarter about their lists, target their efforts more effectively, and get better results.

Data Studio at time of launch is heavy on audience data, mostly from larger publishers, but there’s no reason any data publisher couldn’t participate as well, especially if the Data Studio wants to exploit its full potential.

Interestingly, Salesforce is not the only big player that has an interest in data marketplaces. The Amazon Web Services Marketplace sells software through its marketplace – again, a totally automated buying experience – but it also offers a selection of public domain datasets for free. It’s a small jump then for Amazon to start selling databases on behalf of others.

As you can see, neither of these two marketplaces is quite ready for prime time as far as becoming a meaningful sales channel for data publishers, but they’re tantalizingly close. Keep an eye on these marketplaces: they could become very important to data publishers very quickly.


It’s not news that fraud is rampant in online advertising. It turns out that one of the biggest reasons is the fact that the buyers and sellers of online advertising in large part do not deal directly. They transact through third party brokers and marketplaces. Increasingly, it’s now computers ordering through third party brokers and marketplaces – the wonderful world we call programmatic. With no humans watching, much less policing the buying process, it is notsurprising that crooks and thieves have rushed in.

One of the easiest types of fraud is simply to misrepresent yourself online. You can tell an online marketplace that you represent the CNN website, collect the revenue, then run the ads you sold on some other website, often one that gets lots of bot traffic and other fake clicks in order to show performance.

To fight this type of misrepresentation, the Internet Advertising Bureau (IAB) created a new standard called ADS.TXT. It’s a small standardized format file that a website owner creates and places on the website that lists all the website’s authorized sellers. If you’re familiar with ROBOTS.TXT, it is exactly analogous.

The idea is that programmatic advertising buyers can easily and confidently check a website’s list of authorized resellers. It’s a full, workable solution to a significant problem, but it comes with one big catch: the ADS.TXT file is necessarily open to everyone who wants to view it. And a lot of publishers and other website owners aren’t thrilled about exposing what they consider proprietary information.

The solution? In my view, it’s a central database, operated by an independent third party. The same information can be placed in the database, but access can be easily restricted to those who “need to know” the information. I’ve always liked opportunities where an industry needs to share information but at the same time doesn’t want to make that information public. A neutral data provider is most times the perfect answer, as I think it is in this case.

Moreover, a central database can add additional value, because it can track what is happening. It can automatically nag website owners who don’t update their reseller lists regularly. It can check which advertising marketplaces are using the service. In these and many other ways, it can actively work to keep all players engaged and honest.

And of course, data being data, there’s an easy opportunity to aggregate this reseller data to look for sales trends and market share. This information can be given or sold back to the industry without any privacy concerns.

ADS.TXT is just one example of a good idea that could be a much better idea if there was a trusted data provider in the middle, protecting privacy while mediating and recording access to insure compliance and data accuracy. I’d like to see ADS.TXT as what you might call ADS.DATA. You’d be wise to look for analogous opportunities in your own market.


Top Level Domains/Low-Level Trustmarks

If you’re not immediately familiar with the term top level domain (TLD), think of “.com” and “.net” and “.edu” – they are all top-level domains, along with hundreds of others, and by the way, they are not limited to three characters anymore.

In the early days of the Internet, domain names were free for the asking, and I stocked up on quite a few for no other reason than a gut feeling they had some value. I did ultimately sell a lot of them, including several Fortune 500 companies who bought their corporate names back from me. By the time I realized there might be a bigger opportunity here, the rules of the game changed and big companies that had previously shown up with checkbooks now showed up with lawyers. Ah, well!

But for all my domain name hoarding, I couldn’t ever get domains names with the “.edu” TLD because they were reserved for schools. Similarly, “.net” was reserved for Internet Service Providers back then, and “.org” was reserved for non-profits. These distinctions were widely understood back then, and even today, I hear people telling me some organization “must” be a non-profit because it has a “.org” domain name. Old naming conventions die hard. More importantly, people are hungry for trustmarks.

But TLDs were never great trustmarks, for two reasons. First, validating an organization’s credentials before handing out a domain name is hard and expensive work. Second, domain names don’t sell for a lot, so you can only make money with volume. The pickier you are, the less money you make.

Despite this, the non-profit sector is now pushing the “.ngo” TLD. Think of it as a do-over of the “.org” TLD, because the operator of the domain is trying to limit sales to non-profit entities with the explicit hope that the TLD will become a trustmark over time. Similarly, the AICPA, the big association of certified public accountants, is in a fierce battle to control the forthcoming “.cpa” TLD, again with the hope it can restrict its use to certified public accountants and build it into a trustmark.

My view is that TLDs make for poor trustmarks. The economics make it hard to enforce standards, and there are too many sleazy operators in the business that drag down the credibility of TLDs across the board. The need for online trustmarks remains high. Who better than data companies to seize the opportunity?