Has anyone else noticed a change when uploading unicode files? I tried several different methods of uploading a file (including this Import a Non-Latin Characters List - Marketo Docs - Product Docs), but I always seem to have to retype the headers in the upload process:
I also noticed that the bottom of the form says that zero fields are ignored, but that's definitely not the case.
Any one have insight or want to vent about the same issue?
I noticed it once when I used an incorrect header format in the csv file after I chnaged the header name it worked fine.
Hey Addy - Thanks for the note. I haven't noticed any issues with Tab Delimited or CSV files myself. Do you import lists containing Asian characters using CSV?
CSV should never be used for advanced/alternative character sets - always use Unicode Text. It's also worth mentioning that you should always define the file format and never leave this field as "auto-detect" (I wish Marketo would just remove that option) as this often causes issues. When importing Unicode Text, be sure to select "Tab Delimited".
It also looks like you have some invalid characters in your header row:
Hey Dan,
Thanks for your response. The form is automagically changing the header after I start the upload process. I've already tried copying and pasting the entire spreadsheet into a different file and saving it like that. No luck. I tried rewriting all of my column headers and saving the file like that. Same thing. I also never choose the "Auto-Detect" option and totally agree with you that it should be eradicated from the menu. I opened a ticket with Mkto Support in hopes to figure this out. This issue is becoming a timesuck for the leads that can't be updated/created via API.
Thanks again,
Danny T.
Hi everyone,
We're experiencing the same issue. We've been uploading Unicode .txt files from a standard upload template for the last 18 months with no problems, always using the tab delimited option, and then suddenly this week we started havng the same problems that Danny is having. We haven't made any changes to the header or the columns and yet Marketo is picking up the strange characters before the Email Address field and then not mapping any of the columns to field names. Also worth noting that manually mapping the fields does NOT work... the record is imported, but the values don't map properly.
Something is definitely broken... support case also opened. Fingers crossed...
Gary
This issue exists for us as well. After selecting the list and setting the options, we see this:
After manually selecting the proper fields to map, the import results in new leads with no data!
This is a huge issue for us as we are a global company. We import program members weekly (and sometimes daily) containing leads with special characters.
Marketo Support came back with the following (even though I told them that Unicode text file imports have worked for years in Marketo):
We are only supporting UTF-8, UTF-16, Shift-JIS and EUC-JP as per documentation. Could you provide a list of an import that used to work so I can compare? As a workaround, could you in excel do a save as and save it as a tab delimited format? That should save it as a UTF-8 format and you should be good to import it.
So I decided to try this alternate approach. When I saved the file as "tab-delimited" (vs. Unicode Text), the data in that file contained the special characters. So that was encouraging. But unfortunately, Marketo replaces all of those characters with question marks after it has been imported:
I'm not quite sure why Marketo Support isn't recognizing this as a bug - that just surfaced this week with multiple customers - rather than say "we don't support the file type you're trying to import"
We've been doing some more testing today (in spite of Marketo telling us that they can't replicate the problem!)... and we've had some success with saving as a csv with UTF-8 enabled and then importing with 'auto-detect' enabled. Seems to keep the special characters and map the fields... we're going to run a few more tests in the morning, but it seems that at least this is a workable alternative.
Just need to be careful about having commas in our address fields now, I guess!
Unfortunately, that didn't work for us. We tried the following:
And all resulted in black diamonds with questions marks to represent the special characters.