What is community analytics, and how do you build it in Metabase?
Community analytics turns members, posts, threads, events, and registrations into shared metrics about who participates, who answers, and who comes back. Community teams are usually handed vanity numbers — total members, total posts — and asked to prove value with them. The durable version is different: participation joined to product usage, support tickets, and revenue, built in your own BI on data you control.
TL;DR — Land members, posts, topics, events, and registrations in a warehouse, and snapshot member counts daily so deleted accounts stop rewriting history. Define "active member" once, with its window stated on every card. Treat attendance as missing, not zero, wherever nobody ran check-in.
What does community analytics measure?
- How many members are joining, and how many are quietly leaving?
- Do new members become contributors — and how quickly does that happen?
- Do questions get answered, and how long do people wait?
- How concentrated is participation? What happens if the top ten members stop?
- Which spaces, categories, or channels have gone quiet?
- How many registrations convert into people who actually turned up?
- What did an event earn, net of fees and refunds — and who came back for the next one?
- Do community members retain, expand, or file fewer support tickets than everyone else?
Which tools feed community analytics?
| Tool | Best for | Getting data into Metabase |
|---|---|---|
| Discourse | Member growth and activation of new signups; Engagement: posts, replies, and reactions over time | Discourse API, pipeline, or Discourse MCP server for exploration |
| Circle | Member growth and paid-membership mix; Space-level engagement and quiet spaces | Circle Admin API v2, pipeline, or Circle MCP server for exploration |
| Discord | Member growth and joins vs. leaves; Message volume by channel and hour | Discord API, pipeline, or Discord community MCP servers for exploration |
| Luma | Registrations by event and calendar; RSVP-to-attendance conversion from check-in data | Luma Public API export or pipeline (no vendor MCP server) |
| Eventbrite | Registrations and ticket revenue by event; RSVP-to-attendance conversion and no-show rate | Eventbrite API v3 export or pipeline (no vendor MCP server) |
| Slack | Internal and customer channel activity | Analytics exports, connector, or Slack API |
What shared data models should you build?
Build clean models on top of raw synced tables so every dashboard uses the same definitions — especially the two that cause the most arguments, "active" and "attended".
community_members— one row per member, with join date, source tool, and a stable identity key for cross-tool matchingcommunity_members_daily— one row per day per source: total members, joins, and leaves, snapshotted so history stops moving when accounts are deleted or anonymizedcommunity_posts— one row per post, comment, or message, with the space or channel, the parent post, and the authorcommunity_topics— one row per topic or thread, with reply count, first-reply timestamp, and whether it was ever answeredcommunity_events— one row per event, with start time, capacity, location type, and whether it was paidevent_registrations— one row per guest per event, with registration and check-in timestamps and ticket typeevent_orders— one row per order, with gross amount, fees, and refunded amount as separate columns
Which community metrics matter most?
- Member growth rate — net new members per period, computed from daily snapshots rather than the live member list.
- Engagement rate — the share of members who did something, over a window stated on the card.
- RSVP-to-attendance conversion — check-ins over registrations, for events where check-in was actually used.
- Reply rate — the share of questions that get an answer; its inverse is the honest alarm.
- Conversion rate — activation of new members, and free-to-paid membership where that applies.
- Median time to first reply — the percentile, never the average: one topic answered three weeks late ruins a mean.
- Contributor concentration — the share of posts from the top ten members, and the key-person risk it represents.
How do you connect tools to Metabase?
- Database replica where you can — self-hosted Discourse runs on PostgreSQL, which makes it the richest source in the category by a wide margin.
- Pipelines everywhere else — a managed connector for Eventbrite, Discord, or Luma, and scheduled Admin API pulls for Circle, which has no connector at all.
- MCP or API + CLI — a scoped live lookup or scripted export, then
mb upload csvfor quick analysis. Discourse and Circle publish MCP servers; Luma and Eventbrite do not.
Which dashboards should you build first?
- Member growth — new members, net growth, and activation of recent signups.
- Engagement activity — posts, messages, and reactions by space, channel, and month.
- Event performance— registrations, attendance, ticket mix, and net revenue by event.
- Community health— response times, unanswered questions, and contributor concentration.
Common mistakes
Reporting total members as the headline number.→ A large member list with ten people posting is a mailing list. Pair growth with engagement and contributor concentration on the same screen.
Recomputing member history from the live member list.→ Deleted and anonymized accounts disappear from it, so last quarter's numbers move every refresh. Snapshot daily into a table you control.
Publishing an active member count with no definition.→ The window and the action are choices. State both on the card, or everyone assumes the reading that flatters them most.
Scoring events with no check-in data as 0% attendance.→ That is a missing measurement, not a bad result. Exclude those events and show how many were excluded.
Averaging time to first reply.→ One neglected thread drags the mean past anything a member would recognize. Use the median, and show the no-reply share beside it.
Stopping at the community tables.→ The value of this work is the join. Connect members to product usage, support tickets, and revenue — that is the question leadership is actually asking.
Related
Integrations
Analytics
Dashboards
Terms
FAQ
What is community analytics?
Community analytics is the practice of turning the raw records of a community — members, posts, threads, events, and registrations — into governed, shareable metrics. Where a platform's built-in reporting answers "how many posts last week?", community analytics answers "are new members becoming contributors, are questions getting answered, and do community members retain and expand better than everyone else?" In Metabase you build it on data landed in a SQL warehouse from tools like Discourse, Circle, Discord, Luma, and Eventbrite.
What is the difference between community analytics and event analytics?
They share a member table and diverge after it. Community analytics measures ongoing participation — posting, replying, returning — over open-ended time. Event analytics measures discrete moments: registrations, pacing before the door opens, check-ins, and ticket revenue. The join between them is the interesting part: whether people who attend events go on to participate, and whether participants show up to events.
Why build community dashboards in a BI tool instead of the platform's own reporting?
Three reasons. Joins: the questions worth answering — does community participation reduce support tickets, improve retention, or precede expansion — need community data next to product, support, and CRM tables that live in your warehouse. Governance: "active member" becomes one certified definition instead of five conflicting screenshots. Reach: dashboards go to marketing, support, and leadership without another platform seat. The platforms remain the place the community actually happens.
Which metrics should a community dashboard track?
Start with three: member growth rate from daily snapshots, engagement rate over a window you state on the card, and — once you can compute reply times — reply rate with its inverse, the no-reply share. For events, add RSVP-to-attendance conversion. Contributor concentration, the share of posts written by the top ten members, deserves a card even though nobody enjoys it.
What data do I need to get started?
Two tables. A member table with a join date, and a daily snapshot of member counts so history stops moving under you — that alone powers the member growth dashboard. Posts or messages come next, then topics with first-reply timestamps, then events and registrations. Every integration guide shows how to land them for a specific tool.
How do I count active members honestly?
Pick a window and an action, model it once, and put both in the card title. "Posted in the last 30 days" and "logged in within 90 days" are both defensible and will differ by an order of magnitude. What is not defensible is a number labeled "active members" with no definition attached — it invites everyone to assume the flattering reading.
Can I build community dashboards without a data warehouse?
For a first pass, yes: pull a summarized slice through a vendor MCP server where one exists — Discourse and Circle both publish one — or a scripted API export where none does, and load it with the Metabase CLI (
mb upload csv). That works for spot-checks. Durable reporting wants the data in a warehouse: history, scheduled refreshes, and definitions people can trust. Each integration guide documents both routes.