WooCommerce Historical Data Import Not Working
WooCommerce Analytics does not read your orders. It reads a set of lookup tables built from them, and the historical import is what fills those tables — which is why a stalled import and wrong report figures are the same problem seen from two angles.
Quick fix: open Analytics → Settings, look at the historical import status, then open WooCommerce → Status → Scheduled Actions and filter to Pending. If import actions are queued with times in the past and the count is not moving, the import is not broken — your site is not processing background tasks at all.
Take a backup before clearing and rebuilding anything, per how to back up a WordPress site.
What the import is actually doing
WooCommerce Analytics does not query your orders when you open a report. That would be far too slow on a real store. Instead it maintains a set of flat lookup tables — order statistics, order line items, customers, coupons and taxes — and every report reads from those.
New orders write to those tables as they are placed. Orders that already existed when Analytics arrived, or that were inserted by a migration tool, have no rows there. The historical import is the backfill: it reads existing orders in batches and writes the missing lookup rows, queued as scheduled actions and processed in the background over many requests.
Two consequences follow, and they explain nearly every report of this "not working":
- A stalled import is normally a stalled queue, not a data problem.
- A completed import with empty reports is normally a filtering problem, not an import problem.
Decide which of those two you have before doing anything else.
If the import never progresses
Check the queue first. Pending actions that never move mean background processing is dead site-wide. Confirm with Tools → Site Health — a failed loopback stops the queue immediately, and the causes are covered in loopback request failed. Also check whether DISABLE_WP_CRON is set in wp-config.php without a real system cron behind it, which is the pairing described in replacing WP-Cron with a system cron.
Check for a backlog. The queue is processed a batch at a time. If another plugin has scheduled tens of thousands of actions, the import sits behind them. Compare the pending count across all groups with the count for the import.
Check for failed actions rather than pending ones. A batch that crashed will be logged as failed with a reason, usually PHP timeout or memory exhaustion on a store with a long order history. Raising the limit as described in increasing the WordPress memory limit lets larger batches complete.
Check the lookup tables exist. The WooCommerce Status page lists the database tables it expects and flags any that are missing. If a table was never created — a restricted database user during install is the usual reason — the import has nowhere to write and will fail silently or repeatedly. Create the missing tables before retrying.
If the store also shows a pending database update notice, resolve that first. The two share the same queue, and the update routines can be reshaping the very data the import is trying to read — see database update not working.
If the import completes but reports are empty
Work down this list; the first two account for most cases.
- The report date range. Reports open on a default range that may not include your historical orders. Widen it before concluding anything.
- Excluded order statuses. The Analytics settings control which statuses count towards figures, and statuses such as cancelled, failed and refunded are deliberately treated differently from completed ones. Imported orders in an excluded status are present and invisible, which looks exactly like a failed import.
- Orders that are not really orders. A migration that wrote rows directly into the database, bypassing WooCommerce, can produce records with the wrong type or missing key fields. Open one in the admin: if it renders incorrectly there, the import is right to skip it.
- An incomplete order storage sync. If you have switched order storage modes, an unfinished sync leaves the import reading a partial set. Let the sync finish, then re-import.
- Cached report output. Report results are cached briefly. Reload after a few minutes before deciding a number is wrong.
Rebuild cleanly rather than repeatedly
Pressing import again on top of a half-finished run adds more queued work without addressing why the first one stopped. Once the underlying cause is fixed, delete the previously imported data from the Analytics settings and run a single clean import. The lookup tables are derived, so nothing original is at risk.
If your real goal is getting a product catalogue in rather than rebuilding reports, this is the wrong tool entirely — that job belongs to the product CSV importer.
Verify it worked
Pick a month with known revenue and compare the Analytics figure against the order list filtered to the same range and statuses. Then check that the import status reports completion, that pending and failed action counts are zero, and that a newly placed test order appears in reports within a few minutes — because that last check proves ongoing writes work, not just the backfill.
Frequently asked
- Usually the orders exist but sit in statuses that Analytics excludes from its figures, or the report date range does not cover them. Check the excluded statuses in the Analytics settings before assuming the import failed, because a completed import with excluded orders looks identical to a failed one.
- No. It only builds report tables from orders already stored in WooCommerce. Migrating orders from another store is a separate job, and the import can only summarise records that were created properly as WooCommerce orders.
- Yes. The lookup tables are derived data, rebuilt entirely from your orders, so clearing and re-importing destroys nothing original. Reports will be incomplete while the rebuild runs, so avoid doing it in the middle of a reporting period.