-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find a permanent solution for analytics #10
Comments
I was literally just looking into this, because I want this functionality for my own personal reasons as well, so if I find/make a solution I will share. Useful resources on this topic:
|
So Jonah was the one who suggested the first one to me, and based on that, here seems to be the basic order of operations:
Regarding being privacy respecting, I think this is a sample of what it can do: https://caddyserver.com/docs/metrics#caddys-metrics |
If you go the Grafana route you'll end up with a dashboard like this: https://grafana.com/grafana/dashboards/13460-caddy/ (this is a pre-made dashboard for Caddy, but you could also make your own with any Prometheus queries you want) |
That doesn't seem as obvious and user-friendly to a non-techy. Even I'm kind of struggling to figure out exactly what I'm looking at. Not criticizing you, I appreciate the input, more just thinking aloud that this seems like the less desirable option for my use-case. |
Yeah, that is kind of why I thought you should see that beforehand. I guess the main issue with option 1 in this issue is that Caddy metrics really only captures numerical values (i.e. number of requests, how long they take, etc.) and not things like IP address, web browser, country, etc. that a typical web analytics product might. So in the example above, the only graph which is probably relevant to you is the first one, which may or may not be enough data for your use-case. |
I appreciate the heads-up. For the use case I have in mind, raw numbers are probably enough - assuming it's easy enough to make sense of - but certainly not ideal. Plausible is more than ideal, but we may have to face some serious questions about sustainability in the long run that may force us is into other less-than-ideal options like non-public server-side stats. |
Also, having spent an hour looking at Safing's solution and at Caddy's module code, I think that option 2 is 100% possible, but unfortunately I don't think I'm good enough at Go to create a Caddy middleware module that does this (and mainly it's not a priority for my personal projects to spend any more time on myself). But, if you could find or hire someone who does know Go, I think that adapting Safing's existing Go code to Caddy or just creating a Plausible middleware module for Caddy from scratch should be a pretty trivial task for them. In that case, you'd basically have server-side analytics which feed directly into the Plausible dashboard, which I think we both agree is a very ideal interface for public stat sharing :) |
As an update, it seems like changing the domain name hasn't really fixed the issue. The numbers should be skyrocketing by comparison. I wonder if people are using other adblockers that are more effective or something. Server-side seems like an unavoidable solution in the long run. |
So the options right now are:
I think the fix for now could be the second one + unreliable plausible client side statistics, while the first one is not available. To me it seems doable to make the middleware, but it is something that will take time on my end (because learning a new language, learning CaddyModules, etc.) |
I'm not opposed to hiring a developer on a short-term basis to build this, so long as they can also provide support (initial troubleshooting + maybe a few years of security updates if needed) and, of course, assuming I can afford their rate. This is something I'm expecting would be an investment in the long-run. |
Welp. I ended up coding a solution to this for privacyguides.org on my own after all: https://github.com/jonaharagon/caddy-umami The only problem (for you) is that I ended up going with Umami instead of Plausible, mostly just because it's available from Pikapods, partly because it is rather nice looking. So if you folks decide to switch to Umami I can write up a guide on how to get it installed quick on your site too, otherwise yeah I'm very confident you'll be able to figure out your own custom solution, it was relatively easy to do. Umami Demo: https://stats.privacyguides.net/share/nVWjyd2QfgOPBhMF/www.privacyguides.org |
Yeah those numbers look pretty accurate for PG lol Is there any reason I may not want to use umami? I mean, it looks nearly identical (it actually collects even more info, but still nothing I would consider overly invasive), it can also be self-hosted, etc. Are there any drawbacks apart from less brand recognition compared to Plausible? |
Nothing comes to mind for me. It might collect more data than Plausible if you're using the JavaScript code (just screen resolution?), but with this server side approach we're taking the server is limited in what data it can collect (the server can't ask the browser what its screen resolution is), so the data that will be collected in either case is identical. |
Well I say it seems to collect more data based on showing - for example - OS (down to which version) but like I said, I don't think that's fingerprinting users, nor is tracking them from site to site. So it's really not a big deal. More of a note than a complain tor anything. Yeah this seems like a great solution. Thanks for your work and for sharing. I'll see about how to implement this. |
Damn Chrome OS, sounds accurate and totally not like a spoofed user agent 😂 |
Methinks you are correct lmao |
So for actually deploying this, I assume I use this documentation to install the public facing side (eg "stats.thenewoil.org") and then what? |
On the
|
I never expected to see the day when Jonah would be recommending a bare metal install instead of docker :P |
I mean, I would definitely use Docker if you're up for it 😉 |
I'm down for whatever. It seemed to work fine with Plausible, but I'm not sure how to edit env variables. Rik sent me a config file on Signal that seemed to work until I tried to bring in Caddy for TLS and then I start getting issues. |
Not sure why it'd be different from Plausible, what's the config? |
Adblockers like uBlock that make use of EasyList to block the self-hosted Plausible analytics. The (publicily available) analytics are helpful to know how much effort should be spent into the website as a whole.
For now a workaround has been used by naming the analytics domain
plausible.thenewoil.org
, but this will likely be blocked later on. A reliable way to do analytics that can't be blocked (and in our case must respect privacy) is server-side analytics. A few options are on the table:aejklg.thenewoil.org
. It could be automated, but that would be hard and janky. I advice against it, but it is technically possible.The text was updated successfully, but these errors were encountered: