Datadog Experiments

Copy a metric collection into a new non-decision metric group on an experiment, preserving the collection's metric order. The group is a snapshot: later changes to the collection do not affect the experiment. The service refuses empty collections and collections with metrics incompatible with the experiment's subject type without creating a group. The result reports needs_pipeline_refresh. When true, call refresh-experiment-results after finishing your edits. WRITE OPERATION. Confirm the collection with the user before calling. If the outcome is uncertain, check with list-experiment-metric-groups before trying again.

create-experiment-metric-group-from-collection

Create a Product Analytics labeled action: a named, reusable label for a user action (e.g. clicks on "Add to cart" on /checkout) that can then be used in Product Analytics queries. A labeled action matches actions by their target name (@action.target.name, the button text or data-dd-action-name) on a view (@view.name), optionally narrowed to an action type (@action.type, e.g. click). CSS selectors are not supported. Values match exactly, except that {{*}} in action_target_name or view_name matches any characters, including "/". Use a pattern only when the user wants one label across a family of views (e.g. "Save anywhere in organization settings" -> view_name "/organization-settings/{{*}}") or across target names that vary (e.g. "Export{{*}}"). A bare * is not a wildcard, and a value made only of {{*}} (matching everything) is rejected. One labeled action can hold several rules: an action matches if any rule matches. The top-level action_target_name, view_name and action_type are the first rule; put the others in additional_rules. Use several rules when one user action shows up as variants that no single {{*}} pattern covers without also matching unrelated controls (e.g. "New Notebook" and "Create Notebook" on /notebook/list, or Save on /monitors/edit and Apply on /monitors/create). Ground every rule the same way as the first. GROUNDING IS MANDATORY. Before calling this tool: 1. Find the action and its view, e.g. with search_product_analytics_org_entities (source "actions"), which returns action names (@action.name, e.g. "click on New Dashboard") with the view they were seen on and their app ids. Pass that app id as application_id; if the action was seen in more than one application, ask the user which one. 2. Get the exact target name with aggregate_product_analytics_events on that view, grouped by @action.target.name (and @action.type). @action.target.name is often shorter than @action.name (e.g. "New Dashboard"), and the labeled action only matches @action.target.name, so never pass an @action.name value. If several different controls on the view share the target name, the labeled action would match all of them: tell the user and ask how to proceed instead of creating it. 3. For a {{*}} pattern, preview what it matches: run aggregate_product_analytics_events with the pattern as a search wildcard (replace each {{*}} with * and escape spaces with \, e.g. @view.name:/organization-settings/* @action.target.name:Save), grouped by @view.name and @action.target.name. Every value in the results will be labeled. If unrelated controls or views show up, narrow the pattern. Unless the user's request clearly covers every match, list them and confirm before creating. 4. Check that it doesn't already exist with search_product_analytics_org_entities (source "labeled_actions"). If it does, show the existing one instead of creating a duplicate. Up to 10 rules in total. This is a persistent write and requires confirm: true. If the user explicitly asked for this labeled action, ground it and then invoke with confirm: true; otherwise review the definition with the user first. Names must be unique in the org. Returns the created labeled action with its server-assigned id and a link to view it.

create_product_analytics_labeled_action

Create a new Product Analytics Launch — a persistent record bundling a feature launch's lifecycle phase, KPIs, and tracking plan (context, properties, and events to instrument). **Always review the name, KPIs, and tracking plan with the user before invoking** — this creates a durable record. Requires confirm: true. Returns the created Launch including its server-assigned id.

create_product_analytics_launch

Create a Product Analytics segment — a named, reusable audience of users or accounts — of one of three segment_type values: "funnel" for a journey of one or more steps in order (provide steps, plus an optional filter applied to every step), "properties" for users or accounts whose profile attributes match a query (e.g. accounts on an enterprise plan, users in France), or "combined" to join two or more of those as blocks. The facet is the identity of the segment: @usr.id creates a user segment and @account.id creates an account segment. For funnel segments it joins matching events; for properties segments it selects the user or account profiles. Each funnel step identifies an event by facet and value and can include its own step_filter. A properties query filters profile attributes, not events, and uses the same search syntax, e.g. "@tier:enterprise" or "last_browser_name:Chrome". Use the exact attribute names returned by search_product_analytics_org_entities with source "profile_attributes" for the matching entity (user or account). Properties segments match current attribute values, so they take no time window. For "users who did X", use a single step. For "did A, then B", use one step per event, in order. For "did A but not B afterwards", use two steps with conversion_type "drop-off" (drop-off needs at least two steps). A multi-step funnel only counts entities that complete every step within 24 hours of the first one (window only sets the dates searched), so tell the user about this limit before creating a multi-step segment. For "did A and B in any order", use a combined segment with a one-step funnel block per event and combine "all". For "never did X", use a combined segment with a single one-step funnel block for X and exclude: true. An excluded block is subtracted from every user (or account) with a profile, including ones with no activity in the window, so tell the user that "never did X" also counts inactive users. Use "combined" only when one block cannot express the request, e.g. users in France (properties) who went from the dashboard list to a dashboard (funnel), or users who did A but never B (a block for A, and an excluded block for B). Put each block's segment_type, query, steps, filter, conversion_type, window, and exclude inside blocks, set facet once at the top level, and set combine to "all" (entities in every block) or "any" (entities in at least one block). A combined segment needs at least two blocks, or a single excluded block. Example: {"segment_type": "combined", "facet": "@usr.id", "combine": "all", "blocks": [{"segment_type": "properties", "query": "last_country_code:FR"}, {"segment_type": "funnel", "steps": [...], "window": {"type": "rolling", "last": "30d"}}]}. GROUNDING IS MANDATORY. Every @view.name, @action.name, or other facet value you put in steps or filters must be a real value you have just confirmed with aggregate_product_analytics_events (or search_product_analytics_events), and every profile attribute in a properties query must come from the profile_attributes search above — never one you guessed, read off the URL bar, or inferred from the user's wording. @view.name and @action.name are exact-match terms, so an invented or slightly-wrong value (e.g. "@view.name:/product-analytics/funnel" when the real views are "/product-analytics/funnel/<id>") matches zero events and silently creates an empty, useless segment. If the user describes an area rather than an exact value, aggregate first to find the real values. A family of paths can be matched with a trailing wildcard (e.g. "/checkout*" as a step value); step values follow run_product_analytics_journey's syntax, so "A OR B" matches either value. Do not call this tool until every value in the definition came from aggregation output or was given verbatim by the user. This is a persistent write that creates a durable segment, and it requires confirm: true. If the user explicitly asked for this segment, ground it and then invoke with confirm: true; otherwise review the definition with the user first. Call it once with the final, grounded definition — the grounding aggregation above is a prerequisite you run first, not the confirmation step, and not a preview you should skip. Never create a segment speculatively. Segment names must be unique. Returns the created segment including its server-assigned id and a link to view it.

create_product_analytics_segment

Create a Datadog-backed experiment metric that can be attached to a Canary as a guardrail. Use this for APM mean duration, APM error rate, APM p90 duration, APM numeric means, RUM percentiles, and Product Analytics percentiles. The tool writes the normal metric API and does not bypass APM query validation. APM measures use source_type APM, source_subtype APM_SPANS, and a query targeting the metric-bearing span. Root-span metric queries include parent_id:0. Child-span metric queries target the child directly and join to root assignment metadata by trace ID; temporary retention then keeps the allocation-matched trace cohort. An APM error rate is a ratio of count(error query) / count(base query). APM p90 uses percentile 0.9 over @duration. Non-APM percentiles use source_definition_filter to isolate the event type and synthetic event name, for example @type=view plus @view.name for RUM views or @type=server plus @event.name for Product Analytics server events. WRITE OPERATION. Confirm the exact metric definition with the user before calling. *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools.

create-datadog-guardrail-metric

Create a new Feature Management environment. *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools. Use when reconciliation against list-environments shows a detected DD_ENV value has no covering environment ("will create" outcome), or when a user explicitly wants a new environment. WRITE OPERATION. Before calling, show the user the exact plan (name, queries, is_production, require_feature_flag_approval) and get explicit approval. Production environments have serious operational impact — confirm intent for is_production=true. queries are the DD_ENV values this environment covers (e.g. ["dev"], ["staging","stg"]). Wildcards are rejected by the service; DD_ENV values already used in another environment also cause a 409 Conflict.

create-environment

Create a metric collection: a reusable, ordered set of experiment metrics. Copy it into an experiment later with create-experiment-metric-group-from-collection. The service rejects metrics that do not exist and a name that another collection already uses. WRITE OPERATION. Confirm the name and metrics with the user before calling. If the outcome is uncertain, look for the collection with list-metric-collections before trying again.

create-metric-collection

Create a new experiment.

create-experiment

Create an experiment metric from Datadog or customer-warehouse data. The metric type follows from the aggregations supplied: numerator_aggregation alone is SIMPLE, numerator_aggregation plus denominator_aggregation is RATIO, and percentile_aggregation alone is PERCENTILE. DATADOG metrics set datadog_metric_measure on each aggregation. CUSTOMER_WAREHOUSE metrics set warehouse_metric_measure to a measure UUID from a metric SQL model; property filters use property or measure UUIDs from the same model. Every reference must belong to the aggregation's data source. Certification cannot be set here. Use create-datadog-guardrail-metric for the guided Canary guardrail shapes. WRITE OPERATION. Confirm the exact definition with the user before calling. If the outcome is uncertain, look for the metric with list-metrics before trying again.

create-metric

Attach metrics to an experiment as a new non-decision metric group (additional metrics reported alongside the decision metrics). To set the primary or a secondary decision metric, use attach-metric-to-experiment instead. The service rejects metrics that do not exist, duplicate metric IDs, and additions that exceed a protocol metric limit. Holdouts cannot be edited here. The result reports needs_pipeline_refresh. When true, call refresh-experiment-results after finishing your edits; this tool does not recompute results. WRITE OPERATION. Confirm the group name and metrics with the user before calling. If the outcome is uncertain, check with list-experiment-metric-groups before trying again.

create-experiment-metric-group

Create a reusable experiment protocol draft. Creation sets the organization's default subject type; call update-protocol to configure the draft, then publish-protocol to make it available for experiments.

create-protocol

Create the onboarding proof flag: a predictable boolean flag (disabled=false, enabled=true; default disabled) with a catch-all FEATURE_GATE allocation serving enabled=true in the selected NON-PRODUCTION environment, tagged source:agentic-onboarding. Safety gates enforced by this tool (not by the agent): the environment must resolve, must NOT be production, must NOT require feature-flag approval, and its queries must cover dd_env under the runtime matcher. It refuses to write unless confirm is true — call it first with confirm:false (or omitted) to get the exact write preview, show that to the user, then call again with confirm:true.

create-onboarding-flag

Create a new feature flag with a FEATURE_GATE allocation linked to a standard experiment. Use this tool instead of create-feature-flag when an allocation has experiment_id. The allocation schema and environment requirements are otherwise identical to create-feature-flag. MANDATORY: If the user did not specify an environment, ask the user to specify one before creating allocations. This allocation's exposure_schedule.rollout_options.scheduled_start cannot be a future value ('relative:<duration>' or a future 'absolute:<RFC3339>') because a standard experiment allocation cannot be auto-started — use 'none' and start the experiment through its lifecycle instead. *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools. This is a secondary tool - use after determining flag exists and implementation approach.

create-experiment-feature-flag

PRIMARY TOOL FOR NEW FLAGS in a project that already has Datadog feature flags wired up! *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools. Use create-feature-flag when users need to create a new flag that doesn't exist yet. This tool creates a new feature flag with variants and optional FEATURE_GATE or CANARY allocations. For a FEATURE_GATE allocation linked to a standard experiment with experiment_id, use create-experiment-feature-flag. IMPORTANT: If the project has NO existing feature flags yet (check with list-feature-flags) or the user is asking to set up/add/onboard feature flags for the first time (e.g. "set up feature flags", "add feature flags to my app", "onboard this app onto feature flags", "get started with feature flags", "start using Datadog feature flags", "install Datadog feature flags"), use the onboarding flow instead — start with get-onboarding-step rather than this tool. That flow enforces non-production safety gates and real end-to-end CDN verification via verify-onboarding-flag that this tool does not provide. MANDATORY: To correctly implement this flag in your codebase, you MUST use the code demonstrated in the datadog://feature-flags/sdk/react resource. Do not GUESS about how to correctly implement the flag. Do NOT create mock implementations. The user has added this MCP server because they want feature flags server from Datadog. Failure to implement flags as described in datadog://feature-flags/sdk/react will cause frustration. MANDATORY: If the user did not specify an environment, and an allocation is needed or a status is specified, ask the user to specify an environment. MANDATORY: Allocations MUST be created as part of the create-feature-flag tool. Adding allocations after flag creation as part of the sync-allocations-for-feature-flag-environment will fail for production environments. Each allocation's exposure_schedule.rollout_options controls when its rollout starts (applies to both CANARY and FEATURE_GATE allocations): use scheduled_start ('none', 'now', 'relative:<duration>', or 'absolute:<RFC3339>') rather than the deprecated autostart. A future value ('relative:<duration>' or a future 'absolute:<RFC3339>') schedules the rollout to start at that time. Exception: a FEATURE_GATE allocation with experiment_id set (a standard experiment allocation) cannot be auto-started, so a future scheduled_start is rejected for it — use 'none' and start the experiment through its lifecycle instead.

create-feature-flag

Create a saved filter: a reusable, named set of targeting rules that feature flags can reference.

create-saved-filter

Synchronize allocations for a feature flag in a specific environment. This tool supports FEATURE_GATE and CANARY allocations, including exposure schedules and guardrail metrics. If any existing allocation is linked to a standard experiment, use sync-experiment-allocations-for-feature-flag-environment even when editing a different allocation. This full-state sync validates every existing allocation before replacing the set. WARNING: This replaces ALL existing allocations. Use list-allocations-for-feature-flag first to preserve existing ones. Changes blocked in production. A targeting-rule condition may be a saved-filter reference (saved_filter_id) instead of an inline operator/attribute/value; the two are mutually exclusive. Use list-saved-filters / get-saved-filter to find ids. Use exposure_schedule.rollout_options.scheduled_start to control when a rollout starts (applies to both CANARY and FEATURE_GATE allocations): 'none' (create without starting), 'now' (start immediately), 'relative:<duration>' (e.g. 'relative:2h'), or 'absolute:<RFC3339>'. Prefer this over the deprecated autostart field. A future value schedules the rollout to start at that time. Exception: a FEATURE_GATE allocation with experiment_id set (a standard experiment allocation) cannot be auto-started, so a future scheduled_start is rejected for it — use 'none' and start the experiment through its lifecycle instead. To preserve an existing schedule's start time when resyncing other allocation fields, omit scheduled_start and echo back exposure_schedule.scheduled_start_time unchanged. *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools. This is a secondary tool - use after determining flag exists and implementation approach. For context on using feature flags in applications, see the datadog://feature-flags/sdk/react resource.

sync-allocations-for-feature-flag-environment

Synchronize allocations that include a FEATURE_GATE allocation linked to a standard experiment. Use this tool when the requested or existing full allocation set contains a FEATURE_GATE allocation linked to a standard experiment, even if the immediate edit targets a different allocation. WARNING: This replaces ALL existing allocations. Use list-allocations-for-feature-flag first to preserve existing ones. Changes are blocked in production. A targeting-rule condition may use saved_filter_id instead of inline condition fields. For a FEATURE_GATE allocation with experiment_id set, exposure_schedule.rollout_options.scheduled_start cannot be a future value ('relative:<duration>' or a future 'absolute:<RFC3339>') because it cannot be auto-started — use 'none' and start the experiment through its lifecycle instead. *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools. This is a secondary tool - use after determining flag exists and implementation approach.

sync-experiment-allocations-for-feature-flag-environment

Delete an experiment metric. The metric stops appearing in reads. The service refuses a metric that any experiment still references; detach it from those experiments first. Imported and certified metrics cannot be deleted here. DESTRUCTIVE OPERATION. Confirm the metric's name and ID with the user before calling.

delete-metric

Detach a non-decision metric group and all of its metrics from an experiment. The metrics themselves are not deleted. The decision group cannot be deleted. Results are not recomputed; if the experiment already has results, call refresh-experiment-results after finishing your edits. DESTRUCTIVE OPERATION. Confirm the group's name and metrics with the user before calling.

delete-experiment-metric-group

Soft-delete a protocol that no experiments reference. Call with confirm=false first for identity, lifecycle, and usage preview; then confirm=true with its confirmation_token only after user approval. The service refuses deletion while experiments reference the protocol.

delete-protocol

Diagnose why the latest (or a specific) combined pipeline run for an experiment failed. Returns the root-cause task, a categorized failure explanation, actionable next steps, and support identifiers that can be shared with Datadog support. This tool does not return Datadog-internal ffeworker logs or logs_query. Call this when the user reports that an experiment pipeline run has failed and wants to know what went wrong. Do NOT use this tool for result interpretation, metric trust checks, or sample ratio mismatch (SRM) analysis — use get-experiment-diagnostics for those. This tool is exclusively for diagnosing pipeline execution failures (tasks that crashed, timed out, or errored). Each root cause includes a support_info object with dag_run_id and task_run_id. If a full internal stack trace is needed, surface the support_info IDs so the user can share them with Datadog support. When the failure category is unknown, do not speculate about the root cause.

diagnose-experiment-run-failure

Segment computed experiment results by an assignment property or over time. Results use the experiment's configured analysis settings. Returns per-variant per-segment point estimates, confidence intervals, and p-values. Use after get-experiment-results when the caller asks 'how does this look for mobile users?' or 'how did this trend over time?'. Call get-experiment-diagnostics first; do not declare a segment winner if results are unreliable.

explore-experiment-results

Fetch a single Product Analytics Launch by its id. Use search_product_analytics_launches first if you don't already have the id. Returns the full record including phase, name, KPIs, the nested steps (tracking plan, and any experiment/dashboard/funnel linked to this launch), and audit metadata.

get_product_analytics_launch

Get the current Canary exposure schedule, including rollout steps and guardrail triggers. Use this after start-canary to distinguish asynchronous APM-retention activation from a running or failed schedule. Obtain exposure_schedule_id from list-allocations-for-feature-flag. *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools.

get-canary-schedule

Get a single Datadog metric property's definition by ID (name, column, source type/subtype, description). Does NOT include discovered values — call list-datadog-metric-property-values for those. Obtain `metric_property_id` from list-datadog-metric-properties.

get-datadog-metric-property

Get a metric SQL model with its SQL, timestamp and date-partition columns, subject types, measures, and properties. Use the IDs it returns to build a CUSTOMER_WAREHOUSE metric with create-metric or update-metric: - event_count_measure_id: warehouse_metric_measure.id for a count aggregation. - subject_types[].unique_subject_count_measure_id: warehouse_metric_measure.id for a uniqueSubjects aggregation. - measures[].id: warehouse_metric_measure.id for other aggregations, such as sum or average. - properties[].id or measures[].id: property_id or measure_id in property_filters.

get-metric-sql-model

Get a metric collection, including its ordered metrics (metric_id and metric_name).

get-metric-collection

Get a saved filter by id, including its targeting rules.

get-saved-filter

Get a specific experiment by ID.

get-experiment

Gets variants and status in environment for a specific feature flag by ID or key. Provide featureFlagID or featureFlagKey (or both). *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools. This is a secondary tool - use after determining flag exists and implementation approach. MANDATORY: You MUST implement using the exact patterns from datadog://feature-flags/sdk/react resource. Do NOT create mock implementations.

get-feature-flag

Get details for a specific guardrail metric by ID. Use this to inspect a metric's full details including description and aggregation configuration. *** FEATURE FLAG DETECTION *** If users mention: flags, toggles, feature switches, A/B tests, experiments, gradual rollouts, canary releases, or say they want to 'flag' something, this is feature flag work and should use feature flag tools. This is a secondary tool - use after determining flag exists and implementation approach.

get-guardrail-metric

Get a single warehouse metric property by ID, including its discovered values (with observed counts). Warehouse metric properties are breakdownable dimensions on a warehouse-backed metric's source; they are created via metric-sync, so there is no org-wide list endpoint — fetch one by its known ID. These are METRIC properties, NOT experiment segmentation/assignment properties.

get-warehouse-metric-property

Get an experiment metric's stored definition, including its aggregations in the shape update-metric accepts. Use this before update-metric so a replacement aggregation starts from the current one. To investigate why a metric moved, use get-metric-definition instead.

get-metric

Get a reusable experiment protocol's full typed template and enforcement settings by ID.

get-protocol

Get one experiment subject type by ID, including its Product Analytics attribute, warehouse column names, and whether it is the organization's default. Set include_counts to see how many experiments, exposure SQL models, metric SQL models, and protocols use it.

get-subject-type

Return the customer-warehouse assignment source SQL definition configured for an experiment, if one exists. Assignment sources define which subjects were assigned to which variant and when; a bug in this SQL (bad join, wrong column types, missing partition filter) is one of the most common causes of a broken analytics pipeline. Use this after get-experiment-pipeline-diagnostic surfaces a pipeline error, to inspect the assignment SQL as a possible root cause. If the experiment does not use a customer-warehouse assignment source (e.g. it uses a Datadog-default or reference-table source instead), this tool returns a message saying so rather than SQL — that is expected, not an error; look elsewhere (Datadog-default sources cannot fail this way).

get-experiment-assignment-sql

Read the experiment's latest recorded pipeline run state: NOT_STARTED, PENDING, RUNNING, SUCCEEDED, FAILED, or CANCELLED, with start and end timestamps when available. This reads actual run state, not SQL failure diagnostics. Use it before and after refresh-experiment-results to observe changes, then read results with get-experiment-results. This is the latest recorded run, not a refresh receipt. A newly queued refresh may not be visible yet. This response does not identify a specific refresh; NOT_STARTED or an older successful run cannot establish its outcome. Compare the timestamps with when you requested the refresh. If the outcome is still unclear, check the experiment in the Datadog UI before considering a retry.

get-experiment-run-status

Return the PIPELINE_STATUS diagnostic for an experiment — the platform's verdict on whether the experiment's most recent SQL-driven analytics pipeline (assignments + metrics) ran successfully. If present, the diagnostic includes an `error` message, a `resolution_prompt` describing the likely fix, an optional `resolution_link`, and the `dag_run_id` of the pipeline run it was computed from. Call this FIRST whenever a user reports that an experiment's pipeline or analysis 'failed', 'has no data', or 'looks broken' — before reaching for any other diagnostic tool. Its `dag_run_id` output feeds directly into get-experiment-failed-queries to find the exact query that failed. This tool is specifically for SQL-DEFINITION-caused pipeline failures (bad assignment SQL, bad metric SQL, warehouse permission errors, etc.) — NOT for interpreting experiment results, sample ratio mismatch (SRM), or metric trust (use get-experiment-diagnostics for those), and NOT for diagnosing dag/task-level execution crashes, timeouts, or Datadog-internal orchestration errors (use diagnose-experiment-run-failure for those). If no PIPELINE_STATUS diagnostic exists yet, this tool returns a message saying so — that does not necessarily mean the pipeline is healthy, only that no diagnostic has been computed.

get-experiment-pipeline-diagnostic

Get how much traffic an experiment received: the total number of subjects and the exposure count for each variant, with an is_traffic_imbalanced flag for a sample ratio mismatch (SRM). An experiment that has not started returns zero traffic and no variants. Use this to answer "how many users has the experiment reached" or "is traffic split as expected". When is_traffic_imbalanced is true, the random assignment may be broken: do not interpret variant differences or declare a winner. Call get-experiment-diagnostics for the SRM statistics (the ASSIGNMENT_IMBALANCE diagnostic).

get-experiment-traffic-summary

Get computed per-variant per-metric experiment results. Each metric carries an authoritative `verdict` field — one of `better`, `worse`, `inconclusive`, or `unreliable` — derived from the platform's significance classifier (CI excludes zero AND sign matches the metric's desired_change). TREAT `verdict` AS AUTHORITATIVE: do not re-derive significance from raw p-values or confidence intervals to overturn it. When verdict=unreliable, do not reason about magnitudes — the platform deems the result not trustworthy; surface the unreliable_reason and stop. Magnitudes (point estimates, lifts, confidence intervals, p-values, z-scores, sample sizes) are returned for narration only. Results are filtered to the experiment's configured CUPED setting; the alternate flavor is not exposed. Call get-experiment-diagnostics first so SRM warnings or zero-data metrics are surfaced before interpreting these numbers; never declare an overall experiment winner from this tool's output alone.

get-experiment-results