Releasebot
Docs Latest Create account

Feature Flagging and Experimentation Release Notes

Release notes for feature flagging, A/B testing and experimentation platforms

Get this feed:

Products (17)

Latest Feature Flagging and Experimentation Updates

  • July 2026
    • No date parsed from source.
    • First seen by Releasebot:
      Jul 19, 2026
    LaunchDarkly logo

    LaunchDarkly

    Metric measurement window

    LaunchDarkly adds metric measurement windows for warehouse native experiments, helping teams reduce bias by only counting completed metric periods. The feature supports Snowflake data sources, optional offsets, and clearer exclusion reporting in experiment results.

    This topic describes how to use metric measurement windows to prevent bias in warehouse native experiment results.

    A metric measurement window defines a fixed, required period of time during which LaunchDarkly collects metrics for a context. A window begins after a context first receives a flag variation in an experiment, and ends after a configured duration.

    Attached experiments only consider those metric events that occur within the configured measurement window, and the window must fully complete before the experiment includes any measurements for a context. When you stop an experiment, any metrics for contexts that have not reached the end of their measurement window do not contribute to experiment results.

    Restricted to Snowflake data sources

    You can only configure metric measurement windows with metrics created from Snowflake data sources, for use with warehouse native Experimentation. You cannot configure windows on metrics created from LaunchDarkly hosted events or other warehouse data sources. To learn more, read Metric event sources.

    Avoiding measurement bias in experiments

    Metric measurement windows ensure that all contexts included in an experiment have the same amount of time available to generate metric measurements. You define the period of time required to produce a conversion event or to produce the volume of metric values you want to measure. LaunchDarkly ensures that only measurements from completed windows are considered in experiment results. In this way, metric windows help you prevent late or incomplete user activities from biasing experiment results.

    When no measurement window is configured (the default behavior), all contexts that participate in an experiment contribute equally to the experiment result. Contexts added near the end of the experiment have less time to generate metrics, so they can negatively impact the experiment results. For example, consider a conversion event that typically requires three days to complete. Most contexts that join the experiment in the last two days of the experiment will negatively impact the conversion metric, even if some of those contexts eventually generate a conversion. By configuring a metric window of three days, you ensure that the experiment only considers units that have the full three days in which to produce the conversion event.

    Prerequisites and limitations

    You can configure metric measurement windows for any warehouse native metric created from a Snowflake data source. You cannot configure windows on metrics created from LaunchDarkly hosted events or other warehouse data sources. To learn more, read Snowflake native Experimentation.

    The data source you use for creating the metric must map the Timestamp value to a column that uses timestamp or datetime format and encodes timezone information. To learn more, read Metric data sources.

    By default, new metrics do not include a metric measurement window. When no measurement window is configured, all metric measurements collected during an experiment contribute equally to the experiment result. This matches the LaunchDarkly experiment and guarded release behavior prior to the introduction of metric windows.

    Configuring a metric window

    When you choose the duration of a metric measurement window, keep in mind:

    • The duration you choose should be long enough to capture all relevant measurements. LaunchDarkly stops measuring events for a context after the window completes.
    • If your conversion events require a lengthy period of user activity to generate, ensure that experiments run long enough to capture the needed volume of completed metric windows.
    • If you are measuring an activity that requires a lengthy setup process, you can optionally configure an offset value to delay measurements until some point after a context first receives a flag evaluation. Offset values enable you to exclude early metric events that might be considered as “noise” in the overall measurement. For example, if you want to measure input validation errors that occur when customers complete a purchase, you could use an offset value to exclude input validation errors that occur earlier in the purchase process.

    You configure optional metric window properties after you specify the analysis method for a warehouse native metric.

    To configure a measurement window:

    1. Open the Data section and navigate to the Metrics list.
    2. Click Create metric. The “Create metric” dialog appears.
    3. Select Warehouse native from the “Event source” drop-down menu.
    4. Select an available Snowflake data source from the “Metric data source” drop-down menu. To learn more, read Metric data sources.
    5. Search for or enter an Event key to use for the metric.
    6. Choose options in the “Metric definition” section to configure the metric aggregation type and analysis method. To learn more, read Components of a metric.
    7. Select the Enable custom measurement window checkbox.
    8. Use the “Window measured in” menu to choose whether to define the window in days, hours, or minutes.
    9. (Optional) Change the value in the “Start” field to delay metric measurements for a period of time after a context receives a flag variation. A value of zero specifies no offset, meaning the measurement window begins immediately after a context joins the experiment.
    10. Enter a value in the “End” field to configure the length of the measurement window.

    The end value must be greater than the start value

    Both the “End” and “Start” values are calculated relative to when a context first receives a flag variation in an experiment. The “End” value must be greater than the “Start” value to configure a measurement window.

    1. Enter a Metric name and and optional Description.
    2. Click Create.

    Interpreting metrics excluded from experiments

    Metrics with measurement windows introduce additional conditions for excluding their measurements from experiment results. For any connected experiment, a context’s metric measurements are excluded if:

    • Measurements occur outside of a configured metric window. Any metric events that occur before the window offset, and any events that occur after the window completes, are excluded from the experiment.
    • A configured measurement window does not complete. If the experiment ends before a context’s measurement window completes, all measurements for that context are excluded.
    • A configured measurement window completes, but the context generated no events. For numeric metrics, if you select the Exclude units that generate no events option, then contexts that complete their measurement window are excluded if they generate no event. To learn more, read Units without events.

    LaunchDarkly experiments show the full accounting of units that are excluded from experiment results, both during the experiment and at experiment completion. To view a breakdown of why units are excluded from an experiment, click a value in the “Sample size” column of the experiment results.

    To learn more, read Experiment results data.

    Original source
  • July 2026
    • No date parsed from source.
    • First seen by Releasebot:
      Jul 19, 2026
    LaunchDarkly logo

    LaunchDarkly

    Metric winsorization

    LaunchDarkly adds metric winsorization for warehouse native experiment metrics, helping teams reduce outlier impact on results with one-sided or two-sided percentile bounds.

    This topic describes how to use configure metric winsorization to eliminate extreme values in experiment results.

    Restricted to warehouse native metrics

    You can configure winsorization only for warehouse native metrics, for use with LaunchDarkly experiments. You cannot configure winsorization for metrics created from LaunchDarkly hosted events. To learn more, read Metric event sources.

    Limiting the impact of extreme values on experiments

    Winsorization is a statistical technique that replaces outlying values with values at a configured percentile. Using metric winsorization helps you limit the impact of extreme values in LaunchDarkly experiment results without introducing bias by selectively removing values.

    For example, consider a metric that generates the following (sorted) latency values for a single randomization unit during the course of an experiment:
    5, 120, 135, 140, 145, 150, 155, 160, 170, 950

    The value 950 is an extreme outlier in this sample of data, and would significantly affect the mean latency value. The P90 value for the data is 170, so configuring winsorization for the metric at upper bound P90 percentile replaces all values higher than 170 with the value 170. This yields the modified data set:
    5, 120, 135, 140, 145, 150, 155, 160, 170, 170

    LaunchDarkly supports configuring one-sided or two-sided winsorization as needed to limit the impact of extremely high values, extremely low values, or both. For example, winsorizing the example metric at both the lower bound P10 percentile and the upper bound P90 percentile mitigates the lower outlying 5 value, yielding the modified data set:
    120, 120, 135, 140, 145, 150, 155, 160, 170, 170

    Common use cases

    Winsorization is most commonly used with metrics that produce a long tail distribution of values. This generally corresponds to metrics that measure revenue, latency, or session duration. Using winsorization at the upper bound for P90 or higher percentiles limits the impact of extremely high values that would negatively skew experiment results.

    How LaunchDarkly computes winsorization percentiles

    LaunchDarkly computes the percentile values for winsorization using all metrics collected for a randomization unit across all arms of a warehouse native experiment. For metrics that use a metrics measurement window configuration, LaunchDarkly uses only those values collected within the configured window to determine the percentile values. If no window is configured, the measurement duration corresponds to the length of the experiment itself.

    If you choose Include units and set the value to 0 for a numeric metric, LaunchDarkly does not include assigned zero values when it computes winsorization percentiles. To learn more, read Units without events.

    Prerequisites and limitations

    You can configure metric measurement winsorization for any warehouse native metric. You cannot configure winsorization for metrics created from LaunchDarkly hosted events.

    Configuring winsorization

    You configure optional winsorization properties after you specify the analysis method for a warehouse native metric.

    To configure winsorization:

    1. Open the Data section and navigate to the Metrics list.
    2. Click Create metric. The “Create metric” dialog appears.
    3. Select Warehouse native from the “Event source” menu.
    4. Select an available data source from the “Metric data source” menu, or create a new data source. To learn more, read Metric data sources.
    5. Search for or enter an Event key to use for the metric.
    6. Choose the metric aggregation from the “Metric definition” section. The window populates a full metric definition using default values.
    7. Change options in the “Metric definition” drop-down menus as needed to change the analysis units or other metric analysis options. To learn more, read Components of a metric.
    8. (Optional) Choose Enable custom measurement window if you want to configure a metric measurement window. To learn more, read Metric measurement window.
    9. Choose Enable winsorization.
    10. Enter percentile values in the Lower bound and Upper bound fields as needed to specify the percentile value(s) used to winsorize extreme values. If you are configuring two-sided winsorization, the Upper bound value must be greater than the Lower bound value.

    Set Lower bound to zero, or Upper bound to 100, to disable winsorization for that bound.

    1. Enter a Metric name and and optional Description.
    2. Click Create.
    Original source

  • All of your release notes in one feed

    Join Releasebot and get updates from LaunchDarkly and hundreds of other software products.

    Create account
  • July 2026
    • No date parsed from source.
    • First seen by Releasebot:
      Jul 19, 2026
    LaunchDarkly logo

    LaunchDarkly

    Ratio metrics

    LaunchDarkly adds ratio metrics for Snowflake warehouse native experimentation, letting teams compare numerator and denominator aggregations for more flexible experiment analysis. It supports count distinct, shared context kinds, and frequentist experiments.

    This topic explains how to create LaunchDarkly ratio metrics, which measure the ratio of two separate aggregations from Snowflake warehouse data sources.

    About ratio metrics

    A ratio metric is a complex metric type that computes the ratio of two separate metric aggregations: one for the numerator component and one for the denominator component. Each aggregation component is a simple metric created from a warehouse data source. LaunchDarkly divides the total of the numerator aggregation by the total of the denominator aggregation to compute the final metric value.

    Configuring numerator and denominator aggregations for a ratio metric.

    A ratio metric helps you determine how flag variations affect the relationship between two measurements. You can use ratio metrics to address the following use cases, which simple metrics do not support:

    • Clustered analysis for experiments: Ratio metrics let you measure events that are grouped by an analysis unit that is finer-grained than the randomization unit chosen for the experiment. For example, you could measure the number of session errors generated relative to the total number of prompts that users created. In this example, you randomize the experiment by user contexts and configure a user aggregation for the denominator component, then configure a session aggregation for the numerator.
    • Conversion metrics normalized by a separate event: Simple metrics can measure conversion events normalized by users who participate in the experiment. Ratio metrics can measure conversion events normalized by users that generate some other event, configured in the denominator aggregation. For example, you could measure the number of users who clicked on a search result, relative to the number of users who initiated a search.

    You can add ratio metrics only to LaunchDarkly experiments that use the frequentist statistical methodology.

    LaunchDarkly uses the computed value of the ratio to compare the performance of flag evaluations during an experiment. Because a ratio metric can track two separate analysis units, LaunchDarkly uses the statistical delta method to account for covariance of the two units. This helps to ensure that experiment recommendations remain accurate, even when analysis units in the denominator perform differently for a given experiment arm. To learn more, read Statistical methodology for frequentist experiments.

    Aggregation types for ratio metrics

    You configure each aggregation in a ratio metric separately. The numerator and denominator can use the same or different aggregation types, and can even use data from different warehouse data sources. However, the selected data sources must include context key mappings for one or more shared context kinds.

    For example, if the data source for the numerator contains context key mappings for the “account,” “user,” and “session” context kinds but the denominator includes mappings for “session” and “device” contexts, then the ratio metric can only use “session” as the analysis unit. To learn more about mapping context keys in a warehouse data source, read Create data sources.

    Ratio metrics support the same aggregation types available for simple metrics, plus one additional aggregation type, count_distinct, that counts distinct values from a warehouse column you provide. The available aggregation types are:

    • Count uses sum aggregation to measure the total number of times a context generates the metric event (conversion metric).
    • Sum uses sum aggregation to measure the total of the numerical values provided with a context’s metric events (numeric metric).
    • Average uses average aggregation to measure the average numerical value provided with a context’s metric events (numeric metric).
    • Count distinct uses count_distinct aggregation to measure the total number of times a unique value appears in a warehouse column associated with a context’s metric events (numeric metric). This option ignores duplicate or null values in the column.

    The count_distinct aggregation type is available only for ratio metrics. It provides the flexibility to measure a distinct signal independently of the metric event count or event value. When you choose Count distinct, you provide the name of a warehouse column associated with the metric event to use for measuring distinct values.

    For all ratio metric aggregations that correspond to a numeric metric, LaunchDarkly uses imputation to assign a zero value to any units that do not produce a metric event. To learn more, read Units without events.

    Prerequisites and limitations

    You can create ratio metrics only from Snowflake warehouse native metrics, for use with warehouse native Experimentation. Configure your Snowflake warehouse integration and create a data source before you create new warehouse native metrics. To learn more, read Metric data sources.

    You cannot create ratio metrics from LaunchDarkly-hosted metric events, OpenTelemetry traces, or from warehouse data sources other than Snowflake.

    You can add ratio metrics only to experiments that use the frequentist statistical methodology. To learn more, read Analyzing experiments.

    Create a ratio metric

    To create a ratio metric:

    1. Open the Data section and navigate to the Metrics list.
    2. Click Create metric. The “Create metric” dialog appears.
    3. Click Ratio in the “Select metric structure” section. The “Select metric structure” section appears only if you have configured warehouse native Experimentation and a Snowflake warehouse data source.
    4. Configure metric options for the “Numerator” component:
      i. Choose an existing data source from the Select metric data source menu. The data sources you choose for the numerator and denominator components must have at least one context key mapping to the same context kind.
      ii. Enter the Event key to use for the numerator component of the metric.
      iii. Choose an aggregation type from the Aggregate as menu:
      - Count uses sum aggregation to measure the total number of times a context generates the metric event (conversion metric).
      - Sum uses sum aggregation to measure the total of the numerical values provided with a context’s metric events (numeric metric).
      - Average uses average aggregation to measure the average numerical value provided with a context’s metric events (numeric metric).
      - Count distinct uses count_distinct aggregation to measure the total number of times a unique value appears in a column associated with a context’s metric events (numeric metric). This option ignores duplicate or null values in the column.
      iv. If you chose Count distinct, enter a column name to use for the measurement in the Count distinct on field.
      v. (Optional) Click + Add winsorization or + Add custom measurement window as needed to configure the aggregation. To learn more, read Metric winsorization or Metric measurement window.
    5. Repeat the previous step to configure an aggregation for the “Denominator” component of the metric. The aggregation type or warehouse column does not need to match the configuration of the numerator. However, the data sources you choose for the numerator and denominator must have at least one shared context key mapping.

    Both metric windows must complete

    If you configure a metric window for the numerator and denominator, windows for both components must complete before LaunchDarkly includes the ratio metric result in an experiment. To learn more, read Interpreting metrics excluded from experiments.

    After you configure the numerator and denominator, the window displays a complete metric definition using the values you selected.

    1. Use the Analysis unit menu to select the analysis units to use for the metric. The same analysis units apply to both the numerator and denominator components of the ratio metric.
    2. Choose higher is better or lower is better to define the success criteria for the computed ratio.
    3. Enter a metric Name.
    4. (Optional) Add a Description.
    5. (Optional) Add any Tags.
    6. (Optional) Update the Maintainer.
    7. Click Create.

    You can also use the REST API: Create metric.

    Original source
  • July 2026
    • No date parsed from source.
    • First seen by Releasebot:
      Jul 19, 2026
    LaunchDarkly logo

    LaunchDarkly

    Creating metrics from traces

    LaunchDarkly adds Early Access support for creating custom metrics from OpenTelemetry traces, letting teams measure guarded rollouts with existing span data instead of new track() events. It also supports numeric trace metrics and creation from the Create metric dialog or Traces page.

    This topic explains how to create LaunchDarkly custom metrics from OpenTelemetry traces.

    This feature is for Early Access Program customers only

    Creating metrics from trace spans is only available to members of LaunchDarkly’s Early Access Program (EAP). To request access to this feature, contact your LaunchDarkly account manager.

    LaunchDarkly lets you create custom metrics from OpenTelemetry traces instrumented in your code, for use with guarded rollouts.

    Creating metrics from traces lets you use existing OpenTelemetry instrumentation to measure how application behavior changes during a guarded rollout, without re-instrumenting those behaviors as metric events using the track() method. You define a query that selects the trace spans you want to use to measure your application, and create a metric based on the query result. Each matching span observed during a guarded rollout indicates a metric event.

    To create numeric metrics from traces, such as for measuring regressions, you specify the span attribute name that provides the value you want to monitor.

    Trace metrics use the same aggregation and analysis methods as LaunchDarkly metrics created from metric events. To learn more, read Components of a metric.

    Prerequisites and limitations

    You can create custom metrics from trace spans that include a LaunchDarkly feature flag span event, indicated by the feature_flag.set.id attribute. The LaunchDarkly observability SDK plugins automatically include feature flag span events when you create trace spans.

    If your application uses a different OpenTelemetry library or package, you can configure the OpenTelemetry collector or use tracing hooks to add the required feature flag span events. To learn more, read Server-side SDKs.

    Trace metrics are compatible with guarded rollouts for managing feature releases. You cannot use trace metrics with LaunchDarkly experiments.

    Creating trace metrics

    You can create trace metrics using either the LaunchDarkly “Create metric” dialog or the observability “Traces” page. Both methods let you create a span query to select the spans you want to monitor in the metric.

    Use the “Create metric” dialog if you are familiar with creating metrics and filtering metric events and you want to use a similar interface to create metrics from spans. Use the “Traces” page if you are familiar with the observability search syntax or you want a real-time preview of your filter query results.

    Span query syntax differences

    The “Create metric” dialog uses a graphical query builder to help you filter trace spans, while the “Traces” page uses the observability query search specification.

    Both interfaces can create equivalent span filters, but they use different syntax for some conditions. The “Create metric” dialog uses the present token to indicate whether an attribute is present in a span. It does not support the EXISTS operator or its negation, NOT EXISTS.

    For example, if you use the “Traces” page to create a search that reads service_version EXISTS, the equivalent filter in the “Create metric” dialog is service_version is present.

    Using the Create metric interface

    To use the “Create metric” dialog to create a new trace metric:

    1. Navigate to the Metrics list.

    2. Click Create metric. The “Create metric” dialog appears.

    3. Select Traces from the “Event source” drop-down.

    4. Use the “Filter to spans” field to create a query that selects the trace spans to use for the new metric.

      The “Filter to spans” field uses these basic controls:

      • Click an empty spot in the field to display the span attributes, operators, or relational functions you can add to the query at that spot.
      • Type characters to filter the available selections you can add. Enter or click a name in the drop-down list to add the value.
      • Use checkboxes in the drop-down list to select multiple values, or use commas to separate multiple, typed values.
      • Click an existing attribute name, value, or operator to change or edit the displayed value.
      • Click the x icon next to a name, value, or operator to delete it.

      Span functions (Any span, Any span 2, Any span 3) can only be added to the top level of the filter query, and cannot be nested within parentheses. To learn more, read Span functions for trace search.

    5. (Optional.) Click View traces to view recent spans that match your filter query. This opens a new tab to the Traces page with your filter query applied.

    6. In the “Metric definition” section, choose the aggregation type for your metric. The window populates a full metric definition using default values.

      • Use Count or Count distinct units (Percent) to measure matching trace spans during a guarded rollout.
      • Use Sum or Average to create a numeric metric that aggregates a value from the filtered trace spans.

    7. If you are configuring a numeric metric:
      i. Click the “Choose a numeric span attribute” field and type or select the span attribute that provides the numeric value you want to measure.
      ii. Select Include units and set the value to 0 or Exclude units that generate no events to choose how to handle units that do not generate a matching span during a rollout.
      iii. Enter a Unit of measure to describe the value you are measuring.

    8. Use the “Metric definition” section to configure the metric’s analysis method and success criteria. To learn more, read Analysis method.

    9. Enter a Metric Name.

    10. (Optional) Add a Description.

    11. (Optional) Add any Tags.

    12. (Optional) Update the Maintainer.

    13. Click Create.

    Using the Traces interface

    To use the “Traces” page to create a new trace metric:

    1. Navigate to the Traces page.
    2. Use the Search… field to create a query that selects the trace spans to use for the new metric. Use feature_flag.set.id EXISTS to limit results to trace spans that have the required feature flag span event. To learn more, read Search specification.
    3. Review the filter query results in the “Spans” list.
    4. Select Create metric from the three-dot menu next to your query. This opens the Create metric dialog and populates it with the query you created.
    5. In the “Metric definition” section, choose the aggregation type for your metric. The window populates a full metric definition using default values.
      • Use Count or Count distinct units (Percent) to measure matching trace spans during a guarded rollout.
      • Use Sum or Average to create a numeric metric that aggregates a value from the filtered trace spans.
    6. If you are configuring a numeric metric:
      i. Click the “Choose a numeric span attribute” field and type or select the span attribute that provides the numeric value you want to measure.
      ii. Select Include units and set the value to 0 or Exclude units that generate no events to choose how to handle units that do not generate a matching span during a rollout.
      iii. Enter a Unit of measure to describe the value you are measuring.
    7. Use the “Metric definition” section to change the metric’s analysis method, analysis units, and success criteria as needed. To learn more, read Analysis method.
    8. Enter a Metric Name.
    9. (Optional) Add a Description.
    10. (Optional) Add any Tags.
    11. (Optional) Update the Maintainer.
    12. Click Create.

    Adding trace metrics to guarded rollouts

    You select trace metrics for use with guarded rollouts in the same way you select other LaunchDarkly metrics. To learn more, read Creating guarded rollouts.

    Original source
  • Jul 16, 2026
    • Date parsed from source:
      Jul 16, 2026
    • First seen by Releasebot:
      Jul 17, 2026
    Flagsmith logo

    Flagsmith

    v2.254.0

    Flagsmith ships 2.254.0 with OAuth login now surfacing new-user status, rollout segments defaulting to control, and new onboarding “next quest” cards. The release also tightens SCIM, seat-limit, and tagging behavior while improving segment membership performance.

    2.254.0 (2026-07-16)

    Features

    auth: surface is_new_user in OAuth login responses (#8011) (2c000a2)

    experimentation: default to control when rollout segment is created (#7905) (d53e0d7)

    onboarding: "next quest" cards (#7941) (403b292)

    Bug Fixes

    e2e: staging E2E failures from shared-project pollution and onboarding flag race (#8027) (df9a777)

    organisations: Enforce seat limit against licence-derived metadata (#8014) (3b840fd)

    scim: Arbitrary usernames accepted via SCIM (#8019) (0e3c8c7)

    tags: Duplicate system tags wedge GitHub tagging with MultipleObjectsReturned (#8013) (8aa41ab)

    Performance Improvements

    Segment Membership: Count all segments in one scan per environment (#8018) (b51e6b7)

    Original source
  • July 2026
    • No date parsed from source.
    • First seen by Releasebot:
      Jul 16, 2026
    LaunchDarkly logo

    LaunchDarkly

    OpenTelemetry in server-side SDKs

    LaunchDarkly now supports OpenTelemetry in server-side SDKs, letting teams send traces, metrics, and logs to LaunchDarkly, automatically normalize semantic convention attributes, and use the data for observability, experimentation, and guarded rollouts.

    OpenTelemetry in server-side SDKs

    This topic explains how to enable OpenTelemetry (OTel) in server-side SDKs, and how to display and use OpenTelemetry data in LaunchDarkly.

    Looking for information on OpenTelemetry in client-side SDKs?

    For information about using OpenTelemetry in LaunchDarkly client-side SDKs, read OpenTelemetry in client-side SDKs.

    About OpenTelemetry

    OpenTelemetry is an open source observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. Because OpenTelemetry is vendor- and tool-agnostic, you can reuse OpenTelemetry instrumentation that already exists in your code to send OpenTelemetry data to LaunchDarkly.

    We recommend enabling OpenTelemetry in LaunchDarkly server-side SDKs if you use the Observability, Experimentation, or Guarded rollouts features, or if you use third-party observability tools that support the OpenTelemetry framework.

    If you want to implement OpenTelemetry features in new code, we recommend using the LaunchDarkly observability plugins to automate the process of adding flag evaluation metadata and forwarding telemetry data directly to LaunchDarkly endpoints. LaunchDarkly provides observability plugins for many client and server SDKs. To learn more, read Observability SDKs.

    Using OpenTelemetry data in LaunchDarkly

    You can use OpenTelemetry data in LaunchDarkly in two ways:

    1. OpenTelemetry data ingestion: LaunchDarkly provides OpenTelemetry protocol (OTLP) HTTP and gRPC endpoints to support ingesting traces, metrics, and logs from your applications and from third-party application integrations. LaunchDarkly observability features help you search and visualize ingested OTel data, or configure alerts to respond to OTel signals. To learn about configuring OTel ingestion, read Observability SDKs and Observability Integrations. To learn about viewing ingested OTel data, read Observability.
    2. LaunchDarkly metrics: LaunchDarkly automatically generates metrics from certain OpenTelemetry traces, and these metrics are available in the Experimentation and guarded rollouts features. When ingested trace data contains feature flag evaluation span events along with certain HTTP span attributes or error span events, LaunchDarkly correlates the data and creates metrics to use with guarded rollouts. To learn more, read OpenTelemetry autogenerated metrics.

    You can also use any OTel traces that include feature flag span events to create custom LaunchDarkly metrics for use with experiments or guarded rollouts. To learn more, read Creating metrics from traces.

    Sending OpenTelemetry data to LaunchDarkly

    To configure and send OpenTelemetry data to LaunchDarkly when you are using LaunchDarkly server-side SDKs:

    1. (Optional) Add flag evaluation information to OpenTelemetry spans in your application. To learn how, read the section for your SDK under Server-side SDKs, below.
      • This step is optional but highly recommended, as it means that flag-specific details are available when you review your OTel data in the LaunchDarkly UI.
      • You might choose to skip this step, at least temporarily, if you have already instrumented OpenTelemetry in your application and only want to send your existing OTel data to LaunchDarkly.
      • If you create spans using a LaunchDarkly server-side observability plugin, the SDK adds the required flag evaluation information automatically.
    2. Configure your application or OpenTelemetry collector to use the LaunchDarkly OTel endpoints:
      • For HTTP, use https://otel.observability.app.launchdarkly.com:4318 or https://otel.observability.app.launchdarkly.com:443
      • For gRPC, use https://otel.observability.app.launchdarkly.com:4317.
      • If you use a LaunchDarkly server-side observability plugin, the SDK automatically sends telemetry to the default endpoints.
      • You may need to update your infrastructure to make sure your application can reach this domain. To learn more, read Accessing LaunchDarkly by domain.
    3. (Optional) Include an active LaunchDarkly SDK key as a resource attribute in your telemetry data.
      • This step is required if you are using OpenTelemetry SDKs. To learn how, read Setting resource attributes, below.
      • This step is not required if you are using LaunchDarkly server-side SDKs. If you use LaunchDarkly SDKs, this is set automatically.
    4. Send the OpenTelemetry data to LaunchDarkly. LaunchDarkly supports traces, metrics, and logs. Only traces data generates LaunchDarkly metrics. You can view metrics and logs in the LaunchDarkly UI when you use the Observability features.
      • You can use the OpenTelemetry Collector to pre-filter and aggregate this data. To learn how, read Configuring the collector, below.
      • Alternatively, you can send data directly from your application using OpenTelemetry SDKs.
      • LaunchDarkly server-side observability plugins automatically send telemetry to the default LaunchDarkly endpoints.

    Setting resource attributes

    [Expandable section]

    Configuring the collector

    [Expandable section]

    Automatic attribute normalization

    OpenTelemetry semantic conventions define standard attribute names for common concepts like HTTP requests, database operations, and messaging systems. These conventions evolve over time, and attribute names are occasionally renamed or restructured. For example, http.method was renamed to http.request.method and http.status_code was renamed to http.response.status_code. For more details on how attribute names change across OpenTelemetry versions, see the semantic conventions changelog.

    LaunchDarkly automatically normalizes deprecated OpenTelemetry semantic convention attributes to their current equivalents when it ingests your telemetry data. This means you can send data using older attribute names, and LaunchDarkly will create the corresponding current attribute names for you. This normalization applies to all OpenTelemetry data LaunchDarkly ingests, whether from LaunchDarkly SDKs with tracing hooks enabled or from external OTLP endpoints.

    This automatic normalization provides several benefits. LaunchDarkly ensures consistent attribute names across your telemetry data, even when services use different OpenTelemetry versions. You can search and filter using the current attribute names regardless of which version your services emit. You can also upgrade your instrumentation gradually without losing the ability to correlate data across services.

    When viewing trace attributes in LaunchDarkly, the UI displays indicators showing which attributes have been remapped from deprecated conventions.

    Server-side SDKs

    LaunchDarkly processes metrics, logs, and traces from your OpenTelemetry data:

    • LaunchDarkly processes OpenTelemetry metrics and logs and displays them in the LaunchDarkly UI under Observability
    • LaunchDarkly processes two types of data from OpenTelemetry traces:
      • HTTP span attributes, including latency, 5xx occurrences, and other errors, where the span has or overlaps with another span that has at least one feature flag span event. This includes nested spans.
      • Exception span events that occur after a feature flag span event on the same trace. If the exception occurs before the feature flag event, LaunchDarkly does not capture it.

    A feature flag span event is defined as any span event that contains a feature_flag.context.key attribute. LaunchDarkly ignores traces that do not include span events with this attribute.

    In most server-side SDKs, the OTel traces are specific to the LaunchDarkly project and environment that you specify in the collector configuration, described above. In the .NET (server-side) and Node.js (server-side) SDKs, you can provide the LaunchDarkly client-side ID in the tracing hook. This enables you to send traces for multiple projects and environments using one collector.

    The following sections describe, for each supported SDK, how to ensure your spans have compatible feature flag events.

    Sending feature flag event data requires feature flag evaluation

    The OpenTelemetry tracing hook automatically attaches feature flag event data to your OTel traces for you. Feature flag event data, including the feature_flag.context.key attribute, is only generated when your application uses the LaunchDarkly SDK to evaluate a feature flag.

    This feature is available in the following SDKs:

    • .NET (server-side)
    • Go
    • Java
    • Node.js (server-side)
    • PHP
    • Python
    • Ruby

    .NET (server-side)

    Use the .NET (server-side) SDK observability plugin for new applications

    We recommend you use the .NET (server-side) SDK observability plugin for new application development or OpenTelemetry instrumentation. The observability plugin provides additional configuration options and automatically adds LaunchDarkly environment and flag attributes to OpenTelemetry spans.

    The instructions that follow are provided for reference, for OpenTelemetry applications that were developed before the observability plugin was available.

    [Expandable .NET (server-side) code sample]

    Go

    Use the Go SDK observability plugin for new applications

    We recommend you use the Go SDK observability plugin for new application development or OpenTelemetry instrumentation. The observability plugin provides additional configuration options and automatically adds LaunchDarkly environment and flag attributes to OpenTelemetry spans.

    The instructions that follow are provided for reference, for OpenTelemetry applications that were developed before the observability plugin was available.

    [Expandable Go code sample]

    Java

    [Expandable Java code sample]

    Node.js (server-side)

    Use the Node.js (server-side) observability plugin for new applications

    We recommend you use the Node.js (server-side) SDK observability plugin for new application development or OpenTelemetry instrumentation. The observability plugin provides additional configuration options and automatically adds LaunchDarkly environment and flag attributes to OpenTelemetry spans.

    The instructions that follow are provided for reference, for OpenTelemetry applications that were developed before the observability plugin was available.

    [Expandable Node.js (server-side) code sample]

    PHP

    [Expandable PHP code sample]

    Python

    [Expandable Python code sample]

    Ruby

    [Expandable Ruby code sample]

    Original source
  • Jul 15, 2026
    • Date parsed from source:
      Jul 15, 2026
    • First seen by Releasebot:
      Jul 17, 2026
    Flagsmith logo

    Flagsmith

    v2.253.0

    Flagsmith releases 2.253.0 with experiment and API improvements, including unique analytics IDs, wizard UX updates, Core API OpenAPI bundling, and lifecycle API adoption. It also brings dark mode refinements, bug fixes, dependency updates, and new experimentation guides.

    2.253.0 (2026-07-15)

    Features

    • add unique analytics IDs to experiment, metric, and warehouse buttons (#7997) (d479a3d)
    • API: Adopt the flagsmith entrypoint (#7901) (da194ca)
    • API: Bundle the Core API OpenAPI schema (#7959) (a7b0d21)
    • experiments: wizard UX improvements (#7978) (4510b72)
    • use lifecycles API (#7793) (26ddf19)

    Bug Fixes

    • add navigation to identity page from segment members list (#7927) (f005081)
    • API: Nested viewsets expose data across projects and organisations (#7945) (26a1e29)
    • dark mode: move colour and shadow utilities from Bootstrap to tokens (#7982) (9ecdf6d)
    • dark mode: resolve .text-secondary to the token, not Bootstrap (#7981) (3eeaf38)
    • experimentation: poll warehouse status for created connections (#8001) (038238b)
    • Experiments: Dark mode visibility in results page (#7980) (c92b305)
    • features: preserve multivariate bucketing salt across feature state recreation (#7914) (62a8143)
    • LaunchDarkly: Import processing not idempotent for completed requests (#7954) (5cfb9f4)
    • make Headway bell icon clickable (#7925) (fd438ba)
    • nav: stop project navbar items clipping off-screen (#7968) (2b4473b)
    • return 400 when environment is null in featurestate update (#7957) (686bb9c)
    • Segment Membership: Enabled for different organisations in backend and frontend (#7966) (aa4ad62)
    • webhooks: accept 2xx status codes in webhook test endpoint (#7992) (7a6210c)

    Dependency Updates

    • api: update dependency django to v5.2.16 [security] (#7990) (1c73453)
    • api: update dependency flagsmith-common to >=3.12.0,<4 (#8008) (0cb114b)
    • api: update dependency flagsmith-private to >=0.11.0,<1 (#8006) (1042aad)
    • MCP: Bump flagsmith-common to 3.12, pyfakefs to 6 (#8007) (e55b56d)

    CI

    • Renovate: Eagerly bump flagsmith-common and flagsmith-private (#8005) (d625997)

    Docs

    • add Experimentation guides (#7993) (1c7121d)
    • update links for local evaluation and edge proxy docs (#7961) (f9560b6)
    Original source
  • Jul 15, 2026
    • Date parsed from source:
      Jul 15, 2026
    • First seen by Releasebot:
      Jul 16, 2026
    Growthbook logo

    Growthbook

    AI Coding Agents and A/B Testing: How to Automate the Experiment Lifecycle

    Growthbook 4.4 brings AI coding agents into the experiment lifecycle, letting teams ideate, create feature flags, analyze product data, build, test, and roll out changes from Claude Code, Cursor, Codex, or other tools with templates and guardrails for safer experimentation.

    Ideate on features, create feature flags, analyze product data, and test what you build, all from Claude Code, Cursor, or Codex against GrowthBook.

    AI coding tools are reducing the cost of coding in ways no one ever imagined. Coding that used to take days now takes a prompt. But coding is just one step in the software development lifecycle. Deciding what to build, deploying safely, and tracking the impact of new features still take time. Finding ways to speed to up these processes unlocks even more of the benefits of agentic coding.

    That is the vision behind GrowthBook’s 4.4. Your AI coding agent can now drive the entire experiment lifecycle against GrowthBook. From a single conversation in your editor, an agent can analyze your product data, ideate on a new feature, create the feature flag, build the variant, and test it. This post covers what that workflow looks like, how you can incorporate guardrails to create trust, and how to run it from any AI coding agent.

    How AI agents can automate the entire lifecycle

    Automating the lifecycle is broader than running a single A/B test. AI coding agents can now cover the full product development lifecycle:

    • Analyze product data. The agent pulls product metrics and experiment data to identify new product opportunities
    • Ideate. Describe a problem in plain language and have the agent propose concrete changes to try, grounded in your actual codebase.
    • Create feature flags. The agent creates the feature flag and wires it into your code, so the change is rolled out gradually and safely.
    • Build and test. Create experiments using templates, standardized metrics and guardrails.
    • Analyze experiments and make decisions. Use AI to analyze experiment data, extract learnings, and make go/no-go recommendations.

    How templates and guardrails streamline using AI to create experiments

    There are many ways an experiment can go wrong, including flawed assignment rules, bad metrics, and unexpected side effects. Consistency and rigor become even more important as you scale.

    GrowthBook addresses these needs in a couple of key ways. Experiment templates pre-define the metrics, randomization, and setup for a class of experiments, so the agent knows your best practices. A team can keep a template for, say, logged-out conversion tests, and every front-end experiment of that type inherits the right goal metrics and guardrails automatically. A built-in decision framework encodes when a result is genuinely shippable, rather than leaving that to the agent's guesswork. And GrowthBook stays the source of truth, so business context lives in one place instead of being re-derived in every prompt.

    This is the real shift behind agentic experimentation. The agent handles the mechanics. The platform holds the judgment.

    AI can apply a series of skills to automate the experimentation process

    Take a simple example: testing new copy for a landing-page headline. You give your coding agent the idea in plain language and point it at the file. From there, the agent works the lifecycle:

    • Ideate and build. Reads the file, proposes a few headline variants, and picks one to test.
    • Configure. Finds the right experiment template in GrowthBook, confirms the metrics, and creates the experiment in draft.
    • Wire it up. Creates the feature flag, links the experiment to it, and edits the component to read from the flag. Nothing is live yet.
    • QA checkpoint (you). Confirm the flag is wired correctly in GrowthBook before anything ships.
    • Launch. On your approval, the agent starts the experiment and tracking fires automatically as users are bucketed into variants.

    (Screenshot of Claude Code showing the results of an experiment)

    Reading and shipping work the same way. Later, you ask the agent how the test is doing:

    • Analyze. Pulls the latest results, checks the test is well-powered with clean data, and summarizes what happened.
    • Recommend. Because the decision framework lives in GrowthBook, the recommendation reflects your team's shipping criteria, not a generic heuristic.
    • Ship (your call). If the result clears the bar, tell the agent to roll out the winner. It ships the treatment and writes up the result, with flag cleanup as an optional next step.

    This works from any AI coding agent

    Whether you use Claude Code, Cursor, Codex or any other coding agent, you can apply this same workflow. All the key components are coding agent-independent, including the programmatic endpoints, the CLI, and a set of open-source skills that teach an agent how to drive GrowthBook correctly. All of this then combines with the context of your own repository.

    The governance layer, the templates and the decision framework and your source of truth for experiments, all work the same, consistently and safely with any tool.

    The skills are open source and available on GitHub. You can use them as-is or adapt them to how your team runs experiments.

    Where humans stay in the loop

    Automating the lifecycle does not mean removing yourself from it. The workflow is designed around checkpoints precisely because some decisions should not be fully delegated.

    QA is the clearest example. Before an experiment goes live, a person should confirm the feature flag is wired correctly and behaves as expected. Ambiguous results are another. When a test is underpowered, or a goal metric moves while a guardrail slips, that is a judgment call about tradeoffs, not a mechanical decision. The agent can surface the situation and make a recommendation, but a human should own the call.

    Think of the agent as a fast, tireless operator that handles the setup, the wiring, the data pulls, and the rollout. The strategy, the QA gate, and the final ship decision stay with you.

    Key takeaways

    • AI made building cheap, but the experiment lifecycle stayed manual. Agentic experimentation closes that gap.
    • An AI coding agent connected to GrowthBook can run the full product development lifecycle: ideate, create feature flags, analyze product data, build, and test.
    • Guardrails are what make it trustworthy. Experiment templates and a built-in decision framework move judgment into the platform so agents cannot improvise metrics or ship on noise.
    • It is tool-agnostic. The workflow runs from Claude Code, Cursor, Codex, or any agent, because the logic lives in GrowthBook's skills, CLI, and endpoints.
    • Humans still own QA and the ship decision. The agent handles mechanics, not judgment.

    Get started

    The build step and the test step are now both moving at the speed of AI. The way to keep that fast loop safe is to put your experimentation structure into the platform, then let your coding agent drive against it.

    The GrowthBook skills are open source and ready to try on GitHub. To see the full workflow end-to-end, watch the walkthrough video. And if you are new to GrowthBook, you can start with feature flagging and experimentation in one platform.

    Original source
  • Jul 13, 2026
    • Date parsed from source:
      Jul 13, 2026
    • First seen by Releasebot:
      Jul 14, 2026
    Statsig logo

    Statsig

    🔐 Granular Delete Permission for Configs

    Statsig adds granular role permissions for configs, letting teams separate Edit, Archive, and Delete access on the Role Permissions page. The update helps organizations keep delete rights narrow while expanding edit access, with opt-in enablement through the Statsig account team.

    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

    .

    Original source
  • Jul 10, 2026
    • Date parsed from source:
      Jul 10, 2026
    • First seen by Releasebot:
      Jul 11, 2026
    Vercel logo

    Flags SDK by Vercel

    @vercel/[email protected]

    Flags SDK improves flag bucketing by aligning rollouts, splits, and segment splits onto one shared hash scheme. This release keeps split assignments effectively unchanged and prevents user reassignment when converting between rollout and split outcomes.

    Minor Changes

    #427 50b1aa4 Thanks @dferber90! - Align rollout, split, and segment split user assignment onto a single hash bucketing scheme.

    Previously splits and rollouts bucketed users with opposite conventions, so switching a flag between a split and a rollout (or locking in a rollout as a split) could reassign users even when the effective distribution was unchanged. All three now derive their cut points from one shared boundary function over the full hash space, so a rollout at a given percentage is identical to the equivalent split.

    Split assignments are effectively unchanged. Rollouts and segment splits are re-bucketed once with this release; after that, converting a flag between outcome types never reassigns anyone.

    Original source