mixpanel_experiment (Resource)

Manages a Mixpanel experiment — a structured A/B test configuration that measures the impact of product changes. Experiments define variants, metrics, and hypothesis, and track lifecycle states from draft through active testing to conclusion with recorded decisions.

Example Usage

resource "mixpanel_experiment" "pricing_test" {
  name        = "Pricing Page Redesign"
  description = "Test impact of new pricing table layout"
  hypothesis  = "Simplified pricing tiers will increase conversion"

  desired_state = "draft"

  metrics = [
    {
      id   = "metric_123"
      name = "Conversion Rate"
      type = "primary"
    }
  ]

  variants = [
    {
      id   = "control"
      key  = "control"
      name = "Current Layout"
    },
    {
      id   = "treatment"
      key  = "treatment"
      name = "Simplified Layout"
    }
  ]
}

# Launch the experiment
resource "mixpanel_experiment" "pricing_test_active" {
  name          = "Pricing Page Redesign"
  description   = "Test impact of new pricing table layout"
  hypothesis    = "Simplified pricing tiers will increase conversion"
  desired_state = "active"

  metrics = [
    {
      id   = "metric_123"
      name = "Conversion Rate"
      type = "primary"
    }
  ]

  variants = [
    {
      id   = "control"
      key  = "control"
      name = "Current Layout"
    },
    {
      id   = "treatment"
      key  = "treatment"
      name = "Simplified Layout"
    }
  ]
}

# Conclude with a recorded decision
resource "mixpanel_experiment" "pricing_test_concluded" {
  name          = "Pricing Page Redesign"
  desired_state = "concluded"

  decision = jsonencode({
    success = true
    variant = "treatment"
    message = "Simplified layout improved conversion by 12%"
  })
}

Lifecycle management (desired_state)

The desired_state attribute drives an experiment through its lifecycle. Valid states:

• draft — The initial state when an experiment is created. Use this to prepare configuration before exposing it to users.
• active — Launches the experiment and begins variant assignment. Users start receiving the test variants.
• concluded — Ends the experiment. If the decision attribute is set, the provider records a success/failure decision (which variant won, and why). Without decision, the experiment is force-concluded with no decision recorded.
• archived — Soft-deletes the experiment. An active experiment is automatically concluded before archiving. Setting desired_state to any other value restores an archived experiment.

When desired_state is unset, the provider tracks the server-side state without performing transitions.

Important lifecycle rules: - An experiment cannot return to draft after being launched. - An experiment with a recorded decision (server status of success or fail) cannot be relaunched. Create a new experiment instead. - Both decided states (success and fail) are represented as desired_state = "concluded". The raw decision status remains visible in the read-only status attribute.

Schema

Required

• name (String)

Optional

• decision (String) jsonencode() of the decide payload used when desired_state reaches concluded: {"success": bool, "variant": str, "message": str, "mode": "ship_variant"|"do_not_ship"|"abandon", "keep_cohort_targeting": bool}. success is required unless mode is set; variant is required when mode = ship_variant. When unset, concluding uses force_conclude (no decision recorded).
• description (String)
• desired_state (String) Lifecycle state to drive the experiment to: draft, active, concluded, or archived. A decided experiment (server status success or fail) surfaces as concluded; the raw value stays readable in status. When unset, tracks the server-side state.
• experiment_id (String)
• exposures_cache (String)
• feature_flag (String)
• feature_flag_id (String)
• feature_flag_key (String)
• hypothesis (String)
• metrics (Attributes List) (see below for nested schema)
• results_cache (String)
• settings (String)
• share_with_project (Boolean) Whether to share this entity with the whole project after creation. Entities created by a service account are otherwise visible only to that service account. Defaults to true. See the Entity sharing guide.
• tags (List of String)
• variants (Attributes List) (see below for nested schema)

Read-Only

• allow_staff_override (Boolean)
• can_pin (Boolean)
• can_share (Boolean)
• can_update_basic (Boolean)
• can_view (Boolean)
• content_environments_id (Number)
• content_type (String)
• created (String)
• creator_email (String)
• creator_id (Number)
• creator_name (String)
• deleted (String)
• end_date (String)
• feature_flag_content_env_id (Number)
• id (String) The ID of this resource.
• is_favorited (Boolean)
• is_shared_with_project (Boolean)
• is_superadmin (Boolean)
• last_modified_by_email (String)
• last_modified_by_id (Number)
• last_modified_by_name (String)
• modified (String)
• pinned_date (String)
• project_id (Number)
• project_name (String)
• start_date (String)
• status (String) The experiment's lifecycle status.

Nested Schema for metrics

Optional:

• data_group_id (String)
• id (String) Unique metric ID
• name (String) Metric display name
• type (String) Type of experiment metric.

Nested Schema for variants

Optional:

• id (String) Unique variant ID
• key (String)
• name (String) Variant display name

Import

Import uses a composite ID format: PROJECT_ID:EXPERIMENT_ID.

import {
  to = mixpanel_experiment.pricing_test
  id = "1234567:exp_abc123def456"
}

Retrieve the experiment ID from the Mixpanel UI URL or via the mixpanel_experiment data source.

Related Resources

• mixpanel_feature_flag — Experiments can drive feature flags to control variant delivery and enable ship decisions.