How does Google Analytics prevent fake data attacks against an entity's traffic?

Question

In order to register a "hit" on Google Analytics, the list of things required are:

1. Unique API key(s) for Google Analytics
   • Public: can be gotten from the embedded JavaScript files on the pages for tracking.
2. HTTP requests that seem to originate from the page in question.
   • Can be spoofed in a multitude of ways: which means detecting and putting a stop to it is hard enough to be not worth it.
3. JSON data representing traffic, in a schema that Google expects.

Stop me right here if I’m wrong with the list.

If I’m not, then it’s really easy to spoof traffic on a site and make someone’s Google Analytics look really good even if they’re not getting any traffic!

How, then, does Google prevent these attacks? Doesn’t it hurt the credibility of Analytics stats?

I’m interested in this because of another question I’m still struggling to formulate involving Alice, Bob, Mary and some private keys that somehow need to be safely public. I’m hoping that Google may have solved that problem by trying to address this issue. I’ll post a link here once I have that question up.

Answer 1

Ultimately separating real data from the fake is almost impossible, but in addition to the measures you listed Google employs blacklists. This problem is likely to never go away.

Review this question for more info. https://stackoverflow.com/questions/2418609/how-does-google-analytics-prevent-traffic-spoofing#2419115

Answer 2

As noted before, there is no real way of not allowing to send fake data. Yet, in case you have access to both servers (tracked website + tracking service), you can make it "bulletproof".

From the tracked website before displaying the page to the user, generate a random hash into his session and show the hash together with the session ID as plain JS variables, which would then be sent with the usual track object to the tracking service.

In turn, the tracking service, before writing the received object into the DB, should do an additional request back to the website with the session ID, asking what is the random hash currently in it? If the hash matches, it's a valid request and can be inserted into the DB.

The cons here is that analytics service is expected to have lots of requests and with this validation it will double them. This could also be avoided in case both services are located on the same server or have a shared directory where the session files are kept.

If this is not the case, to reduce the loading and time of the validation request, on the tracked website, create a very small .php file which would do nothing else but receiving the request with the session ID and random hash, opening the session file/storage and doing the validation. No DB connection or anything else should be needed for this purpose.

Update: Also, when generating and replacing for every page load a new random hash in the session, if the user will open more than one tab, only the last tab's hash will be valid. To solve this you could either reuse the same hash for a certain amount of time, or better, create a pool (list) of valid hashes in the session (i.e. 3-4 maximum) which will allow up to 3-4 tracked opened tabs in parallel.