How do you define event data fields before connecting systems?

Imagine your ticketing report says you've sold 240 tickets. The customer database says you have 180 customers. Your email tool shows 156 people you can contact. Somebody asks which number is right, and you spend the next hour checking exports instead of planning the next event.

Those figures can describe different parts of the same event. You need their definitions before deciding whether they disagree.

Before connecting event systems, create an event data dictionary: a shared reference explaining what each field means, where its value comes from and how another tool may use it. Start with the information needed for a real decision, then document its format, permitted values, update rules and exceptions. Test the agreement against actual booking situations before anyone relies on the connection.

That sounds like a job for whoever builds the integration. Part of it is. But a developer can't decide whether your business means orders or tickets when it says sales, or whether a customer who bought for friends counts as an attendee. Those are decisions your event team has to make.

This guide explains how to make them without turning the exercise into a software project of its own. You'll get a reusable definition template, worked field records and a practical way to approve the handoff. The examples are invented to show the reasoning. They aren't claims about a particular platform's export format or results.

Start with the decision the connection must support

The first thing you want to do is describe what somebody needs to do with the data. Perhaps your marketing manager wants to exclude current ticket holders from an acquisition email. Perhaps finance wants ticket charges after completed refunds. Perhaps you're comparing admissions across a monthly workshop series before signing another venue agreement.

Each task needs different facts. The email needs a current audience rule. The financial report needs a defined amount and reporting cutoff. The venue decision needs comparable admissions and costs. A field called customer status won't answer all of them, however neatly it travels between systems.

Write the intended decision as a sentence somebody outside the setup meeting could understand. For example, "Before sending a sales email for the June workshop, exclude addresses attached to people who currently hold a valid June ticket, then apply our promotional email eligibility rules." That sentence reveals questions the field list must answer. Which event is June? What makes a ticket valid? Do you know the current holder's address? How recent must the information be?

If your systems only identify buyers, change the audience description accordingly. You can exclude known buyers using purchase records. You can't claim you've excluded every ticket holder when group guests haven't supplied their details. The dictionary should make that limit visible before marketing plans a message around an audience you cannot identify.

The UK's Government Data Quality Framework recommends defining terminology clearly, documenting data and communicating changes that affect its use. It was written for government, but those practices help an event team too. Here, you're applying them to a specific commercial task rather than adopting an entire organisational framework.

Keep the first version small. Cover the fields needed for one useful handoff and the reports or messages that depend on it. Add more when a named task requires them. Copying every available field into a shared document makes the important decisions harder to find and gives your team more information to maintain.

Separate the definition from the field mapping

A field is one piece of information, such as an order reference or payment date. Its definition explains what that information means. A mapping explains how a particular source field becomes a particular destination field. You'll need both, and keeping them distinct saves confusion when you replace a tool.

Your definition might say that original ticket charges are the admission charges after discounts, before refunds, excluding separately recorded taxes and fees. The mapping then identifies the actual source column or supported interface field that provides that amount. If your source only provides a combined checkout total, it doesn't meet that definition automatically. Record the gap and choose another supported amount or an agreed calculation.

The same definition can serve several connections. Your reporting tool and customer database may both need an event reference, although each stores it under a different name. Keep the business meaning stable and document each destination separately. Otherwise a change in one tool can quietly change what everyone thinks the field means.

You'll also need the calculation behind a reported measure. Ticket charges after completed refunds might use several fields rather than exist as a single source value. Name that measure separately, show the calculation and identify which underlying records it uses. A convenient dashboard label shouldn't hide a calculation your team has never agreed.

Our guide to connecting ticketing, customer records and email covers the wider choice of what should travel between tools. This guide focuses on the written definitions that make each handoff understandable. If you're repairing existing exports instead, use the process for cleaning event data before comparing events. Defining fields now helps prevent the same ambiguity returning with every new export.

Decide what one record represents

Before discussing column names, ask what one record describes. A purchase, a ticket, a scan attempt and a person are different things. Your dictionary should identify the kind of record a field belongs to, because the same value can become misleading when copied somewhere else.

Imagine a fictional paid workshop called Studio Exchange. One buyer places an order containing two standard tickets and one premium ticket. One standard ticket is later refunded and cancelled. The other standard ticket is transferred to another holder. The premium ticket remains with the buyer. We'll use this booking throughout the worked definitions.

You still have one original order. You issued three tickets. After the cancellation, two tickets remain valid. The transfer changes who holds one admission; it doesn't create another sale. These are separate facts your records must be able to describe at the same time.

Make the record type part of every definition. The original order amount belongs to the order. Current admission validity belongs to the ticket. A scan outcome belongs to a scan attempt. You can connect them through references, but you shouldn't add the full order amount every time a ticket or scan appears in a report.

For a series, distinguish the recurring programme from the dated event. Studio Exchange might run every month, while June's workshop has its own bookings and admissions. A shared programme name helps you compare the series. A dated event reference tells the system which purchase or arrival you're discussing. Renaming June's workshop shouldn't make it appear to be a new event.

Multi-day passes need another explicit decision. One pass may permit several daily entries. Define whether your report counts passes sold, first admissions for each day or identified people attending any day. You can use all those measures, provided their names explain the difference. Don't call them all attendance and expect the next person to infer the right meaning.

Use a definition template people can actually complete

Use one entry per shared field. A spreadsheet or ordinary shared document can work; the useful part is the agreement inside it. Don't buy another system because the reference has a technical name. Choose somewhere the event owner, finance, marketing and the implementer can read and maintain it.

For each field, complete the following information:

• Field name and readable label. Record the exact name used by the connection and a plain description people recognise.

• Meaning and purpose. Explain what the value describes and which decision needs it.

• Record type and reference. State whether it belongs to an event, order, ticket, person, payment or activity, and how that record is identified.

• Source and responsibility. Name the system that records the fact and the person responsible for resolving questions about it.

• Format and permitted values. Specify text, amount, date or another supported format, including currency, units and status definitions where relevant.

• Missing information. Say when a value may be absent, what absence means and how the destination should respond.

• Change rules. Explain when the value can change, which update governs and what history must remain available.

• Destination and use. Identify where the field goes, any conversion and what the receiving tool may conclude from it.

• Example and approval check. Include an invented or approved test value, its expected result and who confirms the result.

You don't need long paragraphs in every box. "Text; preserve leading zeros; required for each ticket" can be enough for a format rule. "Customer details" isn't enough for a purpose. Someone should know whether the field lets them find a booking, address an arrival email or produce an audience count.

Keep examples beside the rules. They make disagreements easier to spot. If finance and marketing both approve a definition of spend but produce different answers for the same example order, the definition still needs work. Resolve that while you're looking at a small booking, before the figure appears in a budget review.

If a source doesn't supply a required field, record that as a limitation. Ask the provider whether a supported alternative exists. Don't fill the box with what you hope the connection will deliver. A short dictionary with visible gaps is more useful than an apparently complete one built on assumptions.

Make references stable enough to follow a booking

An identifier is a reference that distinguishes a particular record. Your dictionary needs to say who issues it, where it is unique and whether it ever changes. A reference that's unique inside one event may repeat in another. A customer number from an older system may match an unrelated number in your current system.

For an order reference, a workable example definition is "The original reference assigned to this purchase by the named ticketing account." Record the source account alongside it where necessary. If the reference is only unique within an event, include the event reference in the matching rule. Ask the implementer to demonstrate the actual combination used to find the right record.

Here's how that becomes a usable entry for our invented workshop. "Order reference: text identifying one purchase within the stated source account. Purpose: find the original booking and connect its tickets and adjustments. Example: 000418. Required: yes. Source: the original order record. Changes: preserve the original reference; keep any destination reference separately. Destination: order reporting. Owner: ticketing operations. Missing value: hold this record for investigation. Check: all three tickets in this order link to the same order record without creating extra purchases." Your provider's actual uniqueness rules must replace the example's account-level assumption.

Preserve references as supplied, including letters and leading zeros. A reference of 000418 isn't an amount to calculate. Your format rule should prevent it becoming 418 during a spreadsheet import. Don't rely on someone remembering to change the column format after the original characters have already disappeared.

An event title, attendee name or email address shouldn't substitute for a source reference without an agreed reason. Titles change. Names repeat. A buyer can use different addresses. Matching people across addresses needs its own cautious process; it shouldn't happen accidentally because a field was labelled customer ID when it really contained an email.

The World Wide Web Consortium's Data on the Web Best Practices covers stable identifiers, origin information and version history for shared web data. Your internal event connection doesn't need to copy its publishing architecture. The relevant principle is traceability: keep enough information to identify the original record and explain where a received value came from.

Define what happens after a transfer or replacement credential. The destination may need to preserve the original ticket relationship while recording the new holder or new admission reference. The exact behaviour depends on your provider. Write the relationship you need, then confirm the supported behaviour rather than assuming every platform keeps the same identifier.

Give money fields names finance can defend

Avoid a shared field simply called revenue. Start with the actual amount you need, then describe its components. Original ticket charges, checkout amount, completed refund amount, processor charges and cash paid into the bank answer different questions. A connection shouldn't collapse them into one number because the destination only offers a convenient sales box.

For Studio Exchange, assume standard admission costs $40 and premium admission costs $70. The invented order contains two standard tickets and one premium ticket, with a $15 order discount allocated equally across the tickets under this example's pricing rules. Each standard ticket therefore carries $35 of ticket charges and premium carries $65. The original ticket charges total $135. All amounts in this example are USD; taxes and fees are excluded to keep this calculation focused.

A completed $35 refund cancels one standard ticket. Ticket charges after that completed refund are $100. The remaining standard ticket still contributes $35 and premium contributes $65. The transferred standard ticket keeps its financial history. Nothing about the change of holder increases the amount charged.

This allocation is an assumption for the example, not a rule to impose on every discount. Use ticket amounts provided by your source where available. If you must calculate allocations, finance should approve how discounts, refunds and rounding are assigned. Preserve the order total so you can check that the ticket amounts add up correctly.

A sample field entry could read as follows. "Original ticket charges: order-level amount after admission discounts, before completed refunds, excluding separately recorded taxes and fees. Currency: USD. Example value: 135.00. Source: approved ticketing order report. Missing amount: unresolved error, never zero. Owner: finance. Destination: reporting only. Check: the three allocated ticket amounts total 135.00."

Add the actual source field name during implementation. If the interface uses an integer to represent cents, document that 13500 must become $135.00 in a dollar display. This is an example conversion, not a statement about your provider's format. Confirm the units and currency before accepting the result.

Define refunds separately from admission status. A goodwill partial refund may leave admission valid. A pending refund request isn't necessarily a completed return of money. A cancellation can affect entry independently of the timing of its payment adjustment. The dictionary should let finance explain the amount and the door team explain access without forcing both into one status.

Finally, define the reporting cutoff. "After completed refunds as recorded at the report time" is different from a final settlement figure. Your ticket-charge calculation doesn't establish profit, tax treatment or bank cash. Bring those other records into the financial review under their own definitions.

Replace vague statuses with specific questions

A status field needs a subject. Payment status, ticket validity and marketing eligibility shouldn't share a definition simply because their source labels look similar. Start by writing the question each one answers. Has payment completed? Can this ticket currently admit someone? Is this address eligible for this promotion?

Next, list the exact source values and their meanings. Paid could describe a successfully completed original payment while leaving later refunds to separate records. Active might describe a contact record rather than a usable admission. Ask the provider when the label changes and what can happen without changing it.

Don't translate a source value into a stronger destination claim. If the source says issued, mapping it to paid attendee adds two assumptions: that money was received and that someone attended. Use a destination label that preserves what is known. If the receiving tool can't represent the distinction, restrict its use or choose a more suitable field.

Complimentary tickets make this easy to test. A complimentary admission may be valid and later checked in while having no ticket payment. A failed checkout may have buyer details without a valid admission. A refunded purchase may remain in order history without granting current access. Your statuses should describe all those cases without contradictory labels.

Keep a small agreed list of reporting categories if several sources need comparison, but retain each original source value. For example, you might group several confirmed source outcomes as currently valid for admission. Record which values qualify and what event conditions apply. A new source value should prompt review instead of automatically joining the nearest familiar category.

Have the responsible team approve each translation. Finance approves financial meanings. Operations approves admission meanings. Marketing approves audience use alongside whoever owns permission decisions. The person building the connection can explain its options, but the department using the field should confirm what its result allows them to do.

Define attendance with its limits attached

For Studio Exchange, suppose the two remaining valid tickets each record a successful first admission. One holder later attempts another scan. Your first-admission count remains two. A scan history can contain more activity than the number of people admitted, so importing every activity as attended would overstate the result.

Write the attendance definition around the evidence your operation records. For example, "Recorded first admission: the earliest accepted admission for this ticket to this dated workshop, including an approved manual admission recorded by authorised staff." That is a proposed definition for the example. Confirm how your door process handles manual entries before adopting it.

Record whether the field describes a ticket, a person or a daily admission. A ticket used at the door doesn't prove the original buyer attended. Nor does a missing scan establish that the holder stayed home if an entrance wasn't recording entries. Preserve those limits wherever attendance is used for customer segments or future venue planning.

A reusable entry might say, "First admission time: ticket-level timestamp of the first qualifying recorded entry. Source: check-in record. Missing value: no qualifying entry recorded yet; this alone does not establish absence. Owner: event operations. Destination: attendance reporting. Check: a later repeated scan does not create another first admission."

If operations needs a final no-show category, define when and how it is assigned. The event must have finished, relevant devices or manual records must have been reconciled, and the remaining evidence must support the category. Where records are incomplete, use an unresolved result. A campaign shouldn't describe someone as a no-show simply because a device hasn't uploaded.

For a ticket that was admitted and later refunded, preserve the admission history. Its current financial position can change without rewriting whether entry happened. This is especially relevant when your reporting tool refreshes the latest ticket status and could otherwise remove a previously recorded attendee from the event's history.

Say what dates and update times actually describe

An event date, purchase time, last-change time and import time are different fields. You may need several, but each should explain its purpose. If a refund completed yesterday and reached your reporting tool today, today's receipt time shouldn't replace yesterday's transaction time.

For exchanged timestamps, ask your implementer to use a supported unambiguous format. RFC 3339 defines an internet date and time format with an explicit relationship to Coordinated Universal Time, or UTC. Your dictionary should state the chosen format and how reports translate it into the event's reporting time zone.

For example, 2027-06-12T23:30:00Z identifies an instant in UTC; the Z indicates that reference. You still need the event's named local time zone to display its local date correctly. Don't infer the venue's zone from the buyer's address. Don't describe an offset as a complete set of future daylight-saving rules either.

Future event scheduling needs the confirmed local date, local time and named time zone, with conversion handled by supported software. The person configuring it should check the resulting display. A correctly formatted transaction timestamp doesn't resolve an incorrectly scheduled workshop.

Update rules need similar precision. Agree how a receiving tool recognises the latest valid change to a record. A delayed older update should not restore an obsolete ticket holder or promotional preference. If the source has a version number or documented update sequence, record how it governs changes. If it doesn't, ask the provider how conflicting updates are resolved.

Also decide which system may change each fact. A colleague editing a customer note in your contact tool shouldn't change whether a ticket admits someone. A purchase import shouldn't override the sending tool's later opt-out. Name the responsible source for each field and the permitted route for corrections. If two systems can edit the same fact, ask the implementer how a conflict is identified and resolved before approving that arrangement.

You don't have to design that mechanism yourself. Ask for a demonstration: make a change, make another, then show that the final record reflects the later authorised decision even when delivery is delayed. The dictionary records the expected meaning and which change takes priority. The implementation team chooses and documents a supported way to preserve them.

Treat blanks, zero and unknown as different answers

A missing value needs a rule. Zero ticket charges can describe a genuine complimentary admission. A blank amount can describe an incomplete record. If your connection replaces both with zero, the report can appear complete while understating charges. An unknown source channel needs its own category too; don't count it as a direct sale. Define whether each field is required and what happens when it isn't supplied.

For each optional field, explain why it can be absent. A current holder may not yet be named. An order may have no promotional code because none was used. A historical record may lack a reliable source channel. Those are different situations, and a single empty box shouldn't conceal them if they affect the decision.

Don't make missing information sound more certain through a destination default. Unknown sales source shouldn't become direct. An absent attendance record shouldn't become did not attend before reconciliation. An empty marketing permission field shouldn't become permission granted. Record a safe, useful response for the specific task, including when a person must investigate.

Also specify the difference between not supplied and deliberately cleared. Suppose a holder's old phone number is removed after a correction. A later update without any phone field may mean the source isn't sending that detail at all. Your destination mustn't interpret every omission as an instruction to erase an existing value, or ignore every deliberate removal. Ask how the supported connection distinguishes those cases.

Required fields should have a failure response. If an order arrives without the reference needed to match it, identify the record and send it for resolution rather than creating an untraceable purchase. Someone must be able to find the problem and know which report or audience may be incomplete while it remains open.

Keep marketing choices separate from purchase facts

Buyer, attendee and promotional recipient describe different relationships. Write separate definitions for each. A group purchase can identify the buyer while leaving guests unknown. Supplying an address for arrival information doesn't by itself explain whether you may use it to promote another workshop.

Where you record marketing permission, document the relevant address, channel, organisation and scope, along with the source, time and evidence required by your process. A broad yes or no may be insufficient if people choose particular cities or event formats. A field should explain what the choice covers before another system uses it.

Rules differ by market. The UK's Information Commissioner's Office guidance on electronic mail marketing describes consent requirements, a conditional existing-customer exception and respecting opt-outs. A purchase alone doesn't establish that the conditions are met. The guidance is marked as under review following legislation changes, so confirm the current requirements that apply to your organisation before adopting a permission rule.

For Studio Exchange, keep the purchase and any later subscription decision as separate facts. If the buyer unsubscribes and subsequently buys another ticket, the new purchase mustn't automatically reset the opt-out. If they later make a valid new promotional choice, preserve its scope and evidence rather than treating every newer customer edit as a resubscription.

An example entry could say, "Promotional eligibility: the result of applying our current sending rules to this address for this organisation, channel and message scope. Source: approved permission and opt-out records. Missing evidence: exclude from this promotional audience pending review. Owner: marketing operations. Check: importing an earlier order does not reverse a later opt-out."

That's a proposed operational definition, not a universal legal formula. Your sending tool may already handle eligibility and exclusions. In that case, use its supported process and document what the receiving tool needs, rather than rebuilding the same rules in a spreadsheet. Our ticket-checkout consent guide explains the wider collection and evidence questions.

If your job is emailing buyers already in Loopyah, start with the attendee email tools. They keep buyer contacts and purchase-based audiences connected and distinguish event updates from promotions, with promotional opt-outs handled in the sending process. You still choose an appropriate message and audience. A separate database needs a specific additional job to justify another transfer of those facts.

Don't assume that using a built-in tool proves an external connection exposes the same fields or applies identical rules. Check each proposed handoff. The dictionary should state what has been verified for that connection and where someone must use the original system to make the decision.

Include access and retention in the field definition

Available doesn't mean necessary. Your reporting connection might need order references, currency and amounts without needing attendees' phone numbers or individual access requests. Start with the destination's purpose, then remove fields that don't contribute to it.

Under the UK GDPR, the ICO's data minimisation guidance explains that personal information should be sufficient and relevant for its purpose without exceeding what's necessary. That guidance is also marked as under review. For your dictionary, record why a personal field must reach a particular destination instead of copying the whole booking because it's convenient.

Describe who needs access. The person tracing a payment discrepancy may need a controlled link to the original order. A programme manager comparing attendance totals usually needs the counts and their definitions. A sponsor receiving an event summary doesn't automatically need the underlying attendee list. Make those uses explicit before a shared export becomes the default source for everyone.

Add a retention rule or a reference to the policy that governs it. Different records may have different purposes and requirements. Don't give all customer details the lifetime of financial records merely because they once appeared in the same order export. Equally, don't erase required financial evidence because a marketing list has been cleaned.

Use invented values in the dictionary's examples. The definition document explains the system; it shouldn't become another attendee database. Put any real test evidence in an appropriately controlled location and link to it only where authorised reviewers need it. That also makes the template easier to share with a new provider without distributing customer information.

Map the meaning into each destination

Once definitions are agreed, create the implementation mapping. For every destination field, name the actual source field, the rule applied and the expected result. Have the implementer complete the exact interface names after checking the provider's current documentation and your account's supported behaviour.

For Studio Exchange, an order reporting mapping might read, "Take original ticket charges and subtract completed ticket refunds in the same currency. Store the result once per order. Preserve the original amount and refund records separately. Example: 135.00 less 35.00 gives 100.00 USD." The receiving report should describe that result as ticket charges after completed refunds, not profit or bank receipts.

An admission mapping might read, "Take the current validity of each original or replacement admission according to the provider's documented relationship. Keep cancelled admissions out of current valid inventory. Keep recorded first entries in the attendance history." Those two outputs need different fields because a current inventory view and a historical attendance view answer different questions.

A buyer audience mapping might read, "Identify known buyers of the dated event using completed purchase records, with the agreed treatment of fully refunded orders. Use current promotional eligibility before sending a promotion." Finance gets order amounts, the door gets admission validity, and promotions need purchase and permission facts. Keep those uses separate.

If your actual aim is reaching current holders, require holder information instead. Don't approve a buyer mapping under a holder label.

Write any unsupported requirement beside the mapping. If the destination only stores one event per contact, it may overwrite the previous workshop when the person buys again. That limit matters for a series. Either use a supported relationship that preserves multiple purchases or restrict what the contact field is used to claim.

Similarly, an email tool's tag may store a historical fact such as bought June workshop. It won't necessarily update itself after a refund. Record who or what maintains it, when it is refreshed and whether a campaign checks the current source before sending. A tag with no update rule is a snapshot, even if its name sounds current.

Where Loopyah ticketing already handles orders, tickets and QR check-in, use those supported records for their existing jobs. The dictionary helps your team interpret what another tool receives; it doesn't require rebuilding ticket operations outside the platform. Verify any external export or integration capability separately before including it in the mapping.

Approve results with a small set of worked cases

Don't approve the dictionary only by reading its definitions. Ask somebody who wasn't in the setup meeting to apply them to a small set of supported test bookings. They should be able to explain the expected records and totals without relying on your memory.

Begin with Studio Exchange's original order. The expected result is one order, three issued tickets and $135 of original ticket charges under the stated assumptions. After the completed refund and cancellation, expect $100 of ticket charges after refunds and two current valid tickets. After the transfer, expect the new holder relationship without an additional order or sale.

Then check the two first admissions and the repeated scan. Attendance reporting should show two qualifying first entries for this workshop, while the activity history retains the extra attempt. If the receiving report counts three attendees, find which definition or mapping allowed a scan attempt to become another admission.

In separate test cases, add a complimentary ticket, a failed payment and a missing amount. Each should produce its specified result without being forced into the same category. Then test an opt-out followed by a new purchase and an import of older information. The permission result should follow the approved rule, not whichever file happened to arrive last.

Keep the expected result and observed result together. Where they differ, name the field, the consequence and the person resolving it. An incorrect currency unit blocks financial use. Missing holder addresses limit an audience description. An outdated permission rule blocks promotional use. Those are more useful outcomes than saying the integration mostly works.

You can approve a narrower handoff when a limit is understood. For example, finance may accept a verified order report while marketing waits for a permission issue to be fixed. Record which use is approved and which remains restricted. Don't let approval for one report become implied approval for every campaign using the same connection.

Keep definitions current as the programme changes

A field definition needs an owner and a version date. So does the mapping that implements it. When someone changes a ticket package, adds a new sales channel or replaces an email tool, review the affected definitions before the new records reach a report or campaign.

Explain changes in ordinary language. "From July, premium admission includes a materials pack that was previously sold separately" tells finance why comparisons need checking. "Status updated" doesn't. Record whether a change affects only new bookings, changes existing records or requires a separate historical reporting rule.

Don't quietly apply today's definition to older records that can't support it. If earlier events didn't record manual admissions, a new attendance definition doesn't recover those missing entries. Preserve the historical limit and identify which periods can be compared on the same basis.

Before your next connection goes live, choose one awkward booking and ask finance, operations and marketing to explain it using the dictionary. They should agree on the original purchase, the current admission position and the messages that may follow. If their answers differ, revise the definition or mapping while the consequences are still contained to a test record.

Then give the person implementing the connection the approved definitions, destination mappings and worked checks. Ask them to show those results in the receiving system. Approve the handoff when the results match, with any remaining limits recorded for the people using it.