"I don't know, how would you do it?"
Capture and process HTTP headers on-the-fly. Either at the server level or the (web) framework level. If done efficiently, it outperforms JavaScript.
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.