WordPress By

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 developer’s 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. He was not immediately available for comment when I asked about the next step once the proposal is further developed.

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.”