“How many of our members actually came last quarter?” sounds like a one-line report. In Altru it usually takes a bit more work, because the answer depends on how a visit got recorded in the first place. Before building anything, it helps to know what Altru can count and what it can’t.
Start with how visits get into Altru
A visit shows up in your data only if something was recorded at the moment the member arrived. Usually that’s one of these:
- A membership card scan or lookup at admissions. If staff scan or look up the member before letting them in, that check-in is tied to the membership and the constituent.
- A member-priced ticket sale. If members “buy” a zero-dollar or discounted member ticket in daily sales or advance sales, the order can be linked to the constituent record.
- An online timed-entry reservation. If members reserve a slot through a web form, the order carries the constituent, though a reservation is not proof they showed up.
If your desk waves members through after a glance at a card, none of those records exist, and no report will find those visits. That’s worth checking before you spend an afternoon on query design. Ask a few front-line staff exactly what they do when a member walks up, and look at a handful of known member visits to see what Altru actually stored.
Find the right query source
Visit reporting in Altru almost always comes down to an ad-hoc query. The two common starting points are:
- A membership-based query. Start from memberships so every row is a membership, then add fields for check-ins or scans if they’re available in your query source list. This shape fits “visits per membership.”
- A constituent or sales-based query. Start from constituents or sales orders, filter to people with an active membership, and pull order or ticket dates. This shape fits “which members visited between these dates.”
Exactly which scan or check-in fields are exposed in query depends on your Altru setup and how your organization records admissions. I can’t promise a specific field name will be there for you. Open a new query, expand the membership and constituent nodes, and search for anything related to scans, check-ins, or attendance. If nothing obvious turns up, Blackbaud support can tell you which query view holds membership scan history, and that’s a quicker path than guessing.
Building “members who visited in a date range”
Once you know where the visit data lives, the filters are straightforward:
- Visit (or scan, or order) date is between your start and end dates.
- Membership status is active, or the membership was active on the visit date. These are different questions. A member who visited in June and lapsed in August should probably still count for a summer report.
- Membership program, if you only want certain levels or programs.
For output, include the constituent name, lookup ID, membership level, expiration date, and email. That gives you a list you can actually use for a thank-you, a survey, or a renewal push.
Watch for duplicates in the results
If a member visited five times, a raw query returns five rows. For a “who visited” list, either select distinct constituents in the query output or de-duplicate afterward in a spreadsheet. Households add another wrinkle: two adults on one membership may each be scanned, or only one may be. Decide whether you’re counting people, memberships, or households, and say so in the report title.
Building “visits per membership”
This one is a count, not a list. Start from memberships and add a summary or count of related visit records within your date range. If your query tool won’t summarize the way you want, export the detail rows (one row per visit, with the membership ID) and count in a spreadsheet with a pivot table. That’s often faster and easier to explain to the person asking.
A few judgment calls to make up front:
- Same-day repeat scans. A member who leaves to feed the parking meter and comes back may be scanned twice. Counting distinct dates per membership is usually more honest than counting scans.
- Guests and add-on tickets. If members bring guests on guest passes, decide whether those count as member visits or separate attendance.
- Special events. Member nights and previews may be recorded through events rather than general admission. Leave them out, or add them on purpose, but don’t mix them by accident.
Check the numbers before you share them
Pick a week where you know roughly how many members came, from gate counts or staff memory, and compare it to what the query returns. If the query is far lower, the gap is probably unrecorded visits, not a broken query. That’s a front-desk process issue, and fixing it (scan every member, every time) does more for your reporting than any query tweak.
Save the query with a clear name and date-range filters you can prompt at run time, so next quarter you change two dates instead of rebuilding.
Getting the results somewhere people will use them
Membership and development staff often want this data in a shared spreadsheet or an email platform rather than an Altru export they have to refresh by hand. Data Bridge syncs Altru query results to Google Sheets, Mailchimp, ActiveCampaign and other tools, so a saved member-visit query can feed a sheet or an audience list without someone exporting a CSV each time.
Quick answers
Is there a standard Altru report for member visits?
Some organizations find what they need in the built-in membership or admissions reports, but most end up with a custom query because they want specific date ranges, levels, and output fields. Check your report list first; if it doesn’t fit, build the query.
Why do some members show zero visits when I know they come often?
Usually because their visits weren’t scanned or linked to their record at admissions. A duplicate constituent record can also split one person’s history across two records.
