Tuesday, June 2, 2009

Form Resubmits: Doing Two Things at Once

Web forms are one of the most valuable sources of leads, insights, and data for the marketer. Web forms can be used to allow prospects to self identify and request a conversation with sales, they can be used to gate access to valuable content in exchange for information, and they can be used to garner additional insights about prospects.

Passing this data into Eloqua is, of course, a very valuable thing for marketing to do. However, there may be instances where the form submit is used for another action and the data needs to be passed forward. For example, the form might be the start of a download of a free trial, and the information is required for configuring the license key. Similarly, the form might be used for searches within the web site, and the data needs to be passed forward to perform the search.

This dual purpose form use can be done easily within Eloqua. There are four main ways that forms can be handled in which the data is provided to both Eloqua and a secondary system:

1) The form can be submitted to Eloqua, the data captured, and then the visitor’s form resubmitted to another URL (such as a trial download or a search page), which then handles the visitor’s experience itself

2) The form can be submitted to Eloqua, which then posts the data to another server, before handling the remaining processing and the visitor's experience

3) The form can be submitted to the secondary application, and then automatically re-submitted to Eloqua, where the data is captured, and the visitor is presented with a landing page or a PURL page from within Eloqua, to complete their experience

4) The form can be submitted directly to another site, which then re-posts the data, server to server, into Eloqua after handling the visitor’s experience

The first option is the simplest and most commonly used. To do this, simply change the type of the final processing step. Normally, this is a Confirmation Page, but by selecting "Change Type" on the drop-down menu, you can change this to a Resubmit Form step. Configure the step by defining the URL to send the form data to. The identical data that was submitted to Eloqua will be resubmitted to the secondary system, which will complete the web visitor's experience.

For the second option, select the "Post Data to Server" processing step type. This will send the form data to the server you select. You will also select whether you are submitting the data via a "Post" method, or a "Get" method, a technical option that will be familiar to those versed in creating web forms. Select "Post" if you are uncertain, or ask your web master. After the forms is submitted, the rest of the processing and the conclusion of the visitor's experience will be handled by Eloqua.

The third option relies on being able to configure the secondary system to resubmit the form to Eloqua. This is less common as not every system is configured to be able to resubmit form data. However, if it is, this is a similar approach to the first option, but in the reverse order. In this case, configure the form as normal, but the final step would be presenting the visitor with a landing page to complete his or her experience.

The fourth option is much more technical, but does allow for some interesting options. The form is submitted to the secondary system, and the secondary system handles the visitor’s experience from there. However, at the same time, the visitor’s data is submitted, server-to-server to Eloqua. If you are interested in this option, it's worth a discussion with your customer success manager, as the setup of it will involve your technology team.

A key thing to remember in this fourth configuration option is that the visitor’s website cookie will not be automatically submitted as it is with web forms normally. As the cookie forms the core of the visitor’s profile, this is very important. Without it, you will not be able to associate the visitor on the website with the form submit, which prevents using the data for lead scoring or segmentation. With a quick configuration, however, you can easily configure the web visitor’s cookie to be passed in to Eloqua from the secondary server. This allows the seamless linking of the web visitor with their form data, even though there was no direct submit.

With whichever of these four options you select, you can quickly and easily configure a form to be submitted to both Eloqua and a secondary system without any interruption. The flexibility of approaches gives you the ability to accomplish whatever you need, regardless of current configurations and limitations.


Chad H said...

There is an example on how option #2 is used to post data from Eloqua to GoToWebinar for your webinars. See: https://eloqua.helpstream.biz/DocumentRevision.jsp?docId=8a7e8d4c20b8098c0120f32c33560188

Steve Nakata said...

We've implemented option #4 for a couple of clients. With one, we push the data to the secondary system using a form post; with the other, we push the data using the secondary system's API. With both clients, we push the data into Eloqua using the API.

We needed to go to the secondary systems first since we had to retrieve information specific to those systems and pass them into Eloqua.

In both cases, we capture and pass the cookie info so that the visitor is associated to the form submit--gotta have that!