How to export your data from Statsig before you leave
If a renewal, a price change or an exit decision means you need a full copy of your Statsig setup, begin with the configuration layer. The Console API covers environments, tags, segments, feature gates, dynamic configs and experiments, and that is the set you should inventory first. Raw analytics events stay in Statsig unless a data warehouse already holds them, so an API export will not reproduce your event history. Treat the export as a configuration backup and a migration input, and as nothing more. Before you plan around it, confirm with your Statsig account team exactly which objects and fields your plan and API key can read.
Several things will not appear in a configuration export. Event-level data, session history and any results computed inside Statsig stay behind unless your warehouse holds the same events. Ask whether your contract includes warehouse native deployment, which the Statsig pricing page places under the Enterprise plan. Also map where your code references each gate and config key, because those call sites live in your repositories and the export will not list them. Metric definitions need the same attention. GrowthBook's Statsig importer handles metric sources and metrics only in beta, and only for warehouse-native Statsig metrics, so metrics built on other sources will need to be rebuilt by hand. Record each one with its owner and the decision it supports.
Verify the copy against your own environment before you rely on it. Run the export under a read-only Console API key, store the output where your retention and access policies apply, and compare object counts per environment with what the Statsig Console shows. Check the API version and the per-project rate limits in Statsig's current developer documentation, since scripted exports across many projects can be throttled. Your script should back off and resume after a throttled response. Then pick a sample of gates and experiments and confirm that targeting rules, rollout percentages and experiment status match the source. The GrowthBook Statsig migration guide documents which objects its importer reads, so use it as a checklist for what your export must contain.
What you can export from Statsig and how
This table lists each Statsig object that GrowthBook's documented importer retrieves, the method it uses and what to confirm before you start. The sources behind this page do not cover format or rate limits, so check Statsig's Console API documentation for those details. The main takeaway is that metric definitions are the part most likely to need manual rebuilding, because their import is in beta and limited to warehouse-native Statsig metrics.
| Data type | Export method | Format | Limits |
|---|---|---|---|
| Environments | Console API key with GrowthBook's Statsig importer | Confirm with Statsig's Console API documentation | Confirm with Statsig's Console API documentation |
| Tags | Console API key with GrowthBook's Statsig importer | Confirm with Statsig's Console API documentation | Confirm with Statsig's Console API documentation |
| Segments | Console API key with GrowthBook's Statsig importer | Confirm with Statsig's Console API documentation | Confirm with Statsig's Console API documentation |
| Feature gates | Console API key with GrowthBook's Statsig importer | Confirm with Statsig's Console API documentation | Confirm with Statsig's Console API documentation |
| Dynamic configs | Console API key with GrowthBook's Statsig importer | Confirm with Statsig's Console API documentation | Confirm with Statsig's Console API documentation |
| Experiments | Console API key with GrowthBook's Statsig importer | Confirm with Statsig's Console API documentation | Confirm with Statsig's Console API documentation |
| Metric sources and metrics | Console API key, beta importer support | Confirm with Statsig's Console API documentation | Beta. Only warehouse-native Statsig metrics are supported |
Getting a Console API key with read-only scope
Any scripted export from Statsig, and the GrowthBook importer that migrates from it, starts with a Console API key. The GrowthBook Statsig importer uses a Console API key to retrieve environments, tags, segments, feature gates, dynamic configs and experiments, so the key needs to read those objects and nothing else. Create a dedicated key for the export rather than reusing a key that your application or CI pipeline already holds. Ask Statsig's administrators whether the Console allows a key scoped to read-only access, and if it does, choose that scope. If it does not, record that limitation in your migration plan, because a key with broader write access carries more risk for the duration of the export.
Store the key in your secrets manager from the moment it is created, not in a local file, a ticket or a chat thread. Limit which people and service accounts can read it, and log access if your secrets manager supports that. Once the export or import has finished and you have checked the output, revoke the key or rotate it, and confirm in the Console that the old key no longer works. Keep a short record of who created the key, when it was used and when it was retired, since that record is often the first thing an auditor or security reviewer asks for.
Before you write any script, confirm three things in Statsig's own API documentation: the authentication method the Console API expects, the API version you should call, and the per-project rate limits that apply to scripted exports. These details are not covered in the sources used for this page, and they can change, so do not take them from a third-party tutorial or an older code sample. Test the key against a non-production project first, then plan a throttled export that respects the documented limits. If your team is using the GrowthBook importer instead of a script, confirm the same points with GrowthBook's own Statsig migration guide and check that the importer's requirements match your Statsig setup.
What stays behind in Statsig and the workarounds
Exporting configuration through the Console API moves gates, dynamic configs, experiments and segments, but several kinds of results and history often do not travel with them. Each card below names one item that may stay behind, the workaround that usually applies, and the check to make in Statsig's own documentation before you rely on it.
Raw event logs and analytics events
Events you sent to Statsig for experiments and analytics are stored in Statsig's systems, and the configuration export does not include them. If you need the raw events later, confirm in Statsig's documentation whether you can export event data and under what limits before the contract ends. If your event pipeline also writes to your own warehouse, that copy becomes the source of truth for analysis going forward.
Exposure and metric results in the console
Experiment results, exposure counts and metric readouts shown in the Statsig console are computed inside the vendor's platform. Screenshots or copied tables preserve a snapshot but not the calculation logic. Ask Statsig which result exports it supports for your plan. Where it allows none, record the experiment name, dates, metric definitions and decision in your own decision log so the outcome stays auditable.
Warehouse-native metrics outside the importer
If your metrics are defined in a warehouse connected to Statsig, GrowthBook's importer can read only the warehouse-native Statsig metrics it supports, and that support is in beta. Metrics defined only in the Statsig console, or in a warehouse you have not connected to the importer, will not arrive on their own. Rebuild those definitions in GrowthBook against your warehouse and check each query returns the same numbers on a test experiment.
Historical experiment analysis
Past experiments may have used analysis settings, such as variance reduction or sequential testing options, that do not map one to one to another platform. The exported experiment definitions show intent but not the statistics used to reach past decisions. Keep a dated archive of each concluded experiment's results and write down the analysis method used, so you can compare older results with new ones without reinterpreting them.
Dashboards and saved reports
Dashboards, saved reports and alert subscriptions built for stakeholders live in the Statsig user interface, and they are not part of an SDK or configuration export. Inventory who uses each dashboard and what decision it supports, then rebuild the essential views in your new platform or your existing BI tool. Confirm with Statsig which of these objects, if any, can be exported before you start the migration.
The sequence for a complete export
This sequence produces a verified, dated export of Statsig configuration objects and a documented record of what sits in your warehouse. Each step ends with a check, so the export can be trusted before anything is migrated or retired.
Inventory every environment, project and object
The Statsig account owner lists every project and environment, then counts tags, segments, feature gates, dynamic configs and experiments in each one. Product teams should confirm which experiments are running, stopped or archived, and whether archived items are in scope for retention. The step is complete when you have a written inventory per project and each count matches the list pages in the Statsig console.
Create a read-only Console API key
Create a Console API key dedicated to the export, labeled with its purpose and an named owner. Confirm in Statsig's documentation which permissions the key carries and whether it can be limited to read access, and record that answer. Store the key in your secrets manager, never in a code repository or ticket. The step is complete when the key reads one known object successfully and the key identifier and owner appear in your change record.
Run the first configuration export
An engineer runs a script or the GrowthBook importer tooling to pull each object type into a staging location, one project at a time. Confirm that the API version your script targets is the version Statsig documents, and keep the raw JSON responses as received. When the API signals rate limiting, pause and retry based on the response instead of hard-coding waits. The step is complete when every project has a folder per object type and the log shows no unhandled errors.
Check counts and sample objects against the console
Compare the exported count for each object type with the inventory from the first step. Then select a sample of gates, dynamic configs and experiments in each project and compare their rules, targeting conditions, status and environment settings with the console. Pagination gaps and archived items are the usual causes of mismatch. The step is complete when counts match or each difference has a written explanation, and every sampled object matches its console record.
Confirm the warehouse copy of event and metric data
A configuration export does not carry event, exposure or metric data, so this needs its own check. If your Statsig events already land in a warehouse, the data owner confirms the tables, the date range covered and that exposure records are complete. If the data stays only in Statsig, ask Statsig which export options your plan includes before assuming a copy exists. The step is complete when you can name each warehouse table, its owner and its date range, and the data owner signs off.
Record a dated manifest with counts and checksums
Write a manifest that lists the export date, the Statsig projects covered, the API key identifier (never the secret), object counts per type and a SHA-256 checksum for each exported file. A reviewer who did not run the export checks the manifest against the logs. The step is complete when the reviewer can recompute one checksum on the stored files and get the same value as the manifest.
Store the export under your retention policy
Move the export, manifest and logs into storage that matches your data classification, with access limited to named roles. Set the retention period and deletion date according to your policy and your legal hold obligations. Revoke the export API key once the export is verified, and record the revocation. The step is complete when the storage location, owner, retention period and key revocation are all documented in your records.
Where your analytics data lives decides the export plan
When events are ingested and stored in Statsig, the platform holds both the raw event stream and the computed results from your experiments and metrics. Those results sit in a system you do not control unless you export them, so the plan has to capture them while the account is still active.
- Experiment results and metric history: Exported results are what you keep after exit. Confirm with Statsig which result exports or API endpoints your tier exposes, and whether historical results can be retrieved once a contract ends.
- Raw event data: Events held only in Statsig do not travel with the configuration objects. Rebuild any metric you need from a source you own, or ask Statsig in writing what event export is available to you.
- Scripted pulls: Bulk exports through the Console API run under per-project rate limits. Schedule pulls over several sessions, and check the documented limits for each project before you begin.
- Timing: Start the export before any renewal date or change-of-ownership notice takes effect. Keep at least one complete, verified snapshot before the account is closed.
Check your order form and data terms for the retention and deletion periods that apply after termination.
Statsig lists warehouse native deployment as an Enterprise feature on its pricing page. In this setup, event data stays in your warehouse, so the export plan shifts from moving events to moving configuration objects and keeping warehouse access working.
- Event data: Exposures and events already sit in your warehouse. Confirm the tables, retention settings and access controls there, because that data does not depend on the Statsig account.
- Gates, dynamic configs and experiments: These configuration objects still live in Statsig. Pull them with a Console API key, either through an importer such as the one described in GrowthBook's Statsig migration guide or through your own scripts.
- Segments, tags and environments: Include these in the export. They are easy to lose in a manual rebuild, and the importer documentation lists them alongside gates and configs.
- Metric definitions: Record the SQL and definitions of your warehouse-native metrics yourself. Metric import is in beta and limited to warehouse-native Statsig metrics, so keep your own copy as a fallback.
- Warehouse credentials: Keep the read-only credentials and network paths to the warehouse under your control, so any analysis tool can query the same data after exit.
Confirm with your account team that warehouse native is included in your contract, and which configuration exports it covers.
The export plan depends on what your contract actually includes, and the two setups above assume different entitlements. Before you run a single export, get the answers in writing so the runbook reflects your agreement rather than assumptions about the product.
- Plan tier: Warehouse native is an Enterprise feature, so check whether your plan includes it instead of assuming it does.
- Export rights: Ask for written confirmation of the export formats, API access and any charges for bulk data extraction.
- Retention after termination: Get the period during which data is kept or deleted after the contract ends, and who confirms deletion.
- Ownership changes: Ask how a change of control affects service terms, support and data handling. Statsig's ownership has changed in recent years, so do not treat earlier terms as current.
- API key scope: Identify who holds Console API keys and whether each key is read-only before you start a scripted export.
Record the answers in your export runbook, and review them again before any renewal or ownership notice.
What to plan before renewal or termination
Before you pull anything out of Statsig, settle the contract facts that set your timeline: when notice is due, what plan you are on, and who owns the vendor now. The cards below cover the items to confirm in writing, from ownership changes and data deletion to the internal approvals that let the export start on time.
Notice periods and renewal dates
Find the notice period, the renewal date and any auto-renewal clause in your Statsig order form or master agreement. Export work usually runs in parallel with the contract window, so the last date you can give notice without triggering another term is the date that sets your plan. Ask your account contact to confirm these dates in writing, and check whether any amendments changed them after signature.
Current plan and warehouse native status
Confirm which Statsig plan you hold and whether warehouse native deployment is included. Statsig's pricing page lists warehouse native as an Enterprise feature, so if your data for experiments already lives in your warehouse, the export scope is smaller than if Statsig stores your event data. Record the plan name and the features in your order form so the scope of the export matches what you pay for.
Ownership changes and support terms
Statsig announced it would join OpenAI in September 2025, and its blog states that Amplitude acquired Statsig in May 2026. Ask in writing which legal entity holds your contract, whether support and service levels changed, which sub-processors now handle your data, and where that data is hosted. Ownership changes can alter these terms without changing your price, so get the answers before you rely on them.
Data deletion after termination
Ask Statsig to state, in writing, when customer data is deleted after termination, how long backups are kept, and whether deletion covers event data, exposures, and logs. Confirm whether deletion is certified and how you receive confirmation. Your own retention and legal hold obligations may require you to keep an exported copy, so the deletion timeline and your archive plan must agree.
Written request for a final data copy
Send a written request for a final export or data copy before the termination date, specifying the objects you need: gates, dynamic configs, experiments, segments, and any event data held in Statsig. Ask for the format, the delivery method, the date by which the copy will be available, and whether it will be provided at no charge. A written request gives you a record if the vendor's offboarding process changes later.
Internal approvals to start the export
Before the export begins, get sign-off from the people who own the contract, the data, and the security review. That usually means procurement or legal for the notice decision, the data owner for scope, and security for the transfer path and the place the export is stored. Agree on who holds the Console API key, how it is rotated, and who approves the import into GrowthBook, so the export can start as soon as the contract allows.
Questions buyers ask before exporting from Statsig
How much effort does a Statsig configuration export take?
The effort depends mostly on how many gates, dynamic configs, experiments, segments and environments you have, and on how consistently tags were applied. A small project with clean naming is largely a scripted pull followed by a review pass. A large estate with duplicated flags, undocumented targeting rules and inconsistent tags takes longer, because each object needs a decision: move it as is, merge it with another object, or retire it. Ask for a count of each object type per project and environment before anyone estimates effort. That inventory also shows how many decisions the review will require.
Can our own engineers export from Statsig without outside help?
Yes, if an engineer is comfortable with REST APIs, pagination, secret handling and version control, the pull itself is straightforward. Outside help becomes worth weighing when the export must be reproducible for an audit, when the target platform is not yet chosen, or when the team lacks capacity for the mapping work. GrowthBook documents an importer for Statsig objects that uses a Console API key, so many teams combine that importer with a small script for anything it does not cover. Fixed-scope engagements with DeployOpen are agreed in writing before work starts.
Who on our team needs to be involved in the export?
Three roles are usually needed. An engineer with Console API access writes and runs the pull. A security reviewer approves the creation of the key, decides where it is stored and confirms it is revoked once the export ends. An owner for the target platform decides how Statsig objects map to the new platform's concepts, for example how feature gates map to feature flags, and signs off on the result. Name these people before the work starts, because the mapping decisions tend to stall when no one owns them.
Can we recover our analytics history from Statsig?
Usually not through the configuration export. Gates, dynamic configs, experiments, segments and their metadata can be pulled through the Console API, but raw event data and the analytics Statsig computed from it stay in Statsig unless the same events also reached your data warehouse. Check which events you already send to a warehouse, since that copy is the one you can query after you leave. For historical experiment results, export the reports you need for records and confirm with Statsig which of them the API returns and in what form.
What should a quote for a Statsig export include?
A useful quote is a written scope that lists objects by type and by project, the Statsig projects and environments in scope, and the target platform and its version. It should also describe the transformation rules, the verification method, how the API key is handled and revoked, and how experiments that are still running will be treated. State what is excluded, such as raw event history and warehouse data. Ask who performs each step, which deliverables tie to each milestone, and whether ongoing support is priced separately. Quotes that follow a written scope can be compared line by line.
How do we verify that a Statsig export is complete?
Measure completeness against an inventory written before the export starts, not against memory. Compare counts per object type and per environment between Statsig and the exported files, then check a sample of gates and experiments for targeting rules, rollout percentages and status. Compare tag and segment names and IDs directly. Before cutover, evaluate a fixed set of test users against both systems and record every difference. Keep the export files in version control with checksums so the result can be reproduced later.
Can a migration importer replace a custom export script?
For the common objects, sometimes, but not for every case. GrowthBook's Statsig importer retrieves environments, tags, segments, feature gates, dynamic configs and experiments with a Console API key. Its metric import is in beta and is limited to warehouse-native Statsig metrics, so teams without a connected warehouse need another path for metrics. Advanced setups may fall outside what any importer handles, and the application still has to replace Statsig SDK calls with GrowthBook SDK calls. Treat the importer as a starting point and keep a script for the gaps. GrowthBook's Statsig migration guide describes the supported objects.
What should we confirm with Statsig before starting an export?
Confirm the current Console API version, the authentication method and the rate limits that apply to your projects, because scripted exports depend on them and they can change. Confirm your contract terms: data retention after termination, your rights to export, and whether your plan includes warehouse native deployment, which Statsig lists as an Enterprise feature on its pricing page. Ask whether support for API access is changing, since Statsig agreed to join OpenAI in 2025 and Amplitude acquired it in 2026. Get the answers in writing before the export begins.
How DeployOpen scopes and delivers a Statsig data export
DeployOpen treats a Statsig export as a fixed-scope piece of work: we agree in writing which objects leave Statsig, where they land and how they are checked before anyone switches a flag. The export is planned alongside your target GrowthBook or other self-hosted environment, so the data you keep is the data you can actually use.
How we scope
- Inventory the gates, dynamic configs, experiments, segments and environments you need to carry out of Statsig.
- Confirm which Console API keys and projects the export will use, and that access is read-only.
- Record which analytics data stays in Statsig and which already lives in your warehouse, so no one assumes it was exported.
How we build
- Script the Console API pulls with pagination and backoff that respects per-project rate limits.
- Write each extract to a documented schema, with versioned files kept in your own storage.
- Test the export against a sample project and reconcile counts and values with the source before the full run.
How we hand over
- Deliver the scripts, configuration, schema notes and a reconciliation report in your repository.
- Document what was exported, what was not, and the known gaps that need a manual decision from your team.
- Walk your engineers through rerunning the export and keeping an archived copy for audit or records requests.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and repeat exports are available as a retainer, scoped separately.
- Ask for a written quote that lists the objects, environments and data sources included in the scope.
