From 032fc7948f97516ddaf7d74224657262f251f582 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Wed, 24 Aug 2022 16:13:19 +0100 Subject: [PATCH 01/13] Add monthly active users documentation --- docs/SUMMARY.md | 1 + .../administration/monthly_active_users.md | 75 +++++++++++++++++++ 2 files changed, 76 insertions(+) create mode 100644 docs/usage/administration/monthly_active_users.md diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md index 2d56b084e269..16720bceb521 100644 --- a/docs/SUMMARY.md +++ b/docs/SUMMARY.md @@ -69,6 +69,7 @@ - [Manhole](manhole.md) - [Monitoring](metrics-howto.md) - [Reporting Homeserver Usage Statistics](usage/administration/monitoring/reporting_homeserver_usage_statistics.md) + - [Monthly Active Users](usage/administration/monthly_active_users.md) - [Understanding Synapse Through Grafana Graphs](usage/administration/understanding_synapse_through_grafana_graphs.md) - [Useful SQL for Admins](usage/administration/useful_sql_for_admins.md) - [Database Maintenance Tools](usage/administration/database_maintenance_tools.md) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md new file mode 100644 index 000000000000..0440859e449c --- /dev/null +++ b/docs/usage/administration/monthly_active_users.md @@ -0,0 +1,75 @@ +Monthly Active Users +==================== + +Synapse can be configured to record the number of monthly active users (also referred to as MAU) on a given homeserver. +For clarity's sake, MAU only tracks local users. + +Please note that the metrics recorded by the [Homeserver Usage Stats](/usage/administration/monitoriing/reporting_homeserver_usage_statistics) +are calculated differently. The `monthly_active_users` does not take into account any of the rules below, and looks for any users +who have made a request to the homeserver in the last 30 days. + +See the [configuration manual](/usage/configuration/config_documentation.html#limit_usage_by_mau) for details on how to configure MAU. + + +## Calculating active users + +Individual user activity is measured in active days, so if a user performs an action on a given day, that day is then recorded. When +calculating the MAU figure, any users with a recorded action in the last 30 days are considered part of the cohort. + +The MAU value is recalculated once every 5 minutes to determine active users, while inactive users are removed from the cohort once every hour. + +A user is **never** considered active if they are either: + - Part of the trial day cohort (described below) + - Have an `appservice_id`. + + +Otherwise, any request to Synapse will mark the user as active. Internally, this is any request that records +the client's IP address into the database. + +### Trial days + + +If `mau_trial_days` is set, the user must have had activity at least this number of days apart for them to be considered part of the cohort. +As an example, if `mau_trial_days` is set to `2` and Alice is active on days 1,2 and 3 then they will be counted as an active user. If Bob +is active on days 1 and 2, then they will NOT be counted as active. + +The `mau_appservice_trial_days` config further extends this rule by applying different durations depending on the appservice ID of the user. + +It is important to note that **deactivated** users are not immediately removed from +the pool of active users, but activity time will decay the same as other users. + +## Limiting usage of the homeserver when the limit is reached + +If `limit_usage_by_mau` is set and the current MAU value exceeds `max_mau_value`, the +homeserver will begin to block some actions. + +Users are exempt from this blocking if ANY of these conditions are met: + - Considered part of the cohort of MAU users. + - Considered part of the trial period. + - Registered as a `support` user. + +The following actions are blocked when the MAU limit is exceeded: + - Logging in + - Sending events + - Creating rooms + +Registration is also blocked for all new signups *unless* the user is registering with a threepid +included in the `mau_limits_reserved_threepids` config value. Users that register this way are also +immediately considered active on that day. + +When an endpoint is blocked, the response will contain the `errcode` `M_RESOURCE_LIMIT_EXCEEDED`. + + +## Metrics + +Synapse records several different prometheus metrics for MAU. + +`synapse_admin_mau:current` records the current MAU figure for native (non-appservice) users. + +`synapse_admin_mau:max` records the maximum MAU as dictated by the `max_mau_value` config value. + +`synapse_admin_mau_current_mau_by_service` records the current MAU including appservice users. This *also* +includes non-appservice users under the `native` label. + +`synapse_admin_mau:registered_reserved_users` records the number of users specified in `mau_limits_reserved_threepids` which have +registered accounts on the homeserver. From 186c1161c2bf0693bf674bd9e27a30c6d7e0995c Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Wed, 24 Aug 2022 16:33:58 +0100 Subject: [PATCH 02/13] changelog --- changelog.d/13617.doc | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelog.d/13617.doc diff --git a/changelog.d/13617.doc b/changelog.d/13617.doc new file mode 100644 index 000000000000..5c7db7c3d751 --- /dev/null +++ b/changelog.d/13617.doc @@ -0,0 +1 @@ +Document how ["monthly active users"](https://matrix-org.github.io/synapse/latest/usage/administration/monthly_active_users.html) is calculated and used. From 2c125cf05d0140a5d01953047e60aeb360ee5742 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Thu, 25 Aug 2022 11:12:37 +0100 Subject: [PATCH 03/13] Tidy up notes --- .../administration/monthly_active_users.md | 32 ++++++++----------- 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index 0440859e449c..a8e75e50f8b4 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -1,33 +1,31 @@ -Monthly Active Users -==================== +# Monthly Active Users Synapse can be configured to record the number of monthly active users (also referred to as MAU) on a given homeserver. For clarity's sake, MAU only tracks local users. Please note that the metrics recorded by the [Homeserver Usage Stats](/usage/administration/monitoriing/reporting_homeserver_usage_statistics) -are calculated differently. The `monthly_active_users` does not take into account any of the rules below, and looks for any users +are calculated differently. The `monthly_active_users` does not take into account any of the rules below, and counts any users who have made a request to the homeserver in the last 30 days. See the [configuration manual](/usage/configuration/config_documentation.html#limit_usage_by_mau) for details on how to configure MAU. - ## Calculating active users Individual user activity is measured in active days, so if a user performs an action on a given day, that day is then recorded. When calculating the MAU figure, any users with a recorded action in the last 30 days are considered part of the cohort. -The MAU value is recalculated once every 5 minutes to determine active users, while inactive users are removed from the cohort once every hour. - A user is **never** considered active if they are either: - Part of the trial day cohort (described below) - Have an `appservice_id`. - Otherwise, any request to Synapse will mark the user as active. Internally, this is any request that records the client's IP address into the database. -### Trial days +The MAU value is recalculated once every 5 minutes for active users, while inactive users are removed from the cohort once every hour. +Internally this works by checking all users, and adding any recently active users to the `monthly_active_users` table. Every hour, any +users with timestamps later than 30 days are removed. The sum of all rows of that table is the final count of active users. +### Trial days If `mau_trial_days` is set, the user must have had activity at least this number of days apart for them to be considered part of the cohort. As an example, if `mau_trial_days` is set to `2` and Alice is active on days 1,2 and 3 then they will be counted as an active user. If Bob @@ -35,15 +33,15 @@ is active on days 1 and 2, then they will NOT be counted as active. The `mau_appservice_trial_days` config further extends this rule by applying different durations depending on the appservice ID of the user. -It is important to note that **deactivated** users are not immediately removed from -the pool of active users, but activity time will decay the same as other users. +It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as blocked users won't +perform actions they will eventually be removed from the cohort. -## Limiting usage of the homeserver when the limit is reached +## Limiting usage of the homeserver when the maximum MAU is reached -If `limit_usage_by_mau` is set and the current MAU value exceeds `max_mau_value`, the +If both config options `limit_usage_by_mau` and `max_mau_value` is set, and the current MAU value exceeds the maximum value, the homeserver will begin to block some actions. -Users are exempt from this blocking if ANY of these conditions are met: +Individual users matching **any** of the below criteria never have their actions blocked: - Considered part of the cohort of MAU users. - Considered part of the trial period. - Registered as a `support` user. @@ -53,12 +51,10 @@ The following actions are blocked when the MAU limit is exceeded: - Sending events - Creating rooms -Registration is also blocked for all new signups *unless* the user is registering with a threepid -included in the `mau_limits_reserved_threepids` config value. Users that register this way are also -immediately considered active on that day. - -When an endpoint is blocked, the response will contain the `errcode` `M_RESOURCE_LIMIT_EXCEEDED`. +Registration is also blocked for all new signups *unless* the user is registering with a threepid included in the `mau_limits_reserved_threepids` +config value. Users that register this way are also immediately considered active on that day. +When a request is blocked, the response will have the `errcode` `M_RESOURCE_LIMIT_EXCEEDED`. ## Metrics From 6f0fddedac8a90c761cd54a0417c75ac0f19764c Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Thu, 25 Aug 2022 11:15:11 +0100 Subject: [PATCH 04/13] more tidyup --- docs/usage/administration/monthly_active_users.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index a8e75e50f8b4..b25776152b07 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -25,16 +25,18 @@ The MAU value is recalculated once every 5 minutes for active users, while inact Internally this works by checking all users, and adding any recently active users to the `monthly_active_users` table. Every hour, any users with timestamps later than 30 days are removed. The sum of all rows of that table is the final count of active users. +It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as blocked users won't +perform actions they will eventually be removed from the cohort. + ### Trial days If `mau_trial_days` is set, the user must have had activity at least this number of days apart for them to be considered part of the cohort. -As an example, if `mau_trial_days` is set to `2` and Alice is active on days 1,2 and 3 then they will be counted as an active user. If Bob -is active on days 1 and 2, then they will NOT be counted as active. +As an example, if `mau_trial_days` is set to `2` and Alice is active on days 1 and 3 then they will be counted as an active user. If Bob +is active on days 1 and 2, then they will NOT be counted as active. Please note that users do not need to be active on concurrent days to +be deemed active. The `mau_appservice_trial_days` config further extends this rule by applying different durations depending on the appservice ID of the user. -It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as blocked users won't -perform actions they will eventually be removed from the cohort. ## Limiting usage of the homeserver when the maximum MAU is reached From 2df80b288198baeffabee78ea5a4f8d60bbf1cfb Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Tue, 30 Aug 2022 12:47:53 +0100 Subject: [PATCH 05/13] Rewrite #1 --- .../administration/monthly_active_users.md | 57 +++++++++++-------- 1 file changed, 34 insertions(+), 23 deletions(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index b25776152b07..3ae58edf50cf 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -3,39 +3,46 @@ Synapse can be configured to record the number of monthly active users (also referred to as MAU) on a given homeserver. For clarity's sake, MAU only tracks local users. -Please note that the metrics recorded by the [Homeserver Usage Stats](/usage/administration/monitoriing/reporting_homeserver_usage_statistics) -are calculated differently. The `monthly_active_users` does not take into account any of the rules below, and counts any users -who have made a request to the homeserver in the last 30 days. +Please note that the metrics recorded by the [Homeserver Usage Stats](/usage/administration/monitoring/reporting_homeserver_usage_statistics) +are calculated differently. The `monthly_active_users` from the usage stats does not take into account any +of the rules below, and counts any users who have made a request to the homeserver in the last 30 days. -See the [configuration manual](/usage/configuration/config_documentation.html#limit_usage_by_mau) for details on how to configure MAU. +See the [configuration manual](../../usage/configuration/config_documentation.md#limit_usage_by_mau) for details on how to configure MAU. ## Calculating active users -Individual user activity is measured in active days, so if a user performs an action on a given day, that day is then recorded. When -calculating the MAU figure, any users with a recorded action in the last 30 days are considered part of the cohort. +Individual user activity is measured in active days. If a user performs an action, the exact time of that action is then recorded. When +calculating the MAU figure, any users with a recorded action in the last 30 days are considered part of the cohort. Days are measured +as a rolling window from the current system time to 30 days ago. + +So for example, if Synapse were to calculate the active users on the 15th July at 13:25, it would include any activity from 15th June 13:25 onwards. A user is **never** considered active if they are either: - Part of the trial day cohort (described below) - - Have an `appservice_id`. + - Are owned by an Application Service (AS). + - Note: This **only** cover users that are part of an application service `namespaces.users` registration. The namespace + must also be marked as `exclusive`. + +Otherwise, any request to Synapse will mark the user as active. Please note that registration will not mark a user as active *unless* +they register with a 3pid that is included in the config field `mau_limits_reserved_threepids`. -Otherwise, any request to Synapse will mark the user as active. Internally, this is any request that records -the client's IP address into the database. +The Prometheus metric for MAU is recalculated every 5 minutes. -The MAU value is recalculated once every 5 minutes for active users, while inactive users are removed from the cohort once every hour. -Internally this works by checking all users, and adding any recently active users to the `monthly_active_users` table. Every hour, any -users with timestamps later than 30 days are removed. The sum of all rows of that table is the final count of active users. +Once an hour, Synapse checks to see if any users are in active (with only activity timestamps later than 30 days). These users +are removed from the active users cohort. If they then become active, they are immediately restored to the cohort. -It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as blocked users won't -perform actions they will eventually be removed from the cohort. +It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as these users won't +perform actions they will eventually be removed from the cohort. This is also the case with shadow banned users. ### Trial days -If `mau_trial_days` is set, the user must have had activity at least this number of days apart for them to be considered part of the cohort. -As an example, if `mau_trial_days` is set to `2` and Alice is active on days 1 and 3 then they will be counted as an active user. If Bob -is active on days 1 and 2, then they will NOT be counted as active. Please note that users do not need to be active on concurrent days to -be deemed active. +If the config option `mau_trial_days` is set, a user must have been active this many days **after** registration to be active. A user is in the +trial period if their registration timestamp (also known as the `creation_ts`) is less than `mau_trial_days` old. -The `mau_appservice_trial_days` config further extends this rule by applying different durations depending on the appservice ID of the user. +As an example, if `mau_trial_days` is set to `3` and a user is active **after** 3 days (72 hours from registration time) then they will be counted as active. + +The `mau_appservice_trial_days` config further extends this rule by applying different durations depending on the `appservice_id` of the user. +Users registered by an application service will be recorded with an `appservice_id` matching the `id` key in the registration file for that service. ## Limiting usage of the homeserver when the maximum MAU is reached @@ -46,15 +53,19 @@ homeserver will begin to block some actions. Individual users matching **any** of the below criteria never have their actions blocked: - Considered part of the cohort of MAU users. - Considered part of the trial period. - - Registered as a `support` user. + - Registered as a `support` user. + - Application service users if `track_appservice_user_ips` is NOT set. + +Please not that server admins are **NOT** blocked. The following actions are blocked when the MAU limit is exceeded: - Logging in - Sending events - Creating rooms + - Syncing Registration is also blocked for all new signups *unless* the user is registering with a threepid included in the `mau_limits_reserved_threepids` -config value. Users that register this way are also immediately considered active on that day. +config value. When a request is blocked, the response will have the `errcode` `M_RESOURCE_LIMIT_EXCEEDED`. @@ -66,8 +77,8 @@ Synapse records several different prometheus metrics for MAU. `synapse_admin_mau:max` records the maximum MAU as dictated by the `max_mau_value` config value. -`synapse_admin_mau_current_mau_by_service` records the current MAU including appservice users. This *also* -includes non-appservice users under the `native` label. +`synapse_admin_mau_current_mau_by_service` records the current MAU including appservice users. The label `app_service` can be used +to filter by a specific service ID. This *also* includes non-appservice users under `app_service=native` . `synapse_admin_mau:registered_reserved_users` records the number of users specified in `mau_limits_reserved_threepids` which have registered accounts on the homeserver. From e46050d9713b4480abc7fa5f0795c84698d3ba34 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Tue, 30 Aug 2022 12:47:59 +0100 Subject: [PATCH 06/13] link back to mau docs --- docs/usage/configuration/config_documentation.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/usage/configuration/config_documentation.md b/docs/usage/configuration/config_documentation.md index 8ae018e6285f..fc32d49db4e2 100644 --- a/docs/usage/configuration/config_documentation.md +++ b/docs/usage/configuration/config_documentation.md @@ -595,6 +595,9 @@ server owner wants to limit to the number of monthly active users. When enabled reached the server returns a `ResourceLimitError` with error type `Codes.RESOURCE_LIMIT_EXCEEDED`. Defaults to false. If this is enabled, a value for `max_mau_value` must also be set. +See [Monthly Active Users](../administration/monthly_active_users.md) for details on how to configure MAU. + + Example configuration: ```yaml limit_usage_by_mau: true From 5632199ac477e6c83e8d3ee9356995841272ad4f Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Tue, 30 Aug 2022 12:48:20 +0100 Subject: [PATCH 07/13] fix links --- docs/usage/administration/monthly_active_users.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index 3ae58edf50cf..4af4f93aa179 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -3,7 +3,7 @@ Synapse can be configured to record the number of monthly active users (also referred to as MAU) on a given homeserver. For clarity's sake, MAU only tracks local users. -Please note that the metrics recorded by the [Homeserver Usage Stats](/usage/administration/monitoring/reporting_homeserver_usage_statistics) +Please note that the metrics recorded by the [Homeserver Usage Stats](../../usage/administration/monitoring/reporting_homeserver_usage_statistics.md) are calculated differently. The `monthly_active_users` from the usage stats does not take into account any of the rules below, and counts any users who have made a request to the homeserver in the last 30 days. From b5f6ee2f8058cfcbe5d04609869163991ebc015d Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Tue, 30 Aug 2022 12:50:34 +0100 Subject: [PATCH 08/13] s/appservice|AS/application service --- docs/usage/administration/monthly_active_users.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index 4af4f93aa179..37c2aa2238f0 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -19,7 +19,7 @@ So for example, if Synapse were to calculate the active users on the 15th July a A user is **never** considered active if they are either: - Part of the trial day cohort (described below) - - Are owned by an Application Service (AS). + - Are owned by an application service. - Note: This **only** cover users that are part of an application service `namespaces.users` registration. The namespace must also be marked as `exclusive`. @@ -73,12 +73,12 @@ When a request is blocked, the response will have the `errcode` `M_RESOURCE_LIMI Synapse records several different prometheus metrics for MAU. -`synapse_admin_mau:current` records the current MAU figure for native (non-appservice) users. +`synapse_admin_mau:current` records the current MAU figure for native (non-application-service) users. `synapse_admin_mau:max` records the maximum MAU as dictated by the `max_mau_value` config value. -`synapse_admin_mau_current_mau_by_service` records the current MAU including appservice users. The label `app_service` can be used -to filter by a specific service ID. This *also* includes non-appservice users under `app_service=native` . +`synapse_admin_mau_current_mau_by_service` records the current MAU including application service users. The label `app_service` can be used +to filter by a specific service ID. This *also* includes non-application-service users under `app_service=native` . `synapse_admin_mau:registered_reserved_users` records the number of users specified in `mau_limits_reserved_threepids` which have registered accounts on the homeserver. From 7969eb85627d5d26d2216addbe1443adfe1e8e17 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Wed, 31 Aug 2022 09:57:39 +0100 Subject: [PATCH 09/13] further review --- docs/usage/administration/monthly_active_users.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index 37c2aa2238f0..787c4480217e 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -19,20 +19,20 @@ So for example, if Synapse were to calculate the active users on the 15th July a A user is **never** considered active if they are either: - Part of the trial day cohort (described below) - - Are owned by an application service. + - Owned by an application service. - Note: This **only** cover users that are part of an application service `namespaces.users` registration. The namespace must also be marked as `exclusive`. Otherwise, any request to Synapse will mark the user as active. Please note that registration will not mark a user as active *unless* they register with a 3pid that is included in the config field `mau_limits_reserved_threepids`. -The Prometheus metric for MAU is recalculated every 5 minutes. +The Prometheus metric for MAU is refreshed every 5 minutes. Once an hour, Synapse checks to see if any users are in active (with only activity timestamps later than 30 days). These users are removed from the active users cohort. If they then become active, they are immediately restored to the cohort. -It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as these users won't -perform actions they will eventually be removed from the cohort. This is also the case with shadow banned users. +It is important to note that **deactivated** and **shadow banned** users are not immediately removed from the pool of active users, but as these users won't +perform actions they will eventually be removed from the cohort. ### Trial days @@ -56,7 +56,7 @@ Individual users matching **any** of the below criteria never have their actions - Registered as a `support` user. - Application service users if `track_appservice_user_ips` is NOT set. -Please not that server admins are **NOT** blocked. +Please not that server admins are **not** exempt from blocking. The following actions are blocked when the MAU limit is exceeded: - Logging in From 6b55c63834bd56346e19c6abdaeacc23e7891385 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Wed, 31 Aug 2022 09:58:57 +0100 Subject: [PATCH 10/13] a newline --- docs/usage/configuration/config_documentation.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/usage/configuration/config_documentation.md b/docs/usage/configuration/config_documentation.md index fc32d49db4e2..ccc6aa75523f 100644 --- a/docs/usage/configuration/config_documentation.md +++ b/docs/usage/configuration/config_documentation.md @@ -597,7 +597,6 @@ Defaults to false. If this is enabled, a value for `max_mau_value` must also be See [Monthly Active Users](../administration/monthly_active_users.md) for details on how to configure MAU. - Example configuration: ```yaml limit_usage_by_mau: true From 91bd9718150d32bdf1b07b088abc023c1df78e21 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Thu, 1 Sep 2022 11:29:28 +0100 Subject: [PATCH 11/13] Remove bit about shadow banned users. I think talking about them is confusing, and the current text doesn't imply they get any special treatment. --- docs/usage/administration/monthly_active_users.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index 787c4480217e..e11c239b2aeb 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -31,7 +31,7 @@ The Prometheus metric for MAU is refreshed every 5 minutes. Once an hour, Synapse checks to see if any users are in active (with only activity timestamps later than 30 days). These users are removed from the active users cohort. If they then become active, they are immediately restored to the cohort. -It is important to note that **deactivated** and **shadow banned** users are not immediately removed from the pool of active users, but as these users won't +It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as these users won't perform actions they will eventually be removed from the cohort. ### Trial days From 3d836a709f1e5a4ac81acfd4532e86fe442fb6e0 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Thu, 1 Sep 2022 13:25:20 +0100 Subject: [PATCH 12/13] Update docs/usage/administration/monthly_active_users.md Co-authored-by: Patrick Cloke --- docs/usage/administration/monthly_active_users.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index e11c239b2aeb..cadb51d3ba51 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -20,7 +20,7 @@ So for example, if Synapse were to calculate the active users on the 15th July a A user is **never** considered active if they are either: - Part of the trial day cohort (described below) - Owned by an application service. - - Note: This **only** cover users that are part of an application service `namespaces.users` registration. The namespace + - Note: This **only** covers users that are part of an application service `namespaces.users` registration. The namespace must also be marked as `exclusive`. Otherwise, any request to Synapse will mark the user as active. Please note that registration will not mark a user as active *unless* From ff429364040433a272fe60972b4e18b111202a31 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Thu, 1 Sep 2022 13:25:24 +0100 Subject: [PATCH 13/13] Update docs/usage/administration/monthly_active_users.md Co-authored-by: Patrick Cloke --- docs/usage/administration/monthly_active_users.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/administration/monthly_active_users.md b/docs/usage/administration/monthly_active_users.md index cadb51d3ba51..d4e90372846a 100644 --- a/docs/usage/administration/monthly_active_users.md +++ b/docs/usage/administration/monthly_active_users.md @@ -28,7 +28,7 @@ they register with a 3pid that is included in the config field `mau_limits_reser The Prometheus metric for MAU is refreshed every 5 minutes. -Once an hour, Synapse checks to see if any users are in active (with only activity timestamps later than 30 days). These users +Once an hour, Synapse checks to see if any users are inactive (with only activity timestamps later than 30 days). These users are removed from the active users cohort. If they then become active, they are immediately restored to the cohort. It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as these users won't