For a while now I’ve been intrigued by the simple e-commerce service provided by Gumroad. They’ve made setting up products to sell on your own site very quick and painless whether or not you’re using WordPress.
So Nick Young and I sat down and created a simple Gumroad plugin for WordPress.
More recently Ryan Delk, head of business development at Gumroad, contacted me via email personally to talk about their service and the value it provides if you’re selling digital products online.
They have a beautiful user interface and extremely simple process for getting paid and tracking sales. I haven’t used them for my own products yet, but I’m definitely leaning towards using them out on a future product.
Update Jan 25, 2014: Besides overlays you can also add a Gumroad embedded product to your pages. This plugin has also been updated to use only shortcodes.
Keep in mind you’ll need to have SSL (https://) enabled on the pages that host your overlay button or Gumroad embedded product.
Download the free Gumroad WordPress plugin here (or simply search for “gumroad” when adding a plugin in your WordPress admin).
When you create a free plugin and submit it to the WordPress.org plugin repository, you get the privilege of creating a landing page for that plugin.
Technically it’s not the same as creating a landing page for your own site using whatever layout and styling you want. But it’s a landing page nevertheless.
Whatever your plugin business model is, one goal most of us have that choose to put a plugin in the repo is to get as many downloads as possible.
Let’s start from the top of the landing page…
Create a Killer Banner Image
Just about everything you need to edit in order to optimize your plugin landing page is in the plugin’s readme.txt file. Except one of the most crucial parts: the banner image.
It’s basically a 772 pixel wide by 250 pixel tall image, and the technical details on how to submit it can be found at the bottom of the WordPress Plugin Developer FAQ.
This banner image is your header and comes above everything else on the page other than WordPress.org’s own header. It’s what viewers will notice first when making that 5-second decision to continue reading about your plugin or moving on to another.
When you’re creating a banner image, remember that the plugin name will overlay the bottom left corner of the banner image. The banner image screenshots below include the overlay text so you can see this. The overlay’s width is determined by how long the plugin name is.
Even though the plugin name is included in this overlay, you don’t have control of its placement or font. For this reason many good banner images include the name of the plugin or a strong headline higher up in the image with the brand’s font, style and sometimes logo.
Here’s what I consider a few great banner image examples at the time of this post:
- Easy Digital Downloads adds its tagline to the banner image below a custom logo and title. Pretty common practice on regular landing page optimization.
- Ultimate Coming Soon Page goes right into its features with a separate bullet list off to the right-hand side.
- VideoPress lists its features at the top-left along with a short subhead underneath its custom headline in the center of the banner image.
- WooCommerce doesn’t include any additional headlines or bullet points in the banner image itself. Instead it relies on its “Woo Ninja” characters to strengthen its brand and adds “excelling eCommerce” to the actual plugin name so it appears in the overlay.
At this point I have to mention a fantastic copywriting and headline writing resource: Copy Hackers.
I’ve gotten a ton of value out of their books over the last couple years. Book 3 is specifically on headlines and subheads. But all their stuff is high quality and will help improve your overall ability to convert users with your web copy and calls-to-action.
Readme.txt and Markdown
Besides the banner image, everything else seen on the landing page is controlled by the readme.txt file. You’ll need to use Markdown, which gives you some formatting control (albeit limited).
For starters, the short text phrase under the banner image is like another subhead. Maybe even the only subhead if you don’t include one in your banner image.
This subhead should be 150 characters or less like a tweet. It should communicate what this plugin does and who it’s for. As you can see, it’s a larger font than the rest of your plugin’s description that follows, so make it count!
Writing Good Landing Page Copy
Don’t just write huge paragraphs. People will lose interest quickly. Make sure to take full advantage of the Markdown syntax available to you.
Use different heading sizes, bullet points and plenty of whitespace to break things up.
In most cases you want to list off the benefits and features your plugin has to offer. If applicable link to demos and examples of your plugin in use.
Besides getting a bunch of downloads, you may want to encourage users to pay for support, upsell them to a premium plugin or add-ons, or simply get your brand name out there. Various plugin shops have different business goals which should be communicated in the copy.
If you want to learn more about good landing page strategies and writing good web copy, here’s a few resources to get your started:
Embed a Video
A lot of non-plugin high-converting landing pages use video as the first visual after the headline. Video happens to be one of the only visual options WordPress.org plugin pages allow besides the banner image and author avatars.
Whether it’s a promo, intro or instructional video, put one out there if you can. Probably near the top. I’m sure this helps a ton and is something I need to tackle for my own plugins. Note you can only use YouTube or Vimeo embeds at this time.
Limitations on Calls-to-Action (CTAs)
As for big call-to-action buttons, the only one allowed on the plugin landing page is the orange “Download Version X.XX” that is automatically generated. If you’re attempting to upsell to a premium plugin or add-ons by directing the reader to your own site, you can’t create a nice call-to-action button in the copy. You just do what you can with Markdown.
Since you’re not allowed to use bold or heading text in a link, at least add line breaks and white space around any links you’re attempting to direct the reader to. Maybe add an exclamation point and/or double right arrow HTML symbol (HTML code ») to emphasize the link as much as possible.
Some “freemium” plugins such as Ultimate Coming Soon Page list their “Pro” features after their free plugin features, then put a link “Upgrade to Pro” after the list. The hope is that some readers will see that they need Pro features right away and head over to buy the Pro plugin immediately.
But in the end it’s assumed the majority of readers will download your free plugin to try it out first before pulling out their credit card. For this reason you may want to focus your upselling efforts more within your free plugin itself where you have more formatting control anyway. I plan on covering methods and strategies for upselling within a free plugin in a future post.
WordPress.org Plugin Page SEO
Remember that WordPress.org is a high-ranking domain in search engines. Do a search for a type of plugin in Google (i.e. “twitter wordpress plugin”) and usually at least a few free plugins hosted on WordPress.org show up within the top 5 or so results.
If you’re selling a premium plugin you’ll also want to get your own website to rank high, but chances are your free plugin on WordPress.org will rank higher for key terms for a while.
Taking this into consideration, make sure your readme.txt content is like a good search optimized post in that it contains the keywords you want to rank for. There’s a ton more to learn to create a highly SEO-optimized page. I suggest heading over to the Hittail blog for some helpful SEO articles.
Plugin Version Numbers and Compatibility
On the right of your main plugin copy is the big call-to-action download button and a few other items to maintain at the beginning of your plugin’s readme.txt. Make sure and get these right.
The “Download Version x.x.x” button points to what you’ve indicated in the “stable” tag. Make sure folks are downloading the correct version.
Set “Requires” to a WordPress version that makes sense for your plugin. Don’t assume everyone will upgrade to the latest version of WordPress right away. Consider going back a few versions as long as it doesn’t create a support headache for you.
Set “Compatible up to” to at least the current version of WordPress. Some plugins put the beta version that’s on the horizon here to give readers confidence it’ll continue to work when they update WordPress core.
“Last Updated” indicates the last date the readme.txt or any code has been updated. Keeping this date fairly current gives readers confidence that the plugin is unlikely to be abandoned or break anytime soon.
If you’re regularly optimizing your readme.txt anyway, keeping this date current will take care of itself.
Here’s a snapshot of my Pinterest “Pin It” Button Lite plugin right-hand side at the time of this post.
Below “Downloads” are your plugin ratings and author avatars. Make sure your WordPress author profiles are filled out and Gravatars linked properly. And please display decent profile images for your authors instead of a lame generated cartoon character. It can only help your plugin page’s trust factor when readers see a real face.
To update these plugin header options properly use the official WordPress.org readme.txt boilerplate or the more in-depth guide by David Decker on Pippin’s Plugins titled How to Properly Format and Enhance Your Plugin’s Readme.txt File for the WordPress.org Repository.
Both of these guides also go into the other pages controlled by the readme.txt besides the plugin landing page, such as Installation, FAQ, Screenshots and Changelog.
Test and Experiment
Just like regular website landing pages, you can continually optimize the conversion rate of your plugin landing page by tweaking and testing.
Since you can update your plugin’s readme.txt as often as you like, test and experiment to find what works for your plugin and your business goals. Try something for a week or two and look at your plugin download stats and referrals to your main website. Make sure to add trackable URLs (like Google campaign URLs) to all links back to your website in your readme.txt.
If you have any tips or tricks that have helped you optimize your WordPress.org plugin landing pages, I’d love to hear about it in the comments.
Recently there’s been a lot of discussion on how to price your premium WordPress plugin.
Chris Lema started it with WordPress Plugin Prices Are Too Low, and many comments followed.
For one of my own premium plugins, Pinterest “Pin It” Button Pro, I ran two price tests recently and wanted to share the results.
My Standard Plugin Pricing Model
For a little background, I launched Pinterest “Pin It” Button Pro in October 2012, so less than a year ago. Prior to that, in December 2011, I released a free/”lite” version on the WordPress repository. The success and number of downloads of the “lite” plugin is what prompted me to create the Pro version. Since then I’ve basically been following the “freemium” plugin business model and it’s been working pretty well so far. No add-ons or packages (yet).
So far I’m basically charging for how many sites I’ll support, and currently it’s as follows (subject to tests and changes going forward of course):
- 1 Site: $29
- 5 Sites: $49
- Unlimited Sites: $99
Total sales per month has ranged from $2000 to $3500 between October 2012 and May 2013. Not high volume, but it’s a niche social network plugin done in my spare time (I have a software development day job currently). I’m also the only developer and support person on the plugin right now.
I have an annual license renewal rate in place, but when I launched I briefly offered lifetime licenses for my top two plans for a quick cash injection.
Pricing Test #1: Lowering Prices
For the month of February 2013 I lowered my 1-site license to $19 and my 5-site license to $39. Below are the results compared to March 2013. I didn’t have any other major deals, advertising or promotions running at that time that would skew it a bunch in my opinion.
|February 2013||March 2013|
The results speak for themselves. $610 more (about 21%) by raising my prices back to $29/$49 as opposed to $19/$39. If you can’t see the above table that’s $3,542 in March vs $2,932 in February.
I even multiplied the February units sold by 1.11 to account for February being 3 days less than March.
Also important is that there were significantly less support requests and nasty complaints at the higher prices. So even if dollar totals came out the same, less support is always better.
A case could be made that the 5-site plan at $39 is better. But would it work to have only a $10 difference between the two lower plans?
Pricing Test #2: Eliminating the Single Site License
Since I heard “Raise Your Prices!” again and again by successful startup owners at MicroConf a month ago, in mid-May I decided to run a 2-week test that simply eliminated my 1-site license.
Yes, that means the lowest plan was $49 for 2 weeks.
I had only one complaint that there wasn’t a cheaper plan available, and I simply informed that person I’d re-introduce the 1-site license soon.
Since I only ran it 2 weeks, I broke down the weekly average and compared it to the 4 weeks prior.
|Date Range||Total Sales $||Weekly Average $||Weekly Units Sold|
|Apr 10 to May 7 (4 weeks)||$3,227||$807||20|
|May 8 to May 21 (2 weeks)||$1,030||$515||10|
$807 per week (with 1-site license) is about 150% the $515 per week (without 1-site license), so I’ll stick with the more profitable one for now. But I should point out that without the 1-site license I sold half the number of units, so profit per sale was actually higher, which usually means less support.
Like I said before, test your prices. Try raising your plugin prices in increments to see what happens. Split test if you want. Possibly test lowering or adding a new tier if you’re not convinced.
Obviously my Pinterest plugin appeals to many single site owners. Yes, some sales are made on the 5-site plan, but very few purchase the highest plan right now, which causes me to believe I don’t have a ton of consultants buying the plugin. I’m sure other plugins lean more towards the consultant side. It just depends who your audience is.
Any other WordPress plugin shops want to reveal pricing tests that have worked for them? If not dollar amounts, maybe units and percentages?
This is a response to Chris Lema’s recent post WordPress Plugin Prices Are Too Low.
There are several important issues that Chris points out about the current state of WordPress premium plugin prices.
The “race to free” is definitely a scary one. Many mobile app developers can relate to this. They work for months (or even years) on a complex app only to be able to sell it for $0.99. There are actual reviews out there of customers complaining that a useful mobile app is “not worth it” at $2! And this trend seems to be heading the same direction a decent portion of the premium WordPress plugin marketplace.
Set your price according to the value it provides
What do you value your time at? Chris points out to consider how much time you’re saving when you buy a premium plugin. How many hours did it shave off your various projects and how much is your time worth? That will give you perspective when thinking about purchasing a $19 plugin vs. a $199 plugin.
This is obviously a subject that has a wide variety of views and opinions, so I highly recommend reading at least some of the huge number of comments in response to Chris’ post.
For the most part I tend to agree in that you need to price at the value your providing the customer. Many developers and product creators tend to undervalue their products and the time spent supporting them. You probably need to raise your prices more than you think. This is something that’s been drilled into my head over and over by successful SaaS startup entrepreneurs like Jason Cohen, Patrick McKenzie and Rob Walling. All three have slashed lower price plans multiple times personally and made huge strides forward in their businesses, and they aren’t afraid to talk about it.
Here’s a portion of my comment in reply to Chris’ post:
While I agree with you on leaning towards pricing higher, like John Turner said you need to test and find that sweet spot that works. I also tested my single site license (with annual renewal) at $19 for a short period but then moved it back to it’s original $29. Same sales in dollars in the end, but with more support and refund requests.
Recently I tested eliminating my single site license altogether, and I haven’t yet gathered the data, but I believe it may NOT work. Like Syed Balkhi mentioned I think that’s only because of my target audience. I think too many of my customers are non-technical single-site owners that don’t make a ton off their sites. But I’m going to dig into the numbers and post more on this soon.
If you have a plugin that’s more B2B or appeals mainly to other WP consultants, I bet your chances are better of a higher price for your cheapest plan working. Or maybe you don’t need a single site license plan at all. But you won’t know until you test, even if it’s only a split test and/or only for a couple of weeks. As part of your test don’t forget to include support costs, whether it’s your own time or support staff.
As for lifetime licenses, I believe they should rarely be used. Following the common model of other non-lifetime plugin plans, I’m using a discounted annual renewal rate as well. However, I haven’t quite yet reached a year since selling my first premium plugin so the jury’s still out how many renewals come in.
I agree on eliminating lifetime licenses except for one scenario: Quick cash injection (but very infrequent). When launching a plugin maybe offer a lifetime license only for your higher priced premium plan, possibly doubling your current highest plan. State that it’s time or quantity limited. A boost of cash when launching a plugin can be a huge motivator for keeping the project going. Another cash boost where you might consider lifetime licenses is when using a deal newsletter like AppSumo or Mighty Deals, especially since you’re discounting it pretty heavily already.
But I don’t have a documented test to prove the lifetime license exception. It may only work for motivation and probably not a good move financially for established plugin businesses.
You won’t know until you test
In short, you need to test, test, test to find your ideal price points. I like testing new pricing plans for 2 weeks. Others will run A/B split tests. Any test is good as long as it’s gathering valuable data over a reasonable amount of time.
Sometimes a price increase doesn’t decrease sales quantity at all, and that’s awesome! Sometimes eliminating the lowest plan decreases the total revenue a little, but you’ve just cut out 80% of your support requests, which is also a huge plus.
Finally, as a WordPress plugin shop it’s tough to sell monthly recurring plans, so the next best thing is annual recurring. Lifetime licenses should only be used in a few cases. But again, you’ll need to test. Every plugin has a different value point and is targeted towards different audiences.
Have you tested different prices for your plugin? What have you found that works or doesn’t work?
Updated May 30, 2013
The discussion continues with some great follow-ups.
Jeff at WP Tavern believes that there’s room for both consumer and consultant price points for the same plugin as the value is quite different for the two audiences.
Chris Lema followed up to his original post with some more perspective on the idea of variable pricing based on value and offering add-on options for your customers.
Thomas Griffin introduced support tokens for his Soliloquy plugin last month instead of charging an annual renewal.
David Peralty of Gravity Forms posted his take on lifetime vs subscription licenses, add-ons vs packages, and what (hypothetical) costs might look like to support a larger plugin business.
Updated June 3, 2013
I ran two pricing tests for one of my premium plugins and posted the results. One price increase resulted in 21% more plugin sales. Dollars and units sold revealed.
If you’re in the business of making money from WordPress plugins, there’s not just one way to go about it. If you’ve gone through any videos, podcast interviews and posts on selling premium plugins you’ll see that revenue models vary quite a bit.
The Smashing Magazine article “How Commercial Plugin Developers Are Using The WordPress Repository” by Siobhan McKeown already covered some of these, but I wanted to dive in a bit more detail on some of them.
The “freemium” model (also called “free + premium” or “lite + pro”) is popular not only among WordPress plugins but also themes, desktop software, mobile apps, and many SaaS (software as a service) web apps. In most cases the idea is to get a bunch of users signed up for the free version with hopes that a decent percentage of them will pay to upgrade to a more fully featured (and better supported) premium version.
For WordPress plugin shops, free plugins published to the WordPress.org plugin repository give them quite a bit of exposure. When WordPress users are searching for plugins in their dashboard or on wordpress.org, these free plugins will show up while paid plugins are not allowed. Doing a Google search for plugins will bring up both paid and free, but many times the free plugins on wordpress.org will rank equally or higher than the same-named paid plugins.
Examples plugins using the freemium model:
- Ultimate Coming Soon Pro / Lite
- Soliloquy Slider Pro / Lite
- Event Espresso Pro / Lite
- Pinterest “Pin It” Button Pro / Lite (my plugin)
For all of these examples you’ll see a fair number of downloads. This volume is necessary in most freemium models where you’re usually converting only a single-digit percentage of these users to paid.
However, as a plugin shop you’re not required to publish a plugin in the WordPress repository. You could go after organic search (Google) by itself and skip the repository and a free version altogether. You could also publish paid-only plugins in a marketplace like Code Canyon. You’d miss out on the exposure the WordPress repository gives you, but it works well enough for some.
Free Base Plugin with Paid Add-Ons
Another business model is to have a free plugin “base” that works out of the box (and is listed in the WordPress repository), but then sell add-ons that extend the functionality of that plugin instead of replacing the entire thing (add-ons are sometimes referred to as “extensions” or “modules”).
An added benefit for the plugin add-on model is that users don’t get a large bloated base plugin. Instead they only purchase and install the add-ons needed for their specific site requirements.
Examples of plugins with paid add-ons:
Backed by SaaS
A WordPress plugin that requires a SaaS (software as a service) for full functionality is another possible revenue model in certain scenarios.
Scribe is an SEO tool that used to be solely a SaaS-backed WordPress plugin. Now they’ve branched out to other platforms, but the Scribe plugin still exists in the repository. It allows a “test drive” for free but requires a monthly subscription for more features and usage.
The best thing about a SaaS-backed plugin is that it lends itself better to annual or even monthly recurring subscriptions. And recurring monthly revenue especially is one of the tougher things to do well as a WordPress plugin business.
Pay Only for Support
Some plugins offer their full-featured plugin for free (no freemium model), but then charge if you need support outside of a public forum or FAQ. The idea here is that many of their users will become dependent on the plugin and not be able to run their own business websites without it. When issues arise time is money, and most business owners will pay for reliable support. This is where a WordPress plugin shop can charge for support either on a recurring basis or even per request.
Once again the beauty of this model is that the plugin can gain the exposure in the WordPress repository like any other free plugin. However, this free plugin might receive more downloads and higher ratings than a comparable “lite” version of a paid plugin since they’re typically not going to put a limitation on features to entice an upgrade.
At the time of this post a great example of the paid support revenue model is Paid Memberships Pro. If you want to hear why the founder chose this model more in-depth, just check out this podcast interview on MattReport.com.
Update: PMP Pro founder Jason Coleman also wrote a detailed post on his reasons for a “paid support only” approach.
Combined Business Models
Sometimes revenue models are combined. Soliloquy is freemium (lite + pro versions), but you can buy paid add-ons to its paid plugin (and only with a developer license at that). There are no add-ons to the “lite” version.
Easy Digital Downloads is a free base plugin with paid add-ons, but you can purchase priority support that covers the base plugin and add-ons combined.
Gravity Forms is paid plugin only, but it provides free add-ons to business and developer license holders. Basically they provide add-ons as a part of your license, with the functionality being optional (not included in the base plugin), and available only when you upgrade to more expensive license.
Paid Memberships Pro and some others have a “white glove” offering. In this model customers can pay high premium for services such as installing, configuring and consultations related to the plugin.
Finally, some developers create free WordPress plugins just to boost their portfolio or as a lead generator for their consulting services. The focus isn’t product revenue but they benefit financially from their plugins nonetheless.