The Event Attendee List: What to Collect, How to Export It, and Who May See It
Every event produces the same quiet artefact: a list of people who said they were coming. It is used at the door, emailed to a caterer, printed for a table plan, queried by a sponsor, and then forgotten in a folder until someone asks for attendance numbers a year later. Most of the trouble organizers have with that list is not technical. It is that three different lists – for the door, for the report, and for everyone else – get treated as one.
This guide covers what belongs on an event attendee list, the columns worth collecting before the doors open, how to get the list out of WooCommerce cleanly, what a door volunteer should and should not see, and the privacy line between using the list and sharing it. If you sell tickets on WordPress, the whole thing is a handful of clicks once the fields are right.
SHORT ANSWER
An attendee list is one row per person, not one row per order: a four-ticket order is four attendees and one buyer. The dependable twelve columns are name, email, ticket type, order ID, ticket ID, order status, price paid, check-in status, check-in time, seat or table, custom fields, and marketing consent. Keep three views of it – a registration list for admin, a door list for check-in, and a post-event report – and export a UTF-8 CSV with ISO dates before you print or share anything.
An attendee list is not an order list
The single most common structural mistake is exporting orders and calling it an attendee list. A family of four buying in one checkout is one WooCommerce order and one payment, but four people who need four badges and four entry decisions. If your list is built on orders, your door count will be wrong on the first group booking, and your caterer will be short four meals.
So the unit of the list is the ticket holder. Somewhere between the order and the person sits a ticket: an individual, scannable record with its own ID, its own ticket type, and its own entry status. Everything useful in an attendee list follows from that: one row per ticket-holder, with the order number kept alongside as the link back to the money.
Two consequences worth planning for. Free RSVPs belong in the same list as paid tickets, otherwise your “guest list” and your “attendee list” will disagree the moment someone asks for the real total. And if you run recurring dates, the list needs a date column, because “checked in” is meaningless across a ten-night run unless it says which night.
The twelve columns worth having
| Column | Why it earns its place | Common mistake |
|---|---|---|
| Full name | The only field a human at the door will read out loud | One “name” field when tickets are bought for other people – collect per attendee, not per buyer |
| Delivery of the ticket, the reminder, the follow-up | Assuming the buyer’s email belongs to the attendee | |
| Ticket type | Determines access, price and usually the badge colour | Free-text types that become “VIP”, “V.I.P” and “vip” |
| Order ID | Links the person back to the payment and the refund | Dropping it from the door copy, then being unable to fix anything on site |
| Ticket ID / QR value | What the scanner actually validates; the unit of the entry log | Using the order ID as the ticket ID and checking in a whole group by accident |
| Order status | Paid, pending, refunded – so door staff don’t admit a cancelled ticket | Exporting mid-sale and treating pending orders as guests |
| Price paid | Reconciliation, comps, and reporting that stands up | Mixing gross and net, or ignoring the fee the buyer paid on top |
| Check-in status | The difference between sold, expected and actually arrived | Reading attendance from ticket sales |
| Check-in time | Tells you when the crush happened, which is how you staff the next door | Timestamps in the scanner’s device timezone instead of the organizer’s |
| Seat or table | Reserved seating, galas and dinner events live or die on this column | Storing the seat on the order rather than on the person |
| Custom fields | Dietary needs, accessibility, T-shirt size, member status, licence number | Collecting data you have no purpose for – see the privacy section below |
| Marketing consent | Separates “we may email you about this event” from “you may email me next year” | One consent checkbox for everything, which makes the list unusable for both |
A header row you can copy
Whatever tool you build it in, start from a header row like this and keep it stable, so exports from different events can be stacked later:
name,email,ticket_type,order_id,ticket_id,order_status,price_paid,checked_in,checked_in_at,seat,custom_fields,marketing_consentThree formatting rules save more time than any column choice: export CSV as UTF-8 so accented names survive Excel, write dates as ISO 8601 (2026-09-18T19:42), and never merge cells in a table you intend to filter. If you keep a printed copy, keep it a copy – the spreadsheet is the source of truth.
Three lists, not one
The same data serves different readers, and giving every reader the full spreadsheet is how personal data leaks into the wrong hands.
- The registration list is the admin view: everything, including order status, price and consents. It lives behind an account, not on a clipboard.
- The door list is the operational view: name, ticket type, and entry status, plus the ability to search by name, email or order number for the person who has lost their QR code. It does not need anyone’s price or marketing consent.
- The post-event report is the analytical view: sold vs checked in, by ticket type and by date, with no personal detail at all. This is the version you can share freely – with a venue, a committee or a sponsor – because it contains no one’s contact details.
Where the list lives when you sell on WordPress
If tickets are WooCommerce products, the data is already there, attached to the order. What matters is which fields are attached to the order and which to the ticket. Quantity, payment status and the buyer’s email are order-level. Attendee names, seats and anything like a dietary requirement are ticket-level, because there are four of them in a four-ticket order. Venuera calls that distinction plain: standard attendee fields for names and emails, and a custom attendee fields add-on when you need questions answered per person or per ticket type, with the answers included in the export.
Two habits keep the list trustworthy all the way to the door. First, collect attendee details at checkout rather than chasing them by email afterwards – the collection step is where the list is actually built (our guide to collecting custom attendee information at WooCommerce checkout covers the field design). Second, treat the export as the output of a system, not the system itself: CSV and PDF export is free in the Venuera core, and sales and check-in reports give you the report view without touching the personal data.
Check-in status belongs in the list – carefully
A check-in column turns a static list into a live document, and it is where a printed attendee list stops being useful. The moment entry status starts changing, a PDF on a table is wrong, and staff will update the wrong copy. Live entry status belongs in the check-in app: searchable by name or order, with the count of checked in / sold / remaining, and an undo for the inevitable mis-scan. Manual check-in with entry rules is part of the free core, and the door scanner app adds scanning with a live count.
What you give the door is the point of failure. A volunteer with your full registration export has your entire customer database and every marketing consent on a personal phone. Venuera’s answer is a Door Staff role that can open the check-in app and nothing else in the admin; the guest list itself holds names, tickets and entry status rather than prices and consents. Whether you use that or a paper list, decide in advance who may undo a check-in – if anyone can, then “already used” means nothing.
Printing the list, and printing the badges
Print the registration list in order of surname for a name-based check-in lane, and one page per ticket type if you run multiple doors. For badges, the practical route is a merged template fed by the export rather than typing names by hand: the mechanics are in our guide to exporting attendees and printing event badges. Whichever you print, mark it with a date and time in the footer – a stray printout is the most common reason door staff trust an hour-old attendee count.
What you may do with the list – and what you may not
An attendee list is personal data about identifiable people, and the rules that apply are the usual ones: collect only what you have a purpose for, tell people what you will do with it, keep it no longer than you need it, and let them see or delete it. Under the GDPR framing most organizers work with, that means a documented purpose (running this event and delivering the tickets), data minimisation in the field design, and a retention period you have actually decided on rather than “forever, because the spreadsheet exists”.
The line people cross most often is sharing. A caterer needs a count, not emails. A venue needs a technical rider, not your attendee names. A sponsor who wants “the attendee list” is asking for direct marketing access, and that needs its own opt-in, given separately and recorded – consent to hear about the event you are attending is not consent to be contacted by a partner afterwards. Where you do share, share the aggregate report view, which is why keeping that version separate from the registration list pays for itself.
If you are handling attendee data at all, read our GDPR guide for event organizers alongside this, and if you operate in a specific jurisdiction, check the local rules rather than a blog post – including this one.
If what you actually wanted was someone else’s attendee list
One clarification, because a lot of people arrive at this topic through the wrong door: lists of exhibitor or conference attendees are sold by data vendors as prospecting files. That is a different product from the list you build from your own sales, and it is also a legally fraught one – the people on it did not give you their email address, and in most jurisdictions that is what matters. If your aim is to reach new audiences, build your own opt-in list, or rent access to a space (an ad, a newsletter, an event partnership) rather than buying a file of names.
Seven mistakes that ruin a good attendee list
- Exporting mid-sale. Pending orders become attendees; refunded ones stay guests. Export after the door closes, or filter on paid status explicitly.
- Counting orders, not people. The group-booking error that shows up as four missing badges and one confused family.
- One row per order with names crammed into a cell. Unfilterable, unpivotable, unprintable.
- Consent as one checkbox. The list can then be used for neither purpose cleanly.
- Checking in from the list when a scanner exists. Manual entry is the exception path; it is how duplicates enter your numbers.
- Handing the door the full export. Prices, consents and everyone’s email on a volunteer’s phone.
- No date column on recurring events. Sales and attendance pool across nights and you learn nothing from any of them.
Frequently asked questions
What should an event attendee list include?
One row per ticket holder, with at minimum name, email, ticket type, order ID, ticket ID, order status, price paid, check-in status and check-in time, plus seat and any custom fields your event needs. Keep marketing consent in a separate column with its own value per person, and delete any column you will not act on.
How do I export an attendee list from WooCommerce?
If you sell tickets as WooCommerce products through a ticketing plugin, the plugin exports it rather than WooCommerce itself. In Venuera, attendee export to CSV and PDF is part of the free core, and custom attendee field answers are included with the custom attendee fields add-on. Export after sales close, as UTF-8, and keep the header row stable so exports from different events can be combined.
Should check-in status be on the attendee list?
Yes, but as a live field in the check-in app rather than a printed column. A printed list is stale the moment the queue starts moving and staff will update the wrong copy. Keep the printable list for name-based lanes and planning, and let the app hold entry status, live counts and the undo.
Can I share my attendee list with a sponsor or partner?
Not the personal version, not without a separate opt-in that is specific to that sharing. Consent to receive information about the event you registered for does not cover marketing from a partner. Share the aggregate report – sold, checked in, by ticket type – which contains no personal data, and if someone genuinely needs contact access, collect a fresh opt-in for that purpose and record it.
How long should I keep attendee data?
As long as you need it for the purpose you collected it for, and then no longer. Practically that means: keep the operational list while the event is live, keep the financial record as long as accounting requires, and decide a retention window for the marketing list separately – with a way to honour a deletion request. If you have not written a retention period down, you do not have one.
What is the difference between a guest list and an attendee list?
They are usually the same list read differently. A guest list is used at the door to admit people by name, so it needs entry status; an attendee list is the record of who registered, so it carries ticket type, order and payment detail. Free RSVPs and comps should appear in both, otherwise your door count and your sales report will disagree.