Technical
Server-log analytics
Also called log analysis.
Server-log analytics is measuring traffic by parsing a web server's access logs instead of running a script in the browser. It counts the requests the server saw, whether or not JavaScript ran.
How it is measured
Parse each line into IP, time, path, status, bytes, Referer, and user-agent. Drop asset requests such as `.css`, `.js`, and `.png`, keep status 200 on HTML, and classify bots by user-agent and reverse DNS. Counting unique visitors needs a guess, such as IP plus user-agent per day.
GoAccess, AWStats, or a script with `sort | uniq -c` all work. Run on a fixed window and keep the filters identical from one run to the next.
Worked example
A static docs site on object storage behind a CDN logs 410,000 lines in a week. After removing assets and crawler agents, 61,000 HTML 200 responses remain. Googlebot accounts for 18,000, and an uptime monitor polling `/` every minute for 7 days accounts for 10,080, leaving about 32,900 human-looking loads.
A browser tag on the same site reports 29,000 pageviews. The gap of about 3,900 is prefetches, text browsers, feed readers, and blocked scripts. Neither number is wrong. They count different things.
How it differs
A log file is the raw set of lines. Server-log analytics is the counting done on them. Logs include crawlers and visitors who block scripts, which a browser tag misses, but they know nothing about scroll or screen size.
Common errors
Counting asset requests as pageviews. Skipping bot filtering. Treating an IP as a person. Ignoring the CDN, where most requests never reach the origin log. Forgetting that rotation cut the window. Reading the proxy's address as the visitor's.
In practice
If you use a CDN, turn on its logs and analyse those. Pick a tool, set the filters once, and keep them. Use logs to confirm crawler behaviour and to cross-check a browser tag's total.