The question usually starts in a board meeting or a grant report: “Who are our members, and who actually shows up?” Answering it means tying two things together that Altru keeps in different places. Membership and visit activity sit on one side. Demographics like ZIP code, age group, or how someone heard about you sit on the constituent record. Check-in is the moment that can connect them, but only if the desk captures the right identifier.
Below is how the pieces relate, what to set up, and where the gaps are.
The link already exists: it’s the constituent
A membership in Altru belongs to a constituent (and, for household memberships, to the people listed as members). Anything you know about that person, such as address, age range, or attributes you’ve defined, lives on the constituent record. So you don’t need to “attach” demographics to the membership. You need the check-in to point at the right constituent.
That’s the real job at the front desk: when a member arrives, staff should look the member up or scan their card so the visit is recorded against that constituent’s membership, rather than ringing them through as an anonymous admission. If a member walks in and staff simply sell or comp a general ticket, the visit happens but the connection to that person is lost.
Get the desk habits right first
- Scan or look up every member. Make it the rule, not the exception, even when the line is long. A card scan is faster than typing a name and less error-prone.
- Record who came, not just the cardholder. On household or dual memberships, find out how your setup records which member card holders were present. If it only captures the primary member, your attendance data will skew toward whoever’s name is on the account.
- Fix the record while they’re standing there. A returned-mail flag, a missing ZIP, or an old email is a ten-second fix at the desk and a much bigger job later.
Decide what demographics you actually need
Teams often want “demographics” without defining them, and end up asking guests too many questions. Pick a short list tied to a real use:
- ZIP code for geographic reach, tourism reporting, and funder questions. You probably already have it for members from their mailing address.
- Age group or household composition (adults, children, seniors) if programming or grants depend on it.
- A single optional question, such as first visit or how they heard about you, if you’ll really report on it.
For members, most of this belongs on the constituent record as address data or constituent attributes, collected at join or renewal rather than at every visit. Asking the same questions each time someone checks in slows the line and annoys regulars.
What about non-member guests?
Walk-up visitors who pay cash and never give a name don’t have a constituent record to hang data on. Some organizations ask for a ZIP code at the register for every sale. Whether and how Altru’s daily sales can capture that natively depends on your configuration and version, so confirm it in a sandbox or with Blackbaud support before you train staff on a process. If it can’t be stored the way you need, a simple tally or a post-visit survey is more reliable than a workaround that staff skip under pressure.
Pull it together with a query
Once check-ins are tied to constituents, the reporting is a query problem. Start from the membership or constituent side, include the scan or visit information your system records, and add the demographic fields you care about: ZIP from the primary address, any attributes, and membership level. From there you can answer questions like:
- Which ZIP codes have many members but few visits?
- Do members at higher levels visit more often?
- Which members haven’t visited since joining, and are they up for renewal soon?
Build the query against a recent, small date range first and spot-check a few members you know visited. If someone you personally scanned last Tuesday doesn’t appear, the issue is in how check-ins are being recorded, not in the query. Smart fields can help if you want a value like “visits in the last 12 months” sitting on the constituent for quick filtering, but test how they count before relying on them in a report.
Where it tends to break
- Duplicate constituents. If a member exists twice, visits may land on one record and demographics on the other. Clean duplicates before trusting any member-visit analysis.
- Shared cards. A nanny or grandparent using a household card shows up as the cardholder. Your data will say the member visited, which is true for the membership but not the person.
- Inconsistent attributes. Free-text demographic fields fill up with variations (“60+”, “Senior”, “65 and up”). Use a defined list of values wherever Altru lets you.
- Missing scans. Busy entrances wave members through. Spot-check daily member admissions against what you’d expect, and coach on it.
Privacy and consent
Collect only what you’ll use, tell people why you’re asking, and make sensitive questions optional. Age and household details are reasonable for program planning, but they shouldn’t be required to get in the door. Check your privacy policy says what you collect and how you use it.
Quick answers
Do I need a separate demographic record for each visit?
Usually not for members. Keep demographics on the constituent and let the visit point to that constituent. Per-visit questions make sense mainly for anonymous guests.
Why don’t my members’ visits show up in reports?
Most often the member was admitted without being scanned or looked up, so the visit isn’t connected to their membership. Check desk practice before rebuilding the query.
