Contact uploads in Eloqua without the dirty data

Why uploads cause more damage than sends

A bad email embarrasses you once. A bad upload keeps paying out. Ten thousand records with the country in the wrong column will break every regional segment, every CRM sync rule that keys on country and every report that groups by it and nobody will connect the symptoms to the spreadsheet a marketer uploaded after the trade show. The upload that overwrote the lead source on existing contacts, or added a purchased list to the newsletter group, has the same shape: quick to do and slow to find.

That is why Ops teams that happily let marketers send email still insist on doing every upload themselves. It is also why upload requests pile up in the ticket queue faster than anything else.

The Eloqua Contact Upload Wizard

Oracle’s Contact Upload Wizard lives under Audience > Contacts, as Upload Contacts in the Redwood experience or Upload in classic. It handles more than adding people. The Import Purpose drop-down covers adding or updating contacts, changing email addresses, unsubscribing contacts from lists, marking hard bouncebacks, deleting contacts and, with the SMS add-on, changing SMS opt-in status. Picking the wrong purpose is the first thing that can go wrong, and Oracle’s page reminds you to be sure to click the correct type.

The file

The wizard takes .txt, .csv, .xls and .xlsx files. Fields can be separated by commas, pipes, tabs or semicolons. The first row must be column headings and “Oracle Eloqua will attempt to map the headings to existing contact fields.” Contacts need a unique identifier, usually the email address. Oracle’s troubleshooting page adds that heading names must be unique and no longer than 100 characters, that commas inside a value need the value wrapped in double quotes, that dates should be in the required format, often YYYY-MM-DD, that files over the limit of “usually up to a few MBs” may fail and that duplicate rows should be removed because “duplicate data can cause rows to be merged.”

Mapping and update rules

After a preview the Map Fields step shows each column against the contact field Eloqua guessed for it. The user confirms or changes each mapping and then chooses for each field when it should update, for example only if the existing value is blank. Set to default applies the rule an administrator configured per field under Settings > Manage Fields and Views. Oracle notes one quirk: when the default is Update if new email address the upload actually uses Update if new value is not blank.

The last step offers to add the contacts to a shared list and to save the settings for next time. Then Finish and the rows are written. If a contact was recently updated by the CRM the upload may not change it because of data import priority which an administrator sets under Settings > Integrations.

What Eloqua checks

The wizard validates the file’s structure: the format, the headings, that every column is mapped. It rejects email addresses containing non-breaking spaces. It does not check that a country column holds countries, that a date column holds the date you think it does, that a picklist field received a value on the picklist, that a yes/no opt-in column was mapped to the consent field or mapped at all, or that the people in the file have any business being in your database.

Scheduled and SFTP imports go through the separate data import tool under Audience > Tools which needs its own permission and is subject to a 30-minute timeout. It validates the same things.

Marketo’s list import has the same blind spots and a few of its own and the Marketo list import guide goes through them.

Where the dirty data comes from

Put a well-meaning marketer in front of the wizard and the same handful of things go wrong.

• The mapping screen asks them to confirm guesses about fields they have never seen. Company becomes Company Name, or Account, or the wrong custom field and they click Next because the screen looks finished.
• Values don’t match the field. “United States,” “USA” and “US” in one column, a picklist field fed free text, a date in the wrong order that silently becomes a different date.
• Update rules overwrite data that was right. A column of blanks or placeholders replaces job titles the CRM owned, because the default rule for that field was never set with marketers in mind.
• Consent never makes it in. The file has an opt-in column, or it doesn’t and either way nothing in the wizard asks whether these people agreed to hear from you or records the source and date if they did.
• The wrong purpose or the wrong list. A file meant to add people to an event list is run as an update across the database, or lands in a shared list that feeds a nurture.
• Duplicates in the file merge into one record with the last row’s values, as Oracle’s page warns.

None of these are caught at upload time because nothing at upload time knows what your fields mean. By the time a segment count looks wrong the records are mixed in with everything else and the only fix is another upload, by Ops, with a file somebody has to reconstruct.

Why the permission alone isn’t enough

The native answer is to take the permission away and that is what most teams do: nobody outside Ops may upload. It works, in the sense that the database stays clean and every file goes through someone who knows the fields. It also means that every list is a ticket with an attachment, Ops spends its week reformatting spreadsheets and the marketer who needed the list loaded before the webinar waits with everyone else.

There is no setting in between. The permission says who may use the wizard. It can’t say “only files with these columns,” “only ISO country codes,” “never overwrite these fields” or “only into this list.” Those rules live in Ops’s heads and in a document nobody reads, and the wizard was never meant to enforce them.

Validation before import in Campaign Launchpad

Campaign Launchpad makes the upload a step in a wizard which means Ops gets to say in advance what a valid file is. For each wizard that accepts a list Ops defines the columns it must contain, the values each column may hold and the format each one should be in, along with where the records go and what else happens to them. When a marketer uploads a file Launchpad checks every row against those rules before anything is written to Eloqua or Marketo. Rows that fail are shown to the marketer with what is wrong so the person who has the original spreadsheet fixes it rather than Ops guessing at it a day later.

A few other things follow from treating the upload as part of the campaign:

• The import can need approval, with as many levels as Ops wants so a large or unusual file is seen by a person as well as by the rules.
• The list is tied to the campaign that uses it so the audience and the send are one request with one audit trail and Ops can see later which upload fed which send.
• Launchpad imports contacts and custom object records so the same validation covers event registrations and product data as well as plain contact lists.
• When a file needs something the rules can’t handle, say a one-off deduplication against a partner list, the wizard hands that step to Ops with the file and the conversation attached rather than failing silently or letting it through.

BMC Software, one of the teams using Launchpad, describes list uploads as one of the two jobs they moved to self-service with it, alongside deploying email campaigns. The upload is the job most Ops teams are most reluctant to let go of and it is also the one where rules checked by software beat rules remembered by people by the widest margin.

If uploads are a large share of your queue, the request intake guide covers how to find out and what to automate first.