NOTE: The code samples below are merely a proof of concept. This solution is not actively in place in any production environmetn that I am involved with.

I was talking to a fellow ColdFusion developer about a web site he was working on, specifically a registration form, and what were some of the best practices with form length and such that would facilitate users filling out the form and submitting.   This is a common issue with web sites that will not be going away anytime soon.  In fact the questions he had are the same ones I have seen in dozens of blog posts trying to figure this out.

• How many questions to put on a form?
• What type of questions work the best?
• What question(s) scared off a user and kept them from completing the form?

I know that there are a few "Form Abandonment" plug-ins out there for Omniture and the likes, but from what I've seen the data you get is somewhat limited.   If your form has 20 elements on it and the plug-in only lets you know what the last element with focus was, you have to really think about the validity of that data.  How do you know for sure that the user filled out the elements in order?  Did the developer of the form set the tab index correctly?  Did the user glance at the form, click somewhere near the bottom and then bail?  Did the user fill out half the form the shut down the browser?

From my understanding of the tools out there today, you are not able to get accurate answers to the questions above.     However, this is an very interesting problem that got me thinking on how I could leverage ColdFusion to be able to capture and get more meaningful data from the abandoned forms.

The Challenge:

• Capture data by users from abandoned forms
• Push that data into Omniture SiteCatalyst
• Create a report with real, actionable data on form abandonment

The Setup:

• ColdFusion 8
• Client Variables stored in a database (SQL)
• jQuery

Step 1:  Capture the form data

The trick to capturing the data would be to find a way to save the form data in some persistent variable so that the data could be retrieved later.  Right away I thought of the Client Scope .   Then the task was to find a method that could be deployed to multiple forms across a site with minimal re-coding.    For that I wrote this snippet of jQuery:

<script language="JavaScript" type="text/javascript">
$(document).ready(function(){
// Form Handling/Analysis Test
$('#Form2BeTracked').children().each(function() {
$(this).bind('change',function (event){
$.post("/includes/processFormProgress.cfm", $('#Form2BeTracked').serializeArray() );

});

});

});
</script>

This jQuery function simply binds an onChange event to every form on the page it finds with the id: Form2BeTracked.   This is an easy to deploy script site wide and has no impact on the normal form behavior.

The code on the proccessFormProgress.cfm is all of 3 lines :

<cfparam name="client.formProgress" default="#session.cfid##session.cftoken#">
<cfwddx action="cfml2wddx" input="#form#" output="wddxSession">
<cfset client.formProgress = wddxSession>

This code takes the entire Form Struct and saves it into the client scope/database

Form data is saved real time in the client scope.

The nice part about this is that by default, ColdFusion saves the list of form elements in the form.fieldnames variable. Using that we can get a count of the number of variables for this form, and then see that only 2 of the fields were filled out and what the values of those fields are. All of this without the user clicking submit.

Step 2: Clear data on form submit

If the user submits the form, we need to clear the data in the client variable. This is an easy one line of code to be added on the page that handles the normal submitting of the form.

<cfset client.formProgress = "">

This will clear the form data out of the client variable. This is an important step that can not be skipped or your count of abandoned forms will be inflated.

Step 3: Check for abandoned form data

By saving the form data in the client scope it will be held there in the database for as long as the time frame defined in the ColdFusion Administrator. This setting will determine the frequency that you must check for abandoned form data.

select cd.cfid, cd.data, cg.lvisit from
CDATA as cd join CGLOBAL as cg
on cd.cfid = cg.cfid
where cg.lvisit >= (your timeframe here )
and cd.data like 'formprogress%'

This should pull a result set with all the records of form data that has been saved. ie. abandoned.

With a little ColdFusion magic

<cfquery name="abandoned" datasource="#REQUEST.dsn#">
	select cd.cfid, cd.data, cg.lvisit from
	CDATA as cd join CGLOBAL as cg
	on cd.cfid = cg.cfid
	where cg.lvisit >= GETDATE()-1
	and cd.data like 'formprogress%'  

</cfquery>

<cfset variables.wddx2Convert = abandoned.data>
<cfset variables.wddxLen = len(variables.wddx2Convert)>
<cfset variables.wddx2Convert = right(variables.wddx2Convert,variables.wddxLen-13)>
<cfset variables.wddx2Convert = replacenocase("#variables.wddx2Convert#","##","","ALL")>
<cfdump var="#variables.wddx2Convert#">

<cfwddx action="wddx2cfml" input="#variables.wddx2Convert#" output="variables.form">

<cfset variables.formElementList = variables.form["fieldnames"]>
<cfset variables.formElementCount = listlen("#variables.formElementList#")>

<cfset variables.formList = "">
<cfloop list="#variables.formElementList#" index="formItem">
	<cfset variables.tempValue = variables.form["#formItem#"] >
	<cfset variables.valuePair = "#formItem#:#variables.tempValue#">
	<cfset variables.formList = ListAppend(variables.formList,"#variables.valuePair#","|")>
</cfloop>

You end up with a variable string that you can then submit to Omniture using the Data Insertion API. See this post on details if the API.

As you can see from the image above, you now have the count of the form elements in the form along with the data values from the form elements that were filled out before the user abandoned the form. With this, you can choose what format would be the most useful for your needs to really dig into abandoned forms.

-Rudi

Share/Save

Note: After you choose which s.prop you are going to use to store/capture the data in, you will need to contact Omniture Client Care to get pathing enabled for that s.prop

Where does your path take you?

In a previous post, I went over how we capture the search terms from the Google Mini. So when I returned from the training, I contacted client care and had then enable pathing on the s.prop and "Shazam!". We now have pathing on the internal search terms.

This has been working great, and I've been really pleased with being able to see exactly how visitors refine their searches. Recently, I had the opportunity to chat with Susan Fariss, at the American Chemical Society (@soozantf) about search analytics and the questions came up on do we know where the user was on the site when they initiated the search and then what search result did they click on.. if any? Well... I did not have those answers, but I sure wanted to.

So the question was could the following be accomplished:

• Detect/capture where visitor was on the web site when the search was initiated
• Modify the google mini xslt to tag all of the search results so that the result clicked could be captured
• Would this provide the full search pathing expected

Detect/capture where visitor was on the web site when the search was initiated:
This was the easy part of the adventure for sure. I already had a JavaScript function handling the initial search, so I added another function call in that

			function recordInternalSearchOmniture(){
				var s = s_gi(s_account);
				s.linkTrackVars="prop1";
				s.prop1 = s.pageName;
				s.tl(document.location.href,'o','InternalSearch');
				s.linkTrackVars="";
			}

This code snippet simply pulls the s.pageName and puts it into the same s.prop used to store the actual search terms, creating the "entry point" of our search path.

Modify the google mini xslt to tag all of the search results so that the result clicked could be captured:
This proved to be the pesky part of the adventure. The challenge was to be able to add the jQuery function to tag the search results someplace where the Google xslt could access it. After a few missteps I added the jQuery to a main .js file (not the s_code.js) that I was able to link to inside the xslt. But first I needed to add a div with a specific Id to the xslt so that I would be able to tag the results with the tracking codes. So inside the xslt I did the following.

<!-- **********************************************************************
 Search results (do not customize)
     ********************************************************************** -->
.
.
.
<div id="googleSearch">
<!-- *** Customer's own result page header *** -->
.
.
<!-- *** HTML footer *** -->
</div>

So find the section that says "Search results (do not customize)" - I viewed this as more of a suggestion than a hard rule. Inside this section, wrap the header/footer items with a new div with the id of "googleSearch" (or some other id of your choosing). This is needed so that the jQuery function can find the elements that need the new tags. Once that div is in place add a jQuery function to find all results in that div and tag them. The first function below binds a function call to the a href tags in the search results. The second function does pulls in the location of the search results and records where the user clicked. This provides the "exit point" to our path.

$(document).ready(function(){
$('#googleSearch a').each(function(i) {
  var hrefval = $(this).attr('href');
  $(this).bind('click',function (event){
  	omniGoogleSearchResultClicked('Search Result Clicked',hrefval)
  	});
});
.
.
function omniGoogleSearchResultClicked(propTitle,hrefVal){
	var s = s_gi(s_account);
	s.linkTrackVars="prop1";
	s.prop1 = hrefVal;
	s.tl(document.location.href,'o',propTitle);
	s.linkTrackVars="";
}

Would this provide the full search pathing expected:
Yes! This does indeed provide a full search path.

I knew IE6 was evil!

Ok..  so maybe I changed the actual values, but this is the type of search pathing you can achieve with tracking the entry and exit points in the same s.prop as the search terms and having pathing enabled on that s.prop.

-Rudi

Share/Save

Problem: How do you take a static list of hyperlinks on a set of pages and go about setting up some method to tag each of these links with a Javascript call to Omniture.  Also trying to put in some type of future proofing so that ongoing updates to this file(s).

Environment: ColdFusion8 Server / jQuery

My Approach:

$(document).ready(function(){
   $('#divToBeTagged a').each(function(i) {
       var hrefval = $(this).attr('href');
       $(this).bind('click',function (event){
          omnitureJSCall('Product Category',hrefval)
       });
    });
});

I went with this for a few reasons, the main one being the ease of future updates to this page. I work on a small team of dev's and anyone else could be making updates to this page and with this method, we will always have the correct tags on our product downloads on this page. Is it perfect? Nah... but it does work well for me.

-RRS

Share/Save