In a recent project we had to build a vast amount of webinar registration, whitepaper download and contact us forms in 19 different languages. The total amount of forms was 418, meaning that the expected outcome or action of each form was unique. For example a gated download form had to deliver a link to a number of individual PDF documents (one per form) or perform different actions like webinar registrations depending where the form was called from. Obviously the forms had to be pre-populated. If a prospect fills a form to download document A, we should not ask him/her to key in all the data again when document B is requested etc.
Since building 418 forms is a formidable task even by using the new, fantastic form management tool in Eloqua 10, we thought there must be a better way.
On the form field level there were only two different types of forms:
- a small gated download form with just basic contact information fields
- a more complex contact us and webinar registration form with additional fields
We ended up building 38 unique forms, one of each form type for each language (19+19). We thought we could have even reduced this to only 2 by parameterizing the languages, but we felt that this would lead to an overly complex form. Handling the languages separately made for example the form validation part easier, since we could use Eloqua’s own validation system.
Without going too much into details, this is what we did and how we will instruct our employees to do in the future:
Plan well ahead and map the differences and similarities between all your forms. Build one form of each type first as readyas possible and test it properly. Set up validation and all processing
steps needed. Once everything works and is approved by the client, then save the form as a template and use it to create language versions by modifying field labels and validation error messages.
Let’s say the URL ofthe gated download form on Eloqua is http://marketing.yoursite.com/ENdownload.
When called in context of downloading document A, the URL becomes http://marketing.yoursite.com/ENdownload?doc=documentA.
Create a processing step “Redirect to Web Page” determined by this form field.
- Making system-wide changes to your scripts is much easier when the files are stored in single location.
- Script editing is more convenient using a professional code editor with code highlighting and FTP capabilities (UltraEdit is my favorite).
Use custom data objects to store all form data. There are multiple benefits:
- You don’t need to consume contact or account table fields for data that really doesn’t belong there
- Custom data objects can be used for profiling
- All form activity data is stored in one location and can be exported easily (without going into each form individually and taking the “View Submission Data” option.
Note: If you want to capture multiple actions per user instead of updating a single data row, leave “Select the Key Field” undefined.
If you set the email address as the key, only one record per user will be created.
Do not embed the Eloqua forms inside iFrames on client’s corporate website. Even if it works most of the time, you should not because:
- Layout issues: If you later need to modify the form page size (add text, add fields), you would have to also change the iFrame size on corporate web CSM (at every form instance in the worst case).
- Tracking and pre-population: In most cases both do work, but depending of the user’s browser security settings, the Eloqua cookie may be rejected (as a 3rd party cookie) leading to mismatch in tracking and preventing pre-population.
If you really have to have the form on the actual website, build it there and just integrate it to Eloqua.
Always add a processing step “Add to Program” to every form, even if you don’t need it for now. Create a one step program in program builder doing nothing and activate it. This enables you to later extend the functionality of all your forms without tweaking each and every form individually. Program builder is very powerful and with it you can implement complex conditional processing that can’t be done using the form processing steps.
You can easily integrate the webinar registration functionality to your Eloqua forms using “Post Data to Server” processing step to submit data into Eloqua and to an external webinar system in one pass. To manage this, we studied the webinar system’s (GoToWebinar in this case) registration form HTML and duplicated the fields with proper default values as hidden fields on our Eloqua forms.
The benefits are:
- One form submits data to two systems, Eloqua and GoToWebinar.
- You don’t have to add “Send Submitter an Email” processing step to your Eloqua form, since GoToWebinar will send it for you and does it much better (including all webinar details, phone numbers, cancellation and add to calendar links etc.)
This article explains the form setup side of the campaign my colleague Tero Rantaruikka explained in his fine article: