Experimentation stat sig change (#783)

* Change Chance of Beating Control text

* Fix Date Range description

* Update images on feature experimentation page

* Update metrics images

* Fix spelling mistake

* Update Experiment Results text and images

* Update image quality and fix grammar

docs/best-practices/product-led-experimentation.md

@@ -75,7 +75,7 @@ Once you have set up the SDK to send custom events, you can [create Metrics](/pl
 The **Event Type** in the modal must correspond to the `type` field defined in code. This is not to be confused with the Type selected from the dropdown.
 :::
 
-To [apply your Metric to a Feature](/platform/experimentation/creating-and-managing-metrics#attaching-metrics-to-features), navigate to the Comparative Analysis section of the Feature page, and select the metric you wish to attach. 
+To [apply your Metric to a Feature](/platform/experimentation/creating-and-managing-metrics#attaching-metrics-to-features), navigate to the Experiment Results section of the Feature page, and select the metric you wish to attach. 
 
 ![Attach a Metric](/mar-2024-attach-metric.gif)
 

docs/platform/experimentation/creating-and-managing-metrics.md

@@ -96,7 +96,7 @@ To run a test, the following fields must be set:
 
 **Control** - After selecting a Feature, a "control" variation must be selected. This is what will be used to show a comparative analysis against all other variations in a feature. Typically, an "off" or "Baseline" variation would act as the control. For more information on this, please refer to the [Feature Experimentation documentation](/platform/experimentation/feature-experimentation).
 
-**Date Range** - This range will default from the moment the Metric (or feature) was created, to now within 30 days. If 30 days have passed since the creation of the Metric or feature, the date range must be a 30 day range.
+**Date Range** - Select a date range of up to the last 30 days to display results for. This range will default to the last 30 days or to the Feature creation date if the Feature was created within 30 days. 
 
 **Environment** - This will calculate the Metric using events from the specified environments.
 
@@ -114,39 +114,35 @@ Tracking metrics within a feature is an important aspect of data analysis, as it
 
 Here are some steps you can follow to track metrics within a feature:
 
-1.  **Select the feature you want to track**: Within that feature, navigate to the `Data & Results` section of the page and click on `Comparative Analysis`.
+1.  **Select the feature you want to track**: Within that feature, navigate to the `Data & Results` section of the page and click on `Experiment Results`.
 
-    ![Comparative Analysis tab within a DevCycle feature's Data & Results view](/comparative-analysis-navigation-tab.png)
+    ![Comparative Analysis tab within a DevCycle feature's Data & Results view](/experiment-results-navigation-tab.png)
 
 2.  **Choose the metric(s) associated with the feature**: Create new metrics or attach existing ones to the feature by navigating to the `Choose a Metric` dropdown.
 
-    ![Choose a Metric dropdown menu](/comparative-analysis-metrics-dropdown.png)
+    ![Choose a Metric dropdown menu](/experiment-results-metrics-dropdown.png)
 
 3.  **Attach the metric(s)**: Attach the metric from the dropdown menu by selecting it. For our example, let's use the metric `Metric Testing`, which has already been setup within our project.
 
-    !["Metric Testing" metric selected from the metrics dropdown](/comparative-analysis-metric-testing.png)
-
-4.  **Calculate results**: Once one or more metrics have been selected, we can then run the metric calculation to generate insight into how the feature is doing.
-
-    ![Feature metrics ready to be calcuated](/comparative-analysis-calculate-metrics.png)
+    !["Metric Testing" metric selected from the metrics dropdown](/experiment-results-metrics-testing.png)
 
     While the setup has some default values, the Metric requires the following fields to be filled:
 
     - **Control** - This is what will be used to show a comparative analysis against all other variations in a feature. Typically, an "off" or "Baseline" variation would act as the control. For more information on this, please refer to the [Feature Experimentation documentation](/platform/experimentation/feature-experimentation).
 
-    - **Date Range** - This range will default from the moment the Metric (or feature) was created, to now within 30 days. If 30 days have passed since the creation of the Metric or feature, the date range must be a 30 day range.
+    - **Date Range** - Select a date range of up to the last 30 days to display results for. This range will default to the last 30 days or to the Feature creation date if the Feature was created within 30 days.
 
     - **Environment** - This will calculate the Metric using events from the specified environments.
 
-Once these fields are set, the calculation can be ran by clicking the calculate button, which will run for all Metrics for the Feature.
+4.  **Calculate results**: Once one or more metrics have been selected, we can then run the metric calculation to generate insight into how the feature is doing.
 
-![Arrow pointing to calculate button on Metric](/june-2022-calculate-metric.png)
+    ![Feature metrics ready to be calcuated](/experiment-results-metrics-calculate.png)
 
-Once calculated, if there is available data for the Feature, the results data will populate within the dashboard.
+5. **View your results**: Once calculated, if there is available data for the Feature, the results data will populate within the dashboard.
 
-![Calculation results](/june-2022-metrics-calculated.png)
+    ![Calculation results](/feature-experiment-full-results.png)
 
-From here, useful information such as trends and patterns in the data can be used to make informed decisions about how to optimize the feature for performance improvements.
+    From here, useful information such as trends and patterns in the data can be used to make informed decisions about how to optimize the feature for performance improvements.
 
 ### How do Metrics get calculated?
 

docs/platform/experimentation/feature-experimentation.md

@@ -44,16 +44,16 @@ To set this up, create a targeting rule in Production that delivers to All Users
 ## Adding Metrics to Your Feature
 
 :::info
-Experimentation relies on custom events.
+Experimentation relies on [custom events](/sdk/features#tracking-custom-events).
 
-Experimentation is available to all customers on any plan. However, to perform experiments, events must be sent to DevCycle to calculate metrics. These events are added to your existing plan. To learn more, read about our pricing, or contact us.
+Experimentation is available to all customers on any plan. However, to perform experiments, events must be sent to DevCycle to calculate metrics. These events are added to your existing plan. To learn more, read about our [pricing](https://www.devcycle.com/pricing), or contact us.
 :::
 
 Now that you have two segments receiving different experiences, the only other thing you need to run an experiment is a metric to evaluate the comparative performance of those experiences.
 
-To add a metric to your feature, click “Comparative Analysis” under the “Data & Results” section on the sidebar of the feature editing page. Click the “Choose a Metric” dropdown. This will bring up the option to add a metric that has already been created in the project or to create a new one.
+To add a metric to your feature, click “Experiment Results” under the “Data & Results” section on the sidebar of the feature editing page. Click the “Choose a Metric” dropdown. This will bring up the option to add a metric that has already been created in the project or to create a new one.
 
-![Add Metrics from Feature Editing Page](/august-2022-add-metric-feature-page.png)
+![Add Metrics from Feature Editing Page](/add-metric-feature-page.png)
 
 For the creation of new metrics check out our documentation [here](/platform/experimentation/creating-and-managing-metrics).
 
@@ -63,11 +63,11 @@ Once you have metrics in your project, all you need to do is:
 
 ![Adding a Metric](/feature-experiment-control-metric.png)
 
-Now that you have a metric added and a control Variation selected, the performance of the experiment will be tracked over time. With the performance of the treatment Variation compared to the control Variation with Difference and Chance of Beating Baseline percentages shown and updated in real-time as the experiment runs.
+Now that you have a metric added and a control Variation selected, the performance of the experiment will be tracked over time. The performance of the treatment Variation compared to the control Variation will be tracked by the Difference and Statistical Significance indicator in real-time as the experiment progresses.
 
-![Reviewing Metric Performance](/feature-experiment-full.png)
+![Reviewing Metric Performance](/feature-experiment-full-results.png)
 
-Any number of metrics can be added to a feature for analysis, keep clicking “Choose a Metric” and add pre-existing or create new metrics as needed.
+Any number of metrics can be added to a Feature for analysis, keep clicking “Choose a Metric” and add pre-existing or create new metrics as needed.
 
 ## Determining a Winner
 
@@ -77,14 +77,20 @@ The length of time an experiment needs to run to determine a winner varies depen
 
 Given the time it takes, your team should generally avoid early analysis and create a process by which an experiment runs with no review of results until a pre-determined amount of time has passed.
 
-Once this time has passed, the charts and graphs for any added metrics can be reviewed to determine which Variation performed best. When metrics are created, you define if a decrease or an increase is the targeted improvement. Our results graphs take this into account and show clearly if the metrics have driven either positive or negative results. The charts also provide guidance on if statistical significance has been achieved by providing a Chance of Beating baseline.
+Once this time has passed, the charts and graphs for any added metrics can be reviewed to determine which Variation performed best. When metrics are created, you define if a decrease or an increase is the targeted improvement. Our results graphs take this into account and show clearly if the metrics have driven either positive or negative results. The charts also provide guidance on if statistical significance has been achieved by displaying the following indicators.
 
-Statistical significance has been achieved if this number is either 0% or 100%.
+| Statistical Significance | Definition |
+| :-: | - |
+| :white_check_mark: | Positive Significant Result |
+| :x: | Negative Significant Result |
+| ... | Non-Significant Result |
 
 **Positive Results**
+
 ![Positive Metric Results](/feature-experiment-positive-results.png)
 
 **Negative Results**
+
 ![Negative Metric Results](/feature-experiment-negative-results.png)
 
 

docs/platform/experimentation/how-metrics-are-calculated.md

@@ -22,52 +22,46 @@ Below is a brief definition of the calculations used to determine the success of
 
 This type counts the total number of times this event has been seen ONLY when the actual related variable has been evaluated. This is a very useful case, as there may be events which already exist within your system which could potentially also be impacted by this variable. In this case, this type of Metric represents the exact number of times that event has been sent ONLY after the related variable has since been evaluated for use.
 
-![Per Evaluation Example](/june-2022-per-evaluation-example.png)
-
 ### Type: Count per Unique User
 
 This Metric type calculates the total number of times a unique user (or service) has sent this event. This can be something such as total number of clicks on a new feature, total number of API calls for a new service, total number of of views for a new advertisement, etc. This is also useful for error tracking -- A total count of specific errors is a great Metric to count when monitoring the rollout of a new release of a feature.
 
-![Per User Example](/june-2022-per-user-example.png)
+![Per User Example](/feature-experiment-negative-results.png)
 
 ### Explanation of Columns
 
-**Variation** - The name of the variation for the feature. Each event sent by DevCycle will contain a set of Features and Variations a user is in at that time, which will ultimately influence the entire calculation
+**Variation** - The name of the variation for the feature. Each event sent by DevCycle will contain a set of Features and Variations a user is in at that time, which will ultimately influence the entire calculation.
 
-**Events/Denominator** = This is a straight calculation of the number of events divided by the denominator chosen for the metric
+**Events/Denominator** = This is a straight calculation of the number of events divided by the denominator chosen for the metric.
 
 **% Rate** - This is calculated in the following way:
 
 `(Conversion Rate Variation - Conversion Rate Control) / Control Rate`
 
 **% Difference** - This is a simple calculation of the difference between the Events/Denominator of the variation and the Control variation. 
 
-**Chance to beat Control** - This number will fluctuate as your experiment accumulates more data.
-
-Once the Chance to beat Control reaches 100% it confirms that the variation has reached a 95% confidence between Control and Variation.
+**Statistical Significance** - An icon that indicates whether the Feature has reached statistical significance or not at a 95% confidence interval.
 
 ## Value Optimization Metrics (Numerical Metrics)
 
 ### Type: Sum per User
 
 Each event can carry a numerical value with it, and this Metric will sum up the total number sent with the events per unique user. This type of Metric is great for tracking things such as Revenue, or number of total items purchased or interacted with. From an engineering view, things such as a total number of api calls per unique user may be something intended to decrease (for optimizations) or increase (for increased interaction).
 
-![Total Value](/june-2022-total-value-example.png)
+![Total Value](/feature-experiment-positive-results.png)
 
 ### Type: Average per User
 
 Similar to the sum per user, the average for user also uses the numerical value on each event. This type of Metric is extremely useful for tracking things such as the average latency per API call, or average size of an API call, hoping for a decrease. Load times, server load, api latency, or even your own internal build time can be candidates for a Metric which is re-used across every single feature for viewing the impact and reacting accordingly. 
 
-![Avg Value](/june-2022-avg-value-example.png)
+![Avg Value](/feature-experiment-negative-results.png)
 
 ### Explanation of Columns
 
-**Variation** - The name of the variation for the feature. Each event sent by DevCycle will contain a set of Features and Variations a user is in at that time, which will ultimately influence the entire calculation
+**Variation** - The name of the variation for the feature. Each event sent by DevCycle will contain a set of Features and Variations a user is in at that time, which will ultimately influence the entire calculation.
 
 **Average Value per User** - Is the calculated mean of the user event averages.
 
 **% Difference** - Simple difference check against the Control value.
 
-**Chance to beat Control** Similar to above - this number will fluctuate as your experiment accumulates more data.
-
-Once the Chance of Beating Baseline reaches 100% it confirms that the variation has reached a 95% confidence between Baseline and Variation.
+**Statistical Significance** - An icon that indicates whether the Feature has reached statistical significance or not at a 95% confidence interval.

docs/platform/feature-flags/variables-and-variations/variables.md

@@ -7,7 +7,7 @@ Variables are the elements that can change within a Feature.
 
 > For example, if you have a Feature that controls a new UI element, a Variable could be the color of that element. 
 
-By default, upon creation of a Feature, a `Boolean Variable`` will be created which has the same name as the Feature's key for easier reference. 
+By default, upon creation of a Feature, a `Boolean Variable` will be created which has the same name as the Feature's key for easier reference. 
 
 :::tip Already understand the variable essentials?
 Be sure to check out our advanced variable documentation which covers topics like: