Hacker News Reader

Comment by jorgeortiz85 | Hacker News Reader

I thought the whole point of Quantcast is that they can directly measure traffic instead of trying to guess. They don't even charge for it: http://www.quantcast.com/info/publisher-overview

View on HN

Which is fine, but if you have to do that for all the traffic analysis firms you add lots of JavaScript beacons to your page, slowing it down a lot.

They need to start working with companies like Google to use Analytics as a clearing house.

Then you get issues with what and how people are instrumenting. For example, if you instrument a carrousel you'll get a lot of page "loads" which don't necessarily correspond to page loads or ad impressions.

What is most interesting is to see the stats difference when you remove their tracking code from your "quantified" site.

I decided with my business to consolidate on google analytics, so I removed their code. It resulted in a HUGE drop in their traffic reports - about 20%. We went from 440K of unique visitors to 305K just after the changes, and google analytics shows (and our revenue shows) the exact opposite.

quantcast tracking code is nice, small and fast.

By comparison, google tracking code is unfortunately massive. It sets a ton of cookies, which are then sent with every single request to your server. Wasting bandwidth. It's worse if you have it on subdomains, since then it'll set even more cookies, and send even more crap to your server every single request.

For a website with a large number of reloads, or ajax or comet, this can be a complete killer.

Quantcast has no asyncronous tracking. If their servers are running slow at all, their javascript will block your site from loading, even if you have it at the bottom.

I know this because it happened to us. We contacted them about it but they have no solution,they don't seem to think it's a problem since "most of the time" their servers are up and quite fast. Marketing requires the tracking, so our solution is to host their javascript on our server and run a cron nightly to redownload the code from their servers in the hopes that we'll never get so far behind that the tracking stops working. So far, so good.

Google, on the other hand, offers an asyncronous, non-blocking solution. Much better.

async tracking helps if the size of the download is large. In that case, a small stub of js is loaded, execution continues, and the large payload is downloaded async.

But the tracking code is small. It's not going to make much difference at all IMHO (And anecdotally in my experience).

Async vs sync, you're still going to have a DNS lookup, and an initial GET unless it's cached. Both can block your site from loading...

Google Analytics doesn't load any stubs for async tracking, it inlines an array of "events to send" and then loads the entire GA script asynchronously. Once it's done, it runs through the list of things to track.

If you let them, they can directly measure the traffic of your website. If you sign up for their service, Quantcast's numbers will be very close to your own Google Analytics.

But, if you don't sign up, they'll still "measure" your traffic and come up with results that are no better than the other web traffic rankers. I don't know why anybody takes sites like these seriously anymore. Everybody I've met who had a website with decent traffic has said that these sites are always way off. I'd imagine that Alexa's main reason for reporting a ridiculous statistic like % of global/country traffic is that it makes it harder for website owners to realize how wrong they are.

And how do they actually measure those numbers without (i) guessing; (ii) having some JS on the page, or (iii) using Voodoo Black Magic.

I think it's ridiculous to believe ANY company that claims that they can measure traffic of a site accurately without the DIRECT INVOLVEMENT of the site's owners. How are they doing it? Through the ether? Come on! Data, people. Data. Google's figured that out, maybe other companies should too.

They get clickstream data from the big ISPs. In theory, if the samples are large enough and their models are appropriately calibrated, this ought to be a reasonable way to do it.

Wild guess: maybe they look at the increase in IP ids? On a lot of TCP/IP stacks they are not randomized, and can be measured from the outside by simply looking at 2 successive datagrams from the server. So, make up a reasonable estimation of how many IP datagrams are sent in an average visit. Make sure to do the same thing on all frontend servers. Congratulations, you now have a reasonably credible bullshit number to chart.

You'd also might be surprised at the difference in numbers between one javascript-based analytics package and another.

(For example, definitions one what constitutes a "visit" can vary)

Reply on news.ycombinator.com