## Date Range
Determine the time range of a query by clicking on the date range selector. The date range selector is common across all reports.
-All dates and times in Mixpanel reflect the project timezone. The default on most reports is “Last 30 days” (displayed as "30D"), but there are a variety of preset options, as well as the option to select a custom date range.
+All dates and times in Mixpanel reflect the project's timezone [(by default, UTC)](/docs/orgs-and-projects/managing-projects#changing-your-timezone). The default for most reports is “Last 30 days” (displayed as "30D"), but there are a variety of preset options, as well as the option to select a custom date range.
- 
+ 
-For these date ranges, the output shows results from the last complete 30 days, plus any results from the current incomplete day.
+For these date ranges, the output shows results from the last complete days, plus any results from the current incomplete day.
| Preset | Description |
| --- | --- |
+| Custom | Gives multiple customization possibilities, explained below. |
| Today | Includes the current incomplete day up to the current second. |
| Yesterday | Includes the whole of the previous day from midnight to midnight. |
| Last 7 days | Last 7 days and the query count from the current incomplete day up to the current second. |
@@ -169,54 +177,101 @@ For these date ranges, the output shows results from the last complete 30 days,
| Last 3 months | Last 3 months and the query count from the current incomplete day up to the current second. |
| Last 6 months | Last 6 months and the query count from the current incomplete day up to the current second. |
| Last 12 months | Last 12 months and the query count from the current incomplete day up to the current second. |
-| Week to Date | From midnight of the start of the current week up to the current second. |
-| Month to Date | From midnight of the start of the current month up to the current second. |
-| Quarter to Date | From midnight of the start of the current quarter up to the current second. |
-| Year to Date | From midnight of the start of the current year up to the current second. |
-### Select a Date Range
+### Custom
-Selecting **Custom** on the date range selector opens up some additional options: "Last", "Fixed", and "Since".
+Selecting **Custom** on the date range selector opens up some additional options: "Recently Applied", "Fixed", Last", Since", "Period to date", and "Previous period".
-### Last
+### Recently Applied
-“In the last” allows you to select a rolling time range similar to the default “last 30 days”, but you have the flexibility to choose the time value and scale, either days, weeks, or months.
+This option will give you access to a prompt field, where you can type the range you're looking for (_'last 16 days starting on June 4th'_) for the AI to resolve for you, and also see a list of the last ranges used.
- 
+ 
-If you need to, you can click on the **\+ Ending** button and shift back the desired time window by a selected number of days. So, for instance, in the example below, we are still looking at a 2-week window that is shifted by 7 days back. This is a rolling date range, and if this report is saved as a bookmark or added to a board, the actual dates will continue to update to show this relative time period vs. today.
+### Fixed
+
+“Fixed” allows you to select two dates to query between by entering the same start and end date. If you save this report as a bookmark or add it to a board, the date range selection will always persist.
- 
+ 
-### Fixed
+### Last
+
+“Last" allows you to select a rolling time range similar to the default “last 30 days”, but you have the flexibility to choose the time value and scale, either days, weeks, months, or quarters.
-“Fixed” allows you to select two dates to query between, by entering the same start & end date. If you save this report as a bookmark or add it to a board, the date range selection will always persist.
+
+ 
+
+
+If needed, you can adjust the desired time window backward by the selected number of days in the "Ending" section. For instance, in the example below, we are still looking at a 2-week window that is shifted 7 days back. This is a rolling date range, and if this report is saved as a bookmark or added to a board, the actual dates will continue to update to show this relative time period vs. today.
- 
+ 
### Since
“Since” allows you to select a specific date to query for all data since that start date.
-### To Date
+
+ 
+
-"To Date" allows you to select a date range that will update dynamically to fit the current interval. You can choose 'Week to Date', 'Month to Date', 'Quarter to Date', and 'Year to Date'. When the boundary of the interval is passed, the date range will automatically update to include only the current interval. For example, if "Month to Date" was selected, and the date was February 27, the date range would include Feb 1 - Feb 27. The next week, after the month boundary has passed, the date range would include Mar 1 - Mar 4. To Date respects start of week and start of quarter settings under project settings.
+### Period to date
-### Minute Level Granularity
+This option allows you to select a date range that will update dynamically to fit the current interval - you can choose "Day", "Week", "Month", "Quarter", and "Year". When the boundary of the interval is passed, the date range will automatically update to include only the current interval. For example, if "Month" was selected on June 27, the date range would include Jun 1 - Jun 27. The next month, after June has passed, the date range would include Jul 1 - Jul 8, as shown in the image below.\
+"Period to date" respects the start of the week and start of quarter settings under Project Settings.
- 
+ 
-Enable hourly and minute-level granularity by going to the advanced submenu under "custom" date range selection. This enables you to select time ranges up to the minute. You can also use this for the "Last" time range to monitor only the past few hours or minutes. When doing time series using minute or hourly intervals, there is a lower time range limit supported.
+### Previous period
-#### Zoom In
+Choosing this option allows you to query information tracked only in the selected period: "Day", "Week", "Month", "Quarter", and "Year".
+
+
+ 
+
+
+### Minute Level Granularity
+
+Enable hourly and minute-level granularity by clicking the "Enable Time Ranges" toggle on the bottom-left side of the date range picker. This enables you to select time ranges up to the minute. You can also use this for the "Last" time range to monitor only the past few hours or minutes.\
+This setting only works for the "Fixed", "Last", and "Since" options; it's not available for "Period to date" and "Previous period".
+
+
+ 
+
+
+## Zoom In
To zoom in, click on the graph and drag to highlight a specific window of time in your report. Click **Reset zoom** to return to the previous view.
@@ -278,15 +333,20 @@ Comparisons are supported across all insights chart types. Depending on the exac
## Saving to a board
## Typecasting
@@ -305,7 +365,7 @@ Insights will automatically bucket high-cardinality segments of number data type
You can either customize the ranges by clicking "[Customize Range](/docs/features/advanced#custom-buckets)".
-Or alternatively, if you'd like to see the exact numeric values, you can typecast the Number property to a String to remove the range bucketing.
+Alternatively, if you'd like to see the exact numeric values, you can typecast the Number property to a String to remove the range bucketing.
## View Users
@@ -318,7 +378,7 @@ View Users can help you:
- Export these users to a CSV file.
- 
+ 
## Segment Limits and Ordering
@@ -392,15 +452,19 @@ Query-time sampling allows you to query a subset of users and shorten the time i
### Enable Sampling
-From the report in which you would like to use sampling, click the **lightning bolt** in the upper right corner of the query builder.
+From the report in which you would like to use sampling, click the **lightning bolt** in the upper-right corner of the query builder. This will enable sampling on the report and will be indicated by the lightning bolt symbol turning blue.\
+The percentage of the total that is included in the query calculations will be indicated in the banner shown above the report.
- 
+ 
-This will enable sampling on the report and will be indicated by the lightning bolt symbol turning blue. The percentage of the total that is included in the query calculations will be indicated in the top right corner of the query builder.
-
-To turn off sampling, click the lightning bolt symbol in the upper right corner of the query builder again. The lightning bolt symbol will turn grey to indicate that sampling is disabled.
+To turn off sampling, simply click the lightning bolt toggle again.
### Query Time Sampling Calculation and Presentation
diff --git a/docs/reports/apps/impact.mdx b/docs/reports/apps/impact.mdx
index 78a8a150..8c611c02 100644
--- a/docs/reports/apps/impact.mdx
+++ b/docs/reports/apps/impact.mdx
@@ -1,21 +1,26 @@
---
-sidebarTitle: "Impact"
title: "Impact: Measure the effect of a launch on your KPIs"
+sidebarTitle: "Impact"
---
## Use Cases
@@ -23,32 +28,26 @@ To access **Impact**, go to the Applications section in the top right of the t
Here are some of the sample questions you can answer in Impact:
- How is the adoption of my feature changing over time?
-- Did my feature launch have an effect on the rate of another key value moment?
+- Did my feature launch affect the rate of another key value moment?
## Quick Start
-
-
+
+
### Step 1: Select a launch event
To build an Impact query, first select a launch event. This is the event that you are measuring as the cause of change.
-
+ 
-Select the start date of this launch event. Add any additional filters to narrow the launch event parameters by clicking the **... dropdown** and selecting the **Add filter**.
+Select the start date of this launch event. Add any additional filters to narrow the launch event parameters by clicking the "**..." button** and then "Filter".
-
+ 
### Step 2: Select metric events
@@ -56,57 +55,62 @@ Select the start date of this launch event. Add any additional filters to narrow
Select a metric event by clicking the **Add** button under **IMPACTED EVENTS**. You are measuring the impact of the launch event on this metric event. Add additional filters to narrow the impacted event parameters.
-
+ 
### Step 3: Add breakdown (optional)
-Breakdown impacted events further by clicking the **… icon**, selecting **Add Aggregation**, then selecting an event property, such as “Amount”. This will add up the value of this property for all of the times this event happened in this time range. All aggregate properties are typecast to numeric properties in order to calculate the sum of that property. For example, aggregate the property “Amount” under the event “Process Payment” to analyze revenue.
+Breakdown impacted events further by clicking the "**…" icon**, selecting **Add Aggregation**, and then selecting an event property, such as “Amount”. This will add up the value of this property for all of the times this event happened in this time range. All aggregate properties are typecast to numeric properties to calculate the sum of that property. For example, aggregate the property “Amount” under the event “Process Payment” to analyze revenue.
-
+ 
### Step 4: Select user group
-Under **USER DEFINITION** select whether you would like to count users who did **only the impacted event** or **any event**.
+Under **USER DEFINITION,** select whether you would like to count users who did **only the impacted event** or **any event**.
-
+ 
### Step 5: Select time range
-Select the time range. The time range is a fixed period of time that determines the adopters and non-adopters of the launch event. The default is "15 days before and after", meaning that the 15 days preceding the fixed launch event date and the 15 days following the launch event will be included in the results. This will allow you to see the difference in the metric event before and after the launch event.
+The time range is a fixed period of time that determines the adopters and non-adopters of the launch event. The default is "15 days before and after", meaning that the 15 days preceding the fixed launch event date and the 15 days following the launch event will be included in the results. This will allow you to see the difference in the metric event before and after the launch event.
The chart will not necessarily change if you change the time range.
-
+ 
-
## Reference
### Adoption
-Adopters are users that have done the launch event. Non-adopters are users that have not done the launch event. Both adopters and non-adopters must perform the metric event to be included in the report.
+Adopters are users who have triggered the launch event. Non-adopters are users who haven't triggered the launch event. Both adopters and non-adopters must perform the metric event to be included in the report.
-The Adoption Rate is the number of users that perform the launch event divided by the total user count:
+The Adoption Rate is the number of users who perform the launch event divided by the total user count:
$\%\,adoption = average\left( (adopters) \over (adopters + non\,adopters) \right)$
### Impact Chart
-The Impact Chart shows how the rate of metric event occurrence changes over time. The y-axis of the chart is the average number of the metric event count and the x-axis is time spanning 30 days.
+The Impact Chart shows how the rate of metric event occurrence changes over time. The y-axis of the chart is the average number of the metric event's count, and the x-axis is time spanning 30 days.
-Unlike other Mixpanel charts, the Impact Chart displays time in relative time, not calendar time. The chart centers around the first day that the launch event is available, or “day zero”. The chart displays the 15 days before and after day zero.
+Unlike other Mixpanel charts, the Impact Chart displays time in relative time, not calendar time. The chart centers around the first day that the launch event is available, or “day zero”. The chart displays the 15 days before and after day zero.
-
+ 
-Every user in the report can have a different day zero. For users in the adopter group, day zero is the first day that they perform the launch event. For users in the non-adopter group, day zero is the day the first adopter performed the launch event (which is most likely the launch day of the feature).
+Every user in the report can have a different day zero. For users in the adopter group, day zero is the first day that they perform the launch event. For users in the non-adopter group, day zero is the day the first adopter performed the launch event (which is most likely the launch day of the feature).
Each data point on the chart is calculated as follows:
@@ -114,31 +118,31 @@ $metric\,event\,rate = { (metric\,event\,count) \over (total\,user\,count)}$
Each point on the line is the average number of times users in the group did the metric event on that relative day.
-For example, if 10 adopters did the launch event for the first time five days ago, and they then did the metric event a total of 30 times today. The +5 days point on the adopter line would read 3. The math would be as follows:
+For example, if 10 adopters did the launch event for the first time five days ago, and they then did the metric event a total of 30 times today. The \+5 days point on the adopter line would read 3. The math would be as follows:
-- 30 = The number of metric events performed by the adopters on day 5
-- 10 = The number of users who did the launch event 5 days before the first day
-- 3 = 30/10
+- 30 = The number of metric events performed by the adopters on day 5.
+- 10 = The number of users who did the launch event 5 days before the first day.
+- 3 = 30/10.
You can see how frequently users in each group perform the metric event, both before and after the launch.
The chart also contains average lines for non-adopters and adopters both before and after day zero (or launch), and the unobserved counterfactual of the adopters (UCA), formerly called projected adopters, average after day zero.
-
+ 
### Impact Table
-The Impact Table summarizes the results of the Impact chart. It displays the average rate at which users in the adopter and non-adopter groups performed the metric event over the course of the 15 days before and after launch.
+The Impact Table summarizes the results of the Impact chart. It displays the average rate at which users in the adopter and non-adopter groups performed the metric event over the course of the 15 days before and after launch.
The table is broken down into three sections: “Pre-Launch”, “Post-Launch”, and “Impact”.
-
+ 
-The Impact Table compares users that performed the launch event and those that did not. For both groups of users, Mixpanel calculates the average number of times per day that users performed the metric event before the launch, after the launch, and the difference between the two (the delta).
+The Impact Table compares users who performed the launch event and those who did not. For both groups of users, Mixpanel calculates the average number of times per day that users performed the metric event before the launch, after the launch, and the difference between the two (the delta).
The average number of times that users performed the metric event before the launch is calculated by:
@@ -150,7 +154,7 @@ A relative delta is also present in each section of the table.
### Pre-Launch
-The Pre-Launch section contains columns for adopters, non-adopters, and the relative delta between them. Adopters are users that perform the launch event after launch, and non-adopters are users that do not perform the launch event after the selected launch date.
+The Pre-Launch section contains columns for adopters, non-adopters, and the relative delta between them. Adopters are users who perform the launch event after launch, and non-adopters are users who do not perform the launch event after the selected launch date.
The relative delta is calculated using the equation:
@@ -158,7 +162,7 @@ $relative\,delta= { (adopter\,average - non\,adopter\,average) \over (non\,adopt
### Post-Launch
-The Post-Launch section contains columns for actual adopters, non-adopters, unobserved counterfactual of adopters, and the relative delta between them. Adopters are users that perform the launch event, and non-adopters are users that do not perform the launch event after the selected launch date.
+The Post-Launch section contains columns for actual adopters, non-adopters, unobserved counterfactuals of adopters, and the relative delta between them. Adopters are users who perform the launch event, and non-adopters are users who do not perform the launch event after the selected launch date.
The UCA value is the projected behavior of adopters if the launch event never happened. This calculation controls for any difference between the adopters and non-adopters that is not a result of the launch event. This value is calculated by the following, where NA is non-adopters, pre is pre-launch, and post is post-launch:
@@ -174,33 +178,33 @@ The Impact section of the table contains the final calculations that indicate if
The delta is the difference between the UCA and adopters in the post-launch period. The relative delta divides that value by the UCA.
-Confidence indicates the statistical significance of report calculations. [See below for details on the calculation of confidence](/docs/reports/apps/impact#confidence-calculation).
+Confidence indicates the statistical significance of the report calculations. [See below for details on the calculation of confidence](/docs/reports/apps/impact#confidence-calculation).
### Interpret the Results
-In general, when the overall delta is positive, and the confidence score is 95% or more, it indicates a successful launch. The most successful launches will see the rate at which adopters perform the metric event increase post-launch, while the same rate for the non-adopters remains relatively constant.
+In general, when the overall delta is positive and the confidence score is 95% or more, it indicates a successful launch. The most successful launches will see the rate at which adopters perform the metric event increase post-launch, while the same rate for the non-adopters remains relatively constant.
-In the Impact Chart, look at the average gap in usage between the adopters and non-adopters. Typically, it is preferable for the increase in the gap to be mostly driven by an increase in the rate at which adopters perform the metric event, rather than a decrease in the rate at which non-adopters perform it.
+In the Impact Chart, look at the average gap in usage between the adopters and non-adopters. Typically, it is preferable for the increase in the gap to be mostly driven by an increase in the rate at which adopters perform the metric event, rather than a decrease in the rate at which non-adopters perform it.
### Confidence Calculation
-Impact includes confidence to indicate the statistical significance of report calculations. Interpret the confidence as the probability that the final delta is primarily caused by the launch event, as opposed to existing by chance.
+Impact includes confidence to indicate the statistical significance of the report calculations. Interpret the confidence as the probability that the final delta is primarily caused by the launch event, as opposed to existing by chance.
The confidence is calculated as a confidence interval using a cumulative distribution function while assuming a normal distribution.
-The confidence variables are as follow:
+The confidence variables are as follows:
- **X** = The number of events per day performed by adopters in the pre-launch period.
- **Y** = The number of events per day performed by adopters in the post-launch period.
- **A** = The number of events per day performed by non-adopters in their pre-launch period.
- **B** = The number of events per day performed by non-adopters in their post-launch period.
-- **Y - X** = The difference in number of events per day performed by adopters between post-launch and pre-launch periods.
-- **B - A** = The difference in number of events per day performed by non-adopters between the post-launch and pre-launch periods.
+- **Y - X** = The difference in the number of events per day performed by adopters between post-launch and pre-launch periods.
+- **B - A** = The difference in the number of events per day performed by non-adopters between the post-launch and pre-launch periods.
- The mean of **Y - X** over time is denoted by:
$\mu_{Y-X}$
-- The mean of of **B - A** over time is denoted by:
+- The mean of B-**A** over time is denoted by:
$\mu_{B-A}$
@@ -212,7 +216,7 @@ $\sigma_{Y-X}$
$\sigma_{B-A}$
-With the variables assigned, the calculations for confidence are as follow:
+With the variables assigned, the calculations for confidence are as follows:
$\mu_{final} = \mu_{Y-X} - \mu_{B-A}$
@@ -226,7 +230,7 @@ $confidence = 1 - p_{value}$
### Causal Impact
-Causal impact uses propensity score methods (a class of causal inference techniques) to refine Impact report results by controlling for self-selection bias. Self-selection bias refers to the tendency of active users to be likely to use your new feature and to perform the impacted metrics, independent of the launch.
+Causal impact uses propensity score methods (a class of causal inference techniques) to refine Impact report results by controlling for self-selection bias. Self-selection bias refers to the tendency of active users to be likely to use your new feature and to perform the impacted metrics, independent of the launch.
Propensity score methods control for self-selection bias by simulating what would occur in a hypothetical, randomized A/B test.
@@ -237,7 +241,7 @@ To learn more about Causal Impact in detail, read this [Mixpanel Whitepaper](ht
Click **View Causal Impact** to use the propensity matching model.
-
+ 
Please note that Causal Impact can take up to a few minutes to calculate results. Causal Impact requires at least 200 total samples and a minimum of 10 features. Each stratum must contain at least 3 treated (adopter) and 3 control (non-adopter) units.
@@ -246,13 +250,13 @@ Please note that Causal Impact can take up to a few minutes to calculate results
Propensity score stratification addresses self-selection bias by comparing adopters and non-adopters who are equally as likely to perform the launch event.
-Users are broken into 10 subclasses after the propensity matching model runs. The 10 subclasses are deciles based on the logit of the estimated propensity score, and weights across subclasses are based on subclass size. Each subclass contains adopters and non-adopters that have a similar likelihood of performing the launch event. Mixpanel determines the rate at which the adopters and non-adopters performed the impacted metric, and calculates the difference for each subgroup.
+Users are broken into 10 subclasses after the propensity matching model runs. The 10 subclasses are deciles based on the logit of the estimated propensity score, and weights across subclasses are based on subclass size. Each subclass contains adopters and non-adopters that have a similar likelihood of performing the launch event. Mixpanel determines the rate at which the adopters and non-adopters performed the impacted metric and calculates the difference for each subgroup.
-Lastly, we average those values across all 10 subclasses to produce the Average Treatment Effect, or ATE. The ATE indicates, on average across all users, how many more or less times per day the newly launched feature led to users to performing the impacted metric.
+Lastly, we average those values across all 10 subclasses to produce the Average Treatment Effect, or ATE. The ATE indicates, on average across all users, how many more or fewer times per day the newly launched feature led users to perform the impacted metric.
### Causal Impact Chart
-The Causal Impact chart plots the ATE on each Impacted Metric. The dark line shows the ATE, and the surrounding box shows the 95% confidence interval bounds of the ATE.
+The Causal Impact chart plots the ATE on each Impacted Metric. The dark line shows the ATE, and the surrounding box shows the 95% confidence interval bounds of the ATE.
When the confidence interval does not include 0, it indicates that the positive or negative effect of the launch event is statistically significant.
@@ -262,10 +266,10 @@ The Causal Impact Table provides additional detail on the treatment effects on t
For each impacted metric, the table displays the ATE, the ATT (the average treatment effect on the treated), the 95% confidence interval (CI) bounds for those, and the number of adopters and non-adopters in the calculation.
-Click the caret to expand the impacted metric row into the 10 subclasses considered. For each subclass, Mixpanel displays the number of matched adopters in the subclass, number of matched non-adopters in the subclass, and the [rates at which each performed the impacted metric](/docs/reports/apps/impact). The Delta column shows the difference between those rates.
+Click the caret to expand the impacted metric row into the 10 subclasses considered. For each subclass, Mixpanel displays the number of matched adopters in the subclass, the number of matched non-adopters in the subclass, and the [rates at which each performed the impacted metric](/docs/reports/apps/impact). The Delta column shows the difference between those rates.
-Note that these values can differ from those reported in the Adoption and Impact Trends charts because Causal Impact only considers users that can be found to have similar propensity to perform the launch event to other users.
+Note that these values can differ from those reported in the Adoption and Impact Trends charts because Causal Impact only considers users who can be found to have a similar propensity to perform the launch event to other users.
### Interpret the Causal Impact Results
-Mixpanel's causal model is confident your new feature successfully changed the rate at which users perform the impacted metric if the ATE on any impacted metric is positive and the 95% confidence interval does not contain zero. This holds true as long as there are no confounding factors outside of your event data.
+Mixpanel's causal model is confident that your new feature successfully changed the rate at which users perform the impacted metric if the ATE on any impacted metric is positive and the 95% confidence interval does not contain zero. This holds as long as there are no confounding factors outside of your event data.
\ No newline at end of file
diff --git a/docs/reports/apps/jql.mdx b/docs/reports/apps/jql.mdx
index 32ffbda6..0983a895 100644
--- a/docs/reports/apps/jql.mdx
+++ b/docs/reports/apps/jql.mdx
@@ -1292,4 +1292,4 @@ function main() {
mixpanel.numeric_bucket('time', mixpanel.daily_time_buckets)],
mixpanel.reducer.count());
}
-```
+```
\ No newline at end of file
diff --git a/docs/reports/apps/signal.mdx b/docs/reports/apps/signal.mdx
index 2734f15f..6312081c 100644
--- a/docs/reports/apps/signal.mdx
+++ b/docs/reports/apps/signal.mdx
@@ -1,80 +1,72 @@
---
-sidebarTitle: "Signal"
title: "Signal: Quantify correlation between two events"
+sidebarTitle: "Signal"
---
diff --git a/docs/reports/funnels/funnels-quickstart.mdx b/docs/reports/funnels/funnels-quickstart.mdx
index 5d555fe0..73a6718b 100644
--- a/docs/reports/funnels/funnels-quickstart.mdx
+++ b/docs/reports/funnels/funnels-quickstart.mdx
@@ -1,19 +1,13 @@
---
-sidebarTitle: "Quickstart"
title: "Funnels Quickstart"
+sidebarTitle: "Quickstart"
---
import { ExtendedButton } from "/snippets/ExtendedButton/ExtendedButton.jsx";
-
-
+
+
A funnel is a sequence of events done within a defined period of time. A converted user is one who triggers the funnel events, in the specified order, within the defined time period.
@@ -24,10 +18,10 @@ A Funnel Behavior is the basic building block of the Funnels report. A Funnel Be
For example, let's say your signup flow contains five steps. Within the funnel definition, you can add one event for each step, in the following order: “Product Viewed” → “Product Added” → “Checkout Started” → “Purchase Completed”. At this point, your query should look like this.
-
+ 
-You can save the Funnel Behavior you built and reuse them in other reports. Select the "..." button in the top right corner of the metric, then click "Save Behavior". Note that saving a behavior and saving a metric is different; a saved behavior consists of the events/Funnels/Retention, while a saved metrics consists of the saved behavior and the measurements of the behavior.
+You can save the Funnel Behavior you built and reuse it in other reports. Select the "..." button in the top right corner of the metric, then click "Save Behavior". Note that saving a behavior and saving a metric are different; a saved behavior consists of the events/Funnels/Retention, while a saved metric consists of the saved behavior and the measurements of the behavior.
Learn more about [Saved Metrics and Behaviors](/docs/features/saved-metrics-and-behaviors).
@@ -36,14 +30,14 @@ Learn more about [Saved Metrics and Behaviors](/docs/features/saved-metrics-and-
After your Funnel Behavior is defined, you can choose how you want to measure the Funnel. By default, the Funnels report will select the unique conversion rate of the funnel as the measurement.
-**Advanced** - See [Counting Method and Measurements](/docs/reports/funnels/funnels-advanced#counting-methods-and-measurements) section for more information on the measurements.
+ **Advanced** - See [Counting Method and Measurements](/docs/reports/funnels/funnels-advanced#counting-methods-and-measurements) section for more information on the measurements.
-
+ 
-Your Funnel Behavior combined with the measurement forms a Metric. You can save the Funnels Metric you built and reuse them in other reports (such as the Insights report). Select the "..." button in the top right corner of the metric, then click "Save Behavior". Note that saving a behavior and saving a metric is different; a saved behavior consists of the events/Funnels/Retention, while a saved metrics consists of the saved behavior and the measurements of the behavior.
+Your Funnel Behavior combined with the measurement forms a Metric. You can save the Funnels Metric you built and reuse it in other reports (such as the Insights report). Select the "..." button in the top right corner of the metric, then click "Save Behavior". Note that saving a behavior and saving a metric are different; a saved behavior consists of the events/Funnels/Retention, while a saved metric consists of the saved behavior and the measurements of the behavior.
Learn more about [Saved Metrics and Behaviors](/docs/features/saved-metrics-and-behaviors).
@@ -52,11 +46,11 @@ Learn more about [Saved Metrics and Behaviors](/docs/features/saved-metrics-and-
In this case, we only care about events performed on the iOS platform. Therefore, add a “Platform” filter, where Platform equals “iOS Native”. At this point, your query should look like this.
-**Advanced** - See [Filter](/docs/reports/funnels/funnels-advanced#filters) section for more information on the filters.
+ **Advanced** - See [Filter](/docs/reports/funnels/funnels-advanced#filters) section for more information on the filters.
-
+ 
## Step 4: Choose Breakdowns
@@ -64,11 +58,11 @@ In this case, we only care about events performed on the iOS platform. Therefore
Breakdowns segment data into groups. In this case, we want to break our funnel down by marketing medium, tracked via UTM tags. Therefore, you can add a “UTM Medium” breakdown.
-**Advanced** - See [Breakdowns](/docs/reports/funnels/funnels-advanced#breakdowns) section for more information on the breakdowns.
+ **Advanced** - See [Breakdowns](/docs/reports/funnels/funnels-advanced#breakdowns) section for more information on the breakdowns.
-
+ 
## Step 5: Choose Visualization
@@ -81,26 +75,23 @@ You can visualize your metric in a variety of ways. Mixpanel allows you to choos
- Metric - see a summary view of your metric
-
+ 
+{/* Next Section */}
+
+
+
+ Next: Advanced Funnels Concept
+
-{/* Next Section */}
+
+ Explore how funnel metrics are measured and the various configuration options below.
+
+
+
-
-
-
-
- Next: Advanced Funnels Concept
-
-
- Explore how funnel metrics are measured and the various configuration options below.
-
-
- 
### View Sample Events
-You can hover over any event and in the context panel, you now have the ability to "View Sample Events", which redirects you to the Events page with the 100 most recent samples of that hovered event: You can see a few samples of an event to help you decide whether that's the right event you want for your analysis or which property you should use for filters/breakdowns.
+If you hover over any event and click "View Sample Events" in the context panel, it redirects you to the Events page with the 100 most-recent samples of that hovered event. You can see a few samples of an event to help you decide whether that's the right event you want for your analysis, or which property you should use for filters/breakdowns.
- 
+ 
### Date Range Guardrails
diff --git a/docs/reports/retention.mdx b/docs/reports/retention.mdx
index 3baf3397..4cf3132d 100644
--- a/docs/reports/retention.mdx
+++ b/docs/reports/retention.mdx
@@ -21,7 +21,7 @@ Retention can be accessed from the left-side navigation by clicking the '\+ Crea
Here are some of the sample questions you can answer in Retention:
-- On average, how many users are still active after two weeks from signing up?
+- On average, how many users are still active after two weeks of signing up?
- What percent of all users are still sending messages after seven days?
- How has my 7-day messaging retention changed over time?
- What percent of users sent messages in 2, 3, or 4 distinct hours of the day?
@@ -32,17 +32,17 @@ Here are some of the sample questions you can answer in Retention:
-Building a Retention report follows the same high-level steps as building any other report. You can read about report building basics [here](/docs/reports).
+Building a Retention report follows the same high-level steps as building any other report. You can read about report-building basics [here](/docs/reports).
### Step 1: Define your Retention Behavior
-The Retention Behavior is the basic building block of a Retention report. A Retention Behavior is doing an event and then coming back to do another event. In this case, since we want to know retention after signup, choose "Sign Up Completed" in the first event slot. Then, we want to know if users are coming back and using the product, so choose "Any Event" in the second event slot. At this point, your query should look like this:
+The Retention Behavior is the basic building block of a Retention report. A Retention Behavior is doing an event and then coming back to do another event. In this case, since we want to know retention after signup, choose "Sign Up Completed" in the first event slot. Then, we want to know if users are coming back and using the product, so we choose "Any Event" in the second event slot. At this point, your query should look like this:
-You can save the Retention Behavior you built and reuse it in other reports. Select the "..." button in the top right corner of the metric, then click "Save Behavior". Note that saving a behavior and saving a metric is different; a saved behavior consists of the events/Funnels/Retention, while a saved metric consists of the saved behavior and the measurements of the behavior.
+You can save the Retention Behavior you built and reuse it in other reports. Select the "..." button in the top right corner of the metric, then click "Save Behavior". Note that saving a behavior and saving a metric are different: a saved behavior consists of the events/Funnels/Retention, while a saved metric consists of the saved behavior and the measurements of the behavior.
Learn more about [Saved Metrics and Behaviors](/docs/features/saved-metrics-and-behaviors).
@@ -52,22 +52,20 @@ After your retention behavior is defined, you can choose how you want to measure
There are 4 types of measurement
-- Retention Rate: Percentage of users retained within window
-- Unique Users: Absolute number of users retained within window
-- Property Sum: Total sum of property within a window (eg. total video watch duration)
-- Property Average: Average across users of sum of property within window (eg average watch time per user)
+- Retention Rate: Percentage of users retained within the window.
+- Unique Users: Absolute number of users retained within the window.
+- Property Sum: Total sum of property within a window (eg, total video watch duration).
+- Property Average: Average across users of the sum of properties within the window (e.g., average watch time per user).
-Your Retention Behavior combined with the measurement forms a Metric. You can save the Retention Metric you built and reuse it in other reports (such as the Insights report). Select the "..." button in the top right corner of the metric, then click "Save Behavior". Note that saving a behavior and saving a metric is different; a saved behavior consists of the events/Funnels/Retention, while a saved metric consists of the saved behavior and the measurements of the behavior.
-
-Learn more about [Saved Metrics and Behaviors](/docs/features/saved-metrics-and-behaviors).
+Your Retention Behavior, combined with the measurement, forms a Metric, which you can also save like a Retention Metric.
### Step 3: Choose Filters
-Filters exclude unwanted data. In this case, we only care about events performed on the Chrome browser. Therefore, add a "Browser" filter, where Browser equals "Chrome". At this point, your query should look like this:
+Filters exclude unwanted data. In this case, we only care about events performed on the "Chrome" browser. Therefore, add a "Browser" filter, where Browser equals "Chrome". At this point, your query should look like this:
@@ -75,7 +73,7 @@ Filters exclude unwanted data. In this case, we only care about events performed
### Step 4: Choose Breakdowns
-Breakdowns segment data into groups. In this case, we want to break our report down based on the browser version they are using to Sign Up. Therefore, add an "Browser Version" breakdown. At this point, your query should look like this:
+Breakdowns segment data into groups. In this case, we want to break our report down based on the browser version they are using to Sign Up. Therefore, add a "Browser Version" breakdown. At this point, your query should look like this:
@@ -85,8 +83,8 @@ Breakdowns segment data into groups. In this case, we want to break our report d
You can visualize your metric in a variety of ways. Mixpanel allows you to choose how you would like to visualize your data. Select "Retention Curve" in the top right to change your visualization. In Retention, you can choose:
-- Retention Curve - see how users retain over time. Users are bucketed by when they initially entered the product.
-- Line - see how your metric is trending over time. Used to see a particular retention group rate is trending over time.
+- Retention Curve - see how users are retaining over time. Users are bucketed based on when they initially entered the product.
+- Line - see how your metric is trending over time. Used to see if a particular retention group rate is trending over time.
- Metric - see a summary view of your metric
@@ -107,9 +105,9 @@ The retention curve chart displays retention data as both a line chart and a tab
-**Incomplete Buckets** Boxes with an asterisk (\*) indicate that the data is still in flux and not set yet because the time is still ongoing. Hover over a box to see when the last qualifying date for that bucket will occur.
+**Incomplete Buckets:** Boxes with an asterisk (\*) indicate that the data is still in flux and not set yet because the time is still ongoing. Hover over a box to see when the last qualifying date for that bucket will occur.
-**Color Mapping** Each box within a row is assigned a shade of purple. The shading gets darker the higher the retention percentage. It's important to note that the scale is relative to each cohort row.
+**Color Mapping:** Each box within a row is assigned a shade of purple. The shading gets darker the higher the retention percentage. It's important to note that the scale is relative to each cohort row.
### Line chart
@@ -123,7 +121,7 @@ Select **Line** from the visualization drop-down list to see how your retentio
Retention counts users, not event totals. In other words, each of the user cohort buckets will include every unique user that met the "A event" criteria in that time window, starting at 0:00 of the first day of the bucket and ending at midnight of the last day. A customer can only be counted once per bucket, but can be included in more than one bucket.
-The first column (Date) indicates the day/week/month when the user performed the "A event". The Size column indicates the number of users that performed the "A event" within the time period.
+The first column (Date) indicates the day/week/month when the user performed the "A event". The Size column indicates the number of users who performed the "A event" within the time period.
For example, if you are bucketing based on your "Item Purchased" event and creating weekly buckets, a customer who purchased at least one item each week will be in every bucket, not just the bucket of their first purchase.
@@ -147,27 +145,27 @@ We think "On or After" retention is a better fit for most businesses, and it is
"On" Retention calculates the percentage of users who come back on a specific time unit (e.g., day, week, month).
-After a user completes the “A criteria”, they will belong to a time unit cohort that corresponds with when they did the "A event," and the Retention report will start the clock counting from the time that particular user performed that "A event". When using "On" Retention, that same user must return to fulfill the “came back and did B criteria” on a specific and exact time unit relative to when they did the A criteria to be counted as retained.
+After a user completes the “A criteria”, they will belong to a time unit cohort that corresponds with when they did the "A event", and the Retention report will start the clock counting from the time that particular user performed that "A event". When using "On" Retention, that same user must return to fulfill the “came back and did B criteria” on a specific and exact time unit relative to when they did the A criteria to be counted as retained.
For example, day 5 retention is the percentage of users who “came back and did B” exactly on the fifth day after they did the A event.
-"On" retention is useful to understand high-level usage patterns. We also recommend using "on" retention when your product relies on users returning in each and every time unit.
+"On" retention is useful to understand high-level usage patterns. We also recommend using "on" retention when your product relies on users returning on every time unit.
#### 'On or Before' time interval
-“On or Before” is a retention criteria most commonly used with measurement type of property sum or average. It looks at total activity done during the period between the start and end event
+“On or Before” is a retention criterion most commonly used with a measurement type of property sum or average. It looks at the total activity done during the period between the start and end events.
-For example, if you want to look at 30 Day LTV (Lifetime value) of e-commerce users, you would look at total money spent on purchases from sign-up for 30 Days. This includes looking at revenue spent from Day 0, Day 1 ..to Day 30, where revenue is a property on the event purchase. Similarly, if you want to look at 30-day ARPU (average revenue per user), you would look at averaging the total revenue spent per user within the first 30 days
+For example, if you want to look at the 30-day LTV (lifetime value) of e-commerce users, you would look at the total money spent on purchases from sign-up for 30 Days. This includes looking at revenue spent from Day 0, Day 1, ..., to Day 30, where revenue is a property on the event purchase. Similarly, if you want to look at 30-day ARPU (average revenue per user), you would look at averaging the total revenue spent per user within the first 30 days.
#### 'Streak mode'
“Streak mode” is mostly meant to count unique users doing consecutive actions across time intervals. If the birth event and retention event are the same, the birth event will count towards the streak.
-For example played a game for 5 consecutive days since sign-up, or visited the doctor for 8 consecutive months since registering for a clinic.
+For example, played a game for 5 consecutive days since sign-up, or visited the doctor for 8 consecutive months since registering for a clinic.
#### Advanced Use-Cases
-These use-cases, use a combination of different retention criteria & measurement types
+These use-cases use a combination of different retention criteria & measurement types
@@ -179,7 +177,7 @@ These use-cases, use a combination of different retention criteria & measurement
- What is the average video watch-time for a new subscriber in their first 30 days since subscription? How has this changed over time?
- Retention Criteria: On or Before
- Measurement: Property Average; 30 Days
-- How many new users have a wordle streak for 5 days or 10 days?
+- How many new users have a Wordle streak for 5 days or 10 days?
- Retention Criteria: Streak Mode
- Measurement: Unique Users; 5 days
@@ -191,19 +189,19 @@ Custom bracket retention gives you the flexibility to split up your retention bu
#### Use Cases
-For example, let's answer an important mobile gaming question: How often do my users come back and play a game between 15 and 30 days after sign-up to represent mid-term players?
+For example, let's answer an important mobile gaming question: How often do my users come back and play a game between 15 and 30 days after signing up to represent mid-term players?
-In mobile gaming, industry-standard intervals typically examine retention for users who came back and played a game on Day \< 1, Days 1-3, Days 4-7, Days 8-14, and Day 15-30.
+In mobile gaming, industry-standard intervals typically examine retention for users who came back and play a game on Day \< 1, Days 1-3, Days 4-7, Days 8-14, and Days 15-30.
-Typical "exact day" retention buckets don't quite solve for this use case because users should be able to play a game on any day between Day 15 and 30 and be counted in a single bucket to understand how many users were retained in that entire period. Exact day retention will log users in each individual day bucket (15, 16, 17, ..., 30), which, while more granular, doesn't give a retention percentage for the entire interval. Instead, we want to know how many users played a game at all in any of the days 15-30.
+Typical "exact day" retention buckets don't quite solve for this use case because users should be able to play a game on any day between day 15 and 30 and be counted in a single bucket to understand how many users were retained in that entire period. Exact day retention will log users in each day bucket (15, 16, 17, ..., 30), which, while more granular, doesn't give a retention percentage for the entire interval. Instead, we want to know how many users played a game at all in any of the days 15-30.
-**Free trials:** If you want to understand how many users come back to use the product during a 7-day free trial and also who came back and kept using the product in the 30 days after the free trial is up, you could do something like this:
+**Free trials:** If you want to understand how many users come back to use the product during a 7-day free trial, and also who came back and kept using the product in the 30 days after the free trial is up, you could do something like this:
-**In between cadences:** Are you somewhere in between a DAU or WAU product? You can group daily buckets to understand how your users retain every 3 days (bi-weekly).
+**In between cadences:** Are you somewhere between a DAU or WAU product? You can group daily buckets to understand how your users retain every 3 days (bi-weekly).
@@ -211,19 +209,19 @@ Typical "exact day" retention buckets don't quite solve for this use case becaus
#### Setting Custom Brackets
-First, go into the time unit drop-down in the Retention query builder and select **Custom**
+First, go into the time unit drop-down in the Retention query builder and select **Custom.**
-Then, select the size of each bracket for the given time unit. In this example, we are selecting the number of days that are in each custom bracket. Apply.
+Then, select the size of each bracket for the given time unit and click "Apply". In this example, we are selecting the number of days that are in each custom bracket.
-Each of these intervals is its own retention bucket, and if the user does the "come back and did B" event anytime inside that bucket, they are counted as retained. Now I will be able to understand what percent of users come back to play at least one game in any day between day 15 and day 30 from signing up.
+Each of these intervals is its own retention bucket, and if the user does the "come back and did B" event anytime inside that bucket, they are counted as retained. Now I will be able to understand what percent of users come back to play at least one game on any day between day 15 and day 30 from signing up.
#### Calendar Retention Mode
@@ -233,7 +231,7 @@ You can go into the advanced menu under Retention Criteria to switch the retenti
-This may be useful in scenarios where you want to check engagement on a strict day basis, OR if you want to check retention of your user base for the entire month and when they return, regardless of when in the month they first entered or when in the next month they returned.
+This may be useful in scenarios where you want to check engagement on a strict day basis, OR if you want to check retention of your user base for the entire month, and when they return, regardless of when in the month they first entered or when in the next month they returned.
@@ -241,28 +239,28 @@ This may be useful in scenarios where you want to check engagement on a strict d
In the above example, we're looking at retention on a calendar week basis.
-- In the \< Week 1 bucket, there were 6 users who did "Sign Up" at any point during the week of Dec 23 - Dec 30, and returned to do "Post Content" in that same week of Dec 23 - Dec 30.
-- In the Week 1 bucket, there were 10 users who did "Sign Up" in the same Dec 23 - Dec 30 interval, but returned to do "Post Content" only sometime between Dec 30 - Jan 6.
+- In the \< Week 1 bucket, 6 users did "Sign Up" at any point of the week of Dec 23 - Dec 30, and returned to do "Post Content" in that same week of Dec 23 - Dec 30.
+- In the Week 1 bucket, 10 users did "Sign Up" in the same Dec 23 - Dec 30 interval, but returned to do "Post Content" only sometime between Dec 30 - Jan 6.
##### How is this different than the basic retention mode?
-This [loom video](https://www.loom.com/share/5484c7bdd61a4332818ceef20f475176) should provide an overview of what calendar interval retention is and how it works vs the default rolling window retention
+This [Loom video](https://www.loom.com/share/5484c7bdd61a4332818ceef20f475176) should provide an overview of what calendar interval retention is and how it works vs the default rolling window retention
-**\[Basic\] Rolling interval retention** - Considers time intervals based on user’s time of birth; i.e
+**\[Basic\] Rolling interval retention** - Considers time intervals based on the user’s time of birth; i.e:
- Day 1 retention = 24-48 hrs since person’s birth
- Week 1 retention = 7-14 days since person’s birth
- Month 1 retention = 30-60 days since person’s birth
-**\[Advanced\] Calendar interval retention** - Considers time intervals based on ‘calendar’ time; i.e
+**\[Advanced\] Calendar interval retention** - Considers time intervals based on ‘calendar’ time; i.e:
-- Day 1 retention = next ‘calendar’ day since person’s birth. If a person did an activity at 8pm on Monday and then 6am on Tuesday, the person is counted under Day 1 retention even though it’s just 10 hrs later
-- Week 1 retention = next ‘calendar’ week since person’s birth. If a person did an activity on Friday and then Monday, person is counted under Week 1 retention even though it’s just 3 days, since the ‘calendar’ week changed
+- Day 1 retention = next ‘calendar’ day since person’s birth. If a person did an activity at 8 pm on Monday and then 6 am on Tuesday, the person is counted under Day 1 retention even though it’s just 10 hrs later
+- Week 1 retention = next ‘calendar’ week since person’s birth. If a person did an activity on Friday and then Monday, the person is counted under Week 1 retention even though it’s just 3 days, since the ‘calendar’ week changed
- Month 1 retention = next ‘calendar’ month since person’s birth. Similarly, if a person made a purchase on 25th Feb and then again on 3rd March, the person will be counted under Month 1 retention metrics
-NOTE — All the above cases would NOT qualify under Day 1 or Week 1 or Month 1 rolling interval retention
+NOTE — All the above cases would NOT qualify under Day 1, Week 1, or Month 1 rolling interval retention.
-**When should you use the calendar vs rolling interval retention mode? **
+**When should you use the calendar vs rolling interval retention mode?**
Both modes are extremely useful. It totally depends on the use-case you’re trying to answer. Some examples -
@@ -271,17 +269,16 @@ Both modes are extremely useful. It totally depends on the use-case you’re try
| Day 1 retention for apps focused on “daily engagement” like music, meditation, or workout apps | Calendar-interval |
| How many users come back after month 1 (30 days)? How many come back after 3 months (90 days)? | Rolling-interval |
| Understanding the effect of a marketing promotion, how many people came back the week after the promotion ended? | Calendar-interval |
-| What’s Mixpanel's quarterly revenue retention? How was gross and net retention in Q4 vs Q3? | Calendar-interval |
-| How many users renewed their Netflix subscription? To note, renewals happen 30 days after last payment | Rolling-interval |
+| What’s Mixpanel's quarterly revenue retention? How were gross and net retention in Q4 vs Q3? | Calendar-interval |
+| How many users renewed their Netflix subscription? To note, renewals happen 30 days after the last payment | Rolling-interval |
-As stated above, the general expectation is that product use-cases which focus on user stickiness are likely to use rolling interval mode. Marketing & Revenue teams which focus on calendar dates for their activities are likely to use calendar interval mode.
+Above said, the general expectation is that product use-cases which focus on user stickiness are likely to use rolling interval mode. Marketing & Revenue teams that focus on calendar dates for their activities are likely to use the calendar interval model.
### Saved Retention Behaviors
-You can save the Funnel Behavior you built and reuse it in other reports. This can be helpful when there is a sequence of events that you frequently analyze (such as sign up flow), or if you want to analyze your Funnel Behavior alongside other metrics in an Insights report.
-
-Select the "..." button in the top right corner of the metric, then click "Save Behavior". Note that saving a behavior and saving a metric is different; a saved behavior consists of the events/Funnels/Retention, while a saved metric consists of the saved behavior and the measurements of the behavior.
+You can save the Funnel Behavior you built and reuse it in other reports. This can be helpful when there is a sequence of events that you frequently analyze (such as sign-up flow), or if you want to analyze your Funnels Behavior alongside other metrics in an Insights report.
+Select the "..." button in the top right corner of the metric, then click "Save Behavior".\
Learn more about [Saved Metrics and Behaviors](/docs/features/saved-metrics-and-behaviors).
### Frequency View
@@ -292,7 +289,7 @@ Learn more about [Saved Metrics and Behaviors](/docs/features/saved-metrics-and-
You can use the Frequency report to learn how frequently users return to use your product or service.
-To generate Frequency reports, click **Reports**, **Retention,** and select the **Frequency** option under the toggle for retention.
+To generate Frequency reports, click **Reports**, **Retention**, and select the **Frequency** option under the toggle for retention.
@@ -300,7 +297,7 @@ To generate Frequency reports, click **Reports**, **Retention,** and select t
Mixpanel groups unique users in time-incremented buckets when they first complete an action, and then groups those same users in subsequent buckets when they return and perform the same or different actions.
-The buckets measure the number of unique time buckets in which a user was active. Depending on the interval chosen, this will one of:
+The buckets measure the number of unique time buckets in which a user was active. Depending on the interval chosen, this will be one of:
- unique hours in a day
- unique days in a week
@@ -324,13 +321,13 @@ Currently, when using "Day" retention, Retention reports are limited to 60 days.
When you create an unsegmented retention query (i.e., a retention query that is not segmented by a property or cohort), Mixpanel will automatically intervalize the retention calculation.
-In other words, we will calculate the retention of each and every cohort based upon the selected birth interval unit (day/week/month cadence that the user performed the A action) and then summarize it into one line by taking the average of all complete buckets. You can see the retention of each individual interval by expanding the Average Retention column:
+In other words, we will calculate the retention of each and every cohort based upon the selected birth interval unit (day/week/month cadence that the user performed the A action) and then summarize it into one line by taking the average of all complete buckets. You can see the retention of each interval by expanding the Average Retention column:
-Segmented queries are now calculated with that same intervalized average method, but for each particular property value or cohort segment. You can now expand out any particular segment's name in a retention query to see the retention of each day, week, or month interval within that segment:
+Segmented queries are now calculated with that same intervalized average method, but for each particular property value or cohort segment. You can now expand any particular segment's name in a retention query to see the retention of each day, week, or month interval within that segment:
@@ -338,7 +335,7 @@ Segmented queries are now calculated with that same intervalized average method,
Intervalized averages to segmented retention queries have two key advantages:
-1. **Not including users in incomplete periods:** The non-intervalized method did not give all users an equal chance to qualify for the later retention buckets. Newer, more recent users who come into the query towards the end of your date range would not have enough time pass to have the opportunity to be retained in the later date buckets. This would sandbag the last retention buckets in your query. With intervalized retention, Mixpanel only counts the completed time periods into the Average Retention calculation so that all users have the same opportunity to be retained.
+1. **Not including users in incomplete periods:** The non-intervalized method did not give all users an equal chance to qualify for the later retention buckets. Newer, more recent users to come into the query towards the end of your date range would not have enough time to pass to have the opportunity to be retained in the later date buckets. This would sandbag the last retention buckets in your query. With intervalized retention, Mixpanel only counts the completed time periods into the Average Retention calculation so that all users have the same opportunity to be retained.
2. **More granular analysis:** Users are now able to see how the individual birth interval cohorts are performing within a particular segment. This unlocks the ability to get more answers and dive deeper into particular cohorts of interest.
### How is the "Average" row for Retention reports calculated?
@@ -351,9 +348,9 @@ Mixpanel calculates the "Average" row values by taking the average of all the co
| March 2 | 500 | 400 |
| March 3 | 700 | 10 (incomplete) |
-From our sample data, the average value for day 1 retained users is calculated as follows:
+From our sample data, the average value for day-1 retained users is calculated as follows:
-#### When examining a Retention report in % / Retention Rate view:
+#### When examining a Retention report in the % / Retention Rate view:
C\_March 1 = 500 (count retained for March 1)
@@ -371,7 +368,7 @@ P\_March 2 = 500 (total profiles for March 2)
In our sample data, this computes to: ( 500 \* 0.66 ) \+ ( 400 \* 0.33 ) = 466.66
-Next, we have to get the weighted average of the total profiles that were eligible for being retained
+Next, we have to get the weighted average of the total profiles that were eligible for being retained.
\*\*Weighted Average of Total Users = P\_March 1 \* W\_March 1 \+ P\_March 2 \* W\_March 2
@@ -399,4 +396,4 @@ In our sample data, this computes to:(500 \* (1000 / 1500)) \+ (400 \* (500 / 15
### What does the Metric view in the Retention Trends report show?
-The Metric view in the Retention Trends Report shows the **_overall value_** for the retention trend for that time period. There is a `Cohortize` option under the `Advanced` menu that, when enabled will show the **_weighted average bucket_** for that retention trend.
+The Metric view in the Retention Trends Report shows the **_overall value_** for the retention trend for that time period. There is a `Cohortize` option under the `Advanced` menu that, when enabled, will show the **_weighted average bucket_** for that retention trend.
\ No newline at end of file
diff --git a/images/applications_impact.png b/images/applications_impact.png
new file mode 100644
index 00000000..078ac71f
Binary files /dev/null and b/images/applications_impact.png differ
diff --git a/images/date_picker_fixed.png b/images/date_picker_fixed.png
new file mode 100644
index 00000000..52cc7272
Binary files /dev/null and b/images/date_picker_fixed.png differ
diff --git a/images/date_picker_fixed_time_ranges.png b/images/date_picker_fixed_time_ranges.png
new file mode 100644
index 00000000..93569091
Binary files /dev/null and b/images/date_picker_fixed_time_ranges.png differ
diff --git a/images/date_picker_last.png b/images/date_picker_last.png
new file mode 100644
index 00000000..a12b4207
Binary files /dev/null and b/images/date_picker_last.png differ
diff --git a/images/date_picker_last_rolling_window.png b/images/date_picker_last_rolling_window.png
new file mode 100644
index 00000000..2db9da47
Binary files /dev/null and b/images/date_picker_last_rolling_window.png differ
diff --git a/images/date_picker_period_to_date.png b/images/date_picker_period_to_date.png
new file mode 100644
index 00000000..1aa77a56
Binary files /dev/null and b/images/date_picker_period_to_date.png differ
diff --git a/images/date_picker_previous_period.png b/images/date_picker_previous_period.png
new file mode 100644
index 00000000..94d8cf4b
Binary files /dev/null and b/images/date_picker_previous_period.png differ
diff --git a/images/date_picker_recently_applied.png b/images/date_picker_recently_applied.png
new file mode 100644
index 00000000..979c2ae1
Binary files /dev/null and b/images/date_picker_recently_applied.png differ
diff --git a/images/date_picker_since.png b/images/date_picker_since.png
new file mode 100644
index 00000000..7ce9e909
Binary files /dev/null and b/images/date_picker_since.png differ
diff --git a/images/event_options.png b/images/event_options.png
new file mode 100644
index 00000000..d46b9acb
Binary files /dev/null and b/images/event_options.png differ
diff --git a/images/flows_breakdown_cohort.png b/images/flows_breakdown_cohort.png
new file mode 100644
index 00000000..7584b2e4
Binary files /dev/null and b/images/flows_breakdown_cohort.png differ
diff --git a/images/flows_expand_event_property.gif b/images/flows_expand_event_property.gif
new file mode 100644
index 00000000..dca057bb
Binary files /dev/null and b/images/flows_expand_event_property.gif differ
diff --git a/images/flows_expand_event_property2.gif b/images/flows_expand_event_property2.gif
new file mode 100644
index 00000000..af9d0ffc
Binary files /dev/null and b/images/flows_expand_event_property2.gif differ
diff --git a/images/impact2.png b/images/impact2.png
new file mode 100644
index 00000000..080731fb
Binary files /dev/null and b/images/impact2.png differ
diff --git a/images/impact3.png b/images/impact3.png
new file mode 100644
index 00000000..d1d26f0f
Binary files /dev/null and b/images/impact3.png differ
diff --git a/images/impact_add_event.png b/images/impact_add_event.png
new file mode 100644
index 00000000..bb736bb3
Binary files /dev/null and b/images/impact_add_event.png differ
diff --git a/images/impact_add_filters.png b/images/impact_add_filters.png
new file mode 100644
index 00000000..b68283bb
Binary files /dev/null and b/images/impact_add_filters.png differ
diff --git a/images/impact_add_impacted_event.png b/images/impact_add_impacted_event.png
new file mode 100644
index 00000000..181578d1
Binary files /dev/null and b/images/impact_add_impacted_event.png differ
diff --git a/images/impact_aggregate_event.png b/images/impact_aggregate_event.png
new file mode 100644
index 00000000..521c351d
Binary files /dev/null and b/images/impact_aggregate_event.png differ
diff --git a/images/impact_causal_report.png b/images/impact_causal_report.png
new file mode 100644
index 00000000..fe9301b3
Binary files /dev/null and b/images/impact_causal_report.png differ
diff --git a/images/impact_correlation_events.png b/images/impact_correlation_events.png
new file mode 100644
index 00000000..03e077a1
Binary files /dev/null and b/images/impact_correlation_events.png differ
diff --git a/images/impact_date_range_picker.png b/images/impact_date_range_picker.png
new file mode 100644
index 00000000..5eeac0a5
Binary files /dev/null and b/images/impact_date_range_picker.png differ
diff --git a/images/impact_impact_chart.png b/images/impact_impact_chart.png
new file mode 100644
index 00000000..374b3148
Binary files /dev/null and b/images/impact_impact_chart.png differ
diff --git a/images/impact_impact_trends_graph.png b/images/impact_impact_trends_graph.png
new file mode 100644
index 00000000..4425fb4f
Binary files /dev/null and b/images/impact_impact_trends_graph.png differ
diff --git a/images/impact_user_definition.png b/images/impact_user_definition.png
new file mode 100644
index 00000000..52642800
Binary files /dev/null and b/images/impact_user_definition.png differ
diff --git a/images/new_date_range.png b/images/new_date_range.png
new file mode 100644
index 00000000..a406306c
Binary files /dev/null and b/images/new_date_range.png differ
diff --git a/images/reports_query_time_sampling.png b/images/reports_query_time_sampling.png
new file mode 100644
index 00000000..95dcb206
Binary files /dev/null and b/images/reports_query_time_sampling.png differ
diff --git a/images/reports_save_to_board.png b/images/reports_save_to_board.png
new file mode 100644
index 00000000..af6cdda1
Binary files /dev/null and b/images/reports_save_to_board.png differ
diff --git a/images/reports_view_events.gif b/images/reports_view_events.gif
new file mode 100644
index 00000000..429c546e
Binary files /dev/null and b/images/reports_view_events.gif differ
diff --git a/images/reports_view_sample_events.gif b/images/reports_view_sample_events.gif
new file mode 100644
index 00000000..787a614c
Binary files /dev/null and b/images/reports_view_sample_events.gif differ
diff --git a/images/reports_view_users.gif b/images/reports_view_users.gif
new file mode 100644
index 00000000..86583fa6
Binary files /dev/null and b/images/reports_view_users.gif differ
diff --git a/images/signal.png b/images/signal.png
new file mode 100644
index 00000000..8ce14ad4
Binary files /dev/null and b/images/signal.png differ
diff --git a/images/signal_access.png b/images/signal_access.png
new file mode 100644
index 00000000..40d2f319
Binary files /dev/null and b/images/signal_access.png differ
diff --git a/images/signal_query_builder.png b/images/signal_query_builder.png
new file mode 100644
index 00000000..ce3c8f44
Binary files /dev/null and b/images/signal_query_builder.png differ
diff --git a/insights_properties_section.png b/insights_properties_section.png
new file mode 100644
index 00000000..b291e641
Binary files /dev/null and b/insights_properties_section.png differ
+
-
-
++ Next: Advanced Funnels Concept +
-{/* Next Section */} ++ Explore how funnel metrics are measured and the various configuration options below. +
+ +-
-
-
+
-
-
-- Next: Advanced Funnels Concept -
-- Explore how funnel metrics are measured and the various configuration options below. -
--