The Forms Report

Note that there can be multiple forms on a single page: search, login, newsletter and all the events related to fields in these forms will be displayed in the same table.

Table Columns

Change Order

This column contains information about an average order in which users were changing (filling in) form fields. Only the order of the first change of a form field value is taken into account.

For example, let’s assume we have a form with two fields: phone and email. Two users tried to fill in this form.

The first user:

1. Entered phone number (order: 1)
2. Entered email number (order: 2)
3. Corrected phone number

The second user:

1. Entered email number only (order: 1)

The average order would be:

Change Order	Field	Changed in visits	Corrected in visits
1	phone	50% (1)	50% (1)
1.5	email	100% (2)

If the table shows form field changes from “all sections at once” the change order is calculated from the entire session. Otherwise, it is calculated based on the order in which fields were changed in a specified section (page).

Form Field Selector

When tracking user interactions with page elements, UseItBetter builds a unique element selector using tag names and CSS classes up to the nearest element with the ID attribute. You can read more about it here.

Let’s assume that our form consists of two fields:

<form>
 <input type="text" id="phone" value="">
 <input type="text" id="email" class="required" value="">
</form>

entering phone number and email would produce the following change events:

input[1]#phone.change({val:"999-999-999", name: "phone", type:"input"})
input[2]#email.required.change({val:"xxxx@xxxx", name: "email", type:"input"})

Let’s assume the form validation detected an invalid email format. It would then add an additional CSS class “invalid” to warn a user which resulted in correcting the email by the user. This sequence would produce a different event:

input[2]#email.required.invalid.change({val:"xxxx@xxxx.com", name: "email", type:"input"})

By default, the form field selectors presented in the table are simplified to treat both events as one:

Field	Changed in visits
input[*]#phone*	50% (1)
input[*]#email*	100% (2)

You can change how form field selectors are grouped in the settings.

Required fields

The required fields are identified based on fields changed by users who reached the final step defined in the funnel and not on any class names assigned to these fields or their attributes.

Example

Let’s assume we have a fictional form with two steps, step 1 and step 2. The form in the step 1 has two fields: email (required) and phone number (optional).

When we define “the final step of the funnel” as “step 2″ the visits are split into two segments:

1. Visits in which users didn’t reach the final “step 2″
2. Visits in which users reached the final “step 2″

If 100% of users who reached the final “step 2″ changed the email field and 60% of users changed the phone field then:

• email field would be marked with * (asterisk) as required
• phone field would be assumed as optional.

There are scenarios possible in which a field that is theoretically required would not be marked as required with * (asterisk).

Let’s assume a situation in which users who already completed the “Step 1″ can come back to a website and resume their journey from “Step 2″ without going through Step 1 and filling in forms there again.

Now, the segment of visits in which users reached the final “Step 2″ would consist of two different groups:

• 80% of users who started from “step 1″
• 20% of returning users who started from “step 2″

The returning users didn’t fill in the email field in the same visit. Therefore, the email field was only changed in 80% of visits and not 100% so it is not recognized as required. In fact, it isn’t required to reach “step 2″ in the same visit. In such cases, you may want to to adjust your segment to include only visits in which users started from “step 1″.

Changed in visits and Corrected in visits

Even though the terms changed and corrected may seem equivalent to you, there is actually a very important difference between them. The term “changed” is based on a name of a JavaScript event which means that an initial value in a form field has been changed (i.e. from blank to “something”) either by a user or programatically i.e. as a result of user behavior. Therefore, the meaning of “changed” is the same as of “entered” and “fill in”. Read more about form field tracking.

If a value in a form field was changed more than once in the same visit, it is considered as “correction”. As change events are captured only when users leave an input form field (focus on that field is lost), then any changes of the text that users make while typing are not considered as corrections.

The percentage value in the “Changed in visits” column is relative to all visits who dropped out at the selected step of the funnel and calculated as follows:

number of visits with at least one change event / number of visits * 100%

The percentage value in the “Corrected in visits” column is relative to number visits in which that field has already changed:

number of visits with at least two change events / number of visits with at least one change event * 100%

The numbers displayed in brackets after the percentage value (i.e. “45% (352)”) mean the total number of visits and not the total count of change/correction events.

Share Compared To Visits With The Final Step

“Share Compared To Visits With The Final Step” tells you if a field value was changed (had value entered) more or less often than in sessions in which users completed the form (reached the defined final step).

1) values in this column are displayed only for fields that are optional (without asterisk) since for the required fields the difference would always be:

value in column "Changed in visit." - 100%

for example the first row in the table below the value would be 98% – 100% = 2%

You could say: “This field is obligatory and it should be changed in all sessions”

2) In the second row, the value in the column is 2.5% (25) which tells us that users who dropped out are changing value in this field more often than users who complete the funnel. The value was calculated as follows:

	9.2%	(156)	percentage of sessions in which users dropped out had vehicleTypeSelect field changed
-	6.7%	(131)	percentage of sessions in which users reached the final step of the funnel had vehicleTypeSelect field changed
=	2.5%	(25)	difference

You could say “Users who enter/change vehicle type are more likely to drop out.” 
You should ask yourself: “How can we get less users to fill in this field? Or how can we better respond to that behavior?”

3) in the sixth row, the negative value is in red which tells us that users who dropped out are entering value in this field less often than users who complete the funnel. The value was calculated as follows:

	33.8%	(570)	percentage of sessions in which users dropped out had carFuel field changed
-	47.5%	(907)	percentage of sessions in which users reached the final step of the funnel had carFuel field changed
=	-12.7%	(-337)	difference

You could say “Users who don’t enter carFuel are more likely to drop out.”
You should ask yourself: “How can we encourage more users to fill in this field?”

Average Time Spent on a Field

The time is measured from a focus event which is dispatched when a user clicks on a field or switches to that field using a tab key) to a change event which is dispatched when a user switches to another field or clicks another element and the focus on the field is lost.

Example

If a user edited the field twice during the same session, the time spent on a field would be a sum of time spent on those two edits.

Behavior	Event	Time spent
User clicks and email field which gains focus	(E) input[1]#email.focus	0 sec.
User is typing in…
User clicks outside of the email field and the the field loses focus	(E) input[1]#email.change	4 sec.
User is editing other fields, reading…
User clicks again on the email field and the field regains focus	(E) input[1]#email.focus	4 sec.
User is correcting the email field’s value…
User clicks outside of the email field and the the field loses focus	(E) input[1]#email.change	7 sec.

The value presented in a column tells the difference between average times spent on a field by the users who dropped out and the users who reached the final step of the funnel.

	12	seconds spend on a field by users who dropped out
-	7	seconds spend on a field by users who reached the final step of the funnel
=	+5	difference

Tip: You can hover over the value in the column to see the actual average time.

Increased time typically indicates that users who dropped out were having problems filling in the form field. Often, this can be accompanied by higher percentage of visits in which a value in the form field was corrected.

Decreased time time can mean that:

• users do not consider an edited field important,
• users don’t want to provide an answer (i.e. entering “-” instead of “+44 723 312 312″ would take less time),
• a value in a form field was automatically populated (i.e. by Chrome Auto-Fill feature) and that your form does not support that well,
• users pasted a value into a field instead of typing it in.

Corrected Entries and Final Entries

Corrected entries show you a chain of changes that users make in a single field. Final entries show you the last value entered into that field.

For example, if a user:

• Entered “+44 7233 123212″ phone number
• Corrected the phone number to “07233 123212″
• and then corrected it again to “07233123212”

then (with default value masking) the final entry would be:

99999999999

and the corrected entry:

+99 9999 999999 corrected to: 99999 999999 corrected to: 99999999999

In the above example, a user tried three different formats:

• digits, white spaces and special characters (“9_&”): +99 9999 999999
• digits and white spaces (“9_”): 99999 999999
• digits only (“9″): 99999999999

The first two of those formats were eliminated by a user in the process of correcting the form field value. If our data set only contained this single user, we would see in our table:

Field	Corrected in visits
phone	100% (1)	9_& 9_ 100% 100%

This tells us that even though users managed to correct their entries, their initial expectations how to fill that form field were wrong. In such a case, you should still try to improve the field:

• change instructions for that form field (i.e. “Your phone number without country code (i.e. 07602092140)”
• programmatically allow/disallow entering certain characters (i.e. disallow use of white spaces) in the front-end or make sure that the back-end will automatically remove them without returning an error.
• change form field type if possible (i.e. break a single “phone” input field into a “country code” select field and “phone” input.)

Let’s assume that in the example above, the form required user to enter a phone number with a country code but without white spaces. In such a case, all final entries in that field for visits in which users reached the final step of the funnel had to be of a single format:

• digits and special characters (9&), i.e. +999999999999

We would see then in the table that format of the final entry by the user who dropped out was invalid:

Field	Corrected in visits		Final Entries
phone	100% (1)	9_& 9_ 100% 100%	1	9 100%

You should always scan your table for formats that are detected as invalid (in red).

The number in the Final Entries column (in the table above: “1”) tells you how many unique entries were provided by users. This value, depending on a field type, can bring valuable insights.

Let’s assume that our form consists of two form fields: a “country code” select field with 257 options and a “mobile phone number” input in which only digits should be entered. Values picked from select field are by default captured without masking (i.e. “+44″), and values entered into inputs are masked (“999999999″).

A low number of unique final entries for the “country code” tells us that most of our users are from a few countries and we should make sure that it’s easy to select corresponding country codes instead of browsing a list of all 257 codes.

Let’s assume that all your users have mobile numbers with the same country code prefix: “+44″ (UK). Since the length of all mobile phone numbers without the country code is the same (10 characters) then any number of unique final entries other than “1” will mean problems.

Trivia: the minimum length of a phone number is 4 for Saint Helena (SH, +290) and the maximum length is 13 for Austria (AT, +43)

Exits After Change

Exits After Change tells you the number of visits in which users who changed a certain form field, submitted the form or received an error and left the website.

For example, if there were 3 users who dropped out:

The first user:

• changed the Phone form field
• and left the website

The second user:

• changed the Phone form field
• submitted the form
• received an error that the Email field is required
• and left the website

The third user:

• changed the Phone form field
• changed the Email form field
• submitted the form
• received an error that the value in Phone field is invalid
• and left the website

the table would show:

Event	Exits After Event
input[*]#phone	1
input[*]#email.required
Action=Submitted form[1]#contact
Error=*	2

A high number of exits after an event is a strong indicator that:

• users had problem filling in a form field and left afterwards (i.e. they received a validation error when entering a value – in this case the exit would be after a change event and not an error, since errors are typically collected after a form is submitted.)
• users did not want to or couldn’t fill in a next form field in the form (i.e. they entered an email address but saw that the next field asks them about a phone number which they did not want to provide).
• they submitted a form, received one or more validation errors (i.e. user entered a phone number in a format that is not acceptable by your form but the error message is not instructive enough for users to correct the format; or users tried to submit form without filling in a required field.)
• if high numbers of exits follow a submit form action and your project is correctly tracking errors, it can be an indicator of technical problems (i.e. a request timeout).