I Just Discovered My Analytics Numbers Are Mostly Fake. Here Is Why.

the 90% cpu and the "modest day" in ga4 aren't contradicting each other, they're two different budgets. one is a cost number, one is a decision number, and the mistake is usually wanting a single dashboard to hold both.

i'd stop trying to clean traffic and instead pick metrics that require state. signups, a saved record, a second session on the same auth token, a paid event. bots hit every endpoint but they almost never complete a sequence that needs something remembered from step one. that's your human layer, and it's boring enough to trust.

then keep nginx as its own thing for capacity, and split agent hits out by user agent so you can see whether chatgpt referrals ever show up on the human side later.

This is a painful but necessary lesson; I stopped trusting vanity metrics like page views ages ago because they almost always hide the real signal. Instead of focusing on traffic, I started tracking 'meaningful actions' like sign-ups or actual messages, which bots rarely replicate. It might be worth checking your referral logs for specific user agents, as that's often where the noise comes from.

This is a real pain, but I’d validate it with one brutally narrow ICP first: founders whose hosting bill or CPU has already spiked from bots. “Cleaner analytics” is nice-to-have for a lot of people, but “my app is being crawled into downtime / surprise infra cost” is urgent. I’d also separate the landing page into two promises: traffic truth vs bot defense. They may be different buyers.

This is a real challenge many developers are starting to face. Separating genuine users from AI bots and scrapers is becoming essential for accurate analytics, better security, and controlling infrastructure costs. A server-side solution focused on true traffic intelligence definitely sounds like it addresses a growing need.

The gap between GA showing a quiet day while your server hits 90% CPU is something most people never catch because they never look at both at the same time.

The global threat network angle is where the real value is. Local log analysis is always reactive. The moment a scraper hits someone else's server it should already be blocked on yours.

Are you positioning this as a security tool or an analytics tool? The pitch changes completely depending on which pain you lead with.

A couple weeks ago I put up my first website in quite a few year. I expected to get essentially no traffic since I just put it live and wasn't driving traffic in any way. When I woke up in the morning I saw in my logs that tons of users had made requests to my endpoints. I didn't actually realize how many bots are just going down the list of domains and scraping websites for any sort of vulnerability they can find.

The part that stands out to me is the framing shift from counting visits to classifying intent. Most founders only discover this after a cost spike, not before. I would be curious whether the three category system holds up once a bot starts mimicking human session patterns on purpose, since that is the direction scrapers seem to be heading. Real ground truth from server logs feels like the right instinct though, dashboards built on client side scripts were always going to miss this.

The pain is real but you have described three products: clean analytics, a WAF rule generator, and a cross-customer threat network. Cloudflare already gives away most of the second and third, so the defensible piece is the boring one you mentioned last: an auditable human-traffic report someone can hand to an acquirer, an ad network, or a diligence data room. I have watched traffic quality become a live argument at the LOI stage with no standard artifact to settle it, which makes that a much narrower wedge with a buyer who already has budget.

this matches what i see too. the gap between what analytics reports and what the server actually eats is mostly bots now, and GA4 hides it because it filters known crawlers and most of these headless/AI agents never run the js tag at all. so you get the worst combo: they dont show up in analytics but they absolutely show up in your CPU bill. one thing worth doing is splitting the access logs by user agent and asn, usually a huge chunk is a handful of cloud provider ranges hammering you, and rate limiting those at the edge buys back most of the CPU without touching real users. the part that worries me longer term is the AI agent traffic that DOES render js, because that pollutes your real metrics and you quietly start optimizing for an audience that will never convert.

The part about discovering it through CPU usage instead of analytics felt real. That's usually how these problems surface.

One thing I'd want before paying is proof that the human traffic classification is accurate. If that layer is trustworthy, the rest of the product becomes much easier to justify.

Great story! Organizing AI conversations across multiple LLMs with full-text search and local indexing is such a valuable solution. Congrats on reaching 5-figure MRR!

The distinction between human traffic and machine traffic is important, but I’d be careful with a binary “verified human” label. Privacy tools, shared networks, and real users behind unusual request patterns make that boundary fuzzy.

For Speechara, GA4 became more useful when we tied events to a user-visible outcome — first transcript, first translation, or first saved meeting — instead of treating pageviews as success. A dashboard that combines traffic likelihood with “did this visitor reach a real product outcome?” might be harder to fake and more actionable than another clean-session number.

There are several different pains bundled together here: distorted analytics, infrastructure cost, bot identification, and automated defense.

The responses to your $29 question may be much less informative than which of those problems people already feel strongly enough to solve.

The practical fallout for early-stage products: if you optimize landing pages off raw sessions, you're optimizing for bots. We switched to measuring signal quality — time on page, scroll depth, the specific pages people actually reach — and our "real user" number turned out to be a fraction of the dashboard figure.

The other thing that caught us: scraper traffic floods one endpoint, not the ones a human would touch. A human lands on the homepage, reads, clicks through. A bot hammers the API. Filtering analytics by that path shape got us closer to truth than any bot-filtering feature.

Worth noting — it also means your server bill is partly paying for machines that will never buy.

Disclosure: LeadGrid (leadgrid.eu) is mine - local-business lead lists - so I'm the kind of small site you're describing.

The traffic that fooled me worst would have sailed through your filter. 895 pageviews all time; about a third arrived from roughly 25 parked domains with names like business-browser-dot-something, plus a block from Yahoo in the same window. That's Bing's search syndication network, and I was paying for it - 483 clicks bought between 6 and 26 July. Real browsers, real sessions, plausible referrers, nothing a bot classifier would flag. Number of those 483 who ran a single search in the product: zero.

So "Verified Human Traffic" would have shown me a clean, healthy number and been exactly as wrong as GA was. Cheap ad syndication and click farms live in the gap between your first bucket and your third.

Worth checking before you build the ingester: the log-parsing half is well covered already. Matomo has imported raw access logs for years, GoAccess does it locally for free, and Cloudflare classifies bots at the edge before they reach your origin. PostHog and Plausible aren't in that group - they're client-side like GA and share the blind spot you found.

The split I'd actually pay for is did-something versus did-nothing, with the source attached.