WordPress Plugin Developers Renew Demands for Better Plugin Metrics

It has be nearly one year since WordPress silently turned off active install growth data for plugins hosted in the official plugin repository, a key metric that many developers rely on for accurate tracking and product decision-making. “Insufficient data obfuscation” was cited as the reason for the charts’ removal, but this opaque decision landed without any communication from those who had made the call in a private discussion.

In a ticket originally titled “Bring back the active install growth chart,” RebelCode CEO Mark Zahra made the opening plea for thousands of plugin developers who were asking for the return of this data. From those who simply host hobby plugins and enjoy the thrill of watching people use software they made to business owners who need this data to make critical decisions, the overwhelming consensus was that this data is valuable and should be available to those who are contributing to WordPress through plugins.

In an appearance on the WPwatercooler podcast last year, Audrey Capital-sponsored meta contributor Samuel “Otto” Wood confirmed the decision was made through private channels via Slack DMs in a discussion initiated by Matt Mullenweg. He also revealed that the active install growth chart was removed because it was giving inaccurate data and that the data one could derive from it was inaccurate:

I read through all that discussion and we worked, they worked on it for a long, Scott and several people tried various things before removing it. They adjusted the values, they adjusted numbers. They, they went through a ridiculous amount of iteration and in the end, none of it worked. People were still using it even though it was giving them basically garbage. So finally removing it was the only thing to do. We did have a plan for replacing it. We just didn’t have a plan for replacing it immediately. Nevertheless, giving them active install count numbers that are wrong is more harmful, we felt, to both users and developers interests than simply not giving them at all. 

Wood offered an explanation on the podcast that should have been delivered weeks earlier by those involved in the discussion on official channels. Despite the earlier data being flawed and “insufficiently obfuscated,” developers still want access to the raw data, not interpretations of that data.

These are the posts that track the history and development of developers’ pleas to reinstate access to the data:

During the height of this discussion, developers made many suggestions for different data points that would be meaningful for tracking their efforts, and Matt Mullenweg responded that he was amenable to showing more stats to plugin authors about their plugins. No progress on this effort has been reported since then.

 StellarWP Product Marketing Director Taylor Waldon has reopened this discussion nearly a year later, calling on Mullenweg to stop restricting access to plugin data from people who are hosting themes and plugins on WordPress.org.

“I talked to a bunch of folks at [WCUS] contributor day,” Paid Memberships Pro co-founder and CEO Jason Coleman said in response to Waldon’s tweet. “As far as I know, there isn’t any other current effort to update or replace the install count numbers or old ‘growth’ chart.’”

Coleman put together a draft proposal with some ideas from his conversations. The document describes a common scenario where plugin developers are left in the dark about the growth or decline of their plugins’ active installations:

Imagine a developer with a plugin with 150k active installations. That developer has effectively 0 quantitative feedback on whether users of his plugin are growing or falling. The download count has a trend, but there is no separation between new downloads and updates. The download count tracks developmental pace as much as user growth. A bump in downloads could be due to a security vulnerability being patched or an influx of new users. The current active installations count is severely rounded and offers no feedback until such a plugin either gains or loses 33% of its users, which are drastically different outcomes.

Coleman contends that plugins hosted outside of WordPress.org are able to gather more meaningful metrics. Popular plugins have resorted to including features in non-WordPress.org add-ons or simply removing their extensions altogether from the repository for lack of data.

His proposal includes a few metrics that would help developers better track their plugins, even if that data is only shown to the authors themselves:

  • Share a more accurate active installations count with the owners of a plugin.
  • Share more accurate version number counts with the owners of a plugin.
  • Differentiate the download count by type: website downloads, dashboard installs, dashboard downloads, updates, other (hits to the zip file).
  • Allow plugin developers to define custom event triggers to be tallied and displayed to the plugin owners on the plugins .org profile page.

Coleman’s draft is still in progress and so far he is the only one who has authored the document. If the recommended actions gain any traction, he said he hopes to be part of the contributor team that implements the changes.

“The intention was to write something that could be proposed to meta team,” Coleman said. “But honestly, I thought I would write it up, it would get shot down, and then I could move on with my life. Even if nothing got updated, it would be more clear to me and others which parts of the .org code were in public repositories and which were in the private repositories. It would be more clear what the real issues are with the active installs count.

“The communication around the removal of the active install growth chart caused many to lose trust in parts of the WordPress .org project. I thought some clarity around how things work and the real reasons around the changes would help to rebuild some of that trust that was lost.”

WordPress.org has always been the most popular distribution channel for the most widely used plugins, but the data available has not kept pace with developer and business needs. Releasing the raw data, while respecting any privacy limitations, would allow developers to extract their own interpretations of that data and allow services to present it in creative ways.

At the very least, this data should be available to developers (even if it’s not public) to help them better track the trajectory of their plugins and the efficacy of their marketing efforts. More data can only serve to improve the WordPress ecosystem’s ability to continue powering a multi-billion dollar economy. There are undoubtedly many technical requirements for supporting the release of this data, and they need to be prioritized if WordPress.org is to continue attracting the best products for distribution.

“This is not about vanity metrics or inflating numbers for marketing purposes,” Coleman said. “This is about getting valuable feedback on the relative use of a plugin hosted in the .org repository so developers can make informed decisions and investments in those plugins.”

12

12 responses to “WordPress Plugin Developers Renew Demands for Better Plugin Metrics”

  1. As a user, I do not need these data (it is reassuring to see that a plug-in is used in thousands of sites, but not critical)—but developers do, and I think that it is important that they are able to get the raw data about their own products. There is not a need for a public release, but those who are building plug-ins need as much information as possible about its use, respecting privacy. I don’t see why this is such a problem; one is tempted to think the worst, that they just want to move away from the .org plug-ins. If there was a plan for a replacement, even if not immediately, is it being implemented? When can developers expect to see some data?

  2. This would violate privacy laws.

    It is no one’s business if I activate a plugin or not.

    For anyone to know I activate a plugin I installed on my website, it has to phone home.

    It is no one’s business the basic stats of my installation. It is no one’s business what plugins I download.

    I shouldn’t have to get an account to use a plugin, like Rank Math for example.

    • No, it wouldn’t. This doesn’t have anything to do with your installation. Data would be anonymized and you won’t be able to connect active installation with the domain. The plugin author would benefit from this a lot and can create decisions for the future. On the other hand, if you don’t like your site sending active install statistics you can always develop your own plugin that is not published to the public repository

    • Plugins have to phone home to also check for and download updates. That inevitably gives out the information that you have a specific plugin activated. People sharing this opinion of yours should be cut off updates, and enjoy their privacy. See how nice that kind of privacy will be.

      I’m in favor of privacy, as much as possible, but in this case what you’re suggesting is an overkill.

  3. I’d love to get those or better stats back for the sake of contributors like me.
    I stopped maintaining some of my completely free plugins due to the removed stats. Seeing a growing users base was the only motivating factor I had.

  4. I’d argue the data does have value for users as well as developers – number of active sites implies that the site owners/admins find the plugin to be stable and useful, so they keep it active. Few active sites, but recently published? Ok, take a closer look. Published a good while ago but few active sites? Maybe good to wonder why. Some code fulfils a niche need so will have fewer installs. Otoh, maybe the plugin has stability/compatibility issues or some other reason to look closer before deploying. In the vast majority of cases plugin authors share value at no (or very reasonable) cost and simply knowing how many sites are using their code (so letting them know if the effort to maintain it is worthwhile/appreciated) doesn’t seem an unreasonable thing to me – maybe what’s needed is an open, transparent and trusted common anonymous reporting framework in the core that all of the plugin ecosystem can use … and that site admins can switch off if there’s a pressing need. I bookmarked a thread on a similar theme a while back https://wordpress.stackexchange.com/questions/69388/how-can-i-track-active-users-of-my-plugin-and-why-doesnt-wordpress-org-offer-t

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: