Yep, I believe technically you can get better results with such an approach. It's just much more hard to do and the tooling for this approach is not as mature as client side tracking.
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 :-)
I've built this solution from scratch and am currently pairing it with a custom/prototype OODB.
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.
I think mostly we are actually on the same page. One thing I would add in is that starting the whole web analytics endeavour from scratch needs a lot of work, testing and iterations. I am actually thinking that it would make sense for counter.dev to offer an API so that you can use that as a backend middleware or in some other way.
> 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 :-)
Capture and process HTTP headers on-the-fly. Either at the server level or the (web) framework level. If done efficiently, it outperforms JavaScript.