This case study looks at the positive steps I took to decrease the number of deactivations on one of my freemium plugins. The steps are based around identifying the problem, analysing the data, and making changes to the product. There’s probably a clever acronym for this approach but I’m afraid I don’t know what it is.

About the plugin

The plugin in question is Discussion Board – a WordPress forum plugin. Discussion Board operates on the freemium principle – there’s a free version on the WordPress plugin repository and a premium version sold through this site. As you are almost certainly aware, the theory behind the freemium model is that you offer a basic version of your product for free, then encourage users to upgrade to a paid-for version that has extra features.

Step 1: Identifying the problem

I have several plugins, free and freemium, on the WordPress directory. The most popular, Cookie Consent, has over 100,000 active installations. Discussion Board has far fewer installations.

One of the most puzzling things I’ve found as a plugin developer is the lack of information for authors on the WordPress directory. I could see that Discussion Board was being downloaded but I couldn’t work out how often it was downloaded by new users, rather than being updated by existing users, or why it was being deactivated.

I started tracking both plugins with Wisdom, which gives me figures on how many users are installing the plugins and tells me how often users deactivate each plugin. I could see that there was a wide difference in the deactivation rates for Cookie Consent and for Discussion Board.

Deactivation rate comparison

Taking data from three months, between July 2017 and September 2017, you can see that the deactivation for Cookie Consent is less than 8% (left hand graphic); the deactivation rate for Discussion Board is over 40% (right hand graphic).

Why do users deactivate plugins?

Although that seems like a significant difference, there are several legitimate reasons why the deactivation rate might be much higher for Discussion Board:

  • Cookie Consent is a much simpler, single-purpose plugin. Users who activate it are already pretty certain it’s going to be right for their needs.
  • Discussion Board is a more complex plugin for a more complex need. Users are more likely to install it just to try it out.
  • Users stick with plugins they know. So a large number of people activating Cookie Consent have already used it on other sites and they will know exactly what to expect.

So all that makes sense – I would naturally expect Discussion Board to be deactivated more frequently than Cookie Consent. However, there was one thing that didn’t make sense.

Step 2: Analysing the data

You can’t beat some solid scientific data analysis. Using Wisdom, I could see what reasons users were giving for deactivating each plugin. When a user deactivates a plugin that is being tracked with Wisdom, they are presented with a form that gives them a choice of reasons for deactivating.

Given that Discussion Board is a fairly complex plugin that users might want to test out first, possibly alongside similar plugins, I expected to see reasons like ‘Not the features I wanted’ or ‘Only required temporarily’ to be the most commonly selected. But to my surprise and, indeed, consternation, the most common reason given by users for deactivation was ‘Didn’t work’.

For the period, the main reason that users gave for deactivating the plugin was that it didn’t work: 28% of responses. Now, this response is fairly vague and generic but one thing is certain: the plugin definitely does work.

Clearly, this is an issue if users are deactivating the plugin almost immediately because they think it’s faulty. Assuming that most users are answering this question genuinely, I feel that there is an issue with perception here – that users think the plugin isn’t working, when in fact it’s working fine.

Listening to anecdotal advice

I could back up my view that the problem was one of perception by listening to the support queries and reviews for the plugin. Now, bear in mind that:

  • Users don’t always report issues – so you don’t always get to hear about things that are going wrong out in the wild
  • Users don’t always report issues in the way you might understand them. You need to read between the lines sometimes

The support thread here is typical of the second point above:

The user had installed the plugin, logged in via the front-end log-in page that is created by the plugin, and encountered a blank page. This appeared to the user to be a bug.

I realised after reading this that I’d seen similar reports previously by other users. The thing is that actually it’s not a bug – the log-in form on the page will only show when the user isn’t logged in (which makes sense I think) – but to the user it seems like a bug, and understandably so, now I think about it.

It wasn’t immediately obvious that there was no log-in form here because the user was already logged in. In truth, I hadn’t really paid enough attention to these support tickets – beyond helping the user to put things right or to help them understand what was happening.

So with a combination of empirical data from Wisdom and a little bit of connecting the dots from various support tickets, I could start to see a bit of a pattern and establish what were the likely reasons that were leading users to think the plugin didn’t work correctly.

Step 3: Fixing the problem

Now, I’m not sure that it’s possible to avoid issues like this 100% but it’s certainly possible to take steps to reduce any poor user experience.

Fixing perceptions

In the case where users were seeing a blank page because they were already logged in, and mistakenly thinking that something was broken, the solution was fairly straightforward.

The plugin automatically adds shortcodes to three pages when it’s installed (to simplify the set-up process). I just modified that process slightly by adding another shortcode that only displays content to logged-in users. Now, when a user who has newly installed the plugin goes to the log-in page, they see a message confirming they are logged in, not just a blank screen. I didn’t really fix anything as such; I just made the process clearer.

The thing I learned here is that user perception is equally as important as your plugin working well. In the mind of the user, if it seems like a bug then it is a bug.

In the mind of the user, if it seems like a bug then it is a bug. Click To Tweet

Hold the user’s hand

I realised that if user perception was so important, I needed to make sure I was creating the right first impressions for new users. I wanted a way to guide them through the initial process of using the plugin so I decided to create a welcome page for the plugin.

Creating a welcome page

This was a significant change that I pondered for a while before implementing it. Many plugins now feature a welcome page that you’re automatically redirected to on activating the plugin – Easy Digital Downloads is one example. A welcome page gives you information about the plugin and/or recent updates and provides an onboarding experience for the user that is helpful for more complex plugins. However, there are some arguments against using a welcome page:

  • Many users are not keen on plugins that grab you and lead you off in unexpected directions. The expected behaviour when installing a plugin is to return to the plugins page, not to be redirected to another page.
  • Many users object to plugins that have a larger footprint than necessary in the dashboard. I personally hate small plugins with very limited feature sets that insist on having their own menu item and icon in the dashboard. I much prefer to see the settings pages for smaller plugins under the Settings menu item where they belong. Welcome pages are another example of plugins imposing themselves on the user, essentially getting too big for their boots.

However, as Discussion Board got bigger and bigger, I felt that a welcome page became more and more justified.

Tell users stuff they need to know

From the example of the blank page support ticket above, it was clear that users’ expectations of the plugin sometimes differed from the actual behaviour of the plugin. I wanted users to be in possession of the facts from the start – and I couldn’t rely on them going off to read the FAQs if something didn’t seem right. I’m sure we’ve all deactivated plugins almost immediately after installing them just because they didn’t do what we expected. People have short attention spans and big expectations.

Discussion Board welcome page
The welcome page, complete with ads

A brief welcome message

By implementing a welcome screen, I could say a quick hello to the user and set expectations. I used standard WordPress styles for the page so that people didn’t feel they were being taken out of the interface entirely. I don’t like it when plugins and themes start adding their own styles that clash with the WordPress dashboard.

Head off the most common issues

For certain, one of the main purposes of the screen is to head off any potential complaints or support issues.  In the first paragraph under ‘Getting Started’ I make it clear that you’ll see different content depending on whether you’re logged in or not. There’s no guarantee that the user will read this but at least I’ve presented it to them and given myself the best possible chance.

Avoid bells and whistles

I needed to keep the page to the point. No one has the time or the inclination to read through all your hopes and dreams for the future of your plugin. I just kept the page to the minimum information I felt was necessary:

  • Getting Started
  • FAQs
  • Settings
  • Further Links

Each section is just a few lines long with some links for more information.

Keep the page available

Several plugins present you with their welcome page when you install or when you update versions. I’ve found in the past that there were occasions when I wanted to refer back to these pages but they’re not included in any menu. I included the welcome page as the ‘About’ sub menu item in the Discussion Board menu in case users wanted to refer back.

The results

After the first week, I got the following results:

I found that the deactivation rate was down to 23% (from 40%), so very nearly halved.

Deactivation rate after updates

Admittedly, that’s only one week and just over 50 sites tracked so I’ll post back here in a few weeks when there’s more data. But it seems at the moment that this is a substantial change.

Final thoughts

This article has been very specific to my own experience with one plugin. However, I hope that if you are developing themes or plugins yourself, you’ve recognised some common areas and that you will be able to apply some of my findings into improving your own products and profitability. The key is to use a combination of empirical data and your own insight into your products and customers to find areas to improve.

Popular Posts

Leave a Reply

Your email address will not be published. Required fields are marked *