Pulsar: you launched. Now what?

You launch your product, install analytics, get some traffic and still have no idea what is actually happening.

You can see page views, sessions and click counts. But you still do not know if users found the thing you wanted them to find, which page created more friction than expected, or whether something changed this week that actually matters.

Assumptions fill that gap. Assumptions turn into bad product decisions.

This is exactly why I built Pulsar.

What Pulsar does

The core metric Pulsar tracks is comeback rate, which is the percentage of visitors who return after their first visit. It is one of the clearest signals that your product is creating enough value for someone to come back. And it arrives in your inbox, not a dashboard you have to remember to open.

Just this:

"Something appears to have broken in your activation flow. 22 rage clicks on /connect-integration suggest users are hitting a wall at the exact moment they should be converting."

That sentence comes from real behavioral signals. Pulsar detected the rage clicks, identified the activation page, compared it against the previous four weeks, and wrote that interpretation automatically.

You don't have to go looking for it.

Analytics shows you activity. Pulsar looks for signal.

Traditional analytics is useful, but it leaves most of the interpretation to you. The numbers show what happened. They rarely explain what it means.

Pulsar is built around the idea that behavior becomes more useful when it is viewed in context. A page view becomes a signal when it keeps showing up as the first page returning users visit. A click becomes a friction signal when users keep clicking something that does not respond. A bounce becomes important when it keeps happening on a page that is supposed to drive activation.

Metrics are inputs. Signals are outputs. The goal is to shorten the distance between user behavior, product understanding, and product decisions.

How Pulsar works

Pulsar starts with a lightweight SDK. You install it in your web app, initialize it with a project key, and start capturing behavioral events.

Those events include the basics like page views, clicks, sessions, scroll depth and referrers, along with stronger behavioral signals like form submissions, copy events, rage clicks, dead clicks, device type and return visits.

Pulsar then looks at how those events relate to each other over time. It identifies returners and bouncers, detects the activation page, measures how deeply returning users explore your product compared to one-time visitors, and watches for friction signals like rage clicks and dead clicks.

One of the most useful patterns Pulsar looks for is the activation page: the page returning users consistently visit that one-time visitors rarely reach. When that pattern is stable, it often points to the moment a user finds the core value of your product. When it changes or disappears, that tends to matter.

The LLM is used to turn those signals into a clearer explanation, not to invent product activity from scratch. It takes the real behavioral patterns and writes them in plain English so you do not have to translate numbers into meaning yourself.

Instead of turning all of that into another dashboard, Pulsar compresses it into a weekly signal delivered to your inbox at a time you choose. It includes your comeback rate for the week, how it compares to the previous four weeks, which page appears most associated with return visits, and a plain-English interpretation of what the data suggests.

Here is an example of what that looks like:

Between weekly signals, Pulsar also runs anomaly detection every six hours. If something unusual happens — a spike in rage clicks, a drop in activation reach, a sudden change in comeback rate — you will hear about it without having to wait for the next weekly summary.

Here is an example of an anomaly alert:

Who Pulsar is for

Pulsar is for people building web products who want a clearer read on user behavior without turning analytics into another job.

It is most useful when you are close to the product, shipping often, and making decisions without a dedicated data team beside you. That matters most when the cost of misreading your users is high because every product decision matters at this stage.

That could be a founder, indie builder, small SaaS team, developer tool, AI product, marketplace or any product where user behavior directly shapes what gets built next.

If you already have a mature analytics setup and someone actively digging through the data every day, Pulsar may not be the first thing you reach for. But if you are trying to learn from real usage while still building the product, Pulsar is built for that stage.

The faster a team learns from real user behavior, the faster the product improves. Pulsar is built around that idea. Not more data. Not more dashboards. Just a shorter path from what users actually did to what you should probably do next.

Try Pulsar

If any of this resonates with where you are right now, Pulsar is worth trying. It is now in closed beta and access is free.

Email joinpulsar@gmail.com with the subject line Pulsar Beta and a quick description of what you are building. I will take it from there and send over beta access if it looks like a good fit.