Plugin API should include active installs

[McGuive7]

Currently, plugin data fetched via the plugin API (​https://api.wordpress.org/plugins/info/1.0/) does not include active installs. This is potentially a nice statistic to have. The default active installs number that displays on plugin cards when searching the repo or via a site's Plugins > Add New screen performs some pretty heavy rounding, and there are use cases for having more accurate numbers.

Is there a reason to intentionally exclude this info? If not, is the code for this functionality available via an SVN repo somewhere for a patch?

[swissspidy]

The API doesn't send active_installs by default, but you can totally fetch that data if you need it. For example, this is what I do in a plugin of mine:

require_once ABSPATH . 'wp-admin/includes/plugin-install.php';

$args = array(
	'author'   => $username,
	'per_page' => 10,
	'fields'   => array(
		'author'          => false,
		'active_installs' => true,
		'banners'         => true,
		'compatibility'   => false,
		'description'     => false,
		'downloaded'      => false,
		'homepage'        => false,
		'icons'           => true,
		'last_updated'    => true,
		'num_ratings'     => false,
		'ratings'         => false,
	),
);

$data = plugins_api( 'query_plugins', $args );

Works like a charm.

[McGuive7]

This is great! Thanks for the info. One question: is there full documentation of this? For all my searching I was unable to find this clearly documented. Did I just miss it?

[McGuive7]

Also, the active_installs is still rounded here. Is there no way to get the unrounded number?

[Otto42]

No, there is no way to get the unrounded number. We do not provide raw statistical data as it can be misinterpreted.

The API calls are not well documented as those are primarily made for WordPress installs to use, not for external calls from other software. However, the active_installs parameter is used by core in the WP_Plugin_Install_List_Table class, as well as the install_plugin_information() function. So, it is a supported parameter as core itself is using it.

[McGuive7]

Thanks for the clarification, and a few more questions. . .

1. Can you elaborate on how the raw active_install count "can be misinerpreted"? Is it not just an exact count of the different URL's logged for a given plugin?

2. Can you clarify the rounding paradigm? It seems to me like generally the rounding amount increases as the active_install number increases, however this doesn't appear to work consistently. For example, take the following screenshot:

One plugin is being rounded to 300+ installs, whereas the other is showing exactly 546 downloads. What's going on there?

At some point it looks like things start to round by 1,000, and then possibly by 10,000, and then maybe again by 100,000 once those respective milestones are reached.

My question for you is, why not maintain the same level of rounding. As a plugin author, I can tell you that seeing 10,000+ leaves me wanting more detail - does the plugin have 10,001 active installs, or 19,999? That's a huge difference.

Any feedback would be much appreciated. Thanks!

[Otto42]

1. Misinterpreted in that there is considerable day-to-day variation. A drop of, say, 300 installs over one day doesn't necessarily mean 300 people deactivated the plugin.

The reporting and data gathering methods are not perfect, and without understanding the potential issues inherent there, giving exact counts would be misleading. In other words, our "exact" count is not "exact" at all.

2. The number is rounded to the first significant digit. 300+ = 300-399. 10,000+ = 10000 - 19999. The displayed number maxes out at 1 million.

The reasoning is that at each point in that curve, you're less concerned about individual installs and should be concerned more with the overall health of the ecosystem you're creating. There really is not a lot of difference between 10000 and 19999, actually. It's over 10k people using your plugin. When it gets to 20k, then that's good to know, but knowing when it hits 15k is not really significant. Growth is what you're looking for, and seeing that early rapid growth is helpful, but that falls off in usefulness as the number grows larger. Or maybe not. Depends on your ego, I'd say. ;)

3. When we have no active install data for a plugin, as in zero reported active installs, then it shows the download count instead.

[McGuive7]

Thanks for the reply, definitely helpful to hear a more in-depth explanation of the methods at play behind the scenes. A few more questions/comments:

1. I respectfully disagree that rounding to the first significant digit is an appropriate method here. For plugin developers attempting to improve/optimize thing, more granular growth data may have less to do with ego and more to do with reaching a wider audience for whom a plugin may be beneficial. In light of your explanation (which was great, thanks), I still fail to see the downside of maxing out rounding at, say, the nearest 1,000. Is there a downside to showing 15,000 instead of 10,000?

2. Documentation - again, is full documentation available anywhere for this API? I'm able to piece together some of the params that are passable to plugins_api() from looking into core source (e.g. /wp-admin/includes/plugin-install.php), however it'd be helpful to see a list of all possible params, or even better yet, is it possible to look at the source code for the API itself?

3. Is there a doc/page that outlines what sections of the meta side of things are and aren't available for patches? I've been pretty confused trying to track down ways to submit patches to the .org/meta side of things. Thanks!

Thanks for your time and assistance!

[samuelsidler]

Replying to McGuive7:

3. Is there a doc/page that outlines what sections of the meta side of things are and aren't available for patches? I've been pretty confused trying to track down ways to submit patches to the .org/meta side of things. Thanks!

This is the most-complete list at the moment: ​https://make.wordpress.org/meta/handbook/projects/