4 ms·

I often have the same concern. What I ended up doing was issuing a token to each user, and verifying the token on the logging endpoint. That way, if someone dec

by pindi 14y ago

I often have the same concern. What I ended up doing was issuing a token to each user, and verifying the token on the logging endpoint. That way, if someone decided to fill the logs with spam, we can easily delete all the events from that token. From what I've seen, major analytics services seem to do nothing at all to prevent a client from pretending to be any user, so this kind of abuse is probably rare enough that it shouldn't be a big concern. Some basic rate limiting is always a good idea, though.

nivla 14y ago
But what is preventing a spammer who has made up his mind to reverse engineer your analytics code from faking the tokens? If its only about filtering, wouldn't it be easier and more effective to do them via ip-addresses? >so this kind of abuse is probably rare enough that it shouldn't be a big concern Yes I would agree too that its pretty rare since webmasters are more cautious around fishy looking sites. However, there were 2-3 instances I noticed someone spammed a referral into my Google Analytics data.
- pindi 14y ago
  The tokens are cryptographically signed with a shared secret between the main server and analytics server. So an attacker can't forge another user's token. IP addresses would be a good solution also, especially if you need to track anonymous users.
  - nivla 14y ago
    Ahh I see, thats a good trick, the use of cryptographic signatures din't crossed my mind.
chengyinliu 14y ago
Thank you for sharing your solution. I think per user token is good since we have captcha on registration. But we also want to something on non-logged-in pages/users. What can we do? Also, if we connect the data point to a certain token, does that count as non-anonymously tracking user?
- pindi 14y ago
  For anonymous users, generate a random token and store it in a cookie. Or you can use the IP address as nivla suggested. Yes, at with these techniques you're tracking users across requests. But that's the point of this kind of analytics, isn't it?

by pindi 14y ago

nivla 14y ago

But what is preventing a spammer who has made up his mind to reverse engineer your analytics code from faking the tokens? If its only about filtering, wouldn't it be easier and more effective to do them via ip-addresses? >so this kind of abuse is probably rare enough that it shouldn't be a big concern Yes I would agree too that its pretty rare since webmasters are more cautious around fishy looking sites. However, there were 2-3 instances I noticed someone spammed a referral into my Google Analytics data.

pindi 14y ago
The tokens are cryptographically signed with a shared secret between the main server and analytics server. So an attacker can't forge another user's token. IP addresses would be a good solution also, especially if you need to track anonymous users.
- nivla 14y ago
  Ahh I see, thats a good trick, the use of cryptographic signatures din't crossed my mind.

chengyinliu 14y ago

Thank you for sharing your solution. I think per user token is good since we have captcha on registration. But we also want to something on non-logged-in pages/users. What can we do? Also, if we connect the data point to a certain token, does that count as non-anonymously tracking user?

pindi 14y ago
For anonymous users, generate a random token and store it in a cookie. Or you can use the IP address as nivla suggested. Yes, at with these techniques you're tracking users across requests. But that's the point of this kind of analytics, isn't it?