mirror of
https://github.com/discourse/discourse.git
synced 2026-08-08 14:34:02 +08:00
bf0128fa86The engagement dashboard's "Trust level pipeline" showed each level's
membership
plus direction-blind "moves in / moves out" counts, colored by
**position**
(in vs. out). That mislabeled healthy movement: a member graduating
*out* of Tiers, especially New,
rendered as a red ↓, reading as negative when it's the best possible
outcome.
This PR reframes the widget as a **directional arrivals funnel** with a
focus on the flow, and specifically looks at promoted/demoted-in
## Design thinking
- **Direction, not position.** Trust-level movement has a meaningful
axis —
up (promotion) is good, down (demotion) is not. We split every move into
`promoted_in` and `demoted_in`, drop the double bars, and colour by
direction: if more promotions => green, if more demotions => red.
Leaving New is now correctly green.
- **An "arrivals" funnel.** Each rung answers one consistent question:
*how many
members arrived here this period?* For every bar it's tracked the same
way + we add an extra label for the tier that is set as the `Default
trust level`.
- **Sign-ups ≠ promotions.** Signups are excluded from both the trend
and the bar scale. It's volume would otherwise often dwarf the other
bars.
## Backend — `reports/trust_level_pipeline.rb`
- **Snapshot** per level: `User.real.group(:trust_level).count` + share.
No date
filter — it's the current distribution, not a period metric.
- **Directional arrivals** from `user_histories` (`change_trust_level` +
`auto_trust_level_change`) within the period: `promoted_in`,
`demoted_in` per level.
- **Sign-ups**: real users created in the period, attributed to the
entry level
(`SiteSetting.default_trust_level`). Not counted as trust-level moves.
- **Trend** (`prev_period`): net = promotions − demotions across the
ladder
(sign-ups excluded) → `climbing` / `dropping` / `stable`.
## Known limitation
The `Default invitee trust level` is not taken into account, which means
invitees can be counted at the wrong rung.
However, accounting for it correctly means distinguishing invited from
organic sign-ups (joining through invites, and handling that a user's
trust level may have moved since they joined), which introduces a second
entry point. That breaks the widget's core simplification and adds
complexity. Overall I'm expecting the % of invitees to usually not
meaningfully muddle the representation of the pipeline flow.
|
||
|---|---|---|
| .. | ||
| activity_by_category.rb | ||
| admin_logins.rb | ||
| associated_accounts_by_provider.rb | ||
| bookmarks.rb | ||
| consolidated_api_requests.rb | ||
| consolidated_page_views.rb | ||
| consolidated_page_views_browser_detection.rb | ||
| daily_engaged_users.rb | ||
| dau_by_mau.rb | ||
| emails.rb | ||
| flags.rb | ||
| flags_status.rb | ||
| likes.rb | ||
| mobile_visits.rb | ||
| moderator_warning_private_messages.rb | ||
| moderators_activity.rb | ||
| new_contributors.rb | ||
| notify_moderators_private_messages.rb | ||
| notify_user_private_messages.rb | ||
| post_edits.rb | ||
| posters_by_member_type.rb | ||
| posts.rb | ||
| profile_views.rb | ||
| signups.rb | ||
| site_traffic.rb | ||
| storage_stats.rb | ||
| suspicious_logins.rb | ||
| system_private_messages.rb | ||
| time_to_first_response.rb | ||
| top_countries_by_browser_pageviews.rb | ||
| top_ignored_users.rb | ||
| top_referred_topics.rb | ||
| top_referrers.rb | ||
| top_referrers_by_browser_pageviews.rb | ||
| top_traffic_sources.rb | ||
| top_uploads.rb | ||
| top_users_by_likes_received.rb | ||
| top_users_by_likes_received_from_a_variety_of_people.rb | ||
| top_users_by_likes_received_from_inferior_trust_level.rb | ||
| topic_view_stats.rb | ||
| topics.rb | ||
| topics_with_no_response.rb | ||
| trending_search.rb | ||
| trust_level_growth.rb | ||
| trust_level_pipeline.rb | ||
| user_flagging_ratio.rb | ||
| user_to_user_private_messages.rb | ||
| user_to_user_private_messages_with_replies.rb | ||
| users_by_trust_level.rb | ||
| users_by_type.rb | ||
| visits.rb | ||
| web_crawlers.rb | ||
| web_hook_events_daily_aggregate.rb | ||
