Good ideas for the future of data disclosed to plugin authors using the wordpress.org repository:
1) Identify surges of unhappy users reacting to a bad release — and the opposite, happier outcome.
2) Use pageview analytics to estimate total potential user interest and conversion rates.
3) Assess a plugin's performance with the .org search algorithm, the quality of releases, and plugin incompatibility as well as PHP compatibility issues.
4) Collect significant user behavior data anonymously without phoning home.
5) Just reveal all the raw data with privacy options for individual authors — no interpretive analysis on wordpress.org.
BONUS: Let's take this discussion somewhere else!
Estimated reading time: 36 minutes
In the renamed Trac ticket Mark Zahra opened for the WordPress.org Active Install Growth charts (“#6511: Provide helpful plugin stats and insights“), the helpful comments offering actionable suggestions comprise about 5% of the total. At least that makes it easy to summarize the five useful ones here.
First of all, Matt Cromwell called for a new and proper discussion in a more appropriate setting where stakeholders can “start a process of talking publicly and with intention and strategy on what it would look like to have real actionable plugin/theme stats that authors need.” To that end, Matt proposed closing the Trac discussion:
Let's close this ticket as “wont fix” and move on to more important and long term strategies that actually benefit the plugin community. The longer we haggle over these ineffective charts, the longer it'll take to actually start getting real plugin data that is meaningful.
Unhappy Users Reacting to a Bad Release
Natalie MacLees describes monitoring incoming support requests relative to the current number of active installs and any dip in install growth following releases with “new features” or “large changes” to “judge whether a change to a plugin was a positive or negative one.” Benjamin Intal echoed this, and previously Steve Burge said he has a similar practice. No doubt others do too.
Total Potential User Interest
Sybre Waaijer suggested sharing page views and bounce rates for individual plugin pages. Paired with install stats, this would give plugin owners a conversion rate for potential customers coming through wp.org.
Site Search Performance, Release Quality, and Compatibility
Amber Hinds‘ blue sky wishlist starts with “Things that tell us if our readme [which is read by the repo's search algorithm] and other ranking factors are on track.” These are smart, useful metrics:
- Number of searches (or impressions) for target keywords
- Average ranking for target keywords for timeframe (month)
- Conversion rates from impression to install for target keywords
So are “Things that tell us if we may have a problem with our plugin” like:
- Number of deactivations per timeframe (month, preferably week)
- Number of deletions per timeframe (month, preferably week)
- Average time from activation to deactivation or deletion
And finally, “Things for better testing of releases” could include:
- Top 20 plugins also active [on a site with your plugin installed and active]
- Top 20 themes also active
- PHP versions (percentage)
- WordPress versions (percentage)
Sophisticated Behavioral Data Without Telemetry
- Time to churn (to deactivate) signals good/bad onboarding, UI/UX
- Repeat installs – how many users (anonymized) install on multiple sites for community opp & advocacy
- Time to result: dev can choose 1 single hook to trigger as “result” and the calculation checks how long from install to get there. By changing the placement of the hook devs can optimize entire flows.
- Inner page tracker: which/how many inner plugin pages users visit
- PHP ver distribution, general country-based installs, active install to review ratio
Open All the Data, Let the Community Interpret It
Finally, in Post Status Slack, Drupal.org has been recommended as a model for simply revealing all the raw data without interpretation and leaving that to the community.