|
| 1 | +# Monthly Active Users |
| 2 | + |
| 3 | +Synapse can be configured to record the number of monthly active users (also referred to as MAU) on a given homeserver. |
| 4 | +For clarity's sake, MAU only tracks local users. |
| 5 | + |
| 6 | +Please note that the metrics recorded by the [Homeserver Usage Stats](../../usage/administration/monitoring/reporting_homeserver_usage_statistics.md) |
| 7 | +are calculated differently. The `monthly_active_users` from the usage stats does not take into account any |
| 8 | +of the rules below, and counts any users who have made a request to the homeserver in the last 30 days. |
| 9 | + |
| 10 | +See the [configuration manual](../../usage/configuration/config_documentation.md#limit_usage_by_mau) for details on how to configure MAU. |
| 11 | + |
| 12 | +## Calculating active users |
| 13 | + |
| 14 | +Individual user activity is measured in active days. If a user performs an action, the exact time of that action is then recorded. When |
| 15 | +calculating the MAU figure, any users with a recorded action in the last 30 days are considered part of the cohort. Days are measured |
| 16 | +as a rolling window from the current system time to 30 days ago. |
| 17 | + |
| 18 | +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. |
| 19 | + |
| 20 | +A user is **never** considered active if they are either: |
| 21 | + - Part of the trial day cohort (described below) |
| 22 | + - Owned by an application service. |
| 23 | + - Note: This **only** covers users that are part of an application service `namespaces.users` registration. The namespace |
| 24 | + must also be marked as `exclusive`. |
| 25 | + |
| 26 | +Otherwise, any request to Synapse will mark the user as active. Please note that registration will not mark a user as active *unless* |
| 27 | +they register with a 3pid that is included in the config field `mau_limits_reserved_threepids`. |
| 28 | + |
| 29 | +The Prometheus metric for MAU is refreshed every 5 minutes. |
| 30 | + |
| 31 | +Once an hour, Synapse checks to see if any users are inactive (with only activity timestamps later than 30 days). These users |
| 32 | +are removed from the active users cohort. If they then become active, they are immediately restored to the cohort. |
| 33 | + |
| 34 | +It is important to note that **deactivated** users are not immediately removed from the pool of active users, but as these users won't |
| 35 | +perform actions they will eventually be removed from the cohort. |
| 36 | + |
| 37 | +### Trial days |
| 38 | + |
| 39 | +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 |
| 40 | +trial period if their registration timestamp (also known as the `creation_ts`) is less than `mau_trial_days` old. |
| 41 | + |
| 42 | +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. |
| 43 | + |
| 44 | +The `mau_appservice_trial_days` config further extends this rule by applying different durations depending on the `appservice_id` of the user. |
| 45 | +Users registered by an application service will be recorded with an `appservice_id` matching the `id` key in the registration file for that service. |
| 46 | + |
| 47 | + |
| 48 | +## Limiting usage of the homeserver when the maximum MAU is reached |
| 49 | + |
| 50 | +If both config options `limit_usage_by_mau` and `max_mau_value` is set, and the current MAU value exceeds the maximum value, the |
| 51 | +homeserver will begin to block some actions. |
| 52 | + |
| 53 | +Individual users matching **any** of the below criteria never have their actions blocked: |
| 54 | + - Considered part of the cohort of MAU users. |
| 55 | + - Considered part of the trial period. |
| 56 | + - Registered as a `support` user. |
| 57 | + - Application service users if `track_appservice_user_ips` is NOT set. |
| 58 | + |
| 59 | +Please not that server admins are **not** exempt from blocking. |
| 60 | + |
| 61 | +The following actions are blocked when the MAU limit is exceeded: |
| 62 | + - Logging in |
| 63 | + - Sending events |
| 64 | + - Creating rooms |
| 65 | + - Syncing |
| 66 | + |
| 67 | +Registration is also blocked for all new signups *unless* the user is registering with a threepid included in the `mau_limits_reserved_threepids` |
| 68 | +config value. |
| 69 | + |
| 70 | +When a request is blocked, the response will have the `errcode` `M_RESOURCE_LIMIT_EXCEEDED`. |
| 71 | + |
| 72 | +## Metrics |
| 73 | + |
| 74 | +Synapse records several different prometheus metrics for MAU. |
| 75 | + |
| 76 | +`synapse_admin_mau:current` records the current MAU figure for native (non-application-service) users. |
| 77 | + |
| 78 | +`synapse_admin_mau:max` records the maximum MAU as dictated by the `max_mau_value` config value. |
| 79 | + |
| 80 | +`synapse_admin_mau_current_mau_by_service` records the current MAU including application service users. The label `app_service` can be used |
| 81 | +to filter by a specific service ID. This *also* includes non-application-service users under `app_service=native` . |
| 82 | + |
| 83 | +`synapse_admin_mau:registered_reserved_users` records the number of users specified in `mau_limits_reserved_threepids` which have |
| 84 | +registered accounts on the homeserver. |
0 commit comments