List imports in Marketo without the dirty data

Why imports do more damage than sends

A bad email embarrasses you once. A bad import keeps paying out. A few thousand rows with the wrong country values break every regional smart list, every sync rule that keys on country and every report that groups by it and the symptoms turn up weeks after anyone remembers the spreadsheet. An import that overwrote Person Source on existing people, or dropped a purchased list into a nurture, has the same shape: quick to do, slow to find, slower to undo.

That is why Ops teams that happily let marketers send email still insist on doing every import themselves and why import requests pile up in the ticket queue faster than anything else. Eloqua teams have the same problem with the Contact Upload Wizard, covered in its own guide.

How a list import works

In Marketo a file is imported into a static list. Adobe’s walkthrough creates the list as a local asset inside a program, then uses List Actions and Import List. You browse to the CSV, choose an import mode, map each column to a Marketo field, pick options such as the person partition and an acquisition program and click Import. A progress window reports when it is done and the people appear on the program’s Members tab. Importing members into a program directly works the same way, with a Member Status chosen for everyone in the file.

The file

The file must be encoded UTF-8, UTF-16, Shift-JIS or EUC-JP and “the size limit for CSV files is 100MB.” Adobe recommends that “column headers should always match the field exactly (case sensitive) to achieve the best auto-mapping results,” and a custom field has to exist before a column can be mapped to it. Any column can be set to Ignore. Dates go in month/day/year format and “any date/time fields being imported are treated as Central Time.” Email addresses need ASCII characters only.

Matching and updating

Marketo matches rows to existing people by email address. A match updates that person’s fields with whatever the file says and adds them to the list. No match creates a new person. Fields in the file overwrite fields on the record unless the column is ignored or the field is blocked which is the main way existing data gets damaged.

Import modes

The wizard offers two modes. Default does everything above: creates, updates, adds to the list and logs activities. Skip new people and updates adds only people who already exist to the list and Adobe describes it as skipping new person creation, field updates and activity logging. It is the safe choice for a list of known contacts, with one side effect: because nothing is logged, triggers and filters that depend on being added to the list don’t see those people. There is no mode that updates existing people without creating new ones, a combination the community has asked for.

Blocked fields and untrusted imports

The strongest native protection is Block Field Updates under Admin, Field Management. For a field such as Person Source you choose which input sources may not update it and Marketo keeps the original value for the lifetime of the record. List import is one of the sources and a second option blocks a field only for imports marked Untrusted which the importer picks at import time. One caveat from Adobe: if a column is mapped by hand instead of matched by name, the import preview won’t show that the field is blocked, “but update-blocking to that field will still be implemented.”

Blocking is field by field, set by an admin, and it is designed to protect existing values rather than to check what goes into empty fields or new records.

Activities and what they trigger

A default import logs an activity for every person added and every field changed. Trigger campaigns that listen for data value changes, scoring, routing, CRM sync, fire for every row. Adobe adds a warning that “importing NULL values via CSV can generate a Change Data Value” even for fields that were already blank which can qualify people for campaigns nobody expected the import to touch.

What the import doesn’t check

Put a well-meaning marketer in front of the wizard and the same handful of things go wrong, none of them caught at import time.

• 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.
• Fields that weren’t blocked get overwritten. Job titles the CRM owned replaced by blanks or placeholders, because nobody blocked that field and the import mode was Default.
• Consent never makes it in. The file has an opt-in column, or it doesn’t and nothing in the wizard asks whether these people agreed to hear from you or records the source and date if they did.
• The partition and the acquisition program are left at whatever the drop-downs showed first so the people land in the wrong database and the wrong program gets the credit.
• The wrong list. A file meant for an event lands in the list that feeds a nurture.
• Duplicates in the file collapse onto one record with the last row’s values.

By the time a smart list count looks wrong the records are mixed in with everything else and the activities they logged have already fired whatever they were going to fire.

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 import. 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. Import List says who may use the wizard. Block Field Updates says which existing values survive it. Neither can say “only files with these columns,” “only ISO country codes,” “always into this list with this acquisition program” or “never without a consent column.” Those rules live in Ops’s heads and in a document nobody reads, and the wizard was never meant to enforce them. Roles in general have the same limit which the roles and permissions guide goes through.

Validation before import in Campaign Launchpad

Campaign Launchpad makes the import 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 which list the people go to, which program gets the credit and what else happens to them. When a marketer uploads a file Launchpad checks every row against those rules before anything is written to 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 import 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 import fed which send.
• Launchpad imports people and custom object records so the same validation covers event registrations and product data as well as plain 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.

The import 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 imports are a large share of your queue, the request intake guide covers how to find out and what to automate first.