Measuring WordPress plugin growth month over month means comparing two numbers you wrote down the same way each time, and checking whether the difference is bigger than WordPress.org's own rounding before you trust it. WordPress.org reports active installs in rounded buckets, not exact counts, for plugins and themes alike, so what looks like a month-to-month change is often just rounding noise.
Below is the manual way to do this correctly, step by step, and then the shortcut once you know what you're actually checking for.
Why your numbers might be lying to you
WordPress.org rounds active installs instead of giving you the exact number, so a plugin sitting close to a rounding cutoff can look like it jumped or dropped from one month to the next even though nothing really changed - it just crossed the rounding line:
Below 1,000 active installs: a month-over-month move smaller than 10 could just be rounding.
Above 1,000 active installs: a month-over-month move smaller than 100 could just be rounding.
Say your plugin reads 820 active installs one month and 830 the next. That 10-install move sits right at the rounding threshold - it could be ten real new installs, or it could be nothing at all, with the underlying number never having moved outside a single rounding bucket. This is how it's played out for me: there's no way to tell the two apart from that one comparison alone.
The manual method: how to log it the right way
Here's the full process, done by hand, before any shortcut:
Write down active installs, not total downloads. Only active installs can actually go down - downloads never drop when someone uninstalls (the full difference is covered in using downloads and active installs to measure growth).
Check on the same day every month. Checking on different days adds its own noise on top of the rounding - the 1st of the month is a reasonable default, since it's easy to remember.
Subtract last month's number from this month's, then compare the difference against the rounding thresholds above for your plugin's install range.
If the move is close to that cutoff, don't treat it as proof either way. A 15-install move on a plugin with 900 active installs is barely above the noise floor - worth watching, not worth reacting to yet.
Wait to see the same direction two months in a row before you call it a real trend. One month past the threshold could still be a coincidence; two months in the same direction rarely is.
I've found this matters most for smaller and mid-sized plugins, where a single rounding bucket can be a meaningful share of the total install base. A plugin with 50,000 active installs barely notices a 100-install rounding cutoff; a plugin with 800 barely notices anything else.
A short worked example
Say a plugin logs 1,200 active installs in April and 1,340 in May - a 140-install gain, above the 100-install threshold for plugins over 1,000 installs. I'd call that a real move worth trusting on its own.
Now say the same plugin logs 1,340 in May and 1,380 in June - a 40-install move, below that same threshold. I wouldn't let June's number alone confirm a continued trend; it's inside the rounding noise. What you can say is that April to May was real, and June needs one more month of data before you can say anything about it with confidence.
A simple log beats memory
Four columns are enough to run the manual method properly: the date you checked, the active-install count, the raw month-over-month difference, and whether that difference cleared the rounding threshold for your install range. Keep it in a spreadsheet, not your head - the whole method depends on comparing this month's number against a number you wrote down, not one you're trying to recall.
| Date | Active installs | Change | Above rounding noise? |
|---|---|---|---|
| Apr 1 | 1,200 | - | - |
| May 1 | 1,340 | +140 | Yes |
| Jun 1 | 1,380 | +40 | No - inside noise |
I've found a log like this also makes the two-consecutive-months rule easy to apply - you're not relying on memory for what last month showed, and you can see at a glance whether a run of small moves has actually been consistent in one direction or just bouncing around the rounding cutoff.
Turn the raw number into something that actually means something
Month-over-month growth means more as a percentage than as a raw number, since a 50-install move means something different for a plugin at 500 installs than one at 50,000. Keep both the percentage and the raw number - the percentage is the one that actually answers the monthly check's growth question, and it's also the number momentum is built from, one step further into the same check.
Skip the math - StatWP already did it
Here's the actual shortcut, step by step:
Open statwp.com/plugins (or statwp.com/themes if you maintain one instead).
Search your plugin's name or slug.
On its overview card, look for Growth % and Install change - both already worked out the same way described above, no writing-down-and-subtracting required.
One thing I'll flag: StatWP won't decide for you here - if the number is small enough to fall inside that rounding noise, deciding what it means is still up to you. StatWP gives you the clean number, not the verdict - that judgment call is exactly what the manual method above walks you through.
Questions people run into here
Why does WordPress.org round active installs at all instead of showing the real number? It's a deliberate design choice on WordPress.org's part, not a bug - rounding to buckets avoids implying a precision the underlying counting method doesn't actually have. I gauge it this way: the tradeoff is that small real changes and rounding noise can look identical from the outside.
Should I check more often than once a month? Checking more often just means running into rounding noise more often without gaining anything - the active-install number doesn't update meaningfully faster than monthly for most plugins, so a monthly cadence matches how often the underlying data actually changes.
What if my plugin sits right at 1,000 installs, on the boundary between the two thresholds? Use the more conservative threshold - treat a move under 100 as possible noise rather than under 10, until you're clearly and consistently on one side of that boundary for a couple of months.
Does this rounding issue affect downloads too? No - downloads are reported as an exact, ever-increasing count, not a rounded bucket. The rounding trap is specific to active installs, which is one more reason the two numbers need to be read differently; see using downloads and active installs to measure growth for that distinction in full.
What if I missed a month and only have every-other-month data? The method still works, but treat the gap honestly - a two-month-old comparison needs a proportionally bigger move before you can rule out rounding noise, since more time passed for a real change to accumulate. Get back to a consistent monthly cadence as soon as you can rather than trying to interpolate the missing month.