Form Analytics
Date: 2026-08-16
Field-level measurement of where a form loses people. Pound for pound the highest-yield diagnostic in ecommerce, because forms are where the money is and a funnel step only tells you the form failed, not which line of it.
What it is
Form analytics measures interaction at field level: which fields were reached, which caused errors, which were abandoned at, how long each took, and which were re-entered.
A funnel says 40% left at delivery details. Form analytics says they left at the postcode field, after an average of two errors.
What to measure
| Signal | Tells you |
|---|---|
| Field reached | Where attention stopped |
| Field completed | Which fields people actually finish |
| Abandonment field | The last field touched before leaving — the single most useful number |
| Error rate per field | Where validation is fighting people |
| Re-entry count | Fields corrected repeatedly: unclear format or bad validation |
| Time per field | Hesitation, though it’s noisy |
| Field order of interaction | Whether people move through as designed, or jump and return |
Abandonment by field is where to start. It points at one line of one form, which is a small enough problem to actually fix.
The instrumentation
Native events give you most of it without a vendor:
field.addEventListener('focus', () => track('field_focused', { field: field.name }));
field.addEventListener('blur', () => track('field_blurred', {
field: field.name,
completed: field.value.length > 0, // NEVER the value itself
valid: field.checkValidity()
}));
form.addEventListener('submit', () => track('form_submitted'));Never capture field values. Names, emails, addresses and card details go straight into your event stream and out to every destination — a disclosure incident, not a data quality issue. Record whether a field was completed and whether it validated, never what was typed. See PII in Analytics.
Fire the last-field signal on visibilitychange, or abandonment events are lost at teardown — Event Batching and Delivery.
What it reliably finds
The same few things, on most sites:
- Validation firing on keystroke, telling someone their email is invalid while they’re still typing it
- Postcode and phone fields rejecting valid formats — spaces, international numbers, BFPO addresses
- Required fields nobody expected to be required
- Fields nobody completes, which are candidates for deletion. The cheapest conversion win available is removing a field
type="number"on postcodes, producing spinners and dropping leading zeros — Forms- Autofill failing, visible as unusually long time-per-field across every address field at once
That last one connects to a large win: autofill working depends on correct autocomplete attributes, and it’s worth more than most redesigns.
The constraint that hurts
You usually can’t run this where it matters most. A hosted or locked-down checkout doesn’t permit arbitrary scripts, so field-level measurement is unavailable on precisely the form with the highest value — Checkout Instrumentation Constraints.
What’s left:
- Instrument every form you do control — account creation, address book, contact, newsletter, returns
- Measure up to the boundary, so entry and completion are precise even if the middle is opaque
- Lean on qualitative methods inside checkout, where the quantitative route is closed — Usability Testing, Session Replay
Reading it
- Segment by device. Mobile form failure is a different problem with different causes
- Compare error rate to abandonment. High errors with low abandonment means people persevere — annoying but survivable. High abandonment with low errors means something confusing rather than broken, and that’s harder to find
- Watch re-entry. A field corrected three times is a format expectation nobody communicated
- Look at the last field, not the first error. People tolerate an early error and leave at a later one
Then hand it to design: the fix is in Form Design and Error Prevention and Recovery. Form analytics locates the failure; it never says what to do about it.