Title: Where AB Split Test Data is Stored in the WordPress Database

If you’re using AB Split Test, you may want to keep your live test results when copying a staging environment to production (or pulling production down to staging). This guide explains where AB Split Test stores its data in the WordPress database, and which tables to exclude when syncing environments.

---

Where is AB Split Test data stored?

AB Split Test keeps two different kinds of data in separate places: your test configuration and your test results.

1. Test configuration (your tests & variations)

Your tests, variations, goals and settings are stored as a custom post type in the standard WordPress tables:

• wp_posts – the test itself (and any full‑page variation pages)
• wp_postmeta – test settings (variations, goals, conversion rules, etc.)

This is the data you usually do want to move from staging to production.

2. Test results (visits, conversions & winners)

Your accumulated results live in dedicated custom tables:

• wp_abst_results – the visit/conversion totals, statistics and chosen winner for each test (recent versions)
• wp_abst_queue – incoming events waiting to be tallied
• wp_abst_fingerprints – per‑visitor tracking log, used only when Advanced / Fingerprint Tracking is enabled

Note: in older versions of AB Split Test the result totals were stored in wp_postmeta (under the observations key). Recent versions move them into the wp_abst_results table so that your configuration and your results can be migrated independently.

---

Migrating staging → production without losing live results

When you push a staging site to production (for example with a host’s selective database sync), exclude the AB Split Test results tables so your live data isn’t overwritten by staging’s test data:

• wp_abst_results
• wp_abst_queue
• wp_abst_fingerprints

Sync wp_posts and wp_postmeta as normal to carry your test configuration across, and leave the three tables above untouched on production. As a rule of thumb, keep results data per‑environment — staging traffic isn’t real and shouldn’t be mixed into your live numbers.

Heads up: a full wp_posts/wp_postmeta sync overwrites all of your content, so it’s only safe when production hasn’t changed since you cloned it to staging. If production has its own live edits, recreate the test on production instead.

On older versions where results are still kept in wp_postmeta: excluding postmeta would also drop your test configuration, so the cleanest option is to rebuild the test on production, or update to a version that uses the wp_abst_results table.