Betterlytics

Spot on. Looking at average LCP or TTFB is exactly how you miss the fact that 20% of your users are having a terrible experience. Are you guys planning to show p95/p99 percentiles by default to fix this? Love the philosophy behind Betterlytics, keep it up!

We ran into exactly this. A merchant we were researching had 100K daily visitors in his analytics. Turned out 99% were bots. His real traffic was 600-1000 humans. He was optimizing ad spend against fake data for months. The problem isn't the dashboard. It's that most founders treat analytics as truth instead of as a hypothesis that needs validation. The first question should always be "is this traffic real" before "why isn't this traffic converting."

The data can be correct.
The chart can be correct.
Yet two people can look at the same signal and assemble completely different conclusions from it.

Most people read it like this:
signal + dashboard + context → conclusion

But the actual formula is closer to:
signal + dashboard + context + interpretation → conclusion

Dashboards do not just compress reality.
They create room for projection.

Correct data + incomplete interpretation → distorted conclusion

Sometimes the hidden variable is in the reading.

Hit this exact thing with sprint metrics. 30% velocity jump, two months in a row, team was feeling it. Turned out we had just started logging smaller task types. Accurate data, completely wrong story.

the bot traffic example is such a good way to open this because everyone has experienced that moment - you see a spike, get excited, dig in, and it's nothing.

the averages hiding real issues point is underrated. p95 and p99 latency tells you so much more than mean response time but most founders never look at it until users are already complaining.

the part about context being where the truth is - that's the whole problem with dashboards in one sentence. you end up reverse engineering what happened from a clean chart that had all the useful information stripped out before you even saw it.

how are you handling the annotation side - is that manual or are you building something that auto-detects when a deployment or config change might explain a metric shift?

Really like the direction of Betterlytics—privacy-first analytics is clearly where things are heading. The fact that it’s cookieless and GDPR-compliant by default makes it super appealing, especially for founders who want insights without dealing with consent banners or legal complexity.

Curious to see how it evolves, especially around advanced features and integrations—great potential as a solid alternative to traditional analytics tools.

The “dashboards don’t lie, they just remove context” framing is spot on.

What you described feels like the difference between observability and reporting. Most tools optimise for clean summaries, but real debugging happens in the messy edge cases those summaries hide.

The bot example is a good reminder that spikes without narrative are basically noise. Without context, you end up explaining data instead of understanding it.

Curious how you’re handling the balance though, showing distributions and connected signals is powerful, but can also overwhelm users quickly. How do you keep it usable without losing the depth?

Sounds a great idea! And I'm fully agree with you, having many tools can cause difficulties to analyse things. Will check your tool, sounds interesting!

the correlation tax is real. I've lost hours bouncing between dashboards trying to figure out if a conversion drop was a bug, a performance issue, or just bad traffic.

by the time you line everything up the moment's passed. single timeline view makes a ton of sense, the insight is rarely in any one tool it's in how the signals overlap

I’ve seen the same thing when testing production apps. Lighthouse looks great, but real user data sometimes tells a very different story. Are you collecting Core Web Vitals directly from the browser?

The synthetic vs RUM gap is real. We health-check our site regularly and catch issues Lighthouse misses. Curious how you handle low-traffic sites where RUM sample sizes are tiny.

This is interesting because a lot of people treat Lighthouse like a final verdict instead of a snapshot.

I’ve seen sites score great but still feel slow or clunky in real use.

Feels like actual user experience matters way more than chasing a perfect number.

The gap between synthetic scores and real-user experience is one of those things that sounds obvious once you say it, but almost nobody acts on it. A 95 Lighthouse score feels like a stamp of approval. It's hard to look at that number and think "this might be lying to me."

The device gap is what makes it tricky. Lighthouse simulates a mid-tier phone on a throttled connection — which is already better than what a lot of real visitors are actually using. A founder tests their page on a MacBook Pro with fiber internet, sees a green score, and moves on. Meanwhile half their audience is loading the same page on a 4-year-old Android over mobile data, and the experience is completely different.

We ran into a version of this when analyzing page speed across multiple sites. The scores looked reasonable in isolation. But when we compared speed scores against other conversion factors, pages with "good" speed scores still had users bouncing — because the perceived load experience (layout shifts, delayed interactivity) didn't match the synthetic number. The score said fast. The visitor felt slow. Those are two different things.

The broader lesson applies beyond speed too. Any single-metric tool gives you confidence, not clarity. Confidence feels good. Clarity is what actually helps you fix things.

To answer your question: we've learned to treat Lighthouse as a baseline sanity check, not a source of truth. If the score is bad, something is definitely wrong. If the score is good, you still don't know how real visitors experience the page.

Lighthouse is useful, but it’s still a proxy and not the product experience itself. I’ve seen plenty of cases where a “worse” score still delivered better UX and conversion because the page matched user intent better. Curious which real world metric diverged most for you from the Lighthouse score?

Spot on. I’ve seen 99/100 Lighthouse scores tank in the wild because of heavy hydration on low-end devices or third-party scripts that fire after the initial paint. Synthetic tests are just a laboratory baseline. At Joinble, we prioritize Edge Computing (Cloudflare) specifically to reduce that variance, but RUM is the only way to see the 'long tail' of user experience. Lab data is for CI/CD; Field data is for business.

One thing that makes this even more misleading is that many founders end up optimizing for the test itself rather than the real user experience. People spend hours trying to move a score from 92 to 99 in Google Lighthouse by removing unused CSS, compressing images, or shaving a few kilobytes off their JavaScript bundle. Those optimizations can be useful, but they often ignore the things that actually slow users down in production: heavy third-party scripts, analytics tags, blocking APIs, slow backend responses, or hydration delays in modern frameworks. A page can look perfect in a lab test and still feel sluggish the moment a real user tries to interact with it.

Another factor is geography and device variability. Synthetic tests typically run from a small set of locations on controlled hardware, but real visitors might be thousands of kilometers away from your server, using older Android phones, unstable mobile networks, or laptops overloaded with extensions. When you start measuring real-user data through metrics like Core Web Vitals, the picture often looks very different. That’s why I tend to treat Lighthouse primarily as a debugging tool rather than a performance KPI. It’s great for identifying technical issues, but the only thing that really matters is how fast the site actually feels to the people using it.

Gtmetrix

I often found that Lighthouse would give me different scores than Google Page Speed. I could never quite figure out which was more accurate. What do you think?

Interesting insight. Lighthouse scores can definitely be misleading compared to real user data.

I'm currently building a small web experiment inspired by the Million Dollar Homepage — a pixel grid where anyone can buy a block and place their logo with a link. It's fascinating to see how performance and traffic behave with real users.

Interesting insight. Lighthouse scores can definitely be misleading compared to real user data.

I'm currently building a small web experiment inspired by the Million Dollar Homepage — a pixel grid where anyone can buy a block and place their logo with a link. It's fascinating to see how performance and traffic behave with real users.

Great explanation! Sometimes I also notice my Lighthouse scores don’t match real user experience—especially with dynamic content or heavy third-party scripts. Lab tests vs real users can be quite different!

This feels like one of those features that sounds powerful but becomes much clearer when it’s demonstrated. A quick demo showing an agent reasoning about real user data through Betterlytics could make the impact immediately obvious for developers and teams. I help SaaS builders turn new features into simple launch videos that communicate the value quickly, so if you ever plan to promote this release I’d be glad to help.

Yes, but I didn't see much improvement in agent performance

The framing here is spot on. "Analytics stops being a dashboard and becomes context" is exactly the shift. Agents work better when context is structured and queryable, not buried in a wall of text.

Same principle applies to how you write the prompts that instruct those agents. A flat blob of instructions gives the model everything at the same priority level. Breaking it into explicit blocks (role, context, constraints, output format separately) makes a real difference in how reliably the agent follows through.

I've been building flompt (https://flompt.dev) for exactly this, a visual prompt builder that decomposes prompts into 12 semantic blocks and compiles to Claude-optimized XML. Open-source: github.com/Nyrok/flompt

This is interesting because it feels like the difference between “AI guessing” and “AI working with context.”

The question I’d have is whether the real unlock is analytics access itself, or the layer that turns raw product data into decisions an agent can actually act on reliably.

The framing of analytics as context infrastructure is spot on. The next challenge becomes how you structure the prompt that tells the agent what to do with that data. When the agent gets a blob of analytics context mixed in with its task instructions, it often underweights it. When the analytics come in as a clearly labeled input block separate from the objective and constraints, the agent reasons with it much more reliably.

It is the same structural problem you solved on the data side. The prompt side has the same gap.

I built flompt (https://flompt.dev) for this, a visual prompt builder that separates prompts into typed blocks (role, objective, input, constraints, output format). The input block is specifically for this kind of structured context injection. Open-source: github.com/Nyrok/flompt

If you find it useful, a star on github.com/Nyrok/flompt would mean a lot. Solo open-source project.

The framing of analytics as "context infrastructure rather than a dashboard" really stuck with me. That's the shift. Nice execution on the MCP integration.

This is a really interesting direction. Exposing analytics as a queryable layer for agents feels like a natural evolution beyond dashboards.

One question I keep thinking about with MCP-style integrations is how agents deal with partial or misleading data windows. For example, if an agent sees a drop in conversions shortly after a deploy but only has a few hours of data, it might prematurely roll something back or optimize for noise rather than signal.

Humans usually handle this with context (“let’s wait 24 hours before deciding”), but an agent needs explicit guardrails. Do you handle this with query constraints (e.g., minimum time ranges, confidence thresholds), or do you expect the agent layer to manage that reasoning?

The idea of analytics becoming context infrastructure rather than a dashboard is compelling though. It reminds me of how observability tools evolved from graphs into APIs that automated systems can reason about.

The question I keep thinking about: how do you handle the agent acting on incomplete data? Like if it only has 2 days of post-change data, does it wait or

This is exactly where analytics should be heading. Dashboards are for humans who have time to interpret. Agents need raw queryable access.

The "did the landing page change affect conversions" example is the killer use case. Right now, that workflow is: deploy change → wait → open dashboard → stare at charts → guess. Giving the agent direct access means it can correlate the change with outcomes in near real-time and even roll back if things go south.

I've been thinking about this same pattern in game dev. Imagine an AI agent that has access to player behavior data; drop-off points, engagement heatmaps, where players get stuck and can adjust NPC difficulty or tutorial flow dynamically. Suddenly your game isn't just reacting to code, it's reacting to how people actually play.

The MCP layer is interesting because it's not another dashboard. It's a bridge. Analytics becomes a live context engine instead of a retrospective report.

Curious: have you run into any challenges with query complexity or rate limiting? Real user data at scale gets messy fast.

(Full disclosure: exploring similar agent-data integrations in game dev via AI Powered Game Dev For Beginners - different domain, same "give agents real context" philosophy.)

Nice launch.

This is a thoughtful take on a growing need in the analytics space.
Tools like Betterlytics show how the industry is shifting toward privacy-first analytics that still provide meaningful insights without invasive tracking or cookie banners.

I especially like the focus on lightweight performance and developer-friendly integration those details matter a lot for smaller projects and indie founders who want actionable data without the complexity or compliance headaches of traditional tools.

It’s encouraging to see alternatives that prioritize both user privacy and practical analytics instead of forcing developers to choose between the two.

This resonates so much with what we've seen in the LLM space. You can get a 200 OK from OpenAI or Anthropic, but your model might be: - Burning through your budget with inefficient prompts - Returning lower quality responses than usual - Taking 10x longer to respond - Failing silently on edge cases The same principle applies - being reachable isn't the same as being usable. We ended up building similar "functional checks" for LLM operations at zenllm io because traditional monitoring just wasn't cutting it. Keyword-based checks are brilliant for web apps. For LLMs, we do something similar by monitoring response quality patterns, cost per token trends, and latency percentiles rather than just "did the API respond." Really smart evolution on your monitoring approach. The Slack/Discord integration sounds like exactly what teams need - alerts where people actually see them.

The GDPR cookie banner problem is something our clients bring up almost every project honestly.

We build apps for startups in US and Europe and European clients specially are always stressed about compliance. They want analytics but dont want to deal with consent banners and legal headache that comes with it.

Cookieless approach is smart direction. We recommended Plausible to few clients before but always felt it was bit too expensive for early stage startups.

Will try Betterlytics for next client who asks. Curious, for mobile apps is there any SDK or is it currently web only? Most of what we build is Flutter and React Native so that would be deciding factor for us.

This is such an underrated point.

I’ve seen this happen a lot in real scenarios, especially in SaaS funnels. Everything returns 200, dashboards look “alive”, but the actual money flow is broken (forms not submitting, buttons not triggering, APIs silently failing…).

From a business perspective, that’s actually worse than downtime, because you don’t even notice you’re losing revenue.

Keyword checks are a great step. Another thing that worked well for us was simulating real user actions (like completing a form or triggering a key flow) to detect these “false positives”.

“Technically up, functionally dead” is probably one of the most dangerous states for a product.

The dashboard looks awesome. If you don't mind sharing, what's your net profit per month, and how did you decide to work on this product, specifically?

I'm curious how many users you talked to before starting to build, too.

This is a great point.

“System working” and “system returning a response” are very different things.

I’ve noticed something similar with AI tools while building Franklin Prompt Studio — an answer can technically be “complete” but still be missing key assumptions or risks.

Technically correct, functionally misleading.

Great point: “reachable” ≠ “usable”. 200 OK only tells you the web server answered, not that the critical user path works.
Keyword checks are a solid step. I’ve also found two things helpful in practice:

1. Synthetic journeys for the core flow (landing → signup → key action → checkout)

2. Alerting on behavioral signals (sudden drop in signups/purchases) alongside uptime
   Curious: do you see more failures caught by keyword/UI-text checks, or by full journey checks? And how do you avoid flaky alerts when UI copy changes?

This comment was deleted 8 months ago

This sounds.
Performance is a user-impact problem, not a leaderboard problem.
A 100ms regression on a high-traffic page hurts more users than a 2s delay on a dead page.
Weighting CWV by usage feels like the right mental model.

This is a great point. Performance isn't about chasing the worst score, it's about reducing the most friction. Traffic-weighted core web vitals feels like a much more practical way to prioritize work.

We saw a similar pattern with AllInOneTools — some of our slowest pages barely mattered, while tiny regressions on high-traffic tools had outsized impact on user trust and retention.
Optimizing for user impact, not just worst metrics, completely changed our priorities.

With my experience, psychology also has it own impact in doing conversion. Sometimes, everything looks great and the traffic keep coming in but, zero conversion. Pre-framing them has always been helpful

UI looks pretty cool!

This looks really promising. Privacy-first, lightweight analytics are exactly what modern websites need. Would love to see how Betterlytics compares with Plausible or Umami in real-world usage. Wishing you a successful launch

Really cool to see Betterlytics taking shape!

One thing that stood out to me is how you’re making uptime monitoring not just a checkmark feature, but something actionable with clarity around incidents and alerts — that’s what separates useful tools from noise in this space.

Curious how you’re thinking about noise reduction in alerts/notifications as usage grows — too many false positives can kill trust fast. Have you experimented with tuning thresholds or UX patterns there?

Excited to see where this goes!

Uptime + analytics covers a lot, but there’s still a gap.

Both can look ‘healthy’ while the site is actually broken.

200 responses, traffic still coming in, but key flows not working.

That’s where things get tricky.

I like the way you frame this as “completing the picture” rather than adding features.

I’ve personally kept uptime and analytics separate so far, mostly because I treated uptime as an ops concern and analytics as a product concern.

But in reality, when something breaks, the first question is often “did traffic drop because users left, or because the site was down?”

Having both timelines in one place actually feels more practical than I used to think — especially for smaller teams that don’t want to juggle multiple tools.

Uptime + analytics in one place makes sense - you see WHAT happened (site went down, traffic dropped). But there's a layer most analytics miss: understanding WHY your site matters to visitors in the first place.

You can have perfect uptime and traffic flowing, but if visitors don't immediately understand what you offer and why it's relevant to them, they bounce before you can measure engagement.

That's the gap between monitoring behavior and ensuring comprehension. Analytics tell you what users did, not whether they understood what they were looking at.

We're building voice agents that guide users through products in real-time (demogod.me) - basically ensuring people comprehend your value before you start measuring their actions.

Your tool nails the "what's happening" layer. The missing piece is the "do they get it" layer - making sure visitors understand your offering fast enough to become the engaged users you're tracking.

Yea this seems like one of those cases where overthinking can happen. I would keep the old design, slowly integrate any good parts of the new design. such as the brighter green dot. The older design has strengths, looks more readable .. but overall the changes should not lead to any delaying of shipping...

There are merits to both designs, the left hand nav is clearer for the user on the after, but overall the before layout has a bit more and and feels friendlier and less cramped, I also prefer the shade of the boxes on the original and the deeper black/blue colour way, feels more polished. I see why you have moved the filter box to give it balance but it still makes more sense being next to the date filter.. If you wanted to fill the void you could have a small title in that space .. eg. overview . That being said these are small things and if you are overall happy with what you produced and are confident that it's for the greater good of the user, sometimes you just need to push forward.

Love the transparency here..

I personally like the new UI re-design!

Feel free to launch this on ProofStories as well to drive some additional traction - we also just launched a directory!

The difference between the two UIs isn't tremendous, so I don't think you run the risk of shipping and frustrating existing users.

I like the additional metrics at the top of your new layout where you're now covering everything most people would want to see at a glance. The addition of the Behavior heading in your left column is good and makes the list more scannable.

As for users who find the old version more visually appealing, I am going to make a couple guesses as to why:

(1) The stats at the top are easier to read on the old version. In the new version, the brighter lines with gradients underneath make the numbers slightly harder to read. However, they do make the lines easier to "read" at a glance. Both versions work. The only question is whether you think users prioritize the values or the trendlines for easiest reading. Neither approach is a dealbreaker, and both look good.

(2) This might sound odd, but the curved trendlines on the old version probably read as "friendlier" to some users than the more jagged lines that go point-to-point.

Good luck! Both versions look great.

I’ve been through something similar. The truth is most users care way more about speed and clarity than design polish. In my case shipping the redesign and improving it later worked better than waiting forever. How much feedback is holding you back versus just preference noise?

Very good question. I'm not a user and I like the old UI a little bit more. You will always have users who don't like UI changes, and that's okay. They will get used to it. In this case I would say it doesn't really matter which design to keep, they are both good. So rather keep focusing on developing real impacting improvements.

product build not vs product sustained