Someone in marketing asks for “everyone who bought tickets online last month, with their email.” It sounds like a five-minute job. In Altru it can turn into an afternoon, because the information is there but spread across the order, the constituent record, and the way your web forms create records. This guide covers where the data actually lives, how to build a query that returns it, and the details that trip people up.
Start with where the data ends up
When a guest checks out through an Altru web form, two things matter for reporting:
- The sale itself (the order and its tickets, items, and payment), which carries information about how and when it was sold.
- The constituent the sale is attached to. Names and email addresses live here, not on the ticket.
So the job is not “report on the web form.” It’s “find the orders that came from the web, then pull the names and emails of the constituents tied to them.” Once you think of it that way, the query is much easier to design.
Building the query
Altru’s query tool lets you pick a source view and then add fields from related records. Exact view and field names differ depending on your version and how your database was set up, so treat the steps below as the shape of the query rather than a literal click-path.
- Pick a sales-oriented source. Start from orders or revenue rather than constituents, so each row represents a transaction you can filter by date and channel.
- Filter to online sales. Look for a field that identifies the sales method, channel, or originating web form. Add a filter for your web sales only, plus a date range.
- Narrow by what was sold, if needed. If you only want a specific event, program, or ticket type, filter on that too.
- Add the constituent fields. Navigate from the order to its constituent and add name and primary email address. Include the constituent’s lookup ID so you can spot duplicates and match records later.
- Return distinct rows. A family buying four tickets in one order, or a member who buys three times a month, can show up repeatedly. Turn on the query’s option to return only distinct rows, and keep the output to person-level fields (no ticket or line-item fields) so each buyer appears once.
Run it against a short date range first and spot-check a handful of rows against the orders themselves. If the numbers look wrong, the channel filter is usually the culprit.
Things that make the list less clean than you’d expect
Guest checkouts and duplicate constituents
Depending on how your web forms match incoming buyers to existing records, a returning visitor may land on their existing constituent or get a brand-new one. If matching is loose, the same person can appear under two or three records with slightly different names or emails. Including the lookup ID in your output makes these easy to see. If you find a lot of them, deal with the duplicates in Altru before the list goes anywhere else.
The purchaser isn’t always the visitor
The email on the order belongs to whoever paid. For a birthday party or a school group, that’s one adult buying for many guests. Your list is a list of buyers, and any follow-up should be written with that in mind.
Communication preferences
Before using the list for anything promotional, filter out constituents who have opted out of email or carry a solicit code that rules out email contact. Add those preference fields to the query and exclude them there, rather than relying on someone to clean the spreadsheet afterward. A transactional message about the visit itself is a different case from a marketing email, and your policy should say which is which.
Missing or bad emails
Web purchases usually include an email if your checkout asks for one, but records that came in through other paths may not. Add a filter for “email address is not blank,” or keep blanks in and treat them as a separate list for data cleanup.
Saving it so you only build it once
Once the query works, save it with a clear name and swap the fixed date range for a relative one (for example, the previous 30 days) if your query options allow it. That turns a one-off ask into something anyone on the team can run. If you aren’t sure whether a particular relative date filter is available on the source you chose, try it in a copy of the query before changing the original.
From there, you can export to CSV for a one-time send, or use the query as the selection behind an Altru communication. If the same list is needed every week, put that on the calendar instead of waiting for the next ask.
When the export becomes the real problem
The query itself is usually a one-time build. What wears people down is the repetition: run it, export it, fix the columns, upload it to the email platform, and do it again next week. Our Data Bridge syncs Altru query results to Google Sheets, Mailchimp, ActiveCampaign, and other tools, so a saved web-buyer query can feed your email list without the manual export step. The query design above still applies; Data Bridge just moves the results.
Quick answers
Can I report on a single web form?
Often yes, if your sales data records which form or channel the order came through. Check what fields are available on your sales source view; if nothing identifies the form, filtering by the events or items that form sells is a reasonable stand-in.
Why does my list have more people than orders?
You’re probably returning one row per ticket or line item. Remove line-level fields from the output and return distinct rows only.
Why does my list have fewer emails than buyers?
Some constituents have no primary email, or the email lives in a non-primary slot. Check a few affected records to see which.
