5 ms·

You should use Server-Side tracking. There is no reason to design your website in a way that makes your legitimate analysis use cases depend on Client-Side com

You should use Server-Side tracking. 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.

XCSme 6y ago
What if your site is a SPA? You would not know, for example, the time spent on site, what pages are visited, where exactly users leave, if there are client-side errors, right?
- wlll 6y ago
  Then now you have two problems ;) 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.
- acdha 6y ago
  If you're using a SPA you need to build that instrumentation in to match the native behaviour, along with robust error handling using something like https://github.com/getsentry/sentry/ https://github.com/getsentry/sentry/ so you can tell when your code is broken client-side where you would otherwise not have visibility. 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.
  - XCSme 6y ago
    You can self-host sentry?
    - acdha 6y ago
      Yes – it's pretty easy to run the open source app in your favorite container runtime: https://hub.docker.com/_/sentry/ https://hub.docker.com/_/sentry/
      - XCSme 6y ago
        Wow, I didn't know that. I remember using it at my last company and we always kept receiving quota warnings, and their higher plans were really expensive.
- igneo676 6y ago
  Use a hybrid approach: 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
snowwrestler 6y ago
Server-side tracking is what everyone started off with. There is a reason client-side analytics won in the marketplace. They just have a better balance of advantages to disadvantages.
- bzb4 6y ago
  Client side analytics won because setting them up involves copying and pasting some code into your HTML code.
- alexchamberlain 6y ago
  What are those advantages and disadvantages?
  - aeyes 6y ago
    Try analyzing a TB of logs per day when all you really want is aggregated statistics. Or really any non-trivial amount of data, even 1GB is a problem. 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.
    - giantrobot 6y ago
      Most websites aren't Google or Facebook so they're not going to generate terabytes of server logs. A million DAU will generate at most gigabytes of log activity in a day. It's pretty easy to tune logs to be more compact and they're highly compressible. Most sites don't have anywhere close to a million DAU. If you can't handle processing a gigabyte of data it seems like there's fundamental problems with your development team. 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.
LunaSea 6y ago
Some things can't be measured on the server side. % of a video watched for example would be broken on the server side due to player buffering.
- choeger 6y ago
  You cannot reliably measure that on the client-side, either. But if you assume a "normal" use case anyways, you could easily track the percentage of the video stream requested by a client. That should approximate percentage watched. Of course you need to have certain control over your infrastructure for the matter. If you outsourced everything to a CDN and thus have no clue what happens to your videos, well, you probably weren't that interested in the data in the first place, weren't you?
- inetknght 6y ago
  > % of a video watched 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?
- JetSpiegel 6y ago
  HLS is just chunks of video in different files, track exactly what files are actually served.
NetToolKit 6y ago
> If Server-Side tracking looks too complex for you, you might want to reevaluate the balance of technical knowledge in your enterprise. 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 https://www.nettoolkit.com/gatekeeper/about

XCSme 6y ago

What if your site is a SPA? You would not know, for example, the time spent on site, what pages are visited, where exactly users leave, if there are client-side errors, right?

wlll 6y ago
Then now you have two problems ;) 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.
acdha 6y ago
If you're using a SPA you need to build that instrumentation in to match the native behaviour, along with robust error handling using something like https://github.com/getsentry/sentry/ https://github.com/getsentry/sentry/ so you can tell when your code is broken client-side where you would otherwise not have visibility. 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.
- XCSme 6y ago
  You can self-host sentry?
  - acdha 6y ago
    Yes – it's pretty easy to run the open source app in your favorite container runtime: https://hub.docker.com/_/sentry/ https://hub.docker.com/_/sentry/
    - XCSme 6y ago
      Wow, I didn't know that. I remember using it at my last company and we always kept receiving quota warnings, and their higher plans were really expensive.
igneo676 6y ago
Use a hybrid approach: 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

snowwrestler 6y ago

Server-side tracking is what everyone started off with. There is a reason client-side analytics won in the marketplace. They just have a better balance of advantages to disadvantages.

bzb4 6y ago
Client side analytics won because setting them up involves copying and pasting some code into your HTML code.
alexchamberlain 6y ago
What are those advantages and disadvantages?
- aeyes 6y ago
  Try analyzing a TB of logs per day when all you really want is aggregated statistics. Or really any non-trivial amount of data, even 1GB is a problem. 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.
  - giantrobot 6y ago
    Most websites aren't Google or Facebook so they're not going to generate terabytes of server logs. A million DAU will generate at most gigabytes of log activity in a day. It's pretty easy to tune logs to be more compact and they're highly compressible. Most sites don't have anywhere close to a million DAU. If you can't handle processing a gigabyte of data it seems like there's fundamental problems with your development team. 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.

LunaSea 6y ago

Some things can't be measured on the server side. % of a video watched for example would be broken on the server side due to player buffering.

choeger 6y ago
You cannot reliably measure that on the client-side, either. But if you assume a "normal" use case anyways, you could easily track the percentage of the video stream requested by a client. That should approximate percentage watched. Of course you need to have certain control over your infrastructure for the matter. If you outsourced everything to a CDN and thus have no clue what happens to your videos, well, you probably weren't that interested in the data in the first place, weren't you?
inetknght 6y ago
> % of a video watched 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?
JetSpiegel 6y ago
HLS is just chunks of video in different files, track exactly what files are actually served.

NetToolKit 6y ago

> If Server-Side tracking looks too complex for you, you might want to reevaluate the balance of technical knowledge in your enterprise. 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 https://www.nettoolkit.com/gatekeeper/about