I am not sure why the numbers are as low as they are. All I know when my scripts were on OUJS on update I would get thousands of new installs on certain scripts per update, so I would expect that total installs should be in the thousands for same scripts, but here the total number on same scripts is much lower than a thousand which begs the question, why?
For example Linx Amender gets more update checks per day (800-1600) then that total number of installs which is less than 800 on this site. I don't have a clue why that is the case. I would expect the update check to be much lower than the install count.
Anyway it is just an idea thrown in frustration (with this and other stuff at that time I wrote the post).
You should consider adding another column to include total install including updates and just for users. To many that's more useful. It does not need to be used for rating.
I use an @resource to an icon file on my web server to log "actual" installs + updates for some of my scripts. It's extremely difficult to de-duplicate the requests, especially from Tampermonkey which seems to have more volatile script storage than Greasemonkey, so I've mostly stopped caring. Maybe if I researched log processing software more thoroughly I wouldn't find myself puzzling over long sheets of data in Excel every 6 month and find it more useful...
I use an @resource to an icon file on my web server to log "actual" installs + updates for some of my scripts.
That is a rather a clever way of bypassing the issue. I would do the same if I had a personal site or a site that offers such services. Maybe I can follow your idea through GitHub and then use API to actually get a more accurate idea of what the download rate is (for each release).
I am kinda of flip flopping on the idea of no longer updating @version and just use my own property tag to check with my own updater, thus forcing people to actually come to the script homepage and update manually. Only issue is GM won't actually show the correct version number. Another way is having a version number with a decremental suffix, which is a bit of a pain to type in.
Greasy Fork counts an "install" as a unique IP clicking on the button to install on Greasy Fork. It counts an "update check" as unique IP checking for updates. If you're getting thousands of "installs" on OUJS every time you update, then I assume they're using a different definition of "install".
I doubt people go out of their way to click install per update to get my counter up. It counts per install (updates are considered installs). Also it was pretty consistent between each update.
If people are installing the script from somewhere other than Greasy Fork, but the script checks for updates from Greasy Fork, that could be the reason.
Until recently the answer would be a no. My main site was OUJS and all updates pointed to it, but my account got removed. But even so looking at dates before OUJS account got closed it seemed to be an issue back then also. Most of my script that are being used out there most likely point to a dead OUJS account.
I don't see how that's useful. That would just inflate the numbers for any script that updates often.
If you want to know how many new users you get, "installs". If you want to know how many users are currently using the script, "update checks".
Varies too much, and total install count or update per version is more interesting and fixed. It can also be listed in the column listing rather than 2 clicks away in stats page. One tends to look at the profile page listing or search listing. The script page is visited when installing and never the stats page. A quick glance of the profile page and comparison between each scripts and then quit.
Update Script Suggestion
I am thinking of writing an update script that adds a property tag in the header called "@version2" to force users to install via the scripts GF page install button to have an actual count of the number of installs.
I find it annoying to only five installs when the number would be in the thousands via OUJS and the Daily Update stats does not represent total install for a new version. This just an idea and nothing more at the moment. What do others think?