Reporting and ROI
Published
Event Tech Notes Reporting and ROI
Post-event dashboards are built to flatter the purchase decision that bought them. Knowing which numbers can bear weight is what separates a report from a press release.
Every event platform ships a dashboard, and every dashboard is generous. Registrations, scans, app opens, "engagements," pipeline "influenced": the numbers are real measurements arranged to imply more than they can prove. The skill in post-event reporting is not gathering more data; it is knowing which claims your data can actually support.
What the data can honestly say
Event data is strong on what happened: how many registered, how many showed up, which sessions filled, when people arrived and left, what the exhibitor scanners captured, how many watched the stream and for how long. These are counts from systems you control, and, cleaned of test records and staff badges, they are trustworthy.
The data is weak on what the event caused. A deal that closed after the CEO met a prospect at your dinner was touched by the event; whether it would have closed anyway is not in any export. Attribution models do not resolve this, they encode a policy for sharing credit: first-touch, last-touch, and multi-touch models will assign the same deal to different causes, and the model chosen is usually the one that flatters the chooser. This is not a reason to abandon attribution. It is a reason to report it as a convention ("under our model, events were credited with X") rather than as a discovery.
The honest middle ground is behavioral correlation with the claim stated plainly: attendees from target accounts advanced at a different rate than non-attendees. That is real information, contaminated by selection (the people who chose to attend were already different), and worth reporting with that caveat attached rather than laundered out.
The one number everyone trusts
Registration-to-attendance is the ratio that survives every argument, because both ends are hard counts from your own systems: people who signed up, people whose badges were actually scanned. No model, no vendor definition, no interpretation.
It is also diagnostic. Free registration is a weak commitment (the registrant risks nothing by not coming), so free events run materially lower show-up rates than paid ones; a shift in your ratio year over year says something real about audience quality, program pull, or how early you opened registration. Track it per event type against your own history rather than against industry benchmarks, which vary by format, price, and city too much to mean anything. Guard its integrity at the door: if staff wave people past the scanners at the morning rush, the denominator of every downstream claim quietly breaks.
Its companion is completion behavior: session scan-outs, stream watch duration, day-two attendance. Day-two badge scans against day-one is the bluntest quality signal an event produces, and platforms rarely put it on the default dashboard, possibly because of what it tends to show.
Board-deck honesty
The board deck fails in two directions. The inflated version claims revenue the event "generated" through an attribution model nobody explains, and gets dismantled by the first CFO question. The timid version reports registrations and satisfaction scores and concedes the argument that events are unmeasurable.
The defensible deck does four things. It states costs fully, including internal time. It reports the hard counts and the show-up ratio against your own history. It reports pipeline touched by the event under a named attribution convention, explicitly labeled as a convention. And it says what the number is for: a consistent yardstick across your own events, so that next year's figure means something. Consistency is the actual asset; a modest metric reported identically for three years beats an impressive one redefined annually.
Two hygiene rules close the loop. Define every metric in a footnote (whose scans, which dedupe rules, what counts as "attended" for the stream), because undefined metrics get redefined under pressure. And write the report's definitions before the event, in the same document as the reporting requirements you gave vendors, so the dashboard you get is the one the deck needs, not the one the platform prefers to show.