Skip navigation

Earlier this year I joined a company that was using Eloqua for their marketing efforts. Coming from a Marketo background, I had a good understanding of how Eloqua could operate. After taking the courses required up to this point, I've gotten a better understand of the internals and processes within Eloqua. One project that the company has been working on for awhile now is a full API integration between our custom CRM and Eloqua (we are currently using a FTP import). Of course, there's many factors to consider in such an involved project, but the first step I saw necessary was to create a Data Dictionary to document what is going on in our Eloqua instance so that we can make a solid plan for integration.


I've seen one other luminary post on here which briefly mentions the use of a data dictionary. As someone from a database background, a brief mention does not render justice to the utility that a data dictionary provides, especially considering how important it is to the integration and management of everyday Eloqua use.


You as a reader, I'm assuming probably works with Eloqua or some other OMC product as part of your job. But that's where the assumption ends! When we start working with these products, we come from various backgrounds, and encounter a unique instance of Eloqua per se, you can have a considerably different experience than the next user. There's a lot of variables, including your marketing initiatives, choice of CRM (if you have one at all), self knowledge of the platform, team size, maturity of your campaigns (some of us pick up where the last person left off, and others start fresh!), utilization of all the features available, etc.


But almost regardless of those factors, a data dictionary can be of great use for you, your team, IT, consulting, and any other stakeholders.


Ok Devon, but what does it do?


It serves as a reference document that lists out each data field within your Eloqua instance, along with other relevant information about each field, such as a description or the data types that can be stored within.


Why do we need one? Can't we just reference the Fields & Views under Settings?


Sure you could...but do you wish to rely on Eloqua to look at those fields? Click on each one to see their properties? Commit to memory a description, quirks, and notes about each one? What if you wanted to print it? Share it with someone else without creating Eloqua credentials or requiring them to sign in? Wouldn't it be best to list everything in one document that can be printed, shared, and easy referenced? That's why you need a DD.


How do I get started?


Glad you asked! In general it will be a spreadsheet, and one sheet will have a set row of column headers. Any additional features are completely up to you. For some of us, changes happen often to the schema and we must continually update and log these in our dictionary. For others, the changes are so few or trivial that you might not even bother to record them. If you think it will help you or someone else's job in the future, then do it.


In my DD, I have the following columns:



These are the headers that I find helpful, you might need to include more or less. Before I explain some of them, let's show you a quick example:


  • The display name is the friendly name that you see and use throughout Eloqua when you're building filters. You should at least have this column.
  • Database name is what Eloqua names it internally, you can find this name in the settings.
  • Object is the table of which the field belongs to. We don't really use anything but the Contact, so this wasn't necessary, but for you it might be.
  • Field type is the data type, which restricts what value can be stored. If it's a picklist, I usually include the possible values in the description within brackets.
  • Elq Default indicates if it's a field that just comes with Eloqua, meaning you cannot delete it.
  • And Desc is where you can put any notes about the field that you or someone else should know. Do we need better data? Why might it be blank? Maybe it was used before, but do you have a new field that will replace it? Are there multiple possible values that could mean the same thing? What does it mean in your CRM system? These notes can be helpful for when you're building out filters and you need to make sure that you're not forgetting about some data oddity that occurs within your CRM that poses an inconvenience for you.


In addition, because I came into a system already pre-configured, I deemed that some fields just weren't necessary or used at all. Because I'm not ready to delete them quite yet, or they're Eloqua defaults, I mark them in pink here as a note to ignore them. When I am ready to delete the field, I cut the row and paste it into another sheet labeled Retired Fields.


For those of you who are integrating with multiple systems that come into Eloqua, you might wish to add a column where you map the original field names from the other system with the corresponding fields in Eloqua. This way, when you're talking to stakeholders who use the other system, you know exactly what data each you're talking about.


So far, I've found this to be one of the greatest resources when it comes to dealing with the integration and day to day segmentations and filters, as I'm still trying to learn the system. With currently over 135 fields, we have plans to grow that even more once the full integration comes. Your marketing is only as good as your data! Do yourself a favor and put one of these together today. The time spent now will save you in the future.



Courses that inspired this post:

  • System Integration
  • Database Configuration

Filter Blog

By date: By tag: