GA4 versus Plausible versus server logs

Open the same week in GA4 and Plausible on the same site and the numbers will not match. Not roughly match, either — a gap of twenty or thirty per cent is ordinary, and it is not a bug in either tool. Most write-ups about analytics platforms skip past this and go straight to a feature table: does it have funnels, does it have a data warehouse export, does it respect privacy law. The feature table is a real question eventually. It is not the first one. The first question is why three tools looking at the same website disagree, and what that disagreement tells you about which one you should actually be reading.

Three tools, three different things get counted

GA4 and Plausible both work the same way at the mechanical level: a snippet of JavaScript loads in the visitor's browser and reports back that a page was viewed. Server logs work differently — the web server writes a line every time anything requests a file, with no browser cooperation required. That single difference explains most of the gap between the first two tools and the third, and a handful of smaller differences explain the gap between GA4 and Plausible themselves.

Ad blockers and browser defaults. A meaningful share of visitors run an ad blocker or a browser with tracking protection switched on by default, and Google Analytics is one of the most commonly blocklisted domains on the internet — a target for over a decade, so blocklists are thorough about it. Plausible's script is smaller, often self-hosted or served from a less recognisable domain, and a newer, less universally blocklisted target. Neither tool sees a visitor who never loaded the script at all. Server logs see that visitor, because the request for the page itself still has to reach the server before any blocker has anything to act on.

Consent state. In markets where a cookie or tracking consent banner is required, a visitor's choice governs whether the analytics script is even allowed to fire, and decline rates vary by audience and by how the banner is worded — a company can move its own number by rewording a button. GA4 and Plausible both live downstream of that choice; server logs do not, because a server log is not a cookie and does not ask permission to record that a request happened.

Bot traffic. Search crawlers, uptime monitors, scrapers and the growing volume of AI crawlers all request pages without executing JavaScript, so GA4 and Plausible never see them — usually an advantage, not a gap. Server logs record every one of these requests, mixed in with human visits, with no marker distinguishing them. A raw log line count is not a visitor count until something filters it, and that filtering is a real, ongoing job rather than a checkbox.

Session definitions. GA4 and Plausible each draw the line between "one visit" and "a new visit" differently — different timeout windows, different rules for what counts as a new campaign starting a fresh session, different handling of a visitor who returns the next day. Two tools can watch an identical stream of page loads and report a different session count from it without either one making an error, because "session" is a definition each tool chose, not a fact about the visitor.

Put together, these four differences mean the honest description of what each tool reports is not "visitors" but "visitors who ran the script, kept it unblocked, consented if asked, and fell inside this counting rule." That is a narrower and more specific thing than the dashboard's headline number suggests, and different enough between tools that asking which one is right is the wrong question.

What consent mode actually does to the number on screen

Google's answer to the consent gap is Consent Mode, and it is worth being precise about the mechanism because the marketing around it blurs it. When a visitor declines cookies, GA4 does not simply exclude them and report a smaller, honest count of the people who accepted. It uses the behaviour of the visitors who did accept — on the same site, in the same period — to build a statistical model of what the decliners probably did, and adds a modelled estimate of those visitors back into the total.

The number a report shows after that is a blend: some of it is people who were actually counted, and some of it is a projection based on other people who look similar. Nothing in the standard report distinguishes the two, and nothing marks the modelled portion with a margin of error. For a company with a high consent rate this matters little, because the modelled slice is a small fraction of a large number. For a company where a large share of visitors decline, the modelled slice can be a large fraction of the number that gets read aloud in a meeting as if it were a count.

This is the same problem the platform-attribution comparison runs into for a different reason — every source marks its own homework with its own ruler, and the reported figure is rarely the raw thing it appears to be. The fuller version of that argument, including why an ad platform's number and an analytics tool's number for the same campaign never reconcile, is in why attribution is mostly a story. Consent-modelled traffic is the same category of problem one layer earlier: before you even get to attributing a visit to a channel, the visit count itself is already partly a guess dressed as a total.

Plausible does not have this problem in the same form, because its approach to privacy law is different — it avoids the kind of persistent identifier that triggers the consent requirement in the first place, for the jurisdictions where that holds, and so it generally does not need a banner-gated script or a modelled fill-in for the people who said no. That is a genuine structural advantage for a company whose audience skews toward markets with strict consent rules, and it is the strongest reason to choose it over GA4 that has nothing to do with the dashboard's design.

What logs see that no script ever will, and what they never see at all

A server log is the request itself — method, path, status code, timestamp, referrer header if one was sent, user agent string — written before any JavaScript has had the chance to run, before any consent banner has rendered, before any ad blocker has had a target. That gives it three things neither analytics platform can offer.

It sees visitors who never ran the script, for any reason: blocked, declined, on a browser that disabled JavaScript, or gone before the page finished loading. It sees non-browser traffic exactly as it happened, which is a liability for a headline visitor count and an asset for anyone debugging why a server is under load or checking which crawlers are actually hitting the site. And it survives every future change to consent law, browser defaults and blocklists without needing a vendor to ship an update, because it was never downstream of any of those systems to begin with.

What it cannot do is the list that makes analytics platforms worth their engineering cost in the first place. A log line has no concept of a session, a device type inferred with any confidence, a scroll depth, a button click, a conversion event, or a funnel step. Everything past "a request for this URL happened at this time" has to be built by hand, from raw text, with no default event model to lean on. A log-based setup answers "did traffic to this page go up" cleanly. It does not answer "did the people from the newsletter convert better than the people from search" without a project behind it that most companies never build.

The cost that does not show up on the pricing page

GA4 is free to run, and that fact hides the real cost, which is engineering time rather than a subscription line. Nothing meaningful in GA4 works out of the box beyond page views. Every conversion event — a form submission, a call-tracking number clicked, a specific button on a pricing page — has to be defined, tagged, tested, and then checked again every time the page it depends on gets redesigned, because a renamed button or a restructured form silently breaks an event with no warning that it happened. Companies routinely discover, months later, that a key conversion event stopped firing after a routine page edit. That maintenance burden is the actual price of GA4, and it scales with how many things you track rather than with visitor volume.

Plausible's pricing runs on a paid subscription rather than being free, in exchange for a setup that is close to immediate — install the script and traffic totals work without any event configuration — and a dashboard small enough to read without training. The cost comparison against GA4 is genuinely close to a wash for a company that would otherwise pay an analyst or a developer to build and maintain custom GA4 events: less time spent, a subscription instead.

Server logs have effectively no incremental cost, because the server was already writing them before anyone thought to read them, but the labour moves entirely to the human side — someone has to parse, filter and summarise that raw text on a schedule, and that work either gets built once as a script that keeps running or gets done badly by hand and abandoned after the second month.

Pick the tool by the decision it needs to support

None of the three is more truthful than the others in any general sense. Each is accurate about a narrower thing than "how many people visited," and the useful question is which of those narrower things you actually need answered.

A company running paid acquisition across several channels, needing to know which campaign justified its spend and comparing conversion rates across landing page variants, needs GA4's event depth and is going to pay the engineering time for it regardless of which analytics tool sits on top, because that depth is what the decision requires. A company that mostly wants a clean number in a market with strict consent requirements, without wanting to explain consent-mode modelling to a client every quarter, is well served by Plausible's simpler, mostly-unmodelled count. And a company whose only real question is whether the site is trending up or down month to month — the situation the only website metrics that mean anything argues most small companies are actually in — can run on server logs plus one free-text field on the enquiry form asking how someone heard about the business, and lose nothing that mattered to the decisions actually being made.

There is a case for running two in parallel, and it is narrower than it sounds: during a redesign or migration, to sanity-check that the new setup didn't silently break tracking, or once a quarter as a reconciliation exercise rather than a permanent habit. Running two tools indefinitely mostly produces two dashboards that disagree forever, each convinced the other is wrong, with nobody able to say which gap is consent, which is bots, and which is a session-timeout difference nobody configured on purpose. Reconciling that gap once a quarter is informative. Living inside it every month is two numbers arguing, permanently, in a report nobody has time to referee. The wider discipline this fits inside — what a monthly report should actually contain, and why sessions itself does not belong in it — is set out in measuring what a website does.