AI shouldn’t mean giving up control. If you already know exactly which events you want to use, you can still build the funnel yourself through Set the events myself.
The difference is that manual configuration is no longer the only way into the workflow. You can let HeronSignal build the initial funnel and adjust it, or skip the AI path entirely when you already know exactly what you want.
That gives you two ways to work: describe the problem and let HeronSignal handle the configuration, or configure everything yourself when you need more precision.
The point isn’t to add another AI button
It’s easy to put an AI button into an existing workflow and call it an AI feature. That’s not really what we’re trying to do.
The goal is to remove work that shouldn’t have been necessary in the first place.
If your application is already recording the events, you shouldn’t have to spend the first few minutes translating a business question into technical configuration before you can start investigating it. You should be able to describe what you’re trying to understand and let the product help you get there.
From building funnels to answering questions
This change is part of a bigger direction for HeronSignal.
Become a Medium member
Traditional analytics tools often organize the experience around the tools themselves: Sessions, Funnels, Events, Metrics, Logs. But when something goes wrong, that’s usually not how you think about the problem.
You don’t think, “I need to use the funnel feature.” You think, “Why did signups drop?” or “Where are users abandoning checkout?” or “Did yesterday’s deployment affect conversion?”
Those questions might require several different pieces of production data, and the user shouldn’t always have to figure out which feature to open first. The product should help connect the question to the right data.
A funnel tells you where. The investigation tells you why.
Finding the drop off is only the beginning. If a funnel shows that users are leaving between two steps, the next question is obvious: why are they leaving?
That’s where the rest of HeronSignal becomes useful. You can move from the funnel into sessions, events, logs, and other production context to understand what happened to the users who dropped off. Maybe a request failed, a button didn’t respond, users encountered an unexpected state, or something changed after a deployment.
The funnel tells you where the problem is. The rest of the investigation helps you understand why.
The workflow should follow the problem
This is the direction we’re taking with HeronSignal. Instead of making users learn the platform before they can investigate a problem, we’re trying to make the platform adapt to the problem they’re already trying to solve.
The workflow becomes:
Question → Relevant data → Investigation → Root cause → Fix
rather than:
Choose a feature → Configure it → Find the information → Figure out what to do next
The change to funnel creation is one example of that approach. The goal is to make the product work more like the way engineers actually investigate problems.
Try it with your own data
If you’re already recording events in HeronSignal, you can create a funnel by describing the journey you’re trying to understand. Start with the question, let HeronSignal handle the initial configuration, and switch to manual configuration whenever you need more control.
What do you want to understand?
Try HeronSignal
Top comments (0)