What the server stats tell you that analytics does not

Analytics tells you about visitors who ran your JavaScript. The server stats tell you about every request that arrived. Most of the time the first is what you want. When something is wrong, it is almost always the second that has the answer.

Four things the server sees and analytics does not

• Bots and scrapers. They rarely execute JavaScript, so analytics never counts them. The server counts every one, which is how you find out that a quarter of your bandwidth is going to a crawler you have never heard of.
• Errors. A page that returns 500 does not report to analytics, because the tracking code never runs. In the server stats it is a row in the error breakdown.
• Requests that never became pages. Missing images, dead theme assets, hotlinked files. Analytics has no idea; the 404 list is full of them.
• Bandwidth by file. Which specific assets are actually consuming the allowance, rather than which pages were popular.

What to look at first on a network

Open the metrics panel for an account and start with the error breakdown rather than the visitor graph. On an estate of sites, the useful signal is comparative: one account with a 404 rate far above its neighbours usually means a broken theme reference or a migration that left links pointing at the old structure.

Then look at bandwidth by file. A single oversized image or an unoptimised video is a common reason an account approaches its allowance while its visitor numbers look ordinary. That is a fix worth making before it becomes an allowance conversation.

The traffic number will not match, and that is expected

Server stats always report more visits than analytics. Bots, prefetching, monitoring checks and people who block scripts all count on the server and not in analytics. A gap of two or three times is normal on a small site.

Do not try to reconcile them. Use analytics for audience questions and the server stats for infrastructure questions, and treat any attempt to make the two agree as time you will not get back.

When it is worth checking

• After a migration, to catch requests still arriving at the old paths.
• When bandwidth on one account climbs without an obvious cause.
• When a site "feels slow" and you want to know whether it is one heavy asset or the whole page.
• Before assuming a traffic drop is a ranking problem. If the server never received the requests either, the cause is upstream.

The stats are generated on a schedule rather than live, so a change you made an hour ago may not appear yet. For anything happening right now, the error log is the faster read.