Top metrics and charts to build with forms analytics data

Top metrics and charts to build with forms analytics data

If you really want to level up your website's user experience, and regardless of whether you have an eCommerce, a SaaS platform or any type of subscription service, knowing your forms performance is more than an important to-do.

It is highly recommended to find out if your forms are causing difficulties to your users: in which fields your users leave, how long it takes to fill each step of the form, etc., in order to improve user experience and conversion. Discover how to get these metrics with Arengu, to build your own dashboard, and easily monitor their performance.

DOM events to take into account

All our forms incorporate a list of DOM events that will be very useful to measure your forms performance. You can check the complete list of events in our documentation, but here it goes a summary of those that will be most useful for this goal:

  • To monitor any type of submission, you can use af-submitForm-success, af-submitForm-error or af-submitForm. This last action fires regardless of whether the submission is executed or not, when a user clicks the button that submits the form.
  • To follow up movements between form steps, af-previousStep and af-nextStep events will contribute to your analysis.
  • To examine user interaction with any field, you can collect data with af-focusField, af-changeField and af-blurField events. We consider 'focus' when a user clicks on a field to edit it, regardless of whether or not changes are made. We mean by 'blur' the fact of clicking outside that field, and by 'change' any type of modification on field content.

Combine them to get completely customized metrics and charts, connecting them to your analytics system or service. Would you like to see some examples?

Essential metrics to track your funnel

If you want to monitor and level up your forms' user experience, we recommend you to build and pay attention to a dashboard that includes the following graphics.

1. Views, starters, completions and abandons

To get a quick overview of a form performance, we can build a graph to collect the total number of sessions that it receives, see how many of them have interacted with it, and how many users have actually submitted it or not.

Which events do we need?

To set up this graphic, we just need to get data from these DOM events:

  • Total views. To show the total number of sessions. You can get them from your current analytics stack.
  • Starters and interaction. Use af-focusField and/or af-nextStep events to find out how many of the sessions have had some kind of interaction with it, depending on whether or not your form is multistep.
  • Completions. Add af-submitForm-success event to see how many sessions have clicked on the submission button. Remember that there must be, at least, one mandatory field to avoid users to submit an empty form.
  • Abandons. To obtain the amount of users who accessed the form but did not submit it, we just need to subtract, from the total number of starters, the number of completions. Abandons = starters - af-submitForm.

What can we deduce from it?

  • If the form is 'scary' for our users. Knowing how many users have left the form as soon as they see it, or the amount of them that have progressed through it without actually submitting it, are essential key points.
  • If we really need to improve it. If the number of users leaving the form is high, we should consider changing it. To know where and why the form is failing, we can check the following graphs before launching an A/B test.

2. Conversion rates, devices and evolution

Find out how effective the form is with a simple rule of three, which we can apply to total sessions also to each of the access devices.

Which events do we need?

We need the following DOM events to build each metric:

  • General conversion rate. We just need to use total sessions and total submission to get this number, applying a simple rule of three. We just need to divide submissions by ┬áthe total number of sessions, and then multiply it by a hundred. The percentage that results from this operation is the conversion rate. Conversion rate = (af-submitForm-success / total sessions) x 100.
  • Conversion rate per device. We can obtain this rate with the same rule of three, but using the total number of sessions and form submissions per device, getting devices from your tracking tool.
  • Conversion rates evolution. Once we have obtained the data above, we can place it on a timeline to see conversion rates progression. This graph will be very useful for us to follow the conversion before and after making changes on the form, especially to check if they have really improved conversion.

What can we deduce from it?

  • If form responsiveness is working properly. If the conversion rate is considerably lower on some device, it is possible that some of the fields or the form itself may not be adapting well to some screen sizes.
  • If improvements are paying off. If we have made changes on the form, we can see in a single number if they are really improving the conversion, in addition to following its trajectory.

3. Step-by-step progression funnel

To check the volume of users that left on the way on a multistep form, you can build a chart like the one you can see in the image below.

Which events do we need?

To set it up, we just need to use these data:

  • Total sessions. Getting them from your tracking tool, as we have commented in previous points, to calculate the percentages of users.
  • Step change DOM events. Use af-previousStep and af-nextStep to check which sessions have gone through the different steps of the form.
  • Any kind of submission. Add af-submitForm event to track anytime a user clicks the button that submits the form. You can also use af-submitForm-success and af-submitForm-error events to check also how many of the submissions have been successfully executed.

What can we deduce from it?

  • Where our users leave the form. This funnel will allow us to see, at a glance, how far our users navigate the form, and where they abandon it.

4. Completion time & progression by steps

To know how long it takes our users to complete the form, and how much time they spend on each step, if it is a multistep form, you can add this information.

Which events do we need?

You can get the data for each of these metrics in the following way:

  • Completion time. Get sessions duration from your tracking tool, to take into account the time since the user opens the form until it is submitted. We can calculate the average time or group the sessions by time ranges.
  • Progression by steps. You can use af-previousStep and af-nextStep events with timestamps to track and calculate time spent on each form step during a session. This way you can see if a step is taking your users too long.

What can we deduce from it?

  • If you need to split the form into more steps. If your form is not multistep, you may need to consider this option to improve user experience. If it is already a multistep form, but one of the steps is time consuming and many users are abandoning it, you may also need to divide it.
  • If it takes too long to fill out the entire form. If just a few users submit the form and completion time is high, this could be the reason for abandonment.
    Consider making it shorter, or even moving to progressive profiling.

5. Monitoring per field ID

If you want to take your metrics even further, you can combine DOM events and field IDs to measure the performance of each input field on the form, for example, to check the volume of users that fill each non-mandatory field.

Which events do we need?

To examine user interaction on a field, we can use these events:

  • Activity on any field. You can use af-focusField and af-blurField events to check if user has interacted with it, but only af-changeField indicates us that there has been any kind of input on it.
  • Time consumption. We can also apply a timestamp to each field ID, combining it with interaction events, to see how much time the user has invested in the interaction with that field.

What can we deduce from it?

  • If we are asking for (in)appropriate information. On non-mandatory fields, we can see where the user has included information and which ones have been deliberately left blank. This can be useful to assess the adequacy of the information we are requesting.
  • If a single field is asking for too much information. This can happen on free text fields. The time that the user spends on answering this field can indicate if it is necessary to split the request of that information.

Monitor, test... and iterate!

To use these DOM events with your tracking tool allows you to evaluate in detail your forms performance and user interaction, in order to improve them if necessary.

You can also easily run an A/B test with Google Optimize, to check if the changes you want to make in the form work better, before applying them definitively.

Furthermore, Arengu lets you apply changes to your forms without deploying, so... you can iterate your forms as fast as you need.

Do you want to try it? Sign up free or book a demo with our team! You can also check on this article how to track them with your current analytics stack. Hope to see you soon!


Andrea L. Lozano

Social Media & Content Specialist.

View Comments
Next Post

7 types of forms you need in your website (and that you can build with Arengu)

Previous Post

Tracking form events using Arengu and your analytics stack