Ask HN: What web analytics strategy do you use in the era of blocked cookies/JS? | Hacker News Reader

Ask HN: What web analytics strategy do you use in the era of blocked cookies/JS?

2 pointstweetle_beetle4 comments

I'm thinking about how to manage best practice consent with web analytics. This is specifically for sites without hardcore data-driven conversion optimisation, etc., where absolute accuracy is not crucial.

My assumptions are that:

- client-side will under report, because users opt out or block JS and cookies

- server-side will over report, because of bots, crawlers, etc.

I was thinking that combining both in a dashboard can give clients a sense that the reality will be somewhere in the middle. Obviously there's a limit to how many metrics can be measured by both systems to enable this comparison, but I'm thinking the basics should be possible. Are my assumptions about over- and under-reporting right?

Does anyone do anything like this and how do you do it?

And are there any metrics that help us understand how much traffic is being missed by, for example, Google Analytics these days? Many clients still assume that it gives a 100% gospel representation.

it's a hard problem to crack. hence why there aren't many solutions/strategies to work around it. hell, tag management services like Google are on easy privacy lists used by most third party blocking software.

if analytics tracking is imperative to measurement of your site and there's little to no profiling (lean toward no profiling) you can typically get your endpoints/domains removed from blacklists by simply submitting a pr with your reasoning. if you have examples even better. if you're profiling a user and need real-time engagements to sell impressions/advertising to that user based on site behavior then i think you're just SOL.

a roundabout solution could be to store events on the client and attach them to some user entity. maybe some queue of action entities of time, type, and any sort of payload. at the end of the session or maybe when you're updating the user entity, you can process those queued events as you normally would.

idk if these are great solutions, but hope it sparks some ideas for you and your team.

I think you'll do pretty well with a Javascript-based solution IF it communicates to a back end that is located on your own domain. That is, something basically like Google Analytics but self-hosted.

So that would be something like Plausible, or Matomo, for the client side, but ignoring the server side becuase they're good enough as they are when set up cookie-less?

Third party cookies are set to go away, I don’t know how bad the situation is for first party cookies and local storage.

Reply on news.ycombinator.com