Monthly Downloads

Instead of stating the number of “monthly downloads” for each keyboard, why not give the “total downloads” and “number of devices” as it is done in bloomlibrary? That, to me, will be a better way to measure the performance of keyboards since people download keyboards just once and not every month. It will also help keyboard authors to know how far their work has reached, and whether it is widely accepted or might need an improvement. Sometimes the monthly downloads drops within a month, and when it is clear that more downloads are being done, the statistics doesn’t improve. Is this something you would want to change or is it done that way on purpose for the consumption of Keyman and staff only?

I like this idea too. I just went to another keyboard yesterday which had “1 monthly download”, but I have no way of knowing how many were downloaded when the keyboard was first created or advertised.

1 Like

It’s tricky. We went with ‘monthly downloads’ because the download statistics are not particularly stable. This model gives users a signal as to what is currently popular, which is probably more helpful than a package which was popular in the past but is no longer.

All time stats have a number of limitations:

  1. The stats start in October 2019, so there’s a good decade of missing stats for many keyboards.(While we have some older stats in another database, it would be a lot of work to merge them)
  2. The stats do not account for renamed keyboards.
  3. Stats for versions prior to 14.0 do not account for mobile platforms (iOS, Android).

To make matters worse, while investigating this, I found that numerous events are being dropped so that the statistics are probably 10% of the actual. This is now opened as an issue to investigate at #297

1 Like

Righto. We are now tracking keyboard download stats ourselves rather than relying on Google Analytics event collection. The advantages here are that the stats are updated in real-time and will increment every time someone downloads a package following the normal URLs on keyman.com or in the apps (only for 14.0 onward for mobile apps).

I have surfaced the total downloads number on keyman.com/keyboards, e.g. Amharic keyboard

image

It’s important to note that the current values are a gross underestimate due to the collection issues I noted earlier. I am hoping that this should be reasonably stable, although we may need to tweak to deal with robots, etc, in the future. (note to self: probably should add a rel=nofollow to package links!)

1 Like

Nice work. “Monthly downloads” combined with “Total downloads” has resolved this issue.

As for this:

I think since the keyboards have to pass some tests, meet some standards and use a certain license (MIT License) before they are accepted into your repository, then you may not need to use “nofollow” since you (Keyman repository/staff/maintainers) have certified that the keyboard is OK. Or is it to tell Analytics to stop doing the work because you’re now doing it yourselves, etc?

The rel=nofollow stops web crawlers from visiting the link and artificially bumping up the statistics :slight_smile:

1 Like

Idea is full of information. It providing one suit for all work.

Hi @Marc

Keyboard download stats of Malar Malayalam keyboard and Malar Malayalam inscript keyboard are look as same in home page of respective keyboards. But in keyboard search result, it is different.



@Ramesh_Kunnappully thank you for the report. We are tracking this here: bug: keyboard home page may show wrong keyboard stats · Issue #358 · keymanapp/keyman.com · GitHub

1 Like

fix: keyboard page was returning incorrect statistics by mcdurdin · Pull Request #359 · keymanapp/keyman.com · GitHub should fix this

1 Like

Please reply to this topic if you need further assistance, otherwise it’ll be closed in three weeks.

This topic was automatically closed after 21 days. New replies are no longer allowed.