Use Eloqua Web Data Lookups to Drive Landing Page Personalization

If you’ve used Eloqua for a while, you may have already heard the term “Web Data Lookups”.  It is thrown around from time to time when discussing things like form pre-population or landing page personalization. Simply put, Web Data Lookups (WDLs) allow a web page to retrieve data from Eloqua and utilize it in landing pages for personalization.

What are they?

WDLs are made up of several blocks of JavaScript code on a landing page that query Eloqua’s database for a specific piece of data using one or more unique identifiers. If data is located, it is returned to the landing page where the waiting code takes it and utilizes it to drive additional functionality.

What can they do?

Eloqua’s WDLs can retrieve the following types of information:

• Data from a contact record field
• Data from a visitor profile
• Data from a custom object record
• The subscription status for an email group

They can also return the total number of records for a specific custom object, though that information typically has application outside of personalization.

What can I use them for?

There are a lot of different ways WDLs can be used on your landing pages. Some common examples include:

• Direct a user to different landing pages based on whether they are known or unknown to Eloqua
• Display different content on a landing page for users that are subscribed to a specific email group
• Trigger a registration form if an email address is unknown to Eloqua
• Pre-populate a preference center form using a combination of contact information, email group subscription information, and custom object data

How do I create and use them?

Create a web data lookup in 7 steps:

1. Log into Eloqua, and navigate to “Assets” → “Website Setup” → “Web Data Lookup”
2. In the menu bar on the resulting screen, click “Data Lookup” → “New Data Lookup”, or click on the “New Data Lookup” in the main section of the screen; you’ll see the following:
   
3. In the “Data Lookup Name” field, enter a name to reference your new lookup
4. Choose the type of lookup:
   • Contacts: This type of lookup is what you would use to return data from a field on the contact record.  One thing to consider if using a contact lookup is to set the “Restricted” option (shown checked here).  Having this option enabled prevents the lookup from returning any information if the visitor is not already linked to that contact record. We strongly recommend that this option be enabled to prevent any unauthorized access of personally identifiable information (PII).
   • Visitors: These are used to return visitor profile fields, which you can set up in Eloqua.  Doing so quickly returns pieces of information, like email address, to help identify a user. These rely on the Eloqua cookie, which contains the global unique identifier, or GUID.  Important note: This lookup type cannot be restricted and therefore should not be used for PII or other sensitive information.  Instead, use Contact lookups for those applications.
   • Custom Object Records: These return information from a custom object record selected by the field that you’ve specified to match against.
   • Contact Group Memberships: These return the email groups that the contact is a part of.  Like custom object records above, the data is associated with the field used to match against.
   • Custom Objects: Not to be confused with Custom Object Records, this lookup returns the number of records in a custom object. While important, this use is not typically applicable in this context.
5. Select an option for the data fields returned. If you’re creating a contact or visitor lookup, you can choose the fields returned by selecting a View in the dropdown menu. If you’re creating a custom object lookup, you will need to choose the custom object the lookup should utilize, and the lookup will return all the fields in the individual record.
6. Depending on the lookup type, you may be able to choose the field that should be used to identify the contact in the “Edit Lookup Criteria” section.  By default, this is usually email address, but you can change that and/or add new fields to the list as well.
   Note: You can only add new criteria fields after the initial creation of the lookup.
7. After saving, Eloqua will generate a unique key for the lookup.  This key will be needed to implement it on your landing page. Look for it in the “Data Lookup Information” section of the page, under the “Data Lookup Type” listing.

How do I Use the Eloqua-generated sample code?

Eloqua will also generate sample code for your lookup. If you click on “Data Lookup Options” in the upper right corner, select “Get Data Lookup Scripts”. You will then see the following:

You can now select what kind of script you would like Eloqua to generate:

• Sample display script: This script will list all the information returned by the lookup.  This is helpful because it gives you a list of all the fields that will be returned, as well as a basis for the scripting that will need to be written to utilize the data.
• Form auto-population script: In order to get this sample, you will need to select a specific form.  Eloqua will then generate a sample script to fill out that form.

Finally, there’s the implementation section.  This provides you with the JavaScript necessary to invoke the WDL you’ve just created.

Oracle has provided some additional documentation for using Web Data Lookups, but the sample code Eloqua provides can get you started!

Can’t field merges do the same thing?

I’m glad you asked! Yes and no. Field merges are also a way to pull information from Eloqua and insert it into different assets like landing pages, emails, and form fields. There are some key differences between them, however, and which one you use will likely be determined by your specific use-case:

• Field merges pull their information from Eloqua and inject it into the asset before it’s served to the user. As a result, field merges work much faster than WDLs. This is because they rely on JavaScript within the asset to load before they can query Eloqua for the information.  This path leads to a slight delay — usually 1 second or less — before the data is returned and the respective fields are populated. However, this also means that…
• Field merges only work on Eloqua-hosted assets. Because field merges pull information directly from the system, they only function on Eloqua-hosted assets. On the plus side, this means that they can be used in emails and forms as well as landing pages, while WDLs are restricted to landing pages only. It also means that if you need data from Eloqua for a landing page hosted outside of Eloqua, say on your corporate website, WDLs are the only option.
• Field merges can drive WDLs, but not the other way around. Because field merges function before the page is served to the user, and the web data lookups are performed after the page is loaded, the values returned by a field merge can be used to drive a WDL. If a field merge doesn’t contain any information, it’s removed from the landing page code completely when it’s served to the user.

Is there anything else I should know?

Here are some additional things to consider when evaluating WDLs:

• They rely on third-party cookies. This is probably the largest consideration with using WDLs as they are currently implemented. They rely on a cookie from the eloqua.com domain dropped in the user’s browser which contains a specific user ID (aka the “GUID”). If that cookie is not present, or if cookies are blocked/disabled, Eloqua doesn’t have any way to determine the user’s identity for the WDL to operate. This means that as web browsers continue to implement more user privacy measures, WDLs as currently implemented will cease to function. Currently, Firefox’s “Enhanced Tracking Protection” feature and Safari’s “Prevent Cross-Site Tracking” feature on iOS, which are enabled by default now, will prevent the WDLs from working as expected. And it would be reasonable to expect other browsers to follow suit in the not-too-distant future.
• They rely on JavaScript. If the user happens to have JavaScript disabled on their browser, they will not function. Field merges do not have this limitation. Also, they can be a bit complex to implement, so it helps to have someone with JavaScript development knowledge to assist.
• They are not instantaneous. Since WDLs are performed after the landing page has loaded, there can be a brief delay before the information is displayed.
• They require Eloqua’s asynchronous tracking scripts to be present on the subject landing page. This is because they utilize the tracking mechanism to perform the lookup back to Eloqua.

Are WDLs right for me?

The answer is the ever popular, “it depends”! Both WDLs and field merges can retrieve information from contact record fields, custom object record fields, and email groups. The difference comes in the intended usage.

Do you need to pull data into a landing page that is not hosted in Eloqua? If yes, then WDLs should be used.  In fact, they’re the only method that will work in this situation. Just be aware of the additional considerations mentioned above around cookies and browser privacy settings.

Is your landing page hosted in Eloqua?  If yes, then we highly recommend that you use field merges instead.  The exception to this answer is a use case that calls for a more interactive method of data retrieval.

We’re here to help!

If you need any assistance with implementing web data lookups on your landing pages, or need some guidance on how they can work for you, our team of Production Services and Marketing Cloud Consultants are ready to help, just let us know!

Thank you for subscribing!

Subscribe to our Thought Leadership Today