Marketing automation is fueled by data – what you store in Oracle Eloqua, how the data comes into Eloqua, and how you structure the data. These factors are key to effective segmentation, personalization, and campaign workflow design. Although you may have experience with other Marketing Automation Platforms, Eloqua has a much more flexible data model than other MAPs. This flexibility requires a different thought process. It’s important to understand how Eloqua works and to be open to a different approach to achieve your ultimate automation goals.
Understanding the Eloqua Data Model
Contacts
Contacts are the primary entity in Eloqua. They are unique by email address, even when using a different identifier, which in general, we don’t recommend. Contacts come with several built-in fields and can have up to 250 additional custom fields. Contacts relate to other entities in the following two ways:
- Many-to-one to Accounts: Meaning each contact can only be associated with a single account.
- One-to-many to Custom Objects: Each contact can have multiple records within a single custom object (or custom table). For example, in a purchase history custom object, a contact will have records in the object for each unique purchase.
Accounts
Typically, accounts are only used when there is a CRM integration. Accounts allow for a different approach to segmentation. Like contacts, accounts also have several built-in fields and support up to 250 custom fields. Accounts relate to other entities in the following two ways:
- One-to-many Contacts: Every account can have multiple contacts in the database.
- One-to-many Custom Objects: Similar to contacts, a single account can have multiple records in a custom object.
Custom Objects
Custom Objects (CDOs) are custom tables and best used to store information that does not apply to the entire database. Custom objects are often used to bring in data from your CRM system but have a variety of use cases. For example, CDOs can be used to store event data, opportunities, purchase data, or unique form submissions. All Eloqua databases have three custom objects that can be re-purposed. Customers who are on the Standard trim or higher can create new custom objects. Oracle recommends limiting CDOs to 50 fields per CDO, but the actual system limit is 1024 fields per object. There is also a limit of 25 million total custom object records per instance of Eloqua. Additionally, CDOs do not support multi-select lists like contacts and accounts. CDO text fields are also longer at 250 characters as opposed to 100 characters on contacts and accounts. CDO relationships can be set up as:
- One-to-one Contacts or Accounts
- Many-to-one Contacts or Accounts
CDO records cannot relate to one another and a single record can only relate to one other contact or account record. Many-to-one relationships are established by creating multiple unique records.
Opportunities
Opportunities are used for Closed Loop Reporting, which shows Marketing’s/Eloqua’s influence on revenue. These are not to be confused with opportunities stored in CDOs for segmentation.
Opportunities relate either to the primary contact or account.
Other Entities
Other entities include picklists (also called single-select lists), and lookup tables. Picklists make it easier to segment and audit data. A good example is when Eloqua is integrated with Microsoft Dynamics because Dynamics stores many values as GUIDs like, “3275FAA8-D737-EA11-80EE-00505683E851”. It’s a lot better to have these values in a picklist with their associated human readable label.
Lookup tables are a simple way of replacing bad values with good ones. Lookup tables are only available with Data Tools, so make sure you have a Data Tools as an add-on under the Audience menu to try them out.
Data Flow: How is the data coming in?
Once you have your data model defined you need to consider how data will actually get into Oracle Eloqua. There are several ways data can flow into Eloqua. The following is a list of the primary sources:
API (BULK/REST) Integration
Eloqua has a variety of APIs. Consider the other options on this list carefully before deciding to proceed with an API integration. API integrations take a great deal of planning, careful execution, and experienced personnel. The BULK API is most commonly used when moving large amounts of data into and out of Eloqua. For example, many sports teams use the BULK API to import ticketing information. The REST APIs are used for smaller tasks that require more of the native functionality within Eloqua such as pulling a list of active campaigns.
Native CRM Integration
The term ‘native integration’ refers to the original method for integrating CRM with Eloqua. This approach uses steps within Program Builder (a feature that will eventually be retired) to connect to CRM systems. Eloqua currently integrates with Microsoft Dynamics and Oracle CRM On Demand using the native integration. Microsoft Dynamics (at the time of this article) is being migrated to the new cloud app integration. The native integration will eventually be sunset.
Cloud App CRM Integration
Oracle CX Sales and Salesforce can be integrated through the cloud app-based integration, and leverage Program Canvas, an automation workflow engine within Eloqua. The Cloud App approach to integrations will be supported by Oracle going forward and will benefit from modern security standards, improved UI/UX, and greatly increased speeds and load handling.
SFTP
Uni-directional and bi-directional integrations can be built using flat files and an SFTP server. These integrations are generally much simpler than API or native/app integrations. Although SFTP has some disadvantages, it’s still a viable option. Having an SFTP integration might be the best solution for your data import needs. SFTP is most often used by organizations that have a proprietary or non-supported CRM system. SFTP is also an easy way of extracting data to translate and load into a data warehouse or to do reporting on.
Eloqua Form Submissions
Form submissions are one of the most common methods of feeding data into Eloqua. In most cases, contacts will submit forms that are hosted on Eloqua landing pages or on your website. But there are scenarios where other systems can be set up to send data to Eloqua through form submissions as well! For example, some organizations use FormStack for an enhanced form experience. Those forms enter Eloqua via a webhook.
List Upload
List uploads are also a common and simple way to import data into Eloqua. This is especially the case for organizations without a CRM or those who have not yet integrated but is often used when data is acquired using other systems such as an events management system. As a best practice, we recommend creating an import template or standardized process for importing data to ensure consistency.
Know what Data Priority is and why it is important
Data Priority is a hierarchy of all data sources (excluding forms) that point into Eloqua. The higher a data source is on the list, the more important or clean the data is. Data sources lower on the list can have their associated fields overwritten by those above but cannot override what the higher-level sources have written. This feature exists to protect you from yourself. If you ever find some data is not loading from a list upload, data priority is the likely reason.
Data Hygiene & Health
What is the plan for the data point?
As a general best practice, don’t include it if you don’t need it. Your goal should be to only store data that will be used for segmentation or personalization in Eloqua. Start small and add new fields and data as needed. In the long run, it’s much more difficult to remove fields (solve dependencies, remember what the field was for, and so on) than it is to carefully consider whether a field should be added in the first place. Also consider the best place for the data – would it make more sense to store it in a CDO than on the contact? Did you choose an appropriate data type to support the segments you will be running? More broadly, what is the strategic importance of the records and data you will have in Eloqua? Finally, if there is any sensitive data, be sure you have the HIPAA or Data Privacy add-ons if applicable.
Keep your data clean from the start
DO
- Create fields with the correct field type and data type
- Use the correct field type and data type for form fields
DON’T
- Use multi-select lists. Multi-select lists can be confusing to web users and don’t work well in segmentation. Instead use individual checkboxes stored in a custom object.
- Misuse data priority. If your list upload isn’t writing data to the Eloqua contact, it’s usually because something higher in the data priority wrote in data. This is by design. A common issue here is when CRM has written in data. Instead of changing the order of the data priority, consider updating the records in CRM instead, or trusting the data from CRM to be more accurate.
A successful Eloqua implementation is that much closer now that you know a little more about the inner workings. Preparing your data, the structure and potential integrations ahead of time will help you create the framework you need to keep Eloqua running smoothly far into the future. This is just one important stop on your modern marketing journey. Contact us today to learn more and to ask us any questions!