CloudFlare provides a unique view into the traffic data for the sites that use our service. Since all traffic to those sites pass through our network, we log these requests. In a typical minute, we'll generate several millions of log lines representing all the traffic to sites on our network. The data from these raw logs is collected and displayed to users through our Analytics Dashboard.
The Anaytics Dashboard is clean and easy to use and, when we first started showing it to people a year ago, many suggested that we should set out to disrupt services like Google Analytics. Analytics is core to what we do, but we most certainly aren't trying to replace Google Analytics or other services people use to understand the traffic to their site. We track data in a different way than a service like Google Analytics and, as a result, we're better at some things and not as good at some others.
Beacons vs. Raw Logs
It's important to first understand how Google Analytics and other "beacon-based" tracking systems work. Google Analytics requires you to install a snippet of Javascript on your site. When the site is accessed, the visitor's browser runs the Javascript and a request with information about the visitor is sent to Google. Inherently this has some limitations. The two big ones are: 1) any visitors that don't execute Javascript won't be counted, including bots and crawlers; and 2) metrics like bandwidth used and hits -- the measure of all the individual requests made to your web server -- won't be tracked because the Google Analytics beacon only runs once on each page view.
Google Analytics was developed in order to help websites understand their visitors in order, ultimately, to better sell advertising. Lots of people use it for other things, of course, but that's its core mission. Most ads, like those in Google's own AdSense program, are also delivered from a line of Javascript, so it makes sense that if what you're trying to measure is delivered via Javascript then you should measure with a Javascript beacon.
CloudFlare's goal is to make sites faster and safer. This means we're concerned about things like the hits your server is actually serving, the bandwidth it's using, and all the visitors to your site -- especially the nasty crawlers that don't trigger Javascript. As a result, we gather raw data about every request as it passes through our network and report that on the Analytics page. The Hits / Bandwidth numbers in particular are metrics you can't get through Google Analytics because services that use Javascript-based beacons have no way to track them.
The Problem with Page Views
Page views are where people often get confused, and we don't blame them -- we're not wholly satisfied with the answer ourselves. The metric of a "page view" stems from the old days of the web when every interaction required the page to reload. Most display advertising payments get calculated based on a "page view" since that is generally what ties to an ad's impression. Even Google AdSense, which pays based on clicks, will calculate your "eCPM," which is the effective amount you are earning for every 1,000 page views.
The problem is what counts as a "page view" is becoming complex. All page views are hits, but not all hits are page views. Our challenge is to only classify certain hits as page views. To illustrate the challenge of this, think about your experience with a modern website like Facebook. Obviously when you first visit Facebook.com that should count as a page view. But what about when you thumb through a photo gallery? Or comment on a post? Or "poke" someone? Each of these is an interaction driven by what is known as an AJAX call to the backend server. Some of them may cause the page to refresh. Others may not. Usually the URL of the page remains the same. So should these count as trillions of page views -- one per interaction? Or only one page view per user per visit?
Facebook follows the most commonly accepted industry standard which counts most of these AJAX requests as "page views" (which partially explains their 1 trillion+ page views per month). That's not entirely satisfying, but the alternative isn't either. If Facebook installed Google Analytics then they would have a much lower page view count. CloudFlare follows the same industry standard and so our reported page views is usually higher than what you're see in Google Analytics. This is especially pronounced for AJAX-driven sites. This doesn't mean you can go to your advertisers and start demanding more ad revenue. It should, however, mean that you now have a more accurate picture into the actual resource demands required to run your site.
So Who Is Right?
We are 100% confident in the hits and unique visitors numbers on CloudFlare and we have the raw logs to back them up. We're shakier on the page view numbers. While we follow the industry standard, that is flimsy in the modern web world. If what you care about is how many ads you're serving, you likely should stick with what is being reported from Google Analytics or another beacon-based service. If you want to know about the load on your server, CloudFlare is great at reporting that. In other words, there's a place for Google Analytics and there's a place for CloudFlare. That's part of the reason that the first CloudFlare App we integrated with Google Analytics. Together, the two services both help you get a better understanding of who or what is coming to your site, what resources they're consume, and how you can best monetize that
traffic.