I Had 112 "Products" and Zero Idea Which Ones Actually Worked
If you're running a multi-product SaaS (or in my case, a tools
platform with 112 free tools), you eventually hit the same wall:
pageviews tell you nothing about whether the thing you built actually
delivers.
I had solid pageview data. Zero idea if a tool completed its job for
the person using it, or if they bounced halfway through frustrated.
The fix: attempt + complete, not just pageview
Two events per core action. attempt fires when a user commits to
the action. complete fires only when it actually succeeds. The gap
between those two numbers is the real product signal, high attempts,
low completes means a reliability or UX problem, not a discovery
problem. That distinction changes what you fix next.
The part that broke my clean mental model
Six of my tools mapped perfectly: user clicks a button, something
processes, success or failure. Standard SaaS action-tracking.
Nine didn't. They're reactive tools that recompute live on every
input change, no discrete "submit" moment at all. One had no button
whatsoever. If your product has any feature like this (live previews,
real-time calculators, anything reactive), "attempt" isn't obvious.
The fix wasn't forcing an artificial trigger. It was identifying each
feature's actual moment of user intent , for most of these, that was
"copy/export the result", and tracking that instead of the
computation itself.
Two more tools auto-fire their core function on every keystroke.
Tracking that directly would've spammed an event per character typed.
Instead, tracking moved to the nearest real intent signal (download,
copy) rather than the underlying computation.
The lesson for anyone building multiple products/features
If you're instrumenting analytics after the fact across many features,
expect this: not every feature has an obvious "attempt" moment, and
forcing one in is worse than finding the real one. Decide what counts
as a meaningful action per feature, don't assume one universal pattern
covers everything you've built.
Where this goes next
16 of 112 tools tracked so far, rolling out in batches rather than all
at once, smaller changes I can verify beat one giant sweep I have to
trust blindly.
Once there's enough data, the plan is to let it decide what gets
built/promoted next; instead of guessing which "product" in a
112-product lineup deserves more investment.
For anyone running multiple products or features, how do you decide
what counts as a meaningful "success" event when the feature itself
doesn't have an obvious submit/run action?
You've already found the answer in your reactive tools, you just haven't generalized it, and once you do it resolves all 112 at once and upgrades the 6 you thought were solved.
The unifying rule: the success event isn't the computation, it's the moment the output leaves your tool and enters the user's real work. Copy, export, download, share, save, those all look like different events but they're one signal, the user committing your result to their actual task. And that's the only un-fakeable proof of success, because nobody copies a wrong answer. Your copy/export instinct on the reactive tools wasn't a workaround, it was you accidentally finding the correct definition of "complete" for everything.
Here's why it's bigger than your question. You defined complete as "the action technically succeeded." But technical success isn't user success. A calculator can compute a perfectly correct number that the user then abandons because it wasn't what they needed, that's a technical complete and a real failure, and your current setup on the 6 clean tools would score it as a win. Tracking the takeaway moment instead flips your attempt→complete gap from a reliability metric ("did it run") to a value metric ("did it produce something worth keeping"). The second one is the one that tells you which of 112 tools to invest in.
So the answer to your question is the same for reactive and button tools alike: track output extraction, not action completion. For the button tools too, "user clicked run" is weaker than "user kept what run produced." Your reactive edge cases didn't break your model, they fixed it, apply their lesson backward to the 6 you already instrumented.
Which raises the real test: on your 6 "clean" tools, how far apart are run-succeeded and result-was-taken? That gap is the tools that work but don't deliver, and it's invisible if complete fires on the computation.
The attempt→complete gap is a useful signal.
Once you have enough data, will completion rate actually determine which tools get more investment?