Form Analytics: The Fields That Quietly Kill Conversions
Form analytics is the practice of measuring how people actually fill out a form, field by field, so you can find the specific inputs where they hesitate, retype, error out, or leave. Overall completion rate tells you a form is bleeding users. Field-level metrics tell you which field is holding the knife. That distinction is the whole game.
Let me show you what I mean with a session I still think about.
Watch what she does at 0:14
A returning customer, mobile, checkout form. First eleven seconds are smooth: she types her name, her email, taps through to the address block. Then at 0:14 she reaches the phone number field. She types ten digits with a space in the middle, the way a human writes a phone number. The field flashes red. No message she can see above the fold. She deletes the whole thing. Retypes it, no space this time. Red again. She scrolls up, scrolls down, taps the field once more, and at 0:31 she closes the tab.
I watched forty-odd sessions on that one checkout before I stopped counting, and roughly one in five of the abandoners died on that same phone field. The aggregate dashboard said "checkout conversion down 8% week over week." It did not, and could not, say "your phone validation rejects the spacebar." Only the field data plus the replay said that.
That's the case for form analytics in one story. Now let me give you the metrics, because the story only scales if you can count it.
The five field-level metrics most teams never track
Most analytics setups stop at "form started" and "form submitted." Between those two events is where the money leaks, and it leaks at the level of individual fields. Here are the five measurements that actually expose the leak. I've ranked them by how often, in my experience, they point straight at the culprit.
| Metric | What it measures | The warning sign | Why it matters |
|---|---|---|---|
| Field drop-off rate | Share of users who reach a field but never advance past it | One field far above the others | This is your prime suspect list. The worst field is usually 3-5x the median. |
| Error / refill rate | How often a field triggers a validation error or gets retyped after blur | Repeated corrections on the same field | High refill means your rules or your keyboard are fighting the user. |
| Time-to-fill | Median seconds a user spends interacting with a field | An input that's slow for no obvious reason | Slow and high-drop is the classic broken-field signature. |
| Return rate | How often users leave a field and come back to it | Users bouncing back after an error elsewhere | Reveals confusing dependencies (address invalidates ZIP, etc.). |
| Blank-submit rate | Share who hit submit with a required field still empty | Users trying to skip a field entirely | Often means the field shouldn't be required, or its purpose is unclear. |
The trick isn't tracking any one of these. It's reading them together. A field with high time-to-fill and high drop-off is broken. A field with high time-to-fill and low drop-off is merely hard but survivable (people grind through it). A field with a high blank-submit rate is one your users are voting to delete. Zuko's field data makes this point neatly: the name field clocks the shortest average completion time at 3.5 seconds because nobody argues with "what's your name." When a field takes four times that long, something's wrong with the field, not the user.
Which fields do the most damage, ranked
If you've never instrumented a form, here's roughly what you'll find, ordered by conversion damage. This is the pattern I see again and again, and the public benchmarks back it up.
Passwords are the worst offender on any form that has one. Zuko's analysis found the password field carries a mean drop-off rate of 10.5%, higher than any other common field. Email came in at 6.4% and phone at 6.3%. People forget which password they used, they fail your strength rule, they can't see what they typed. Every one of those is a field-analytics signal you can watch happen.
Validation errors are the quiet killers. Not the honest "this email is missing an @" error. The dumb ones. The phone field that rejects a space. The card field that rejects a card because it choked on the number the user pasted. Baymard's checkout research is full of these, and they're brutal because the user did nothing wrong and often can't tell what the form wants. Baymard also found that 39% of sites don't use a recommended address validator, and among those that do, a chunk block users outright when the validator doesn't recognize a legitimate address. Inline validation, done right, is the counter-move: showing pass/fail state on blur rather than dumping every error at submit cuts errors by around 22% and completion time by roughly 42%, per the numbers compiled in Inspectlet's form-analytics guide. Right being the load-bearing word. Inline validation that fires on every keystroke and screams red while someone is mid-typing their email is worse than none.
Unexpectedly required fields come next. The phone number is the archetype. Baymard reports that over 70% of people are reluctant to hand over a phone number at checkout, and if you've marked it required, you're forcing a fight you didn't need to have. Watch for the blank-submit signature: users tabbing past it, hitting submit, getting bounced back. That's a field begging to be optional.
Then sheer field count. This one's less about any single field and more about the pile. Digital Applied's 2026 benchmark data shows form conversion sliding from 23.1% at three fields to 17.0% at five, then falling off a cliff to 11.4% at seven fields and 6.9% at ten or more. The steepest drop is between five and seven. Baymard's checkout data tells the same story from the other end: the average US checkout displays 23.48 form elements when an ideal flow needs closer to seven or eight actual fields, and "too many fields" is a top-cited abandonment reason at 27%.
Put those together and a rough damage ranking looks like this:
| Problem | Typical impact | How field analytics catches it |
|---|---|---|
| Broken validation (rejects valid input) | Severe on affected users; often invisible in aggregate | Spike in error/refill rate on one field |
| Password field | ~10% drop-off where present | Highest single-field drop-off |
| Unexpected required field (phone, etc.) | Adds friction most users resent | High blank-submit + return rate |
| Excess field count | Compounding, form-wide | Conversion decay per added field |
| Confusing labels / format hints | Slow, error-prone completion | High time-to-fill + refill |
Notice that the most damaging problem, broken validation, is also the hardest to see in a conversion chart. It hits a subset of users hard rather than everyone a little. Averages hide it. Field error rates surface it in a day.
Why the aggregate number lies to you
Here's the thing about "form conversion rate down 6%": it's true and it's useless. Digital Applied pegs the median completion rate for a qualified visitor at 17.3%, so more than four in five people who see your form leave. Baymard's documented average cart abandonment is 70.22%. Those are real numbers and they'll make you anxious without telling you what to do on Monday morning.
The reason the top-line lies is that a form isn't one decision, it's a sequence of small ones, and the user can quit after any of them. A 17% completion rate could be a form where everyone glides through until the last field detonates, or a form that loses 5% at every step evenly. Same headline number, completely different fix. Only the field-by-field drop-off curve tells you which world you're in. If you're new to the vocabulary here, our behavior analytics glossary defines drop-off, blur, and the rest in plain terms.
This is the same reason product teams moved from "did they use the feature" to breadth-and-depth measurement in feature adoption metrics: the granular cut is where the decision lives. A form is just a very short funnel where every field is a step, and steps are where people fall.
Pairing the count with the replay
Field metrics tell you where. They rarely tell you why. The phone field has a 40% error rate. Fine. Why? Is it the space character? A confusing label? A keyboard on mobile that pops up letters instead of digits? The number can't say. The recording can.
This is where field analytics and session replay stop being separate tools and become one workflow. You sort your field table by error rate, you find the offender, and then you watch three or four sessions where users hit exactly that field. Ninety seconds later you've seen the actual finger-taps that produce the error, and you know whether to loosen a regex, fix a label, or drop the field. I do this almost every week and it's the fastest diagnosis loop I know of.
The catch is that most stacks make you stitch it together by hand: form-analytics numbers in one tool, replays in another, and you're copy-pasting session IDs between tabs. A handful of platforms close that gap by keeping the field-level metrics and the replay of the abandoning session in one place, so a spike in a field's error rate links straight to the recordings behind it. Zuko is the specialist most teams reach for on the pure form-analytics side, Hotjar and Contentsquare bundle it with broader replay, and product-analytics platforms like Kixo pair field and behavior signals with the replay of the session that produced them. Each makes different trade-offs on depth versus breadth, so pick for how your team actually works. The point isn't the vendor. It's the join: a number you can act on, next to the footage that explains it.
Where this goes wrong
Two failure modes, since I've fallen into both.
First, over-instrumenting. You do not need to track keystroke velocity on every input. Start with drop-off and error rate on the three or four fields you already suspect, confirm with replay, fix, and re-measure. Field analytics rewards focus, not a firehose. A dashboard with sixty field metrics and no decisions attached is just anxiety with axes.
Second, optimizing the field when the field shouldn't exist. The best fix for a high-drop phone number field is usually deleting it, not polishing its validation. Before you A/B test the perfect inline error message, ask whether you need the data at all. Baymard's whole thesis on checkout length, and every field-count benchmark above, points the same way: the cheapest conversion win is the field you remove. Measurement should tell you what to cut at least as often as it tells you what to fix.
The one-week version
If you want a concrete starting point: instrument drop-off and error rate on your form this week. Sort the fields. Take the worst one, watch five replays of users failing it, and either fix or delete it. Re-measure the following week. That single loop, one field at a time, will do more for your completion rate than any redesign, and you'll actually understand why it worked. Which, when the next form starts leaking, is the part that compounds.