Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This doesn't work in this case.

I have 100 of clients whose analytics are useless, I can't block them on server side since they never visit the sites.

It's impossible to keep up creating filters to filter them out also on Google Analytics.

This technique is a new, has been going on for a month or so.



Google is definitely aware of this kind of abuse, and it's not too small to notice, too far into the long tail, etc.

The real problem here is that Analytics has that real-time view. If a spammer creates a test account and then tries to spam it, they can get real-time feedback on what works / what doesn't.

The solution is straightforward but not "easy": put the analytics frontend[1] on the same host that serves the rest of the application; use the same session auth and spam filtering that is already there.

[1] By "frontend" I mean the first step of the analytics data-gathering pipeline. And this part could be as simple as a new logging module that consumes log data in realtime, anonymizing it and aggregating it, then uploading it to one or more analytics services of your choice.

This solution sacrifices the ease-of-use that analytics currently enjoys. No more "just drop in this <script> tag."


This system already exists and is Measurement Protcol (https://developers.google.com/analytics/devguides/collection...) allowing you to send activity data via your webserver, so you won't need the javascript tool at all.

The problem is still there however as this is how the spammers send fake data. Essentially, even the server side API is still unauthenticated.


But could you get a new tracking ID and keep it a secret? Since it's now only server-side, and not client-side?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: