It's not likely to change so I'm just yelling at a cloud right now, but website stats is one of the biggest losses in modern web dev so it bugs me. Maybe more than it should. For what it's worth, Counter looks to be a much better option than Google-"here's 200KB of glacially slow JS because screw users"-Tag-Manager.
That seems a bit overly dramatic. If you look at your log files these days you'll see that a high percentage of it is just scrapers, bots, scripts trying to access wp-admin etc.
Collecting this information somewhere else (instrumented backend, client-side script) makes a lot more sense now where you can filter out noise more easily. There's also very light client-side scripts like https://plausible.io which are a nice trade-off between privacy and useful information while not being too heavy.
That being said log files are not the ultimate solutions as non-techies would have more difficulties handling with them.
So I actually agree the current situation is suboptimal. Spinning this thought more I see "Honest" analytics players being pressured to circumvent the blockers to stay relevant but ultimately the blockers have the upper hand and its a game I don't want to play so yeahhh....
A consensus between blockers and web analytics providers that tracking really just the simplest metrics is important for e.G. a yoga studio with its website might actually be difficult because... ...users might just choose the most aggressive blockers because more is always better.
I am eager to see how it will play out. But generally it all goes slow.
This isn't entirely true. Blockers only work if you use a JavaScript trigger which isn't necessary for a self-hosted solution.
If you use something like Cloudflare you can also get some of that serverside logging back.
And netlify and Vercel both have first class analytics features.
Interesting, I did not know that narrative. But what I can tell from subjective experience is that bots is'nt so much a problem with client side analytics. counter.dev filters them out by not logging very short page views by the way. For me the bigger challenge with client side analytics is not being able to track clients which are using a tracking blocker. Which I guess is the end users right to use (I even use uBlock origin myself). But if you start missing roughly 50% of page visits it starts getting an issue for web site owners. The data does not need to be detailed, just accurate enough.
Web analytics on hosters... yeah if they fit your use case then great, but for me that is vendor lock in and I would avoid it if possible and web analytics is more or less a topic for itself that I'd prefer to leave with a specialised solution. But obviously I am biased haha.
I think the biggest challenge we have today is that building on SaaS and huge dependency charts is very attractive to somebody eager to get an idea off the ground. It has a typically low barrier to entry (as long as you have a PayPal account) and you don’t have to deal with “low level stuff”. Unfortunately it typically also comes with vendor lock in issues but when you realise that you are already way too far down the road.
The fun thing is, anybody with a little bit of guy and docker know how can have a better developer experience in hosting their web projects on a VM so maybe this is an issue of fundamentals?
A little nostalgia for a time when things were actually better for the end user is exactly where my post is coming from. Going back to analysing traffic using server logs without stuffing more JS into every website seems reasonable to me.
> Counting unique users is achieved with a combination of relying on sessionStorage facilities, the browser's cache mechanism and inspecting the referrer. Using this technique considerably reduces the complexity and load on the server while improving data privacy at the cost of knowing less about users. We can't and don't want to be able to connect single page views to an user identity.
"Hey, I got an idea how we get rid of those pesky cookie banners, let's drop the cookies, no.. wait.. hear me out. We store the id... in localstorage! Brilliant!" POW Confetti.
It's cookies.
edit: it's in the https://v.firebog.net/hosts/AdguardDNS.txt adlist.
(not my website)
cut the js beacon middle man. ...I mean, I myself block your beacons and didn't even know before looking just now.
-- someone who just looked at recent vps prices for a small personal static site and went with gitlab "hosting" .
That being said you can technically self host and I am happy to answer questions at hey@counter.dev . Is just that this solution is not designed to be self hosted and with another web analytics solution the self hosting experience could be more streamlined.
One thing that for me would actually make sense is having a conventional backend that plug and plays with the awesome counter.dev UI - then the "only" codebase change would be to whitelabel the UI. But yeah, that might not happen anytime soon.
Show HN: Counter – Simple and Free Web Analytics - https://news.ycombinator.com/item?id=26379569 - March 2021 (77 comments)
Edit: reposts are fine after a year or so: https://news.ycombinator.com/newsfaq.html. Lists of "related" links are just for curiosity.
With counter.dev you have some metrics that you do not have with GoAccess like for example device type, the country of the users and some other minor things. But the biggest advantage is that it is easier to integrate. There are a lot of people with something like a Wordpress site for their restaurant that email me asking how to add counter.dev's tracking script into their site. Many people don't have access to their log files and I think it would be impractical for them to literally compile their analytics tool.
So if you are happy with GoAccess and have it set up you don't need to change.
But if you want to try counter.dev you get your tracking script after just registering with a username and a password. Then put the tracking script in your site and that's it.
How does Counter compare? I couldn’t grok that from the website or GitHub repo
