A longtime member buys two tickets online. She types her name the way she always does, uses the same email address she has had on file for ten years, and checks out. The next morning there are two of her in Altru: the original record with her membership history, and a brand-new constituent holding last night’s ticket order. Same email, same person, two records.
That outcome surprises a lot of administrators, because email feels like the most reliable identifier a guest gives you. Here’s how matching on online transactions generally works in Altru, why email doesn’t always carry the weight you’d expect, and what you can do about it.
What happens when a web transaction comes in
When someone completes an Altru web form (a ticket purchase, membership join or renewal, or donation), Altru has to decide whether that person already exists as a constituent. It compares the incoming details against existing records using its duplicate-matching rules. If it finds a confident match, the transaction attaches to that record. If not, it creates a new constituent.
The key point: matching tends to lean heavily on name and address. Email may be stored on the record, and may or may not contribute to the match depending on your version and configuration, but in practice many organizations find that a matching email alone does not keep a new record from being created when the name or address differs.
We’d rather be plain than guess here: the exact criteria and how they’re weighted can depend on how your Altru environment is set up. Your administrator settings for duplicate checking are the place to look, and Blackbaud support can tell you definitively how your instance scores email.
Why the same person slips through
Small differences on the form are usually the cause. A few common ones:
- Name variations. “Kate” online, “Katherine” on the record. “Bob and Linda” in the first name field.
- A new or partial address. The guest moved, typed a billing address that differs from the household address, or left off an apartment number.
- Someone else paying. A spouse buys tickets with their own card and name but the shared family email.
- Forms that collect very little. If a quick ticket form asks only for name and email, there may not be enough address data for a confident match at all.
Each of these makes sense from the guest’s side. From Altru’s side, a different name or address looks like a different person, even when the email is identical.
Test it before you change anything
The fastest way to learn how your instance behaves is a small, controlled test, ideally in a sandbox or with clearly labeled test records you delete afterward.
- Create a test constituent with a full name, address, and email.
- Submit a web transaction with the exact same details. Confirm it attaches to the existing record.
- Submit again with the same email but a nickname. Note the result.
- Repeat with the same name and email but a different address.
- Repeat with only name and email, no address, if any of your forms allow that.
Write down which cases create duplicates. That small table tells you more than any general explanation, including this one, and it gives you something concrete to bring to Blackbaud support if the results don’t match what you expected.
Reducing duplicates at the front end
- Collect enough to match on. If a form skips address fields to keep checkout short, you’re trading speed for cleanup later. Decide that deliberately rather than by default.
- Keep form labels clear. “Name of the person attending” and “Name on the card” are different things. Ambiguous labels produce mixed-up records.
- Review your matching settings. If your configuration lets you adjust duplicate criteria, check whether the current thresholds suit how guests actually fill in forms. Change them carefully; looser matching can merge two genuinely different people.
Cleaning up what gets through
Even with good forms, some duplicates will land. A simple routine keeps them from piling up:
- Build a constituent query that groups records by email address and returns any email shared by more than one constituent. Run it weekly.
- Also look at records created recently by online transactions with no other giving or membership history. New one-off records are often duplicates of someone you already know.
- Before merging, check households and spouses. A shared family email doesn’t always mean one person, and merging two real people is harder to undo than leaving a duplicate.
- Agree on which record survives (usually the one with the longest membership or giving history) so staff merge consistently.
The email-based query matters because it catches exactly the cases name-and-address matching misses.
Where Social Good fits
If the weekly review turns into a long list, Deduper is built to find and fix duplicate constituent and email records in Altru, so staff aren’t working through query results one record at a time. The front-end steps above still matter; fewer duplicates coming in means less to clean up.
Quick answers
Will a matching email always link a web order to the right constituent?
Not reliably. Name and address differences can still produce a new record. Test your own instance to see how much weight email gets.
Should we merge every record that shares an email?
No. Families and couples often share one inbox. Review each pair before merging.
