We’ve all got forms on our websites. And chances are, you have multi-page forms. But, do you know how they’re performing? Do you know where people are abandoning your forms? If you knew that, what could you do?
There’s lots of ways to track forms but they vary depending upon what you need to accomplish. Multi-page forms, which are very common these days, are slightly more complex from a measurement standpoint, but you definitely want to get some insights into these types of forms.
Our online application form for enrolment is around 18 pages – only some of which require you to enter information. So it’s important for us to know which pages people abandon on, and which form fields they last interact with.
Another example would be a credit card application form, which might be 10 pages. Or an insurance form that might be 5 pages long. And there’s no real benchmark for completion. The benchmark to use is your historical data. Then you try to optimise it to achieve a greater conversion from your own benchmark.
In the following post, I’ll look at different ways that you can measure forms using SiteCatalyst and Discover. This is a fairly long post, so I apologise in advance.
Success Events
The first thing you need to do is ensure you are setting some success events. This will tell you the number of times a form was viewed and subsequently completed.
To do that, you’ll need to do a couple of things.
Firstly, you’ll need to use an eVar for the form name, and two success events – one for form view, and the other for form completion. We actually use four different success events; Form Start, Form Complete, Lead Start and Lead Complete, being a positive optin.
On the form page, set the eVar to the name of the form, and set the success event, for example:
[javascript]
s.eVar8 = ‘Figure Out Your Life 2009’;
s.events = ‘event2’; // this is our Lead Start success event
[/javascript]
When the user submits the form, you can then set the eVar and the completion event, as follows:
[javascript]s.eVar8 = ‘Figure Out Your Life 2009’;
s.events = ‘event3’; // this is our Lead Complete success event[/javascript]
Now in SiteCatalyst, if you view the Lead Type report (assuming that’s what you called the eVar8), against Lead Start and Lead Complete success events, you’ll have some basic numbers, and you can create a calculated metric to understand completion ratios (lead complete / lead start).
Then you can trend the same report, picking up the Lead Conversion Rate and the name of the form, to analyse its performance over time against other marketing campaigns – for example:
One thing you’ll probably want to do though is contact support to get Event Serialisation turned on for these two success events. This ensures that you don’t count the event twice during the same session, which is especially useful when they have an error and go back to the form which may (or may not) fire off the Lead Start event again.
But that’s not really what this post is about. This assumes that you’re doing that anyway.
Form Field Analysis
What about the fields that they abandon on? Irrespective of it being a multi-page form or not, you’ll likely want to know what fields they last interacted with.
You can get this by using the formAnalysis plugin. See the nitty gritty bit at the bottom for implementation ideas…as always, check with Omniture Support or Engineering Services to make sure you’ve done it correctly as the implementation can be different from client to client.
It’s not a particularly pretty report, and it can be somewhat complex to implement, but there’s a heap of insights it can give you, enabling you to take a closer look at your forms and decide if you need to change the label, or the field itself, or indeed if you really, really, need that field.
We have a form on the Murdoch Uni site called “Stay In Touch”. It appears in multiple places across the site.
The way we have configured our form analysis plugin is to use the pagename, followed by the formname, and then the plugin does the rest.
As you can see from the report below, the pagename varies depending upon which form the user filled in.
As you can see, the most common thing that they last interact with was the field “segment” – that’s a field that asks them to tell us who they are. It actually appears across a number of the different (but same) forms across the site and seems to be fairly consistent.
As that was the last field they interacted with, we need to look at the next field, or the form overall. The next field asks them to tell what they’d like to be kept in touch about…and it appears that it’s that selection that’s putting them off.
I’ve filtered the above report using a number of criteria to look only at “abandon”. The filter was:
So, what…
What can we do about this abandonment?
Well, there’s a number of things in play here. We have another form that’s about getting in touch with the University to ask questions – powered by RightNow. It appears that on further examination using pathing from the forms above, we can tell that the user wasn’t actually looking to use this form – they wanted the Ask a Question form as that’s where most of the “abandoned” traffic went to.
Multi-page forms
Multi-page forms are common, and you can use SiteCatalyst Fallout Reports to see the completion from page to page.
There’s a gotcha here though – you can only use this for 7 pages. So if your form is more than 7 pages long, you’re going to be out of luck if you want to see every page.
The other way, which sort of works, but can lead to a bit of trouble, is to just look at the page views across the forms, by filtering on the pagename. The problem with this approach is that it doesn’t put them in the order that you want them…it only shows the number of page views.
Enter Discover.
Using Discover Fallout
Discover has a wonderful visual fallout report that allows you to add an unlimited number of pages, or steps, to a form fallout report.
The following (very long image) is a representation of our online application process. It’s 19 steps and each step shows the amount of fallout per step vs those that went on, and if they left, where they went next.
The following is an enlarged area of the same report:
The thing that you’re looking for in this report is a larger than expected “lost”, as highlighted above. Simply click on the green arrow and it will tell you where they went. In the above example, the particular page where people “fallout” is the Upload Docs form, which requests documents to be uploaded. Clearly users are not aware they need to upload documents, or don’t have them to hand, so they save the form and come back later – thereby causing an “abandon”. We now alert them to the fact that they’ll need to upload various documents, minimising any fallout.
This is very handy report as it allows you to narrow down your analysis of fields to a specific page. Start at that point to increase the conversions of your forms.
The other, really important capability, is that you can segment this report nine ways from Sunday to see if different segments interact with your forms differently. We commonly look at Domestic versus International visitors through this lens.
And now to the nitty gritty bit
There’s a number of parts to get the form analysis plugin working. Firstly, you’ll need to get the plugin from Omniture. You’ll also need to define an s.prop in SiteCatalyst admin. We’ve used s.prop18.
Then you’ll need to configure your s_code config section. There’s a few variations, but ours is as follows:
[javascript]/* Form Analysis Config */
s.formList=’stayintouchform,form1′; // Names of forms to track
s.trackFormList=true;
s.trackPageName=true; // Append the name of the page to the form name
s.useCommerce=false;
s.varUsed=’prop18′; //sprop used
s.eventList="" //Abandon,Success,Error[/javascript]
s.formList is a comma separated list of forms that you want to track. The name of the form must be the same name that is in the HTML, i.e. <form name=”stayintouchform”>, and should be unique across multi-page forms (to allow for better visibility).
In the s_doPlugins(s) section, you’ll need to add the following:
[javascript]/* Form Analysis */
s.setupFormAnalysis();[/javascript]
Once you’ve got those in place, you’ll start to track each form field. Remember that it’s the last field they interacted with that is recorded. There are some other values as well, such as “Continue”, “Abandon No Data” and so forth, but they’re all fairly self explanatory.
And that’s about it really. There’s also a really great post from Adam Greco, a.k.a. the Omni-Man, who talks about using specific events to track form completions, ratios, etc, without the form analysis plugin.
Final Thoughts
Form abandonment is a critical part of understanding user interactions on your forms. It’ll give you better insight and allow you to improve your overall conversions on your cart completions, product selections etc, and should therefore be definitely considered as part of your overall implementation strategy.
