Managing your catalog in bulk

The Import and Export links are waiting at the top of the list, in Products › All products.

The split between the two ways of working is fairly clear. The file is made for fields carrying a value: a price, a stock level, a reference, attaching a variant to its product. It handles the same move across a thousand rows as fast as across one. The product page is made for what convinces: the description, the order of the visuals, the complementary products. That's the subject of the guide "Getting your product pages right", and it's decided one product at a time.

A simple rule to settle it. If you're about to repeat the same manipulation more than about ten times, it's a file job. If each product calls for a decision of its own, it's a screen job.

A word on rhythm, because it changes how you organize yourself. The export is prepared in the background: an email tells you when it's ready, and the file waits for you in Settings › My files. The import works the same way, with its own email confirmation. On a large catalog, start the operation at a moment when you'll be able to come back to it a few minutes later.

This is the only mechanism to understand, and it explains most imports that produce something other than what was expected.

Each row of your file carries a product identifier, and each variant carries its own. Identifier filled in, the platform recognizes the item and updates it. Identifier left empty, it creates it. That's what makes the same file able to correct your catalog or to build a second one alongside it.

Hence the reflex that holds for any update: always start from an export, never from a blank sheet. The export gives you back two things you have no way of reconstructing from memory. The identifiers first. Then the exact column names, which the import reads to the letter: one misspelled column makes the whole file fail.

Two points attach to that, and they decide the shape of your file. A variant's reference is unique in the shop, and it's what lets you find your way around a thousand-row file. And a product available in three sizes takes up three rows, linked to each other by a shared column: price, stock and reference live on the variant, not on the product.

An import applies as it is: it modifies your products directly, and the previous state only exists in your file. So the whole safety of the operation rests on what you do before clicking, and it comes down to three moves.

Export your complete catalog first. Not one product, not just the collection you're working on: the whole catalog, with every attribute. That file isn't for the operation, it's your reference copy, and it's what lets you go back.

Work on a duplicate. The reference file stays closed in a corner, you edit a copy. A spreadsheet open for two hours always ends up receiving an accidental keystroke, and you want that to be on the copy.

Start with a small scope. The export can take just one collection. The first time you carry out an operation, export one collection, apply your change to it, import, then go and look at the result in your product list and in your app preview. What works on twelve products will work on a thousand.

This is where the file becomes a merchant's tool, because it does in one go what would take a day by hand.

Sales across the whole catalog, for example. The operation fits in two columns: the base price moves into the struck-through price, the reduced price takes its place in the price. You import, and the whole catalog switches over, struck-through prices included. At the end of the operation, the reverse import puts everything back.

What's worth remembering isn't the manipulation, it's what it lets you plan for: prepare the exit file at the same time as the entry file. Putting things back to normal is what gets forgotten, and it's what costs, because you discover it on a Monday morning with the catalog still on promotion. Your reference export is already that exit file, provided you kept it intact.

A blanket operation on prices is one tool among others. When your discount targets a period, an order value or part of your customer base, it's set in Marketing › Discounts › Discount list, without touching the catalog. The guide "Boosting your sales" sets out the comparison between the two.

Stock is read product by product in your list, it has its own screen in Products › Stock, and it's edited on the product page. That pace suits you as long as the movements are those of online sales, which the shop counts down on its own.

It changes as soon as your stock moves somewhere other than in the app: a delivery arriving, a day at the market, an end-of-month inventory. Then you have fifty quantities to correct at once, and that's exactly what the file does well. You export, you fill in the stock column of each variant, you import again.

One value is worth knowing before you fill that column: unlimited stock is a value like any other, the one taken by products you don't count, a service or a made-to-order product. You'll find it as it is in the export, and you can put it on other rows.

The import also serves for moving in, when your catalog already exists on another platform and you're opening your app. That's the case where the time saved is most visible, and where the order of operations matters most.

The file carries the skeleton: titles, references, prices, variants, stock levels, attachment to collections. It puts a shop on its feet in one import.

With the skeleton in place, what's left is what makes people buy. So plan a second pass for the descriptions and the visuals, page by page, and bear in mind that a photo travels by its address: for it to follow your import, it has to be online somewhere already and publicly reachable. Many migrations happen in two stages for that reason, and it's a good plan of action: the file gives you the structure in an hour, the product pages are then worked on at the pace you refine them.

The guide "Getting your product pages right" covers that second pass, and the guide "Organizing your shop" covers the collections to file it all in.