Telegram group statistics: is your moderation actually helping?
Read Defendy's periods and counters correctly, build a small moderation-health scorecard, and separate activity, workload, mistakes and missing data.
Your filter deleted more messages this week. That might mean it caught a promotional wave. It might also mean it started removing legitimate support questions. The deletion chart cannot distinguish those outcomes on its own.
A useful moderation report connects the conversation, the actions taken and their consequences for people. Start with a small set of measures, define the unit behind each counter and decide what you would do differently after reading it. This guide combines Defendy's group statistics with a short human review.
The focus is the moderation process as a whole. For questions about individual participation, use the separate guide to activity and its limits.
Establish the group, period and comparison first
Open Settings in your private chat with @defendy_bot, choose the chat under My groups, then open Statistics. Check the name at the top. A channel's linked discussion report describes that group, not the publishing channel's entire audience.
The reviewed implementation offers 7, 30 and 90 days, plus a custom range. Its main views are Overview, Users, Moderation and Reputation, with additional reports under More. These screens show data; they do not change moderation rules. See the statistics reference for navigation.
For a reproducible comparison, record:
- Exact start and end dates
- The group's timezone
- Whether both observation windows are complete
- Rule changes, events and collection problems
- When you retrieved the report
Days and hours are calculated in the group's timezone. The comparison window immediately precedes the selected window and has the same number of dates. However, if the current range includes today, that day is unfinished. Equal calendar length does not necessarily mean equal elapsed observation time. Select completed days explicitly for a weekly review.
Know the unit behind each card
Messages, distinct authors, events and estimated membership are different quantities. Similar-looking cards do not make them interchangeable.
| Metric | Meaning | Not a measure of |
|---|---|---|
| Messages | Recorded new messages | All reading or complete history |
| Active authors | Distinct senders in the period | Everyone who reads |
| Average daily activity | Mean of daily author counts | Distinct authors across the period |
| Weekly activity, WAU | Authors in the range's last seven days | An average of all weeks |
| Messages per author | Messages divided by active authors | Helpful contributions |
| Moderation actions | Recorded actions and deletions | That many people or incidents |
Overview activity can include messages sent as channels. The active-users table is focused on user senders, so its rows need not account for the entire overview. The newer event model excludes service messages and bot senders; historical events without a sender type use the available legacy fields. None of this is an independent authenticity check on every author.
Average daily activity adds the daily active-author counts and divides by the range's calendar-day count, including days with no recorded messages. WAU counts distinct authors in the last seven local days of the chosen range, or the entire range if it is shorter. It does not count people who participated every day.
Percentage change also needs a valid baseline. The implementation compares against the previous value; a zero previous value makes the percentage unavailable. Activity appearing from zero cannot be expressed as an ordinary percentage increase.
Read Moderation as recorded work, not detection accuracy
The Moderation view separates filter deletions, warnings, mutes, bans and kicks. It also shows daily changes and users with the most counted sanction events.
A single incident can produce multiple actions. Deleting an advertisement and warning its author are two actions associated with one message. Repeated sanctions against one account do not represent several different people. A recorded sanction also does not establish that the decision was correct.
There is a technical reason the views can disagree: Overview includes deletion events more broadly, while Moderation's filter-deletion count requires a named filter. Their accepted event sets also differ. Do not automatically classify a discrepancy as data loss, or add the two totals together: they can overlap. Record the exact view, metric and date range when investigating.
Normalise workload without relabelling it as spam
For your own report, one possible measure is actions of a chosen category per 1,000 recorded messages:
Action count ÷ message count × 1,000.
This is a proposed indicator of moderation intensity, not a built-in accuracy score or the percentage of messages that were spam. The numerator and denominator come from different event streams; a deleted message need not appear in the recorded-message total. One message can generate several actions. Leave the result undefined when the denominator is zero.
Keep the same view, category and collection conditions across comparisons. A spike is a reason to inspect events, not an automatic instruction to increase penalties.
Users: membership counters are not retention
In the reviewed model, New counts distinct users with a recorded verified-entry event in the period; that does not necessarily mean passing CAPTCHA. Left and Kicked count departure and removal events, not necessarily different people. One person can leave and re-enter repeatedly.
Consequently, subtracting Left and Kicked from New does not reliably reconstruct exact membership change from those cards. Total membership is calculated separately and marked as estimated. Daily distinct counts also cannot always be added: the same person may appear on multiple days.
Read the collection-coverage notice. A period before membership collection began has unavailable values, not genuine zero activity. The first partly observed day is not a complete day. Estimated historical totals can be revised.
Retention requires a defined cohort and a later observation window. For a manual study, you might define “returning to conversation” as the proportion of people who entered in one calendar week and posted at least once in the next complete calendar week. You would need compatible events for those same people and complete coverage of both windows. That is a proposed measurement plan, not a claim that the dashboard already supplies the metric. It still does not measure returning silent readers.
Selecting 90 days does not prove complete collection or a guaranteed storage period. This article establishes no service data-retention term. Check whether the data actually exists before promising a historical report.
Add the evidence the cards cannot supply
A weekly review needs a few human observations beside the charts. Keep them in a restricted team note rather than a public ranking of participants.
Mistaken restrictions. Review a defined set of decisions and mark confirmed errors. Errors divided by reviewed decisions gives the error share in that review. If you selected only appeals, the result describes appeals, not the accuracy of the whole system.
Unresolved requests. Track which restriction questions remain open and how long people wait for a substantive first response. An acknowledgement and a resolution are different events. Use consistent start and end definitions if you compare waiting times.
Disruption to legitimate conversation. Inspect ordinary questions and useful answers around a rule change. Did they survive? Are people avoiding necessary documentation links to get around the filter? This is a qualitative check, not an automated politeness score.
Team workload. Sanction counts are not hours worked. A disputed restriction may require more attention than many obvious deletions. Review unresolved cases and backup coverage instead of ranking moderators by bans issued.
Worked example: the same action count tells two different stories
Assume two completed weeks in the same group, with consistent definitions and collection conditions. These numbers are hypothetical. They are neither a community dataset nor recommended targets.
| Measure | Week A | Week B |
|---|---|---|
| Recorded messages | 2,000 | 3,000 |
| Selected actions | 60 | 60 |
| Actions per 1,000 messages | 30 | 20 |
| Decisions reviewed | No review | 20 |
| Errors among reviewed decisions | Unknown | 4 |
The absolute action count stayed the same. Relative intensity fell: 60 ÷ 3,000 × 1,000 = 20. That does not establish less spam or better filtering. A useful live Q&A may simply have increased the message denominator.
Four errors among twenty reviewed decisions is 20% in that review. Because no review took place in Week A, there is no valid before-and-after error comparison. If the twenty cases all came from complaints, generalising the result to the other actions would be especially misleading.
The next useful step is to inspect the four mistakes, identify any shared rule and test it against both acceptable and prohibited examples. Increasing deletions to restore last week's ratio would not follow from the evidence.
End the weekly review with one decision
- Select the group and completed period; note coverage limitations.
- Read Overview, then Moderation and the available records for selected logging categories.
- Match changes to events, outages and rule edits.
- Review errors and unresolved requests, not only obvious successful removals.
- Choose one action: clarify a rule, repair an exception, add backup coverage or deliberately change nothing.
- Assign an owner, a review date and the evidence that would show whether the action helped.
For example: “The link rule is removing legitimate setup instructions. The owner will test the allowed-source configuration; next review, we will inspect mistakes associated with that rule.” That is observable work. “Improve engagement” is not yet a testable decision.
If a rule changes, annotate when it changed. Otherwise, the next review may interpret a different policy as different member behaviour. If a collection problem is suspected, resolve it before using the chart to judge a person or moderator.
Export only when it serves the question
Under More → Data export, choose a dataset and CSV or JSON. Verify the group and period, download the file and inspect its actual columns. Export availability does not mean every desired field or the complete historical record is present.
Keep the definitions and retrieval date alongside the file. A general report usually needs aggregates; names, identifiers and appeal excerpts should stay with the people who need them for the decision. Do not publish the raw export simply because you want to share a chart.
If a download fails or a view appears empty, check the group, dates and error state first. A failed request is not evidence that violations disappeared.
What a good result looks like
A good week does not require rising activity or fewer sanctions in every category. It means demonstrated harm was handled, mistakes were corrected, requests were not lost and the team understands the effects of its rules.
The dashboard helps locate the question. Reviewing events and the people affected supplies the answer.
Sources and verification
Checked on 5 October 2026 against Defendy's Statistics views and current metric definitions. The statistics reference explains the report and period controls. All example figures are hypothetical. No live group's moderation accuracy, update speed or effectiveness was measured. Source review does not establish a particular chat's collection completeness or deployed version.
