This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
Hey everyone!
I’ve been using F-Droid for a while now and love it. Quick idea: how about we add a “Most Popular Apps” tab? The “New Apps” tab is cool for finding fresh projects, but they can often be buggy or incomplete.
A “Most Popular Apps” section would be a great way to quickly find solid open source apps that lots of people use and trust. Plus, it would help newbies like me find reliable open source alternatives to common apps.
Sorry if this has been brought up before, I couldn’t find a recent thread. What do you all think?
2 Likes
We have gotten community agreement to provide some metrics, but only without compromising at all on privacy. That’s not that easy to implement, so we currently only have limited metrics:
Also, it is possible for anyone to generate certain kinds of metrics based on publicly available data. For example, each app could be ranked by “update frequency” based on fdroiddata YAML files. You can find the publicly available data here:
3 Likes
I wrote a bunch of scripts here (Thore Göbel / F-Droid Metrics · GitLab) to:
- Pull the data from F-Droid Metrics
- For a hardcoded list of app ids I am interested in, compute the download numbers over time
- Plot the data (see the graphs/ directory)
The download numbers are computed by summing up the number of hits on the APK files:
- across the three reverse proxies http01, http02, http03, and
- across all apks that are hit.
This seems to be like a “good enough” estimate to me. It only includes the requests that actually download APKs (as opposed to just browsing which would e.g. cause screenshot downloads).
I ignore the origin server, and only count the reverse proxies. Mirrors are not counted (due to lack of data afaik).
2 Likes
awesome!
I put up a small sampling of 151 apps here: Fdroid Stats - DivestOS Mobile
3 Likes
I plotted all of them, there are now 1072 graphs on the page
edit:
here is the patch to add the average to file name:
Summary
diff --git a/plot_data.py b/plot_data.py
index a221e2d..bd36a9b 100755
--- a/plot_data.py
+++ b/plot_data.py
@@ -19,12 +19,16 @@ for app in apps:
x_values = list(app_downloads.keys())
y_values = list(app_downloads.values())
+ average = 0
+ averageCount = 0
plt.figure(figsize=(10, 6))
plt.plot(x_values, y_values, marker="o", linestyle="-")
for i, (x, y) in enumerate(zip(x_values, y_values)):
plt.annotate(str(y), xy=(x, y), xytext=(x, y), ha="center")
+ average += y
+ averageCount += 1
# Rotate x-axis labels for better readability
plt.xticks(rotation=45)
@@ -41,6 +45,8 @@ for app in apps:
ticker.FuncFormatter(lambda x, p: format(int(x), ","))
)
- png_file = f"graphs/{app}.png"
+ averageResult = round(average / averageCount)
+
+ png_file = f"graphs/{averageResult}-{app}.png"
print(f"saving {png_file}")
plt.savefig(png_file)
1 Like
Anyone have an idea why Termux is so off the charts?
My best guess is that someone is using Termux in an automated setting, to run tests in a CI or something.
Donno what we would find server-side, it is the same data. The webservers don’t log user agent, if I remember correctly. Our goal with the metrics is that all the metrics are safe to release publicly, and we write to disk a little as possible everywhere. So there would just be data about uncommon things, since there has to be at least 100 occurances for something to make it to the weekly metrics reports. Also, the server logs are only kept for a couple of weeks.
One thing that this data can clearly tell us is relative relationships. Download counts will always be misleading, since we do not have data from the mirrors, which are the majority of the downloads. I recommend normalizing the numbers to a 0-to-1 floating range, with 1 being the max downloads of any app in that weekly. Or it could be max in all time. Then the graphs should probably be logarithmic, since most will be close to 0. This will show relative activity and trends, like how quickly updates are downloaded.
4 Likes
It seems like there’s a pretty decent middle ground. I’m thinking, something like generating a huge number during the install, and then sharing that with the package manager. The number means absolutely nothing.Then, in a couple of weeks or whatever time you want, the client would reach back out to the server and say “hey I have this big number for you!” and at that point then you would have an idea that the program was installed and being used. that’s about as anonymous as I think is it possible to get.
Now, I’m confident that it would be much easier to be able to aggregate some other further analytics beyond just the number, but at that point things start to get a little sketch. I think that some people (well,me) would probably allow information more in-depth analysis, but sure many people do not.
I’m the weird guy that generally flips on telemetry I’m software; the important part is that it’s often off by default, and any project that gives me the actual choice, in or out. The flip side is Microsoft, who spies on us at an amazing rate, and we can’t turn it off.
you’ve read Managing apps in a decentralized way | F-Droid - Free and Open Source Android App Repository yet?
(っ◔◡◔)っ 
FRESH STATS Fdroid Stats - DivestOS Mobile
4 Likes
Is this page updated automatically?
No, as it’s running a script on their server.
(っ◔◡◔)っ FRESH STATS Fdroid Stats - DivestOS Mobile
also made the graphs bigger so they aren’t squished
3 Likes
I see the downloading of F-droid doubled in the middle of June. I wonder what caused that?
For all apps, the spikes correlate with a new version being released. Then all the people who have the app installed will download the new APK.
E.g. for F-Droid Client v1.20.0 was marked as suggested in June.
1 Like