There is no reason to design your website in a way that makes your legitimate analysis use cases depend on Client-Side computations.
If Server-Side tracking looks too complex for you, you might want to reevaluate the balance of technical knowledge in your enterprise.
If you want to know click paths you'll need additional data in your logs.
If you want to know how much time the average user spent reading an article on your blog, you are probably out of luck using logs.
I don't know how to help you if you can't look at log time stamps and figure out click paths for users. It was a solved problem twenty years ago.
It really doesn't matter how long it took someone to read and article on a blog. They either saw your ads or clicked affiliate links or they didn't. It doesn't really matter if they finished an article or bounced right off the page. It doesn't matter if they took ten minutes or twenty minutes to read an article. You don't know if their kid interrupted them half way through or if they're just a slow reader.
That kind of shit is just meaningless made up metrics. It's the Gish gallop of web advertising. Throw a wall of bullshit metrics at site owners or advertisers to justify them paying for the privilege of listening to that bullshit.
You’re making a completely unfair comparison here. Client-side analytics is performing aggregation as it goes; server-side analytics can do just the same, and serious packages in that space do do that. As an example that readily springs to mind, you can feed server logs into Matomo and use it just as effectively as when you feed client logs into it via matomo.js.
On click paths, they’re largely just an artefact of aggregation, so long as you can track individual users (which you admittedly won’t get out of the box in server logs, and perhaps that’s what you were referring to, but you can definitely make it happen). Multiple tabs thwarts doing the “navigated from page A to page B” form of path tracking correctly purely server side, but that’s not a realistic form anyway and isn’t what you’re likely to use; rather you use “page A was loaded, then page B was loaded” and just guess paths to be adjacent loads, which is perfectly compatible with server side analysis.
How much time, yeah, that’s one that you can’t do any sort of good judgement of server-side. Not that client-side tracking is particularly excellent at it. All up though I suspect that so long as your bounce rate isn’t too high you’ll get decent enough figures from reckoning the time until the next page load and eliminating statistical outliers. If bounces are too high the figures could be misleading because bounces are likely to behave differently. But people often put far too much effort into trying to track everything, where it’s commonly quite sufficient to take a smaller sample and extrapolate to the whole.
One disadvantage is that if your visitor/customer has javascript turned off, you get no data. This was a concern in the early days of client-side analytics, but not really any more.
A more modern disadvantage is that ad blockers might prevent your analytics script from running. However, this is only a problem for client-side analytics packages that are hosted by ad companies, like Google Analytics. It's not a problem with the concept of client-side analytics in general.
EDIT to add:
Another advantage is that only measuring things in the browser makes it a lot easier to exclude non-browser traffic like bots and spiders from your reports.
That's also a disadvantage because you can miss server-only events like "hot-linked" images or PDF downloads straight from Google. On balance, though, we care a lot less today about hot-linked files than we care about excluding automated traffic.
And in my experience, culturally, client-side packages were a huge help in getting management off of pointless vanity metrics like "hit counts" and caring more about human metrics like visits and time.
Counting the size of the executed JavaScript, because that’s what matters more than the compressed transfer size:
ga.js is 45KB, matomo.js is something like 50KB. The “new breed” of trackers are currently commonly 2–5KB (though generally if they were written more carefully they’d be well under 1KB), but they’re sure to continue growing because such is the nature of code.
By using client-side tracking on a different host name, you’re making the browser establish a new HTTPS connection—which can happen in the background so long as you do it properly, so it’s not of itself a serious performance issue—and parse and execute probably 50KB of JavaScript, which blocks the main thread while executing. On a substantial fraction of the devices your site will be running on, that’ll block for more than a hundred milliseconds (to say nothing of the couple of hundred more of CPU time that parsing took, which wasn’t blocking, but was taking away from other things it could be spent on), and on older and slower devices it’ll be adding several hundred milliseconds.
Seriously, parsing and executing JavaScript is slower than you realise. If your site uses JavaScript of your own, using just one type of client-side analytics is probably slowing useful page load down by 0.1–0.5s.
Shameless self-plug: if server-side analytics is too complicated for you, consider using the tool that we just launched to help with that (other functionality gets included as well): https://www.nettoolkit.com/gatekeeper/about
I guess your options here are, do collect metrics in JS and hope that whatever the reason that 20% of visitors don't show up in Google analytics isn't preventing them from using your site.
This is much less likely to be blocked if you self-host it — breaking requests to your server will break the app, whereas blocking common cross-site tracking services is popular because there are few drawbacks for the user.
1. Server side analytics
2. Client side analytics for information akin to what you're asking that Server side misses
3. Crash analytics for client side errors
As mentioned though, you're only getting partial info from some of those options. It also gives you a chance to decide which of these you _really_ need and hopefully eliminate anything you don't
% of a video watched for example would be broken on the server side due to player buffering.
I would consider that to be private information regardless of the reason. Why should eg Youtube know where I stopped in the video?
> would be broken on the server side due to player buffering.
Would it, really?
You don't think that you can tie together "this much of video was buffered and _possibly_ displayed" is useful information?
You don't think that "60 seconds of a 10 minute video was buffered and _possibly displayed_, and another 30 seconds of buffer was requested every 30 seconds for 5 minutes" is useful information?
You don't think that you can determine that the user stopped watching the video after between four-and-a-half to five-and-a-half minutes of the video had played?