Better analytics probably won't fix your disappearing users

I've been thinking a lot about the gap between what a founder or product manager asks for and what they actually need.

A lot of product problems start as vague asks. “We need better analytics.” “People aren’t sticking around.” “We need a better dashboard.” Most of the time, the actual problem is a little more specific and is usually hiding underneath the ask.

This is how I would approach one of those situations.

The brief

Imagine an early-stage SaaS founder reaches out. They are a three-person team with a few hundred signups so far.

“People sign up, click around for a bit, then disappear. We have analytics installed, but it doesn’t tell us anything useful. We think we need a better dashboard.”

That is the entire brief. No clear drop-off point, no explanation for why users leave, just a feeling that something is wrong and an assumption about what would fix it.

The real problem

A lot of early-stage products fail because decisions keep getting made on assumptions about what users want, what is confusing and what “engaged” actually looks like. Meanwhile, the actual behavioral evidence is sitting inside an analytics tool nobody has time to dig through.

Knowing someone visited five pages doesn’t tell you whether they were exploring with intent, lost, or just passing through. Knowing a button got clicked doesn’t tell you whether it worked, or whether the user gave up and clicked it four more times out of frustration.

What this founder actually needed wasn’t a better dashboard. It was a way to turn the same raw events into a short explanation of what was happening, why it might matter and where to look next.

What I built

I built Pulsar with developer experience in mind from the start. I wanted the install path to be as small as possible while still being useful. Add the SDK and it starts capturing enough behavioral context to give the system something real to work with: page views, clicks, scroll depth, rage clicks, dead clicks, form submissions, session duration and related activity.

The first version needed to work before the founder had a perfect tracking plan. Pulsar starts with common product-behavior patterns and uses those as a first pass: which pages returning users consistently reach that one-time visitors do not, where users appear to be clicking repeatedly out of frustration and whether comeback rate is moving up or down week over week.

Those signals are then turned into a weekly plain-English summary and sent directly to the founder’s inbox. The point is to avoid giving them another dashboard they have to remember to check or another pile of numbers they have to interpret themselves. The summary answers the question they were really asking: is this working and where should I look next?

It also compares the current week against a rolling four-week history, so the output is not just a snapshot. It shows whether the product is moving in the right direction, whether a signal is new and whether something that looked important last week is still showing up now.

Example output from Pulsar

Here is an example of the kind of output Pulsar generated from the raw event stream after a week of activity.

In this case, the system found that 65 visitors used the product in the last 7 days, 22 returned and users who reached /connect-integration were significantly more likely to come back. It also compared the current week against the previous four-week trend, showing the comeback rate rising from 22% to 34%.

The number gives you the change. The interpretation gives you somewhere to look: /connect-integration appears to be connected to retention, but the relationship is still correlational. The next step is to figure out what changed this week that drove more users to that page and whether those conditions can be repeated.

The bug I introduced along the way

The four-week rolling comparison wasn’t part of the original launch plan. I added it after the MVP was already working because a single week’s number does not tell a founder much on its own. Up or down compared to what?

While seeding realistic test data, I noticed the weekly summary was showing numbers that didn’t match what I expected. Visitor counts looked too high and a rage-click signal that should have disappeared after a fix was still showing up in the current week’s report.

The cause was a date scoping bug. Weekly stats were querying the full history of events instead of the current week, while the behavioral signal detector was using a rolling 30-day window instead of 7 days. The digest was labeled “this week,” but the numbers behind it were a mix of all-time totals and month-old signals.

That kind of bug is easy to miss. It does not crash anything. It just erodes trust, because the product appears to be giving a clean answer while quietly answering the wrong question.

The fix was straightforward once I found it. I added a consistent 7-day window to both functions so every number in the digest referred to the same period.

What's worth productizing

A few parts of this felt useful beyond Pulsar itself.

Dead click and rage click detection. Most analytics tools track clicks. Almost none of them distinguish between a click that did something and a click that didn't or a click that got repeated four times because the user was frustrated. That gap between “clicked” and “worked” is where a lot of friction hides.

Activation page detection. Instead of asking a founder to manually define a funnel or guess at what their "activation moment" is, the system can find it: which page do returning users consistently reach that one-time visitors don't? That page is usually a strong indicator of where real value gets delivered and it can shift over time as the product changes, so it's worth detecting continuously and not just setting once.

The weekly digest format itself. Simple and to the point: state what changed, explain the most likely reason, be clear when the evidence is only a signal worth investigating and finish with one concrete thing to look at. I think that format works beyond Pulsar, anywhere someone needs to turn ambiguous data into a decision.

The actual takeaway

This is the loop I actually enjoy: a vague complaint, a reframe of what's really being asked, a working system that produces a real answer and the discipline to keep checking that the answer is actually correct, not just plausible.

The useful part came from building the thing and watching what happened. The output looked close enough to seem right, but just off enough that I had to stop and question it instead of explaining it away. That same loop shows up everywhere. A founder asks why users are churning. A support team asks why ticket volume is spiking. A product team asks why nobody finishes onboarding. Different tools, same kind of problem.