11.1 WPMU DEV Hosting Analytics

Link to chapter 1

This guide covers how to locate and understand the analytics data we provide for all sites we host.

After reading this guide, if you still have questions regarding how to make the most of the analytics data we provide, don’t hesitate to start a live chat with our hosting support Superheroes or submit a support ticket using the Support tab of your WPMU Dev Dashboard.

Analytics Overview

Our server-side analytics track key traffic and performance indicators for each site we host. Understanding how this data is collected is critical to developing strategies for your sites, as well as measuring the effectiveness of those strategies over time.

This document covers:

Locating Your Hosting Analytics Data
Defining Visits and Pageviews
Server Analytics vs Google Analytics and Jetpack
Understanding Bandwidth
Estimating Bandwidth Needs
Avoiding Bandwidth-related Downtime

Locating Your Hosting Analytics Data

To locate your Hosting Analytics data, begin in The Hub and click the Hosting tab.

Click the domain name of any site to access that site’s Hosting Overview.

NOTE: Storage usage data is displayed with your Analytics data. See our Storage documentation for a detailed explanation of how we calculate storage usage, including how production, staging, and backups impact storage capacity.

The Quickstats display you see in the Hosting Overview displays 30 days of data regarding visitors, pageviews and bandwidth usage.

Click Analytics to access more detailed graphs of your traffic and bandwidth stats.

Hover over any point on the expanded graphs to see the data for a specific day.

Defining Visits and Pageviews

In simplest terms, Visits are the number of unique IP addresses that accessed your site during the past 30 days, minus identifiable bot traffic and static activity, such as image hotlinking. We exclude static activity because most of the time it doesn’t result in a complete page load.

The Pageviews stat is precisely what the name implies: the total number of times your site’s pages were viewed during any 30-day period. A single visit may involve multiple pageviews.

In practice, it works like this: A unique IP address accesses your site and fully loads a page. That’s a visit and a pageview. If that same IP address then loads another page on your site, it’s not a new visit, but it is a new pageview.

The Visitors stats displayed in the Analytics Overview include both the total number of unique visits to your site during the past 30 days (646 in the example below), and the average number of visitors per day (21 in the example below).

The Pageviews stats displayed in the Analytics Overview include both the total number of pageviews during the past 30 days (1,292 in the example below), and the average number of pageviews per day (42 in the example below).

Server Analytics vs Google Analytics and Jetpack

One of the most common questions regarding our Hosting Analytics is: Why do my Hosting Analytics stats differ from those provided by Google Analytics or Jetpack?

Our server-side stats will always differ from services like Google Analytics (GA) and Jetpack, also known as third-party analytics, because our servers track activity by IP address, whereas third-party services do so by setting a cookie.

Every IP address that accesses your site is recorded in our server logs. We exclude activity that doesn’t meet certain criteria and display the results as Visitors and Pageviews on the Analytics page of your Hosting Overview. The criteria for a legitimate visit is described below under Defining Visits and Pageviews.

For GA or Jetpack to work, a JavaScript file must be downloaded to the visitor’s browser and executed. If the JavaScript file is executed properly the browser will send a request to the third-party servers, and all the activity involved with that visit —known as a session— is recorded. If anything prevents that JavaScript file from executing properly, however, the session will not be recorded.

It’s as simple as that. IP tracking records everything; third-party tracking doesn’t.

For example, if cookies, JavaScript, or images are disabled in the visitor’s browser or the visitor clicks out of a page before the JavaScript file executes, GA or Jetpack won’t record the session, but our servers will.

Another example, specific to GA, involves the tracking codes which must be present on any page you want tracked. If a tracking code is incorrect or absent from a given landing page, visits to that page will be recorded by our servers but not by GA.

Finally, there are bots, and while not all bots are bad bots, they do not reflect real human traffic, so we try not to count them. We maintain a list of hundreds of known bot agents and exclude them from your traffic stats. GA and Jetpack also will ignore identifiable bot traffic if you tell them to. Still, if a bot successfully spoofs a legitimate user from time to time, that can contribute to discrepancies in your stats.

To be clear, we’re not suggesting that GA and Jetpack aren’t great services. They are. However, some users find configuring GA overly burdensome or are wary of JavaScript tracking for security reasons. For these users, our server stats provide a reliable view of site activity.

Many users find configuring Google Analytics intimidating, which is why we developed our plugin Beehive Pro (also available free on WordPress.org). The plugin walks you through configuring GA for either a single site or multisite network and displays your analytics data in your site or network dashboard.

Get Beehive Pro of Beehive for free on WordPress.org

Understanding Bandwidth

The bandwidth provided with your hosting plan represents the maximum amount of data that can be transferred to and from your site or network at any given time.

Your bandwidth stats are displayed along with your traffic stats in the Analytics Overview to make it easy to analyze how site activity impacts your bandwidth usage.

The Bandwidth stats displayed in the Analytics Overview include both the total bandwidth used during the past 30 days (646.4 MB in the example below) and the average bandwidth used per day (21.5 MB in the example below).

The classic bandwidth analogy is that of a highway, where the highway is your available bandwidth and the cars are data. Most of the time traffic moves smoothly, entering and exiting the highway with ease. If too many cars enter the highway at one time, however, traffic backs up.

We do not set hard limits on site traffic, but sites that exceed their hosting plans’ recommended traffic levels will experience performance issues. That’s why we provide recommended visit levels for each plan to help you determine which plan will be right for you.

Estimating Bandwidth Needs

It is difficult to predict how much bandwidth you need unless you are an experienced web admin. Usually, at least a couple of months of accumulated data are required to make a reliable estimate. Once you have some good data to work with, calculating your bandwidth requirements is relatively easy.

If you manage multiple stand-alone sites on one account or a multisite network the following calculations must include all sites.

First, multiply your average daily visits by the average pageviews per visitor. For sites we host, these stats are available in the Analytics Overview.

Next, multiply the results from the first step by your site’s average page size. Calculating average page size can be accomplished simply with an online site analyzer like GTmetrix.

If your site offers downloads then you’ll need to multiply how many downloads occur each month by the average file size. Add that figure to the total from the first two steps.

The result of these calculations is your minimum monthly bandwidth needs, the operative word being minimum. You should always have more bandwidth than you need to avoid performance issues or even outages when your site experiences a surge in traffic.

We recommend maintaining at least twice the minimum required bandwidth because surges in traffic tend to be exponential. The last thing you want is performance issues when your site is “hot”. Not only do you miss the chance to attract new visitors, but you also risk turning off existing users.

If we host your site you’ve already taken an important step toward avoiding bandwidth-related downtime because our hosting plans do not skimp on bandwidth. Even our Bronze plan provides 1TB of bandwidth.

Here are some other steps you can take:

Monitor your bandwidth – You can’t anticipate problems if you aren’t paying attention. Periodically check your bandwidth usage stats in the Analytics Overview, paying particular attention to periods of peak usage.

Design a clean site – Clunky themes, excess JavaScript files, and even plugins you no longer need create extra data that your bandwidth is trying to transfer. Our Hummingbird Pro plugin, available free for all WPMU Dev members, will identify and offer solutions to most of your site’s inefficiencies. Also, read Optimizing Your WordPress Database – A Complete Guide to gain a thorough understanding of your WordPress database and how to maintain it at peak efficiency over time.

Optimize Images – Images are critical to an attractive site, but they can bloat a site faster than just about anything else. Our Smush Pro image optimization plugin can automatically optimize and resize every image in any directory the moment it’s uploaded, saving space and bandwidth. Read The Ultimate Guide to Image Optimization to gain a thorough understanding of the importance of image optimization.

Host Videos Elsewhere – Hosting audio and videos files is rarely worth the space they require. Not only do they eat up resources, but they also increase your backup size tremendously, making it difficult to restore WordPress from backup. Instead, you should use an audio and video hosting service like YouTube, Vimeo, SoundCloud, etc.

Use a CDN – A CDN, or a Content Delivery Network, is a cluster of servers located in data centers around the world which specialize in caching content to improve site speed and reduce the burden on your the servers that actually host your site. While a CDN, like Cloudflare, might be overkill for the average blog, large multisite networks and e-commerce sites are relying on them more and more to reduce the chances of bandwidth-related outages. Read Why You Should Be Using a CDN to help you determine if a CDN is right for you.