Vote by Mail Data: What the Fields Actually Mean

The Five Fields Everything Else Is Built From

Strip a vote-by-mail extract down and you find a small core. There is a status code describing where the ballot is in its lifecycle. There is a request date, recorded when the voter asked for a ballot or was sent one automatically in universal-mail states. There is a delivery or send date. There is a return date, recorded when the election office received it back. And there is often a cancellation date for ballots that were superseded, spoiled, or replaced.

Everything a campaign or an analytics team reports comes out of those five, which is why what to ask before licensing voter file data starts with field-level definitions rather than record counts. Chase lists are built from status plus the absence of a return date. Turnout projections are built from return rate over time. Universe sizing is built from request counts. If the five fields are read carelessly, every number downstream inherits the error.

A Status Code Is Not a Date, and Blank Is Not Zero

State rules differ on when a ballot is sent, what counts as returned, and how cure works, and NCSL's survey of voting outside the polling place is the fastest way to see that variation before reading a file. The most frequent analytical error in VBM data is collapsing status and dates into one concept. They are recorded by different processes and they disagree in normal operation. A row can carry a status indicating the ballot was returned while the return date is blank, because the status was updated at a different point in the workflow than the timestamp. That row is not corrupt. It means the office recorded the outcome without recording, or without yet publishing, the date.

Blank deserves the same care. A missing return date can mean the ballot has not come back, or that it came back and the date is not in this extract. Those are different facts and they belong in different buckets. Folding both into zero produces a return rate that is quietly too low, and it will be wrong in the direction that makes a campaign relax.

Date Anomalies Are Normal at Low Rates

Real vote-by-mail files contain rows where the dates do not sequence cleanly. A delivery date can precede the request date, typically in universal-mail jurisdictions where ballots go out before any individual request is logged. A return date can precede a delivery date where the two came from different systems with different clocks. These appear at low but persistent rates.

The right response is not to discard them silently. Decide a handling rule, apply it consistently, and state it wherever the metric is published. A rate that quietly drops a fraction of a percent of rows is fine. A rate that drops them without saying so is a number nobody can reproduce.

Always Publish the As-Of Timestamp

In the weeks before an election, vote-by-mail counts move daily and sometimes hourly. A return rate without an as-of timestamp is not a measurement, it is a rumor. Every VBM figure that leaves your team should carry the file date it was computed from. This is the single cheapest discipline in election analytics and the one most often skipped. The same timestamp discipline applies to any audience targeting work built on a file that moves daily.

The Chase List Is Where These Fields Earn Their Keep

Most of the care above exists for one operational purpose: building a chase list, the set of voters who have a ballot in hand and have not returned it. That list is the difference between a program that moves turnout and one that mails reminders to people who already voted, which wastes money and annoys the recipient.

The naive construction is status equals sent and return date is blank. It is close, and the ways it is wrong are the ways the earlier sections warned about. A ballot recorded as returned with a blank return date belongs OUT of the chase list, and a naive blank test puts it in. A cancelled or superseded ballot, where the voter was reissued, should be chased on the replacement rather than the original, so a build keyed only on the first record chases a ballot that no longer exists. And a voter who returned a ballot the office has not yet processed will appear chaseable for as long as the processing lag runs, which near a deadline can be days.

None of this is exotic. It is the same three fields read carefully rather than quickly. The check that catches most of it is a reconciliation, run the same way as any other pre-load file QC: chase-list size plus returned plus cancelled should account for every ballot sent, and if it does not, the gap names the case being mishandled. Run that reconciliation every time the file refreshes, not once when the query is written.

One last operational note. Ballot cure, where a voter fixes a signature or other defect, usually lives in different fields or a different file than the return lifecycle described here. If your program includes cure outreach, ask for those fields explicitly and confirm them against the supplier's data dictionary. Confirm which record carries the defect status before assuming the status code in this file covers it. Treating a cure-eligible ballot as simply not returned is a common and costly conflation. These fields come standard in GSDSI's voter and political data file.