A sudden traffic spike creates a useful question: what changed? It does not establish whether the visitors were human. A newsletter, a tracking release, an uptime monitor, and an automated scraper can all produce unusual patterns. Your task is to assemble evidence, estimate how the pattern affects decisions, and make a reversible reporting change when the evidence supports it.
This guide provides a practical investigation workflow for a small website team. Start with a clear definition of the events your website analytics collects. Then use a short incident record, a comparison period, and several independent signals to distinguish suspected automation from a measurement problem.
Understand what your reports can observe
Begin by separating three measurement points: requests that reach your infrastructure, events your collection endpoint receives, and events your analytics report includes. Check which point produced the alarming number. A request count from an access log and a pageview count from a browser tag measure different things. Comparing them directly can turn an ordinary collection difference into a misleading bot estimate.
Some analytics tools already exclude known automation. Google's documentation on known bot traffic states that Google Analytics automatically excludes known bots and spiders. It also says that users cannot disable this exclusion or see the amount excluded. Consequently, an analytics total alone cannot tell you how much automation reached the underlying website.
Record the tool, collection method, report filters, timezone, and current bot controls before investigating. Use the term suspected automated traffic until you have stronger evidence. Keep confirmed monitoring, internal tests, and unknown activity in separate groups.
Capture a useful incident record
Write down when the pattern began and what prompted the review. Save the report query or export with its date range and filters. Compare the suspicious period with the same weekdays in several earlier weeks, while noting campaigns, releases, outages, and changes to consent collection. A comparison is useful only when you can explain differences in measurement.
Make the first pass small enough to reproduce. An incident record might include the affected hostname, page paths, event names, hourly distribution, reported source, and device category. Add deployment timestamps and monitoring schedules from your own team. Where permitted and necessary, ask the infrastructure owner for aggregated request counts over the same interval.
Limit access to detailed logs and use your established retention rules. Investigate aggregate patterns before collecting additional identifiers. The privacy-first analytics guide can help you frame the investigation around information that serves a defined measurement purpose.
Look for combinations of signals
Use several independent observations to prioritize review. The following table is a diagnostic checklist, not an automatic classifier. Each signal needs context, and the explanation in the last column is a reason to check your assumption before excluding traffic.
| Observation | Useful follow-up | Alternative explanation to check |
|---|---|---|
| Events repeat at an exact interval | Compare timing with known monitors and scheduled jobs | Your own availability check |
| Many unrelated paths appear in a rigid order | Inspect a short request sequence | A planned quality assurance crawl |
| A single event suddenly multiplies | Review collection requests after recent releases | A duplicate tracking trigger |
| Traffic lacks expected follow-up events | Test the affected journey on the relevant devices | A broken button or event listener |
| One source label accounts for most of the increase | Check campaign links and landing pages | A new distribution partner |
A short visit, unfamiliar location, unusual browser label, or empty referrer is insufficient evidence by itself. Build a candidate cohort using the narrowest combination that describes the anomaly, then inspect what that cohort actually does. Write down the observations that would persuade you to remove the label.
Rule out tracking errors before filtering
Reproduce one ordinary visit in a test environment or a clearly labeled development session. Open the browser's network panel, reload a page once, and inspect how many collection requests represent that pageview. Follow an internal link, use browser navigation, and complete one meaningful action. Match those requests to your event specification.
Check for an analytics tag installed both in the page template and a tag manager. Review whether a single-page application sends a pageview on initial load and again during route initialization. Inspect event listeners added on every render, retry queues that replay accepted events, and success events triggered before the operation actually succeeds.
In a hypothetical deployment, a release adds a second pageview listener. Your report records two views for each tested navigation, while server requests remain broadly stable. That observation supports a collection defect. Correct the listener, document the affected period, and verify one event per intended action before continuing the bot investigation.
Create a classification you can explain
Once instrumentation checks pass, assign candidate traffic a review status. A simple system is enough: expected automation, suspected automation, reviewed ordinary activity, and unresolved. Record the evidence, rule version, owner, and next review date. Avoid presenting a confidence score unless you have a defensible way to calculate and validate it.
Consider a hypothetical cohort that repeatedly requests the same group of pages every minute, matches a monitoring schedule, and is confirmed by your operations owner. Label it expected automation. A different cohort with rapid navigation and missing interaction events remains unresolved until you have checked the journey and gathered corroborating evidence.
Apply candidate exclusions in a comparison report or a derived dataset where your tools permit it. Keep the original available under your normal retention policy. Describe the rule precisely enough that another analyst can reproduce it; a vague instruction to remove unusual visitors will drift from week to week.
Review examples the rule should preserve
Prepare a small review sample with expected outcomes before evaluating the rule. Include a confirmed monitor, an ordinary mobile visit, a returning visitor using a saved link, and a development test that your team can identify. Add a case resembling the suspicious pattern that you believe should remain in the report. Avoid including personal details in a shared worksheet.
Apply the candidate rule to these examples and record its decisions. Investigate every unexpected exclusion and revise the rule before broader use. This exercise will not establish a universal detection accuracy, but it gives you concrete evidence about the mistakes your team considers most costly and a repeatable check when the rule changes.
Measure the effect on decisions
Show the original total beside the total after your proposed exclusion. Include the number of excluded events and the reason for the rule. Recalculate the metrics that matter to the current decision, such as sessions reaching a contact page or visits containing a completed signup. Keep the numerator and denominator under the same filtering definition.
If your tool cannot support the desired comparison, document that limitation and export an appropriate aggregate for review. Do not silently substitute pageviews for sessions or subtract event counts from a visitor total. These quantities have different definitions, so the resulting arithmetic would be difficult to interpret.
Assess whether the conclusion changes. If the proposed exclusion barely affects the choice under review, record the uncertainty and avoid spending another week optimizing a classification that has little practical value. If it changes a budget or release decision, prioritize validation.
Separate reporting changes from access controls
Decide explicitly whether you want cleaner reporting, less infrastructure load, or protection for a sensitive operation. Those goals require different actions. Excluding events from a report does not establish a rule at your website's request boundary. Coordinate request controls with the person responsible for availability and security.
For a reporting change, preview the rule and inspect ordinary visits it would exclude. For a request control, start with a narrow scope and an observation period where available. Check essential journeys, documented integrations, accessibility tools, and permitted crawlers. Specify rollback steps and an owner before changing production behavior.
Conclusion: make the investigation repeatable
Add the incident to your next website analytics report: the observed pattern, evidence reviewed, affected dates, reporting impact, and chosen action. Preserve an annotation if historical numbers changed. Set a review date for temporary rules so obsolete assumptions do not become permanent exclusions.
Reliable bot analysis begins with measurement boundaries, reproducible observations, and checks for ordinary tracking defects. Use multiple signals, label uncertainty clearly, and test exclusions before relying on adjusted totals. The useful outcome is an explainable report that supports a better decision and a documented path to revise it.
