Analytics and risk summaries
Interpret descriptive server aggregates and deterministic risk heuristics as review context, never as automatic judgment.
- Audience
- senior reviewer · team lead · server admin
- Availability
- premium preview · private beta access
- Maturity
- alpha · partial
Last reviewed
On this page
Use summaries as leads, not verdicts
Analytics summarizes stored server activity such as action volume, trends, workload, jail durations, appeals, open cases, and a limited risk overview. The risk score is a deterministic composite of visible counts rather than a prediction of intent.
Confirm range, population, and visibility
The Analytics dashboard requires server access and the advanced analytics feature gate. Retained behavior detail and linked evidence can require narrower review permissions.
Open Analytics for the selected server, confirm the date range and empty-state messaging, then trace any important value back to its source records.
- A specific operational question and date range.
- Knowledge of which stored records contribute to the chart or score.
- Permission to inspect the source records needed to validate an outlier.
Trace a summary back to records
Choose the question
Start with a specific question such as incident volume, pending appeals, open high-severity Cases, or staff workload.
Check: The viewer avoids treating the entire dashboard as one verdict.
Read the inputs
Inspect count, trend, bucket, and date labels, including empty or unavailable states.
Check: The aggregate is interpreted with its scope and denominator.
Trace the source
Open Records, Cases, or Appeals to verify the items behind a material signal.
Check: A deterministic summary is checked against actual records.
Make a human decision
Document the review conclusion separately and use an authorized case or action workflow only when policy and evidence support it.
Check: Analytics remains context rather than automatic enforcement.
Evidence-led analytics examples
A reviewer can explain which stored inputs produced a visible aggregate and why any subsequent decision was made independently.
- Investigate a higher incident-volume trend by opening the underlying action records.
- Treat a risk score of zero as no contributing stored counts in that view, not proof of no risk.
- Review staff workload distribution without using volume alone as a performance verdict.
Read each analytic as a scoped aggregate
| Family | Useful question | Caution |
|---|---|---|
| Action volume | How many recorded actions occurred in a date range? | Volume does not show appropriateness, complexity, or quality. |
| Action mix | Which action types are most common? | Different policies and incident mixes change the distribution. |
| Trends | Did recorded activity rise or fall over time? | Imports, missing collection, policy changes, and membership can shift counts. |
| Open cases/appeals | What review workload is currently unresolved? | Visibility and workflow state can hide or reclassify items. |
| Jail duration/outcomes | How long do active/completed restrictions remain? | Partial release or role cleanup must be read from records. |
| Deterministic risk overview | Which visible stored counts deserve source review? | Not intent prediction, guilt, or automatic enforcement. |
Trace a chart or summary to records
Confirm scope
Read selected server, date range, filters, timezone, and empty/unavailable notices.
Check: The metric has a defined population.
Read the definition
Identify which stored events and statuses contribute.
Check: The numerator/denominator are understood.
Inspect examples
Open representative records, including outliers and ordinary cases.
Check: The aggregate is grounded in source data.
Look for gaps
Check imports, retention, permission limits, disabled collection, and changed policies.
Check: Uncertainty is recorded.
Decide in the owning workflow
Use a Case, appeal, action, Settings change, or staffing discussion as appropriate.
Check: Analytics never executes the decision.
Make comparisons responsibly
| Check | Why |
|---|---|
| Same date range | Different windows distort volume and rate comparisons. |
| Same filters/source set | Native-only and imported-inclusive counts are not interchangeable. |
| Same policy period | Rule or enforcement changes alter action mix. |
| Comparable population | Server growth, events, raids, or staffing can change exposure. |
| Record availability | Permission/redaction and retention can hide underlying items. |
| Human context | Numbers do not explain case difficulty, evidence quality, or staff role. |
When reporting analytics, state the scope and caveats in the same sentence as the result. Example: “Thirty native moderation actions were recorded in Server X from July 1–17; imported actions and hidden senior-only Cases are not included in this view.”
Changing scoring features remain reserved
Changing predictive analysis, staff-performance scorecards, rankings, automated quality judgments, and unfinished intelligence surfaces are excluded. This guide documents only descriptive aggregates and deterministic review aids that require source-record review.
Know what the summary cannot prove
Results inherit missing, delayed, imported, or permission-limited data. Deterministic weights are a product heuristic, can change, and are not a validated assessment of a person or server.
Something is missing or looks wrong
What you see: The current view does not contain the record, field, source, or output you expected.
What may be happening: Server scope, viewer permission, filters, source availability, feature gates, or stale state can change what the product may show.
What to do
- Confirm date range, selected server, and feature access.
- Read empty/unavailable states before drawing a conclusion.
- Trace a material number to Records or its feature-specific queue.
- Report unexplained drift with the visible inputs and timestamp.
Interpret Watchlist and staff metrics cautiously
Watchlist review starts with observed sources, scheduled follow-up, and separate lifecycle, ownership, and attention states. Historical risk or heat values are not used to order the current queue and do not establish guilt or authorize punishment. Moderator Scorecards are a separate default-off controlled preview with review and correction safeguards.