There is an Omniture plugin, Form Analysis, that will automatically flag which form field a user last touched before abandoning a form. Sounds great, right? This post, which does a great job of going over setting up the plugin, even claims the plugin will make you an office hero! The problem is, this plugin is inherently Evil. And not the good kind of evil. We’d like to tell you how to avoid the evil and keep your Form Analysis on the side of Good.

This plugin is notorious for being implemented incorrectly, and the implications go beyond just one report not working. Since the plugin sends a custom link call (s.tl()) each time a user abandons a form, it has the potential to eat up your secondary server calls (which you pay Omniture for). A recent client of mine has accidentally set one extra secondary server call on every single page view since 2008 because of this plugin. Sending two server calls (one with the click of a link and one on the load of the next page) so close together has been known to cause problems- every once in a while, the two calls compete and only one makes it through to Omniture, decreasing data accuracy. Worst case scenario, the plugin can actually break your form.

And what bugs me most- and this is in no way the fault of the plugin- is that folks use this as a safety crutch: they know they should optimize forms, so they put effort into setting up form tracking, then pat themselves on the back for  job well done. But, feeling comfortable that the data is there, they don’t take it to the next step and actually optimize their forms.

In this situation, you’d be better off skipping the plugin and go right to the “optimize your form” step by using your God-given intelligence. Use common sense. Think like a user: keep forms simple and easy to use. Simply running a plugin or tool will do nothing to improve your forms- remember, brains are more important than tools.

Don’t get me wrong, the plugin has much potential to do good. You just have to put some thought into it. Educate yourself on using this plugin and you can get great value out of it. To help you, here are some implementation pitfalls to avoid:

1. Potential Problem: Tracking the wrong forms

The configuration of the plugin includes two critical variables:

s.formList=”"
s.trackFormList=false

When trackFormList is set to true, it will only track forms specified (using the form’s HTML “name” attribute) in the formList (if formList is blank, then nothing will be tracked). So far so good. When set to false, the plugin will track every form on your site that is NOT specified in the formList. This includes:

• User login forms (even if they are on every page)
• Some asp.net “forms” that are not actually user forms
• Find-a-location-near-you and other single-field forms
• CAPCHAs
• And, the biggest culprit: Internal Search forms

So if a user hits a page with an internal search form field without hitting the search “submit” button, that’s one server call to Omniture letting you know a “form” was abandoned. If each page has that internal search field, that’s one server call for every page view on your site. Not only is that information useless to you, it has potentially terrifying billing implications, depending on your contract.

Solution: s.trackFormList=”true”

My suggestion? ALWAYS have trackFormList equal to “true”. This will require you going through your site and finding the forms that matter most. Focus on one or two key forms on your site. This isn’t just a work-around to get the plugin to work- it’s a great idea for focusing your analysis efforts and avoiding the Data Squirrel pitfall.

2. Potential Problem: The Plugin relies on your forms being set up “just right”

If you do not have the “name” attribute in the HTML <form> tag, the plugin won’t work. And if you do have names but they look like “form134″, it probably won’t have much meaning for you in the reports. And if every form on your site has the same name, the report will be useless. Same goes for form field/input names.
On another note, if your form script references the “this” object at all, the plugin may break your form, or vice versa. Oops. The only way around it is to remove the plugin, or remove the references to “this”.

Solution: Update form html

I’m afraid there is no quick javascript fix here: if you want to automate form abandonment tracking using this plugin, you may have to manually change the “name” attribute of the HTML forms. BUT, if you are focusing on only your 1-2 key forms, as mentioned above, the changes to your HTML should be minimal.

3. Potential Problem: Can paint inaccurate picture of which field is “guiltiest”

The plugin doesn’t tell you which field was the “turn-off”: it tells you the last field touched, which may be counter-intuitive. For example, on the right is what my form looked like when the user abandoned:

Our friend Mal only made it through the 4th field- the one with the name “email”. The plugin would report this as:

pageName:formName:email:abandon

Which might make one think the “email” field was to blame for the abandon, when in truth, he filled out that field successfully and was (presumably) “turned off” by the FOLLOWING field, asking for him to confirm his email- he’s much too busy to waste time by entering the same information twice.

Solution

One can get around this by 1)educating users of the report on what the data means (which you should be doing anyways) and/or 2) creating a classification report that says the FOLLOWING field for each item. Either way, please be aware that a report can only give hints- it cannot actually tell you what the user was thinking when they left the form or if they had looked ahead further in the form and were “turned off” by a later field.

Which brings us back to the idea that your brain is a critical part of making this plugin valuable. If you have a form on your site, now is a great time to optimize it. We’ve removed the roadblocks; what’s stopping you?