Weekly ecommerce tips, deals & news.
A failed import is a product or customer upload that stops partway, skips rows, or writes wrong values. The file looked fine when you exported it. Something in the mapping, the encoding or the server gave out before the last row landed.
A failed import happens when the file and the store disagree about what the data means. Think of it as handing someone a form in the wrong language. Every field is filled in, and none of it lands where it should.
That disagreement can be structural or it can be a single stray character. Either way, the importer either stops or guesses.
Most failed imports trace back to the file rather than the store. First is encoding. A file saved with the wrong character set turns accented names and currency symbols into unreadable strings.
Next is the delimiter. A spreadsheet saved in one region separates columns with semicolons instead of commas. The importer reads the whole row as one field and gives up.
Then there are the value formats. A price written as a formula arrives as nonsense. So does a date in local order, or a number in scientific notation. Long SKUs are the classic case, because spreadsheets quietly rewrite them.
Column mapping sits underneath all of these. Your file calls a column Retail Price and the importer expects Regular price. Map it wrong and every value lands in a field that looks plausible and is not.
Finally there is the missing required field. An empty SKU or a blank product type stops the row, and sometimes the whole run.
Server limits break imports that the file itself would have survived. A large catalog takes time, and PHP execution limits end the request before the job finishes. The result is a half-written import with no error on screen.
Remote images are the slowest part of any product import. Each one is downloaded and resized while the run is open. A catalog with 4,000 images can time out on the images alone.
Memory limits do the same thing. So does an upload cap smaller than the file you are trying to send.
In practice, the fix is smaller batches rather than a bigger server. Splitting a 12,000-row file into four runs costs nothing and removes the timeout entirely. Visser Labs covers the wider process in its guide to data export and import.
A silent success is worse than a visible failure because nobody goes looking for it. The importer reports rows processed and no errors. Meanwhile the wrong column landed in the wrong field.
Prices are the expensive version. A mismapped column can publish a catalog at cost price, live, to every sales channel you run.
A preview run is the cheapest guard against this. Good importers show you the first few rows mapped to their destination fields. Reading that screen properly catches a mismapped column before it reaches a single product.
That is why the check after an import matters as much as the import. Open five products and compare them against the source file by hand. Then compare your product count before and after.
Failed imports are not counted centrally, but the data quality behind them is well studied. Research published in Harvard Business Review found that only 3% of companies’ data meets basic quality standards.
Businesses suspect as much themselves. In Experian’s global data management research, 95% of businesses reported impacts from poor data quality. Organizations believe about a third of their data is inaccurate in some way. An import does not create those errors, it copies them at speed.
The stakes are worth stating plainly. The US Census Bureau puts e-commerce at 17.1% of total retail sales, worth $340.2 billion in a single quarter. Your catalog is the storefront for that channel.
A failed import in practice is usually discovered by a customer or a sales channel. Here is a hypothetical example. Imagine a store with 4,200 products, updating prices ahead of a seasonal sale.
In this scenario, the price list arrives from a supplier as a spreadsheet. Someone opens it, adds a margin column, and saves it as a CSV. No export is taken from the store first.
The import runs for eleven minutes and then the page stops responding. The screen shows nothing useful. Somebody refreshes and runs it again.
As a result the catalog is now in three states at once. Around 2,600 products carry the new prices. Another 900 carry them twice, because the second run created duplicates.
Meanwhile the remaining products never updated at all. Worse, 40 SKUs that started with zeros lost them, so they no longer match the supplier’s codes.
Unpicking it is the real cost. Nobody can say which products carry a correct price without checking all 4,200 by hand. A restore would also wipe two days of genuine orders.
Nothing on screen reported an error. The problem surfaces two days later when a feed channel rejects the mismatched SKUs.
So the store changes the process rather than the tool. First, every import starts with a fresh export of the same products. That export is the backup and the column template at once.
Next, SKU columns are formatted as text before the file is saved. Then the run is split into batches of 1,000 rows.
The preview screen becomes a required step rather than a click-through. One person reads the mapped columns aloud before anyone presses run. It takes a minute and it has caught two mismapped columns since.
Finally, a five-product spot check runs after each batch, against the source file. In short, the store stopped trusting a screen that says done and started checking what actually landed.
| What you’re comparing | Failed import | Partial import |
|---|---|---|
| What changed in your store | Nothing, or very little | Some rows, not all |
| How obvious it is | An error you can see | Often no error at all |
| The risk it carries | Wasted time | Wrong data sold live |
| How you recover | Fix the file, run again | Restore, then start over |
A failed import announces itself, while a partial import hides. That is why the partial one costs more. So the useful habit is checking row counts after every run, even the runs that looked successful.
Usually a server limit rather than a problem with your data. Large files hit execution time or memory caps before the job finishes. The request ends and the screen often shows nothing.
Split the file into smaller batches and run them in sequence. If batches still stop, ask your host to raise the execution limits.
Your spreadsheet reformatted them before the importer ever saw the file. Leading zeros get stripped and long numbers become scientific notation. Both happen the moment the file is opened.
Format those columns as text before saving, or edit the CSV in a plain text editor. Then check a few values in the saved file itself.
Only if you took a backup or an export first, which is why both come before the import. There is no general undo for a bulk write. A restore is the reliable route back.
Do not fix a bad import by running another one on top. That buries the original error under a second set of changes.
A failed import matters because it writes bad data faster than any person could. One mismapped column reaches every product, every channel and every shopper at once. In short, the export you take beforehand is the cheapest insurance in the whole job.
Copyright © StoreOwnerTips.com. All Rights Reserved.
