Skip to main content

Demographics report

National admins reach this from Analytics in the sidebar, then the Demographics tab (/org/analytics?tab=demographics). It reports self-identified member demographics in aggregate, and it is a core reporting surface — not a licensable module, no on/off toggle.

note

It was its own sidebar row at /org/demographics until v0.73.71. That address still works and redirects to the tab, so existing bookmarks and pins keep resolving.

Regional admins see the Analytics page but not this tab: the aggregate is organization-wide, and a region-scoped version is separate work. Per-member values are unaffected — see the visibility table below.

Three states, not two

The report splits everyone in scope into three counts that always add up to the total:

CountMeans
AnsweredGave an actual value
Declined to sayWas asked and chose not to answer
Not answeredNever answered — usually never asked

Keeping Declined out of Not answered is the point of the page. A refusal is a decision someone made, and folding it into "never asked" would make your disclosure rate look worse than it is. If you are reporting a response rate to a national body, Answered + Declined is how many people the question actually reached.

The Breakdown table lists one row per distinct answer with its share of people who answered — not of total membership. A blank field is not evidence about anyone's ethnicity, so it does not belong in that denominator.

Scope

The scope selector covers:

  • Members (default) — everyone who is or was a member
  • Applicants (PNMs) — people with an open or past application who have not crossed
  • Everyone — both

Members and Applicants partition your organization exactly, so no membership is missing from every scope.

Spelling variants are merged

The underlying field is free text, so "Asian", "asian" and " ASIAN " are one answer and are counted as one row. The label shown is the spelling your members wrote most often.

If your members' answers fragment into more than 50 distinct spellings, the table shows the 50 most common and adds an Other responses (N distinct) row carrying the rest. The rows still add up to Answered — the report never quietly leaves people out to fit the table.

What is not merged is different wording for the same idea — "Latino" and "Hispanic or Latino" stay separate rows, because the platform cannot know they were meant as the same answer. This is why the application form offers clickable suggestions: they exist to make the common answers arrive spelled consistently, without ever preventing someone from typing their own.

Who can see an individual's value

The report is aggregate. Per-member values live on a Demographics card on the member's own profile page, and the rule there is deliberately narrow:

  • Can read: the member themselves, the officers of their own chapter, the regional admin of their own region, and org admins.
  • Can write: the member, and nobody else.

Officers and admins read; they do not author. This is enforced by the API, not just hidden in the interface — an officer's attempt to change someone else's value is rejected by the server. Self-identified data that someone else can overwrite is not self-identified.

Note this is narrower than a member profile in two ways. Any member of your organization can view another member's profile details; demographics deliberately do not follow that rule. And officer access is scoped to the officer's own chapter — an officer at one chapter cannot read a member at another, even within the same organization.

This report itself is narrower still: org admins only. A chapter officer's remit is one chapter and a regional admin's is one region, so neither gets an organization-wide roll-up. A region-scoped version is tracked as #1047.

Where the data comes from

Each value is tagged with its origin:

  • From recruitment application — answered during intake and carried over when the applicant crossed.
  • Self-reported — the member entered or corrected it themselves.
  • Imported — loaded through a bulk import.

A member editing their own value replaces an intake answer, and the report reflects the correction immediately. Crossing never overwrites a value a member has already set.

Retention

Nothing here expires. There is no purge schedule and no anonymization clock on demographic values; they are kept for as long as the record exists. That is a deliberate decision, not a gap.

Do not confuse this with two similarly-named features:

  • Retention in the sidebar and analytics means member retention — chapter health, churn projections, exit surveys.
  • Retention Policy under Backups controls how many backup snapshots are kept.

Neither affects demographic data. Audit-log retention (a separate, configurable clock) does not either.

If your national organization or local law imposes a retention requirement on demographic data, that obligation is yours to meet — the platform does not impose one for you.

Answering is always optional

No member is ever required to disclose. "Prefer not to say" is offered as a one-click suggestion on the application form and on the member's own profile, and choosing it is recorded as a genuine answer so the person is not mistaken for someone who was never asked.