Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Add monthly active users documentation #13617

Merged
merged 15 commits into from
Sep 1, 2022
1 change: 1 addition & 0 deletions changelog.d/13617.doc
Original file line number Diff line number Diff line change
@@ -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.
1 change: 1 addition & 0 deletions docs/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
84 changes: 84 additions & 0 deletions docs/usage/administration/monthly_active_users.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# 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/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.

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. 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)
- 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`.
Half-Shot marked this conversation as resolved.
Show resolved Hide resolved

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 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.
Half-Shot marked this conversation as resolved.
Show resolved Hide resolved

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is still wrong on the shadow banned front. If a shadow banned user sends a request, we still record them as active, and later down the line we cancel out their action (in a way that makes it look like it succeeded).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must have misunderstood you initially. I think that makes loads of sense.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's worth talking about this at all, they're effectively the same as regular users and I think the absence of any text tells you as much.

perform actions they will eventually be removed from the cohort.

### Trial days
Half-Shot marked this conversation as resolved.
Show resolved Hide resolved

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.

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

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.

Individual users matching **any** of the below criteria never have their actions blocked:
babolivier marked this conversation as resolved.
Show resolved Hide resolved
- Considered part of the cohort of MAU users.
- Considered part of the trial period.
- Registered as a `support` user.
- Application service users if `track_appservice_user_ips` is NOT set.

Please not that server admins are **not** exempt from blocking.

The following actions are blocked when the MAU limit is exceeded:
babolivier marked this conversation as resolved.
Show resolved Hide resolved
- 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.

When a request is blocked, the response will have the `errcode` `M_RESOURCE_LIMIT_EXCEEDED`.

## Metrics
Half-Shot marked this conversation as resolved.
Show resolved Hide resolved

Synapse records several different prometheus metrics for MAU.

`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 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.
2 changes: 2 additions & 0 deletions docs/usage/configuration/config_documentation.md
Original file line number Diff line number Diff line change
Expand Up @@ -595,6 +595,8 @@ 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
Expand Down