Become the Web Analytics OFFICE HERO with Omniture's Site Catalyst Form Analysis Plug-in

Confusion around this Plug-in stops <form>HERE</form> where the rubber hits Conversion Road.

Darcy’s recipe for OFFICE HERO success may be all the rage, but this is the plug-in you want on your SUPER hero utility belt.

The Form Analysis Plug-in (“The Plug-in”) is a piece of JavaScript code that is inserted into the core Site Catalyst JavaScript File, s_code.js. This little baby is the BIG BROTHER of the forms on your site, watching your visitors take the tentative steps towards conversion or oblivion.

Although one of the more complex of the plug-ins, implementing The Plug-in can be as easy as 1, 2, 3, 4, 5

(Note: This post assumes that at least one other plug-in is implemented in your copy of s_code.js.
If not, Contact Us)

1. Acquire the version of the Form Analysis Plug-in code (that is compatible with your implementation of SiteCatalyst) from your friendly Omniture Implementation Consultant.
2. Insert the code into s_code.js in the designated “PLUGINS SECTION”
3. Make the call to s.setupFormAnalysis() in function s_doPlugins()
4. Set The Plug-in’s configuration parameters
5. Insert “on-page” JavaScript code to send event data to Site Catalyst:

• Success events in the form’s onSubmit event handler,
• Error events as part of your client-side and/or server-side validation code.

… and then start watching your reports to see where your visitors are almost converting…

Steps 1 and 2 need no further explanation.

Step 3 looks something like this, depending on your pre-existing plug-ins:

function s_doPlugins(s) {
       // calls to other plug-in functions may already exist here
       // Form Analysis Plugin v.2.0
    s.setupFormAnalysis();
}
s.doPlugins=s_doPlugins;

NOTE: Suppress the urge to ask if strings are case-sensitive – they almost always are.

Step 4. Insert the configuration code in the “CONFIG SECTION”

This is where the business rules become JavaScript.
Today I deal only with the “how” of Form Analysis.
In a following post I will discuss the “why” of various configurations.

Which forms?

A comma-separated list of forms to be tracked by The Plug-in. Form names are those defined in the name attribute of the forms’ <form>tags.

Indicates if only the listed forms are tracked (true) or if all forms are tracked except those listed (false)

To Name or not to Name

The Form Analysis report shows pageName:Form Name:Result (Abandon, Success, or Failure):Form Element. If trackPageName=false, pageName: is omitted

Traffic or Commerce

If true, eVars (conversion variables) and events are used, otherwise props (traffic variables) are used

If s.useCommerce is true, this designates any one of the available conversion variables (eVarN) to use. If s.useComerce is false, use any one of the traffic variables, eg: s.varUsed=”prop9″

If s.useCommerce=true this represents a comma-separated list of one or more of Abandon,Success, and Error events respectively. Only the events required are listed. Events missing from the begining or middle of the string are omitted but their commas remain to keep their place. Eg. The string

indicates that only Error events will be tracked. If s.useCommerce=false, set

Ask not what The Plug-in does for you
Once implemented, The Plug-in does only 3 things:

1. Recognizes that a page containing a designated form (remember s.formList and s.trackFormList?) has been loaded
2. Provides s.sendFormEvent for custom, on-page code to report Success and Error events.
3. Reports form abandonment, identifying the last field changed*. A form is “Abandoned” if it is unloaded without the s.sendFormEvent being called. If no such interaction occurs, the form is reported as “No Data Entered”

*(the documentation uses terms such as “fields interacted with” and “touched” but our testing with ver 2.0 of The Plug-in with both IE 7 and Firefox shows that Abandoment requires at least some action to change the field (typing in a textbox, clicking in a pull-down, even without changing its value. Beyond being academic, this distinction can have consequences for how one uses success events in conjunction with Form Analysis, as will be discussed in subsequent posts.)

What you have to do for your forms
Call

to report successful for submits and errors.
While Success will almost always apply to the form as a whole, Errors may relate to one or more form fields or to the form as a whole.

The syntax of s.sendFormEvent is:

where:

• 
  is either ‘s’ for success or ‘e’ for error
• 
  is s.pageName if s.trackPageName is true or is ignored if false (pass and empty string to keep its place).
• 
  as per the name attribute of the form’s <FORM> tag
• 
  is any string describing the error.

What is a good error description for the user is rearely good for form analysis. That, however, deserves and will be awarded, a blog post of its own.

The event’s pageName and form are associated with fellow events of the same pageName and form solely by virtue of their names being consistently reported.

Coding for Success

For all but the most unusual business requirements, success is defined by the user submitting the form without tripping over a client-side or server-side error

Success should only be reported once success, as defined in the business requirements, has been determined.

Success that is determined by JavaScript alone, will be reported by calling s.sendFormEvent in the onSubmit event handler of the form and will look something like:

function frmOnSubmit(frm){
   if (formIsValid (frm) ) {
       s.sendFormEvent('s', s.pageName, frm.Name);
   }
}

Where success can only be determined by server-side validation, s.sendFormEvent(), that code will generate the JavaScript on the confirmation page to be called from the onLoad event handler. Conversely, code to send error reports would be generated on returning to the form page.

Whistle-blowing the Errors
Use s.sendFormEvent to report errors are called as part of the field and form validation code.

There are a number of error reporting techniques which will be revealed in a subsequent post which you will not want to miss. Subscribe to our RSS feed below

Regardless of that detail, the implementation structure is the same:

function formIsValid(frm)
{
  if ( isEmail_BS(frm.email.value) )
  {
      strError = "Please enter a real email address";

          // Inform SiteCatalyst of the error
      s.sendFormEvent('e', s.pageName,frm. Name, 'BS Email');
  }
  return strError;
}

To end on a positive note, an error event does not mean the form did not end with a success event.

OFFICE HEROes are tough – after exposing how the designers’ forms suck, subscribe to our RSS feed for tips on coding events for Form Analysis reports you can use to suck up to the marketing VP.