Org-scoped metrics release (July 2026)

Metrics used to be locked inside a single project. Now they are organization-level definitions. You build a metric once and reuse it across every project in your organization. You can share the important ones org-wide. You can even pull a metric's data from a different project, when your traffic lives there. This release rewrote the metric model end to end. That covers the dashboard, the public API, the results pipeline, and the snippet datafile (the small JSON file the snippet downloads, listing every live experiment, flag, and rule for a project).

Metrics are organization-level definitions

A metric is no longer owned by one experiment or trapped in one project. Every metric now has a scope (which projects are allowed to use it):

• This project: the default. The metric has a home project and is used by experiments there. Anyone who can create experiments can make one.
• Org-wide: the metric has no home project and can be attached to experiments in any project. This is the reuse layer for the metrics your whole organization cares about.

Names and event keys are unique across the entire organization. So a "name already in use" message can now point at a metric in a different project. Search before you create. Read more: What Are Metrics?.

Reuse across projects, with admin control

Sharing a metric across projects is deliberately gated. Creating, editing, archiving, deleting, promoting, or demoting an org-wide metric requires the Admin role (or the Owner). Managing a metric homed inside your own project stays open to anyone with Create Experiments, including Collaborators. Read more: Built-in Roles.

You change a metric's scope by editing it: there are no separate menus. Promote a project metric to org-wide, to share it. Demote an org-wide metric back to a single project, when you are done. A demote is blocked while experiments or flag rules in other projects still use the metric. A vs B lists exactly which ones, so you can detach them first. Deleting a whole project no longer loses its shared metrics. Any metric other projects were using is automatically promoted to org-wide. Read more: Managing Metrics.

Where a metric is used, across every project

The metric usage view now spans the whole organization. When a metric is shared, the "where used" panel and the archive/delete confirmations name every project that references it, with per-project links. That way you can see the full blast radius before you change or remove it. Archiving a metric stops it firing everywhere at once, in every project, in the same action.

Cross-project data via a linked source

Some metrics are defined in one project, but the traffic that fires them lives in another. A metric can now name a source project. When it is attached to an experiment, A vs B reads that metric's events from the linked source project, instead of the experiment's own project. One project supplies the data per metric, so there is no double counting. The results page shows a per-metric "data from <project>" note. It also warns you when the two projects look like they don't share visitors. Cross-project metrics rely on the same visitor identity being present in both projects. The snippet exposes the current visitor id, so you can wire it into your server-side SDK.

Under the hood

The snippet datafile now serves the exact set of metrics usable in each project: org-wide metrics included, archived metrics excluded. It draws from a single source, shared by the live datafile and the editor preview, so what you preview is what fires. Every metric and binding change re-publishes the affected projects' datafiles automatically. The public API's create and update endpoints accept projectId: null for org-wide authoring. See the Metrics and Metric bindings API references.

Released July 2026.