How do you figure out why users drop during onboarding?

The honest answer is that most of the time you can't know exactly why someone dropped. You can only narrow it down.
Session replays show you what happened, not why. Someone stared at your pricing page for 40 seconds and left - was it too expensive? Confusing? Did their boss walk in? You'll never know for sure from the replay alone.
What helped me think about this differently was separating two questions. First, is the drop happening because of friction - something confusing, broken, or unclear on the page? Second, is the drop happening because of fit - the wrong person got there in the first place?
These need completely different fixes. Friction you solve with design and copy. Fit you solve by being more specific about who you're targeting before they even reach onboarding.
One thing that actually works is reaching out directly to people who dropped off. Not a survey with 10 questions. Just a short personal email - "Hey, I noticed you signed up but didn't finish setting things up. Totally fine. I'm just curious what got in the way." You won't get a huge response rate, but the answers you do get are worth more than a hundred session replays.
The founders I've seen handle this best aren't the ones with the fanciest analytics. They're the ones who actually talk to the people who left.

@Adznaz the most obvious way is to simply. Jump on a call and interview people. Simple, but ego needs to be left behind :)

Then, you need a system to extract patterns and make a decision for improvements. It's simple boring activities and no, you don't need fancy expensive tools to do that.

Separating 'where they dropped' from 'why they dropped' is the right frame.

One drop-off that's almost never in onboarding analysis: the payment failure moment. When a charge fails after a user has been active for weeks, they experience it as sudden, unexplained access loss rather than a 'payment issue.' From their perspective, the product stopped working. From your analytics, it looks like voluntary churn.

That category — involuntary offboarding through failed payments — accounts for a surprisingly large slice of what most SaaS dashboards call churn but is actually a billing infrastructure problem. The user hadn't decided to leave. The decision was made for them.

A question worth adding to your list: 'How many users who dropped had a payment failure in the 72 hours before they went inactive?' Almost never measured, often surprising. We ran into this pattern while building tryrecoverkit.com — it's the drop-off moment that doesn't show up in session replays.

One thing that helped us was separating drop-off data from drop-off cause.
A lot of users don’t leave because something is “wrong” — they leave because momentum breaks before value is felt. That doesn’t always show up cleanly in analytics.

We started asking:
– Where does effort spike before payoff?
– Where are users asked to prepare, configure, or decide before doing?

Removing even one of those moments often did more than tweaking copy or UI.

Ask them. I have found this the most effective, direct way to receive honest feedback and why they got cold feet.

LOL Speak to me directly. I’m dealing with something similar at NoteOCR. though I’ve realized that if a user hasn't felt the value of a product yet, like in my case: ( seeing their own notes converted perfectly), any friction on the pricing or booking page feels like a huge red flag to them.

I found that if the pricing isn't really 100% dead-simple, the user's brain defaults to 'this is probably a headache.' I’ve started looking at it as a Trust Gap: If they haven't tried the app yet, they have zero 'goodwill' built up. So, the moment they hit a confusing pricing tier or a booking form, they bail.

Are you offering a 'quick win' or a demo before they hit those pages? i notice that since i can get them to like try the tech first before even like signing up, they're way more patient with the boring stuff like pricing. Though another problem, most users then prefer to always use the free try feature rather than signing up so you might just have to strike a balance on the features you provide for the demo