An event registration form should collect what you need to reserve a place, send the attendee their joining details, and reconcile the booking afterward. Keep attendee identity, ticket type, registration source, and permissions in separate fields, so whoever opens the export later can tell them apart.

Use the field decisions below and download the [event registration form CSV](https://eventiq.io/templates/event-registration-form.csv). No email required. It contains the field dictionary, data-purpose review, test cases, and a hypothetical reconciliation example; it is a planning worksheet for your existing registration system.

## Which fields should be visible to the registrant?

Start with the attendee's name, contact email, and ticket or participation choice. Add a question only when a named team will use the answer for a specific task. If the form owner can't say what the answer changes, cut it.

Separate the attendee from the person paying or booking. A team administrator may buy places for colleagues and never attend. Copy the buyer's email into every attendee row and matching attendance later turns into manual detective work.

Ask for company and role only when you will use them. An invitation-only program may need them to check eligibility or prepare a discussion. A sales team that might want them someday is no reason to make them mandatory.

Anything you don't need to reserve the place can wait for a later operational email. Travel details, optional profile content, and session preferences may have a different deadline anyway. Name an owner for that later collection, or nobody asks for the postponed field.
| Field | Purpose | Collection choice |
| --- | --- | --- |
| Attendee name | Identify the person expected at the event | Visible; use the name needed for delivery |
| Attendee email | Send access details and reconcile the attendee record | Visible; distinguish it from the buyer's email |
| Ticket type | Record the entitlement or participation category | Visible choice or assigned from the selected offer |
| Organization and role | Eligibility or program preparation | Ask only when the event requires them |
| Access or dietary request | Arrange an operational response | Provide a suitable route with restricted handling |
| Optional marketing choice | Record a separate communication preference | Use wording approved for the intended audience and purpose |
| Source question | Capture the registrant's own account of discovery | Keep separate from technical campaign fields |
Open the export as well as the visible form. A question that reads clearly on screen can arrive as a cryptic column heading. Before launch, give each field a stable internal name and a readable display label in the field dictionary.

## Which fields belong in the record without another question?

Let the registration system record the event ID, registration ID, creation timestamp, and current registration status. Nobody should have to type an event code you already know. If the event is renamed, the IDs stay the same.

Store ticket type, price paid, currency, and complimentary status as separate fields. A zero amount could be a free ticket, an authorized comp, a pending payment, or a test, and the price column alone won't tell you which.

For group purchases, keep an order ID and a separate attendee ID. Log cancellations and transfers as changes with their effective dates instead of deleting the row that proves the booking existed. Your report then has a defined basis for net registrations.

Fill campaign fields from the tested registration path where it carries them, and leave a missing value visibly empty. Writing "direct" into a blank source field invents an explanation for evidence you don't have.

Don't assume every field reaches every downstream tool. Ask the integration owner to push a test record through the export or connection and show you what arrives. The worksheet lists the records your process needs; whether a particular connector carries them is a separate check.

## How should you capture the registration source?

Keep technical tracking and the registrant's own answer in separate columns. A campaign parameter tells you which link was used on the way to the form, and a self-reported answer tells you what the person remembers. The two can disagree without either being a data-entry error.

The [how-did-you-hear-about-us question guide](https://eventiq.io/md/blog/how-did-you-hear-about-us) covers wording and answer options. Put the question on the form, but don't read the answers as a full account of everything that influenced the decision.

Test the whole path, from an invitation or ad through any intermediate page and the payment step, then check what landed in the registration record. A parameter you saw in the first address bar may be gone by the time the registration completes.

Keep personal information out of campaign values and URLs. A campaign name identifies an activity and should never contain an attendee's email or name. Write the naming convention into the worksheet so the next campaign owner uses the same definitions.

## How do you handle complimentary places and group bookings?

Add a comp reason and an approval reference next to the ticket type. Finance can then tell speaker, sponsor, staff, and other authorized places apart without guessing from the price, while the ticket label the attendee sees stays plain.

The [cost of complimentary registrations](https://eventiq.io/md/blog/comped-registrations-cost) depends on what goes into the denominator and the cost base. Classify each comp at registration, while the reason is known, instead of reconstructing it from someone's memory after the event.

On a group booking, let the buyer mark which attendee details are still outstanding, and give the event team a controlled way to fill them in before access details go out. Don't copy one person's profile into every place just so the export looks complete.

Decide how substitutions work before you need to. The new attendee needs the right access details, and the person they replace should drop out of the active count. Update the attendance roster but keep the payment and order history attached to the booking.

## What should the form say about data use?

Tell registrants in plain language what their information is for, who runs the event, and where the privacy notice is. Whoever is responsible for privacy should approve that wording for the audience, the location, and the intended uses.

Keep optional marketing choices apart from the information you need to deliver the event. Sponsor contact, directory listing, and general newsletters are separate purposes, and each needs its own decision in the form design. Buying a ticket doesn't grant permission for all of them.

Where your approved process requires the evidence, record the wording version, the choice made, and when it was made. Otherwise a later export collapses different choices into one unexplained "yes." The [event data consent guide](https://eventiq.io/md/blog/event-data-consent) covers the wider review.

Access and dietary requests need an owner on the operations side and a policy on who can see them. Collect what that owner can act on, skip detail they don't need, and give people a contact for questions. Don't send the full export to every team that needs part of it.

## What does a clean registration reconciliation look like?

Take a hypothetical workshop with 120 active attendee registrations at the reporting cutoff: 90 paid places at $200 each and 30 complimentary places. The source fields show a recorded source for 102 registrations and none for 18. These are invented worksheet inputs.

**Hypothetical active registrations = 90 paid + 30 complimentary = 120**

**Gross paid ticket amount = 90 × $200 = $18,000**

**Recorded-source coverage = 102 ÷ 120 × 100 = 85%**

**Unrecorded-source share = 18 ÷ 120 × 100 = 15%**

The $18,000 is the gross ticket amount in this simplified example. Fees, refunds, and tax have to be dealt with before you call any of it net revenue. The coverage percentage tells you how much of the file has a source value. It says nothing about whether those values capture every influence on registration.

The CSV keeps ticket reconciliation and source coverage in separate rows because they measure different things. You can't tell how many paid registrations came from a given channel unless some record links payment to source. Separate totals won't fill in a missing cross-tabulation.

When you get to attendance, reconcile the roster against attendance evidence first, because a valid registration doesn't show that anyone turned up. The [event check-in process](https://eventiq.io/md/blog/event-check-in) keeps that arrival record linked to the original registration. Leave unresolved identities visible so the final report can say what matched and what didn't.

## How should you test the form before opening registration?

Make a complete booking on a phone and on a desktop, and check labels, required-field instructions, errors, the confirmation, and the export. Then try the awkward cases: an invalid email, a skipped required answer, an authorized comp, and a group booking with attendee details missing.

Every control needs a visible label, and people should know what is required before they submit. When an error occurs, keep the valid entries and tell the person how to fix the field that failed. The [W3C guidance on form instructions](https://www.w3.org/WAI/tutorials/forms/instructions/) explains why instructions need to stay available while people fill in a form.

For the source path, register through a tagged invitation and check the completed record. Then register without any campaign information and confirm the gap still shows as missing. Test each privacy choice on its own, since one successful submission doesn't cover every path.

Last, reconcile the test transactions against the reporting file and label or remove test records through your approved process before launch. Write down the field owner, where the export lives, and who signs off the registration process, so the next change has somewhere to go.

## Where EventIQ fits

EventIQ replaces nothing. It connects on top of supported event, CRM, and marketing platforms. Cvent and Eventbrite registration records can carry the registration date, ticket type, and price where the platform provides them, together with attendance information. Check source coverage on your own account before you rely on a field.

For Zoom, EventIQ holds attendance and time in session per participant, plus each webinar's registrants with name, email, and registration date. From Eventbrite, answers to custom order questions do not arrive. The extra fields and permission records from your form stay in the systems that collect them, so check what reaches each connected source.

[Book a demo](https://eventiq.io/#early-access) to see registration dates, ticket types, and attendance records on a sample event, in a 30-minute demo.

---

HTML version: https://eventiq.io/templates/event-registration-form