Capture partial form fills with debounced submit

In a multi-step form flow, questions are distributed across pages and are answered a few at a time. Shouldn't you also receive answers immediately after users enter them?

Receiving form data upon completion vs. after every step

Many form builders provide one choice: sending data at the end, when the user completes the flow. This makes sense—after all, a fully completed form is the happy path, and is what you want to happen.

However, only receiving data at the end has a big downside: you do not receive partial responses.

Most non-trivial form flows don't have anywhere near 100% conversion (in fact, nearly 68% of all forms are abandoned), but partial responses can contain useful information about the users who didn't complete.

Partial responses may actually contain more important lessons for conversion improvement than full responses, as they provide hints as to why individuals or segments of users aren't successfully converting. If your form builder only provides the option to receive answers upon submission, you lose the opportunity to engage with this actionable user feedback.

Another common approach, if your form builder supports it, is to receive data after each step or page of the form is completed. This way, you will receive all of the partial data along the way, and can analyze the series of answers provided by individual responders.

The problem with this approach is the opposite as collecting all form responses upon submission - you will end up with too much data coming through the firehose. If you are viewing form responses in a database query result or table, most of the rows will be partial responses—not even necessarily the latest ones.

Introducing debounced submission for abandoned forms

Today we are introducing debounced submission, available in our webhooks, BigQuery, RedShift and Postgres integrations, to make working with form data easier.

Enabling this submission frequency allows you to receive answer payloads in a way that balances having all of the data, without having too many intermediate payloads:

• A payload is sent immediately if the user completes the flow (just like in the Receiving form data upon completion approach described above)

OR

• A payload is sent 5 minutes after the last user interaction, if the user has abandoned the flow.

The result is that, if you are receiving data in a database, most of the time you would have one clean row per responder session containing all completed form fields, as many as had been provided by the time of completion or abandonment.

If you're curious about where 5 minutes comes from, we've seen that >95% of users do not continue a form filling session after 5 minutes of inactivity.

Analyzing the data

By consolidating partial form responses into a single row of data, sessions can be grouped together for broader behavioral analysis. This data can help you surface patterns of user drop-offs and quickly identify the bottlenecks in your form. Formsort allows you to publish form variants without engineering which enables you to test against abandoned form data to identify the version that meets your goals.

This can be especially useful for segmenting users for retargeting opportunities based on their form progress using UUIDs, pixels, or other identity resolution techniques, especially If sequenced messaging is a part of your marketing strategy. Retargeting goals may also inform how you optimize your form fields to make sure you are capturing PII or other identifying information early in the interaction.

We hope that this will enable cleaner, more succinct data sets that empower your marketing teams to optimize your form flows quickly and confidently.

---

See our documentation on frequencies of receiving form data to learn more about data delivery options in Formsort or learn how you can start building with us today.