Which registration fields actually matter to the reports you publish

Every year the same meeting happens. The form has 22 fields, the marketing lead wants two more, the operations lead wants three of the existing ones made mandatory, and everyone has an opinion about how much friction the form can take. The conversation runs on instinct because nobody has the one number that would settle it.

Deciding which registration fields actually matter has a mechanical answer, and it is a count. For each field, how many published outputs stop working without it? Fields carrying several outputs get targets and steward time. Fields carrying none get left alone, no matter who asked for them.

This is a ranking of what you already collect. Whether a question belongs on the form at all, weighed against the drop-off it causes, is a different test applied at form design time.

Rank by how many outputs break

The count comes from the queries, and it has to come from the queries.

Ask a report owner which fields their report uses and you will get the fields they think about. Open the SQL and you will find the fields it reads, which includes joins, filters and the group by clauses nobody mentions. On every file I have looked at, the two lists differ, and the difference is usually a field somebody has been quietly deprioritising because no one told them a report depended on it.

So take every output that leaves the building. On a mid-sized show that is around nine things: the geographic breakdown, the job function mix, the registration type split, the exhibitor scorecard, the pacing report, the acquisition channel report, the pre-show exhibitor pack, the audit submission and the sales workspace extract.

For each output, list the columns its query touches. Then invert the lists into a count per field.

A worked ranking from one show with 22 fields on the form and those nine outputs looks like this. The badge identifier appears in all 9. Company appears in 6. Country appears in 5. Job title, directly or through a derived function, appears in 4. Email appears in 3. Registration type appears in 3. Acquisition channel appears in 2. Postcode appears in 1. Phone appears in 0.

The remaining 13 fields appear in 0. That is 14 of 22 fields, or 63.6 per cent of the form, feeding nothing that anyone publishes.

Which fields carry almost everything?

Four of them, on nearly every show I have seen: the badge identifier, company, country and job title.

The badge identifier is the join key, so it is in everything by construction. Its usage count is the row count of the exercise and it tells you nothing except that a null badge identifier is catastrophic, which you knew.

Company is the surprise for most teams. It carries the exhibitor scorecard, the account view in the sales workspace, the company size distribution, the new against returning organisation split, and any deduplication that runs on organisation rather than person. Six outputs from one free text field that most forms leave optional.

Country carries the geographic breakdown and the audit submission, and it is the field with an external obligation attached. UFI's auditing rules of June 2021 determine a visitor's nationality by place of residence and state in Annex 2 that it must be given on visitor registration forms, with international event status turning on either five per cent international visitors or ten per cent international exhibitors.

Job title carries the job function mix and the seniority view, and it carries them badly, because it arrives as free text. A usage count of 4 on a field whose values cannot be grouped is a specific kind of problem: high demand, low usability, and a mapping project sitting between the two.

Set targets only where the count is two or more

The threshold is a budget decision and the arithmetic is easy to do badly.

Take a field at 78 per cent populated across 22,000 registrations, and a proposed target of 95 per cent. Reaching it means recovering values for 0.95 minus 0.78, which is 0.17 of the file, or 3,740 records. A steward working through an enrichment queue with a lookup per record manages around 40 an hour on a good day. That is 93.5 hours, or better than two working weeks of one person's time.

Two weeks is a reasonable price for a field that carries six published outputs. It is an absurd price for a field that carries none, and the two requests look identical on a project board unless the usage count is written next to them.

So the rule I would apply: fields with a usage count of two or more get a completeness target, a named owner and steward capacity. Fields with a count of one get a target only if that single output is the audit submission or something else with an external deadline. Fields with a count of zero get nothing, and get reviewed for removal at the next form revision.

That rule will feel harsh on fields somebody fought for. It is worth saying out loud that a field collected and never read is worse than a field not collected, because it costs completions at the form and storage afterwards and returns nothing.

Once the ranking exists, it also feeds the per record scoring directly, since the weights in a per record completeness score should be the usage counts rather than anybody's sense of importance.

Why does the ranking need redoing every year?

Two reasons, and the second one is the one people miss.

The obvious reason is that reports change. A new section in the post-show report can move a field from a count of zero to a count of two overnight, and nothing about the field itself changed.

The less obvious reason is that field values decay at very different rates, so a ranking that was accurate on fill rate a year ago is describing a file that has quietly moved underneath it. ZeroBounce's Email List Decay Report for 2026 puts the annual figure at at least 23 per cent, drawn from more than 11 billion email addresses processed through their verification service between January and December 2025, against 28 per cent the year before.

Apply that to the file above. Email is populated on a high share of the 22,000 registrations and is read by three outputs. If roughly a quarter of those addresses stop working within a year, then a list of 22,000 loses on the order of 5,000 usable addresses before anyone edits anything. A reactivation campaign built on last year's file, and any completeness target set against it, are both working from a number that has already moved.

Country decays slowly, because people move house rarely. Company and job title decay in between, driven by job changes. Email decays fastest of the four. That ordering should show up in how often each field is re-verified, and on most shows it does not, because verification effort follows whoever complained most recently.

The fields you do not get to deprioritise

Three categories override the usage count.

Anything the audit needs. Country, as above, plus whatever your auditor asks for in the check-back process.

Anything a legal basis depends on. If consent capture or a lawful basis flag lives in a registration field, its usage count in reporting is irrelevant and its completeness target is 100 per cent.

Anything that is a key. The badge identifier and any external system identifier are load-bearing for every join, and a 99 per cent complete key is a broken key. Keys belong in the governed record with a hard constraint rather than in a completeness target with a percentage.

Everything outside those three is fair game for the count.

Where this stops

The usage count measures demand from reports that exist. It cannot see the report nobody built because the field was too sparse to make it worth trying, and that circularity is real. Industry sector sits at 30 per cent populated, so nobody builds the sector breakdown, so sector has a usage count of zero, so it never gets a target, so it stays at 30 per cent. Breaking that loop needs a deliberate annual look at the fields with a count of zero and a fill rate high enough to be salvageable.

The count also treats all outputs as equal. The audit submission and an internal pacing report both add one to a field's score, and their consequences are not comparable. Weighting the outputs before counting is possible and I have never found it worth the argument it starts, since the three overrides above already handle the cases where it would matter.

And the count says nothing about whether the values are right. A field read by six outputs and populated on 95 per cent of rows with stale employer names will produce six confidently wrong charts. Ranking by usage tells you where to spend effort. It does not tell you that the effort should go on verification rather than on collection, and on company and job title it usually should.

Pull the SQL behind your three most-read outputs, list every column each one touches, and count. You will have a defensible field ranking in under an hour, and the number of fields on your form that appear nowhere in it will end the next mandatory-field argument faster than any opinion will. Then check the ranking against the completeness scope you already report and see whether the two agree.