Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Website analytics and server logs disagree because they measure different things, and a “unique visitor” is an identifier-based estimate—not a verified person. A browser tracker can miss activity that never runs its code; logs can include asset requests and bots. The honest fix is to define the unit, check how events are collected, and keep that definition stable.
What does each system count?
A server log records requests that reach the server. Depending on how it is analyzed, that can include page documents, images, stylesheets, scripts, automated requests, and other HTTP hits. A browser analytics tag records events only when the relevant code runs and its request reaches the analytics service. The totals are therefore not interchangeable measures of the same thing. Matomo’s comparison guidance explains the distinction between log analysis and JavaScript-based analytics; Plausible’s documentation also describes why its counts can differ from GA4 and server logs.
Neither source is a universal count of human visitors. A log is bounded by requests reaching your server; a browser tracker is bounded by the events it can observe and send. Browser extensions, privacy tools, network filtering, consent choices, script errors, and untracked single-page-app navigation can all affect the latter.
Visitors, visits, page views, and hits are different units
- Person: A human being, which analytics systems generally cannot verify from ordinary web activity.
- Visitor: An identity assigned by a measurement system, often based on a browser or device identifier, or an available User ID.
- Visit or session: A group of activity joined according to rules such as inactivity timeout and day boundaries.
- Page view: A recorded page-view event, which may require a page load or explicit route-change tracking.
- HTTP hit: A request to a server; one page load can generate several requests for supporting files.
Matomo describes a unique visitor using available identifiers, such as a first-party cookie or User ID. Its cookie-based visitor ID is device-specific, so the same person on two devices can count as two visitors. If cookies are unavailable, fallback matching is less definitive; cookie-disabled operation also affects unique-visitor and new-versus-returning reports. Matomo’s visitor and visit definitions explain these limitations.
#1 Best Overall
Session rules matter too. Changing a timeout or the rule for splitting activity across calendar days can change the visit count without changing the number of page requests. Before comparing dashboards, identify whether each one reports visitors, visits, page views, or hits.
Four implementation bugs to check
The following are common failure patterns to investigate—not a claim that they occurred on any particular site. For each, use the symptom and evidence to determine whether it applies before changing configuration.
1. A tracking tag fires twice
Symptom: Page views or events appear duplicated, often on the same page load. Likely mistake: The tag was installed in more than one place, such as both a site-wide template and a tag manager. Check: Inspect the page’s source and browser network requests for duplicate tracking calls, then verify whether the analytics service receives repeated events. Fix: Remove the duplicate installation and test representative page templates. Matomo warns that duplicate tags or scripts can send the same data multiple times and recommends documenting the measurement setup. Its hit-usage guidance covers this risk.
2. A template or route does not send page views
Symptom: A section of the site, a particular page template, or navigation within a single-page app is missing from analytics. Likely mistake: The tracker was added to only some templates, or the implementation assumes every navigation reloads the page. Check: Visit each template and route while inspecting network requests and the analytics event stream. Fix: Add the tag to uncovered templates and configure route-change tracking where navigation does not trigger a full page load. Confirm that consent behavior permits the event before treating its absence as a code failure.
3. Requests or page views are mistaken for people
Symptom: A server-log total looks far higher than “unique visitors,” or a change in session settings moves visits without a corresponding change in page requests. Likely mistake: Comparing different units—or treating a browser/device identifier as a person. Check: Write down the metric and identity rule used by each report, including session boundaries. Fix: Compare like with like where possible, and label each number with its unit. Do not convert HTTP hits into a people count or assume one visitor ID equals one human.
4. Consent, blockers, and bot filters are ignored during reconciliation
Symptom: A browser tracker reports less activity than logs, or the count changes after consent or bot-filter settings change. Likely mistake: Assuming every browser executes the tag, or treating filtering as a definitive human-versus-bot test. Check: Test an allowed and a denied consent state, inspect whether the analytics request is sent, and review the platform’s filtering configuration. Fix: Document consent and filtering rules alongside the metric. Google says that when analytics-cookie consent is denied, its tags do not track that user’s activity under the described consent signal. Some eligible Consent Mode implementations can model behavior from similar consenting users, but modeled values are estimates—not recovered individual visits. Clearly distinguish observed events from modeled or combined reporting. Google’s Consent Mode documentation describes consent signals and behavioral modeling.
Bots add uncertainty in both directions: some request pages without running JavaScript, while more sophisticated automation can behave like a browser. Filtering methods differ, and filters can produce false positives and false negatives. Matomo documents bot request-processing modes in its Tracking API; Plausible describes its filtering approach and its limitations in its bot-filtering documentation. A filtered number is the result of a chosen rule, not a certified count of humans.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesHow to audit a discrepancy
- Name the metric. Record whether each number is visitors, visits, page views, events, or HTTP requests. Note the date range, time zone, session rules, and any filtering options.
- Check collection coverage. Test representative templates and routes, including single-page-app navigation. In the browser’s network panel, look for the expected analytics request and check that the analytics platform receives the event.
- Check for duplicates. Look for multiple tag installations or repeated calls on one load. Review both the site templates and any tag-management configuration.
- Test consent behavior. Confirm what the implementation sends when consent is granted and denied. If the report includes modeled data, identify it as modeled rather than observed.
- Review bot and request handling. Establish which requests and automated activity each system includes or filters. Do not assume that log totals or a filtered analytics total represent humans exactly.
- Document the measurement plan. Record the tag locations, event definitions, identity and session rules, consent behavior, filters, and configuration changes. Matomo recommends documenting the implementation, including changes that can affect measurement. Its measurement-plan guidance provides context.
How much difference is normal?
There is no universal tolerance that makes two systems’ counts “close enough”; the methods and definitions vary. Plausible says a 10–20% difference between its own product and GA4 can be normal in its support context, but that vendor guidance is not a general industry benchmark or a guarantee for any site. See the qualifications in Plausible’s comparison documentation. Investigate a discrepancy by checking units, coverage, consent, duplicate events, session rules, and filtering rather than judging it against a single percentage.
Best Value
Make trend reports comparable over time
For trend reporting, choose a metric and keep the same measurement system and configuration. A stable, imperfect measure is more useful for comparisons than a series whose definitions change silently. If you change tags, consent handling, identity rules, session boundaries, or bot filters, record when the change took effect and annotate reports that span it. Matomo’s platform-comparison guidance recommends using a consistent platform for comparative analysis.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
