Event data management is the practice of deciding which event records you keep, who owns
each field, how records connect, and when someone checks the result.

Start with the records,
not the dashboard. A registration, a check-in, and a deal can each be correct in its own
system while the report assembled from them is wrong. A reviewer needs to trace a figure
back to its definition and source.

This guide is for the person responsible for those rules and the exceptions that follow.
For measurement choices, use the [event marketing analytics guide](https://eventiq.io/md/event-marketing-analytics).
For the handoff, use the [post-event report template](https://eventiq.io/md/blog/post-event-report-template).

## What is event data management?

Your systems will not agree merely because they feed the same chart;
[event data silos](https://eventiq.io/md/blog/event-data-silos) sets out the four reasons they differ. Decide what an event
is called, which source owns each field, which identifier connects records, and what happens
when that identifier is missing. Set the point at which a figure is ready for a budget or
board discussion.

Keep the decisions beside the report and name their owner. If someone asks why the
registration count changed, point to the source records and the rule used for that report.
If a field has no owner, mark it unresolved. A blank cell with an explanation beats a total
built from a guess.

A field dictionary and an exception list are enough to begin. Ask a colleague to repeat
your joins. If they get a different set of records, the rule still needs work.

## What are some examples of event data?

Different teams collect different records. Keep the record type and its unit visible:
a person who registered is not automatically a person who entered the venue.

| Record | Typical home | Grain to preserve | Question it can answer |
|---|---|---|---|
| Event definition | Event operations calendar | Event | Which program and date does this record belong to? |
| Registration | Registration platform | Registration record | Who submitted a registration, and when? |
| Presence | Check-in or webinar platform | Presence record | What evidence of participation was captured? |
| Session activity | Engagement platform | Participant activity | Which session, question, poll, or booth activity was recorded? |
| Campaign expense | Marketing platform or budget file | Campaign or expense line | Which channel incurred the spend? |
| Deal | CRM | Deal | What stage and close date does the sales team hold? |
| Invoice and venue cost | Finance ledger | Cost line | Which costs belong in the approved event budget? |

The table is an inventory, not a claim that one tool collects every row. Mark the records
your team actually has. For each source, name someone who can explain a status change or
correct a bad value. Finance may close its ledger after the first event report; label that
report provisional rather than filling the gap with a guess.

For session activity, retain the source, timestamp, and original platform response. A
summary count cannot show whether an answer was absent or left outside the extract.

## Where should each event record live?

Leave the original record with the team that corrects it. Event operations fixes a
registration status in the registration platform; sales operations corrects a deal stage
in the CRM; finance approves costs in its ledger. The report refers to those records.

Map each record type to its source system, identifier, status field, owner, and review time.
Label each working copy with its reporting period and preparer. A reconciliation sheet is
not automatically the source of truth.

Suppose an event manager corrects a check-in after the first report. The next version needs
the corrected source record and the attendance extract it used. Otherwise finance sees two
totals with no explanation. Keep the discrepancy and its resolution in your working file;
do not assume the reporting tool has a place for them.

## Which identifiers can connect event records?

Use a key only for the relationship it proves. An event ID assigns a record to an event;
a registration ID links a status update to a registration. Email can link a participant
record to a contact under an agreed rule. A campaign ID ties expense to a campaign; an
approved mapping ties that campaign to the event. None is a universal person ID.

Record the key, issuing system, and scope in the field dictionary. A blank, mistyped, or
shared email stays an exception. Similar names do not prove that 2 records refer to the
same person. Leave that judgment to a documented rule and a person who can check it.

Keep the participant record even without a contact match, and distinguish an unmatched
email from a missing one. If the event team corrects an address, compare again against the
corrected source record. A matched group is not necessarily everyone who attended.

## Who owns each event data field?

Name an accountable role for every reported field. That person need not enter each value,
but must settle disputes about its definition.

| Field or rule | Accountable role | Decision the role makes |
|---|---|---|
| Event name and event identifier | Event operations | Which records belong to this event and which event date is official? |
| Registration status | Registration owner | Which submissions are valid for the report? |
| Presence status | Event operations | What evidence qualifies as attendance for this event? |
| Campaign naming and channel | Marketing operations | Which expense lines belong to each campaign and channel? |
| Deal stage and close date | Sales operations | Which CRM record and status are current? |
| Cost categories and reporting period | Finance | Which invoices are approved and when they enter the budget? |
| Event-to-campaign relationship | Event owner with sales operations | Which campaign is the approved link for the event? |

Give each owner a precise question. "Check the data" is too vague. "Are cancelled
registrations excluded from this export?" can be answered against source records. Settle
the definition before it reaches an executive report.

## What should count as the source of truth for each field?

Choose the source of truth field by field. The registration platform may own submission
time, the check-in system evidence of presence, the CRM a deal's stage, and finance an
approved cost. One platform cannot settle all those definitions.

Write down the source, definition, allowed values, timezone or currency where relevant,
and report cutoff. State which corrections reopen a published figure. A late check-in
correction might change a provisional operational report, while a newly approved cost
line may wait for the next finance close.

Keep unresolved values distinct: "no email," "email with no CRM match," and "campaign
not approved for this event" send work to different owners.

## How should you name events and campaigns?

Use an event identifier that survives a title edit. Put it on the event calendar,
registration export, budget file, and campaign map where possible. If a source cannot
carry it, map that source's local event ID explicitly. A similar title is not a join key.

Campaign names should identify the event, channel, and period to a reader; keep the source
campaign ID separately. If a campaign serves 2 events, ask whether its spend can be
separated at the source. If it cannot, hold it unassigned until the marketing owner
approves a rule. Copying the same expense into both event reports inflates the portfolio.

Retain old names in the mapping document so a later reader can explain a renamed campaign.

## How do you match event attendees to CRM contacts?

Start with the participant record's email. Compare the exact address with the CRM contact
email. Record the outcome: matched, unmatched, or no email. If the source address contains
a mistake, ask its owner to correct it and then compare again. Keep the original source
value available so the correction can be checked against what arrived.

The match does not mean a person had only one event interaction. Registration and presence
are separate records; if their addresses differ, both may not match. Label the population
used in each analysis.

The contact match and the event-to-campaign map answer different questions. Keep the
campaign approval with the working definition; do not assume that every deal under a
contact belongs to the event. The [Salesforce integration guide](https://eventiq.io/md/integrations/salesforce)
explains the deal, stage, and close-date records available for this review.

## Why don't registration and attendance numbers match?

They count different records. A submitted registration may be cancelled or left unused;
presence depends on check-in or webinar evidence, and
[event attendance tracking](https://eventiq.io/md/blog/event-attendance-tracking) covers what each kind proves. The exports may also have different
cutoffs. Define which population each report shows and verify it against the source.

Label submitted registrations, valid registrations, and recorded presence separately.
Keep the source cutoff with the report. If you need a rate, agree on its numerator and
denominator before dividing. A missing presence record stays missing until its owner
verifies it.

If the lists still differ after the cutoffs agree, record the unresolved rows and their
owner in the reconciliation sheet below.

## How and when should you reconcile event records?

Set the review cadence around decisions, as
[event reporting](https://eventiq.io/md/event-reporting) does for each reader. During promotion, check event IDs, campaign
mappings, and registration status before planning meetings. After the event, compare
registration and presence exports before the first report. Recheck campaign expense at
marketing close, deals at sales operations close, and approved costs at finance close.

Use the same worksheet each time: report period, source extract and time, field
definition, unresolved records, owner, decision, and next review. "CRM differs" is not
enough. List the records or campaign IDs involved. Keep resolved exceptions visible so
the next reporting period does not reopen them without context.

Check the rows most likely to invalidate the report. Does each presence record point to
the intended event? Is a cancelled registration in the valid set? Is a campaign expense
assigned twice? Does a deal appear through an approved campaign map or a guessed name?
Look at the source rows, not just the chart.

If an exception remains at the deadline, publish its status beside the affected figure.
Name the incomplete source and the person who will revisit it. A provisional report with
an explicit exception is easier to defend than a final-looking figure with a hidden guess.

## What should a reviewer receive with the report?

Give the reviewer the report and its definitions together: event ID, source of each
material field, registration and presence populations, approved campaign map, reporting
cutoff, and unresolved exceptions. Name an owner and next review date for each exception.
The reviewer can understand a figure without access to every system; its owner must still
be able to retrieve the source record.

If a figure changes after circulation, issue a corrected version stating which source
record changed, who approved it, and which report lines moved. Keep the old version for
people who already used it. This is a team procedure, not a product feature.

## Where does EventIQ fit?

Registrations and attendance stay separate records. Contacts are matched by exact email,
and every participant record keeps its result: matched, unmatched, or no email. Salesforce deals,
stages, and close dates link to an event through a campaign relationship you confirm.
Marketing spend sits by event and channel, with the author of every change.

[Book a demo](https://eventiq.io/#early-access) with your source inventory. In the product walkthrough on sample data,
review the supported registration, attendance, contact-match, and campaign records;
write down which fields your team must still reconcile outside the product.

---

HTML version: https://eventiq.io/event-data-management