Read each metric correctly
Requests count HTTP requests, not people. Page views cover qualifying HTML loads, bandwidth is transferred data, unique visitors are an estimate and threats are requests identified or mitigated as suspicious. Compare the same metric over the same interval; these values are not expected to match each other.
Establish a normal baseline
Compare equivalent weekdays and hours over several weeks before calling a spike abnormal. Record deployments, campaigns, cache purges and incidents beside the timeline. A traffic increase with stable error rate and origin load may be healthy demand; the same increase with more blocked requests or origin errors needs investigation.
Investigate a sudden drop
Check DNS resolution, TLS, origin reachability and recent rules before assuming demand disappeared. Separate cached from uncached traffic where possible and compare more than one hostname. A graph can identify when behaviour changed, but request-level evidence is needed to establish why.
Investigate a security spike
Compare threat categories, affected hostnames and paths with recent application activity. Review whether a rule blocked, challenged or only logged the requests. Do not weaken broad protection from an aggregate chart alone; reproduce a legitimate request and narrow an exception to the smallest safe scope.
Respect analytics limits
Plan and account level determine available dimensions, sampling and retention. Aggregated analytics are useful for trends and incident timing but are not complete request logs, an invoice meter or proof about one visitor. Use an appropriate log product when individual events and longer retention are required.
