A family buys four general admission tickets and a plush otter from the gift shop. A week later, someone in development pulls a list of donors for a year-end appeal, and that family is on it, right next to people who wrote real checks. Nobody on that list is wrong in Altru’s eyes. It’s just that “donor” in your database and “donor” in your development office mean different things.
This article covers why that gap shows up, how to confirm what is actually driving donor status in your Altru database, and how to build a definition of “donor” that only counts philanthropic revenue.
Where the problem comes from
Altru keeps every kind of revenue on the constituent record: daily sales, advance sales, group sales, memberships, merchandise, donations, and pledge payments. That’s useful for seeing the whole relationship. The trouble starts when a constituency, a smart field, or a saved query labels someone a “donor” based on any revenue instead of only gifts.
Depending on how your database was set up, there are a few common culprits:
- A constituency applied automatically from revenue. Whether Altru assigns a donor-type constituency on its own, and which transaction types trigger it, isn’t something we’d assume. It can vary with configuration and with how your implementation was done.
- Smart fields such as “total giving” or “last gift” that were built on all revenue rather than donation revenue only.
- Older queries and selections that filter on “has revenue” or “revenue amount greater than zero” without filtering by revenue type or designation.
- Imports or batches where staff added a donor constituency by hand to anyone who paid for something.
Step one: find out what’s actually tagging people
Before changing anything, pick three or four constituents who are labeled donors but have only ever bought tickets or merchandise. For each one, look at:
- The constituency entry itself. Note its start date and compare it to their transactions. If the start date matches a ticket purchase, something is applying it automatically or through a batch.
- The revenue history. Confirm there is no donation, pledge, or gift-designated payment hiding in there, such as a round-up or an “add a gift” line at checkout.
- Any smart fields shown on the record, and how each one is defined.
If you can’t tell whether Altru itself added the constituency, test it. In a sandbox or training database, create a new constituent, sell them a ticket only, and check the record afterward. If you don’t have a test environment, Blackbaud support can tell you whether a constituency in your database is system-assigned and what rules it follows. That answer decides whether you’re fixing a setting, a process, or just a report.
Step two: define “donor” by revenue type, not by revenue
The most dependable fix is to stop relying on a single flag and instead define donor status from the revenue that qualifies. In practice that means building it from donation revenue and gift designations, and leaving out sales and membership dues unless your policy says otherwise.
A clean setup usually looks like this:
- A donor query that includes constituents with donation or pledge payment revenue (optionally limited by designation or date range) and ignores daily sales, advance sales, group sales, and merchandise.
- Giving smart fields (lifetime giving, last gift date, last gift amount) built on that same donation revenue, so the numbers staff see on the record match the definition.
- A decision on memberships. This is the part teams argue about. Some organizations count membership dues as giving, some count only the portion above benefits value, and some count none. Decide, write it down, and build the query to match.
Once the query is right, use it as the source for appeals, acknowledgments, and donor reports. If you also want a constituency on the record for visibility, you can apply it from that query in a batch or update on a regular schedule, so it’s driven by your definition and not by whatever someone bought.
Step three: clean up the people who were mislabeled
Run your new donor query and compare it to everyone who currently holds the donor constituency. The people in the second group but not the first are your cleanup list. Before ending or removing anything in bulk, export the list, have development review a sample, and snapshot what you’re about to change. A few of them may be legitimate donors whose gifts were recorded incorrectly as sales, and those are revenue fixes, not constituency fixes.
For constituents you do update, ending the constituency with a date (rather than deleting it) keeps a history of what happened, which helps if someone later asks why a household dropped off a list.
Keep it from coming back
- Train the desk. Staff at admissions and the shop shouldn’t be adding constituencies at all. If they ask a guest about giving, the gift should be recorded as a donation, separate from the ticket.
- Retire old queries. Search your shared queries for anything named “donors” and check how each one is filtered. Archive the ones built on all revenue so nobody pulls from them by accident.
- Review the definition once a year. New revenue streams such as events, rentals, and add-on gifts at checkout tend to blur the line. A short annual check with development and finance keeps everyone counting the same way.
Quick answers
Can I tell Altru to never count ticket revenue toward donor status?
We wouldn’t promise there’s a single setting for that. Confirm with Blackbaud support or test in a sandbox. Either way, a donor definition built on donation revenue in your queries and smart fields gives you control regardless of how the constituency is applied.
Should a membership purchase make someone a donor?
That’s a policy choice, not a technical one. Agree on it with development and finance, then build your query to match.
