Show HN: Counter – Simple and free web analytics
counter.dev
counter.dev
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.
Capture and process HTTP headers on-the-fly. Either at the server level or the (web) framework level. If done efficiently, it outperforms JavaScript.
The main hurdle is that every code base would need a different kind of integration. Or with a proxy you loose overall performance. And complexity would also be increased. But as said more accurate tracking could be possible. Has all pros and cons :-)
These are the tradeoffs as I see them and based on my experience building:
In a self-hosted configuration, advanced analytics can be captured without JavaScript. It's unblockable, transparent, and incredibly fast. This is a stack specific solution.
In a cloud configuration, it requires a JavaScript trigger. With JavaScript, each capture (on a dev machine) takes 70ms including storage (cloud db). Performance is good but blocking is now possible. This is a stack agnostic solution.
One of the above suits me as a user; the other as an entrepreneur.
> One of the above suits me as a user; [...]
That might be true. But as roughly said let's say that for over 99% of people, just reading the term "tracking script" already switches off their brain. If you start with "code base specific middleware addition" or "deploy your own tracking http proxy" or something like this you only have knowledgeable techies which well, to be fair could be fair to a more specialised product.
> [...] the other as an entrepreneur.
With hat thinking for me it wouldn't make much sense to offer and maintain the service for basically free since some years already. At least I can cover the hosting costs. So yes, but also a little bit no :-)
Agreed.
I think the problem facing analytics is that the ideal solution and ideal business require fundamentally different products.
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.
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.
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?
Instead I sent nice HTML reports generated by GoAccess from access logs.
Highly recommend.
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" .
(not my website)
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.
edit: it's in the https://v.firebog.net/hosts/AdguardDNS.txt adlist.
counter.dev is in the https://v.firebog.net/hosts/AdguardDNS.txt adlist.
It seems someone else's mention of adlists not liking the word 'counter' is true. There's almost 300 domains with 'counter' in it just in that list.
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.
How does Counter compare? I couldn’t grok that from the website or GitHub repo
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.
"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.
I can't try myself right now. But last time I checked it's not at all that easy. What am I missing?
With an iframe. Although Safari already has protections in place against this scenario: https://webkit.org/tracking-prevention/#partitioned-third-pa...
please see on my upper response a more technical elaboration on how it works. It is not the same as cookies.
Cheers
Self-hosted solutions where only the site I visit tracks me is not a problem even for me as a privacy extremist. But calling it "no cookies" and putting the id in localstorage is misleading or misunderstanding the problem people have with cookies in the first place.
Don't get me wrong I like the effort and was looking for something similar before just implementing my own solution with regular nginx logs. But this is a space where trust is important.
var id = document.currentScript.getAttribute("data-id");
new URLSearchParams({
id: id,
})
IIRC, GDPR doesn't really care about cookies, but about storing information on the user's machine. sessionStorage would still fall under this classification. So it doesn't really matter if they are different or not.
That said, it does seem like Counter does not use user ids.
- the script is loaded
- check if sessionStorage has the '_swa' item
- if no, then hit the /track endpoint (this I assume is to count unique visitors). Then set the '_swa' item.
- hit the /trackpage endpoint (this one just increases every time)
- On next page load, the _swa item will be set in the sessionStorage, so /track will not be hit again.
That's about it from what I can see.
I think the main point is that the server doesn't do any tracking itself, it just has a number that increases when you hit /track or /trackpage.
I personally would rather have the pages I visit use a self-hosted solution gather everything I do, instead of a third-party getting little data from many sites I use. If this script is used across many sites it can be checked server-side against my IP to get my usage. I can never verify what logs they keep and for how long.
That's the problem people tend to care about, not the cookies themselves.
No! There are a few rudimentary mechanisms on top of each other if one of them fails as you described. The /track endpoint sets up http caching. So if sessionStorage fails, you still have that. Then there is also inspecting document.referrer. If it is the page you are already on, then it's definitely not a unique visit.
I get regular user feedbacks for all kind of stuff and unique visits being counted double was not reported once since now.
> (or why not just a cookie)
Because cookies are considered "bad". But technically basically just saving a boolean value on the cookie would not be worse from a privacy perspective than using sessionStorage for a boolean value.
> I personally would rather have the pages I visit use a self-hosted solution gather everything I do, instead of a third-party getting little data from many sites I use. If this script is used across many sites it can be checked server-side against my IP to get my usage. I can never verify what logs they keep and for how long.
That is a general problem with externally hosted services. You can audit the source code (https://github.com/ihucos/counter.dev) but there is not way to verify that my deployment is as stated. I heard a podcast once that web hosters could guarantee that a deployment is in a specific way and contains a specific code base revision. But such solutions unfortunately do not exist. If you really want to be sure self hosting is the way to go (but somewhat cumbersome)
No! To see the complete tracking script in all glory check it out here: https://github.com/ihucos/counter.dev/blob/master/docs/scrip...
The relevant part is here:
13| sessionStorage.setItem("_swa", "1");
With that the script marked that the visit was tracked and no further http requests to track the unique view are send.
> 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.