Product Updates

🧪 Layers Targeting

Setting up Layers when creating an experiment is now easier than ever.

What you can do now

• See Layers as a top-level Targeting option alongside ID Type and Target Applications.

• Pick a layer and have ID Type and Target Applications auto-fill and lock automatically.

• Clear the layer to unlock those fields and keep your values.

• See Target Applications displayed by name rather than a raw count

Why this matters

Layers keep experiments mutually exclusive, preventing cross-experiment contamination across your project. With Layers now a top-level option in the Create Experiment modal, setting them up correctly takes less effort from the start.

Try it out

Open the Statsig console and create a new experiment to try it out.

✏️ Create Modals Updates

You can now give gates, experiments, and dynamic configs the same display name.

What you can do now

• Use duplicate display names across feature gates, experiments, dynamic configs, and their templates.

• When a name collision occurs, the ID auto-resolves to the smallest free suffix (checkout_flow becomes checkout_flow_1) and Create stays enabled with an info note instead of a dead-end error.

• Edit the auto-generated ID inline by hovering or focusing the row and clicking the pencil icon.

• Works across create, clone, and rename flows.

Why this matters

Before this, two entities with the same display name hit "ID already in use" and teams with naturally similar naming conventions had to add arbitrary suffixes just to get past the create step. Now display names can reflect what something actually is, while uniqueness is still enforced on the ID.

Try it out

Open the Statsig console and create a new gate, experiment, or dynamic config with a name that already exists to see the new flow in action.

🎯 Reorder+ Insight Targeting Rules

Managing targeting rule order is now faster and more intuitive.

What you can do now

• Drag any rule by its IF / ELSE IF rail to reorder it inline — no more opening a separate Reorder Rules modal.

• Hover on any rule to reveal an "Insert new rule" button and drop a new rule exactly where you want it, instead of adding to the bottom and dragging it up.

• Precedence labels update live as you drag so you always know where a rule will land

Why this matters

Rule order matters in targeting. Before this, reordering required a separate modal. Now, you can build and adjust targeting logic directly in the editor without breaking your flow.

Try it out

Open any feature gate, experiment, or dynamic config in the Statsig console and try dragging or inserting a targeting rule.

🗑️ Delete a Single Feature Gate User Override

You can now remove an individual user from a Feature Gate override without touching the rest of the list.

What you can do now

One new endpoint is available on statsigapi.net/console/v1/:

DELETE /console/v1/gates/{gateName}/overrides/userID/{userID}

Why this matters

Before this, removing a single user override meant fetching the full override list, mutating it locally, and re-posting it, which could be risky when test runs are happening concurrently. Now, you can target and remove exactly one user, leaving every other override untouched.

Try it out

Review the full API reference in the Statsig Console API docs.

🚨 PagerDuty Integration for Topline Alerts

Statsig Topline Alerts can now page PagerDuty directly.

What you can do now

• Add PagerDuty services to the Integrations catalog once with a name and Events API v2 routing key.

• Select one or more PagerDuty services per alert in the Notifications settings.

• Test your wiring end-to-end before you rely on it — test pages are tagged [TEST] and never collide with real incidents.

• Deleting a PagerDuty service that an alert still references is blocked, and disabled integrations are clearly flagged.

Why this matters

Topline Alerts catch anomalies in your most critical product metrics, but a notification that in Slack or email isn't always enough when something is on fire. Now, the same alert that fires in Statsig can page your on-call team in PagerDuty, closing the gap between detecting a problem and fixing it quickly.

Try it out

Go to Integrations in the Statsig console, add your PagerDuty service, then open any Topline Alert and configure PagerDuty under Notifications.

Learn more in the Statsig Topline Alerts docs.

✅ Autotune Reviews via Console, Console API, and MCP

You can now submit Autotune changes for review and manage the full review lifecycle across the console, Console API, and MCP.

What you can do now

• Submit Autotune configuration changes for review before they reach production.

• Approve, reject, or cancel in-flight Autotune reviews from the console, via CAPI, or through the MCP.

• Teams with reviews required can now enforce that same approval workflow on Autotunes, the same way they do for gates and experiments.

Why this matters

Teams running Autotune for high-stakes decisions need the same guardrails they have everywhere else. Any change to a live Autotune can shift traffic allocation immediately, so being able to require an approval before it goes out matters. Reviews are now consistent across gates, experiments, and Autotunes.

Try it out

If you have the Statsig MCP set up, try a prompt like:

"Using the Statsig MCP, open a review to update the winner threshold on autotune_name and submit it for approval."

Learn more in the Statsig Reviews docs.

🔧 Holdouts Now Accepts Public Gate IDs

PATCH /console/v1/holdouts/{id} now resolves public gate IDs for targetingGateID, the same way gateIDs and experimentIDs already do.

What you can do now

• Set targetingGateID to a public gate ID — the slug CAPI returns as id on all write paths — without hitting a 500.

• Internal IDs still work, so existing GET-edit-PUT round-trips are unchanged.

• An unknown gate now returns a clean 400 instead of a 500 null still keeps the existing gate, "" still clears it.

Why this matters

Now, targetingGateID behaves consistently with the rest of the PATCH endpoint.

Try it out

Review the full API reference in the Statsig Holdouts Console API docs.

📊 Topline Impact in Warehouse Native

Composite metrics now show the full Topline Impact panel in Warehouse Native experiment results.

What you can do now

• See absolute and projected launch impact for composite metrics, the same way you can for ratio, funnel, and retention metrics.

• Each component's daily value is computed and combined with its operator before rolling up, so the impact calculation reflects the full composite definition.

Why this matters

Topline Impact tells you the real daily effect your experiment is having on a metric across your entire user base. Now, composite metrics are fully supported, so you can make shipping decisions with the same confidence you have on any other metric type.

Try it out

Open any Warehouse Native experiment result and select a composite metric to see Topline Impact. Learn more in the Statsig Topline Impact docs.

☁️ Athena Now Supports Gate and Experiment Keys with . and -

Athena users can now use dots and hyphens in gate and experiment keys without any workarounds.

What you can do now

• Use . and - in gate and experiment keys on Athena, the same way BigQuery and Databricks Warehouse Native users already can.

• Existing keys without . or - are untouched. No renaming or migration needed.

Why this matters

Teams running Athena had to avoid dots and hyphens in gate and experiment keys entirely. Now, you can use any naming convention on Athena without workarounds or renaming.

Try it out

No action needed. Start using . and - in your gate and experiment keys on Athena today.

Learn more in the Statsig Warehouse Native docs.

🔐 Granular Delete Permission for Configs

You can now separate the ability to delete configs from the ability to edit them.

What you can do now

• Manage Edit, Archive, and Delete as distinct permissions on your Role Permissions page

Why this matters

Previously, delete was bundled into a single "Edit Delete Configs" permission with no way to separate them. Now, you can grant edit access broadly and keep delete access narrow, without having to create workarounds or roles with too many extra permissions.

FYI!

This is opt-in and not on by default. To enable granular delete permissions for your organization, contact your Statsig account team. Once enabled, the separate Delete permission will appear on your Role Permissions page under Project Settings.

Try it out

Learn more in the Statsig Access Management docs.