Guide · Product review import

Product reviews

Bring reviews across when you migrate a store. Reviews are the one entity here with no unique identifier of their own, so how a row is matched to an existing review is the thing worth reading before you run a file twice.

Reviews are the classic replatforming job: the products come across first, then the reviews that give them credibility. This importer is built for that file — a few thousand rows spread across a few hundred products.

Commands

Command	Description	Behaviour
MERGE	Create or update.	The default. Updates the review if the row matches one, adds it otherwise.
NEW	Add a review.	Fails if the row matches an existing review.
UPDATE	Update an existing review.	Fails if nothing matches — it never adds.
DELETE	Delete a review.	Fails if nothing matches, rather than reporting a success.
IGNORE	Skip this row.	Does nothing, and is recorded as skipped rather than as a success.
REPLACE	Refused for reviews.	Fails the row. Deleting and re-creating a review changes its ID, and the ID is the only exact handle a review has. Use UPDATE.

Columns

Column	Notes
`SKU`	Which product the review belongs to. Resolved once per product, so a file with 2,000 reviews across 300 products costs 300 lookups.
`Product ID`	Exact, and preferred when both are given.
`Review ID`	BigCommerce's own id for the review — the only exact handle one has. The export always writes it.
`Title`	Required on a create. Up to 255 characters.
`Date Reviewed`	Required on a create. Any date this app can read; see below.
`Text`	The body of the review.
`Status`	`approved`, `disapproved` or `pending`. Friendly spellings are accepted.
`Rating`	A whole number from 0 to 5.
`Name`	The reviewer's name, up to 255 characters.
`Email`	The reviewer's email. Must be a valid address, or left blank for an anonymous review — a blank cell omits the field, which is what BigCommerce actually requires (it rejects an explicitly empty one).
`Date Created`, `Date Modified`	Written by the export for information. BigCommerce maintains both and refuses to be told them, so the importer ignores these columns.

How a row is matched — the important part

Reviews have no unique key

Every other entity in this guide has something unique to match on: a product SKU, a category path, a page name, a coupon code, a customer's email. A review has none. BigCommerce will happily store two identical reviews on the same product, and offers no way to look one up by its contents.

So matching works like this, strongest first:

Review ID — exact. Checked against that product's own reviews, so an id from a different store cannot update an unrelated review.
Email + Title + Date Reviewed — the same person, the same title, the same day is the same review.
Email + Title — when the row gives no date.

If a row matches more than one existing review it fails, naming the ids, rather than editing whichever came first.

And if a row has no Review ID and no Email, it cannot be matched at all — so MERGE adds it, and adds it again the next time you run the file. The result message says so out loud when that happens.

The practical advice follows from that: export first, edit the file, import it back. The export writes Review ID on every row, which makes the round trip exact and re-runs harmless.

A minimal file

Command,SKU,Title,Rating,Name,Email,Date Reviewed,Status,Text
MERGE,TSHIRT-M,Great quality,5,Ana,ana@example.com,2026-03-14,approved,Washed well after a month.
MERGE,TSHIRT-M,Runs small,3,Ben,ben@example.com,2026-04-02,approved,Order a size up.
MERGE,HOODIE-M,Warm,4,Cara,cara@example.com,2026-04-11,pending,

Dates

Ratings

BigCommerce ratings are whole numbers from 0 to 5. A half-star rating from another platform is refused rather than rounded — whether 4.5 becomes 4 or 5 changes your store's average, and that is a decision for the person migrating, not for the import. Fix the column in the spreadsheet and the whole file behaves predictably.

Export

An export writes one row per review, across the whole catalogue or a filter of it.

"Approved reviews only" is faster and it loses reviews — so it is opt-in

Because reviews live under a product, a whole-catalogue export is one API call per product. reviews_count is a product field, so skipping products that report zero looks like a free speed-up.

It is not. Measured against a live store, reviews_count counts approved reviews only: a product with one pending review reports 0, an approved one takes it to 1, and a disapproved one leaves it at 1 — while the reviews themselves are all still there. Skipping on that count silently drops every pending and disapproved review.

So the default reads every product, however slow that is on a large catalogue, and the fast path is the explicit Approved reviews only option. That mode also asks BigCommerce for approved reviews on each product, so the file matches what you chose, and the export tells you how many products it skipped and that the rest are not in the file.

To narrow a big export without losing anything, filter by SKU, product ID or product name instead.

The filters narrow the products walked rather than the reviews, which is what makes "export the reviews for these three SKUs" cheap. The export also tells you if any product's reviews could not be read, so a file is never quietly incomplete, and warns about products with no SKU — those rows carry only a Product ID, so that file re-imports into the store it came from and not into another one.