Hacker News Reader

Comment by throwaway3699 | Hacker News Reader

This is why I proxy GA visits directly through my server. Full accuracy but less privacy issues as my clients don't require JavaScript and I can anon the IP myself. I'm surprised more people aren't doing this.

View on HN

I'd rather use something like Plausible Analytics behind my own domain than go to extra effort just to use Google.

This is also blocked by many lists. All I want is accurate reporting, so there's no incentive to go with that over Google, especially if Google can keep our data safer than Plausible can.

> All I want is accurate reporting

That's the problem, accurate visitor tracking wasn't on the web design goals.

But if you want an independent track to verify your JS report, the server logs have almost an almost completely disjunct set of problems.

You already have that in /var/log.

It's not even close. Bot spam is > half of my logs sometimes.

And as a user I appreciate your efforts to do this in an ethical and privacy preserving manner.

Have you written on how to do this/followed a guide somewhere?

The Google Analytics Measurement Protocol documentation was used. We created a middleware which sends data to GA as a POST request (much like our regular logs middleware)

Newer version off ga tracking doesn't use that protocol. It uses an undocumented one

It's documented now.

https://developers.google.com/analytics/devguides/collection...

How do you do this? Doesn’t googles script load other scripts and post back directly to Google?

Did you write your own scripts to use your proxy URLs with the same API?

Ublock still blocks this

I think OP meant that the info coming to the server gets sent directly to GA. IP Address, etc.

I'm sure OP meant that. Proxy through a server != return a redirect to the client. And as mentioned elsewhere, they're writing directly to GA using a documented API; unless they are sending data from the client to the backend using a query and path that look exactly like GA's (which, why?), there is no way to know what client requests are logging data (and that's assuming they're specific client requests, rather than being logged as part of the actual functional interactions, using a session store, which if Ublock tried to heuristically detect and block, would block actual user facing functionality)

Only if it's DNS level (just a CNAME). Ublock can't detect it if it's really proxied through the server itself.

Yes it can. It blocks the request to your first-party domain based on path/query.

... and there are half a dozen ways to get around that too. You could proxy everything through a function that base64 encodes everything. It's an arms race.

Besides, I was talking about my server directly sending data to Google Analytics without JavaScript on the client side. GA has strong adherence to GDPR so there's no legal or privacy issues I can see with that.

This isn't detected automatically though, right? Someone would have to reverse engineer your setup and add it to the lists?

uBlock does detect this automatically, without reverse engineering your setup and adding it to their lists.

This assumes you self-host analytics.js and proxy GA API requests through your domain without changing path/query. If you manage to reverse engineer analytics.js and change the path/query AND proxy through your own domain, then this likely wouldn't be detected. But there's a chance that Google will make changes to analytics.js that aren't compatible with your reverse engineering it, and your setup breaks.

You're not thinking this through. Any request can be proxied. Ublock won't block GET requests for `index.html` or other assets, nor even random POSTs to `/detail` from button clicks and such

Just speaking from first-hand experience.

Reply on news.ycombinator.com