For years, ElectionsOnline has supported the ability to assign voters to either a voter group and/or a special interest group (SIG) as a way of displaying a certain set of positions to some voters, while other voters see different positions. Depending on the criteria used to place voters into different groups, that could result in the additional benefit of filtering the election results to see how different demographic segments of the electorate voted. Now, Evote features the ability to create up to four additional custom fields dedicated solely for the purpose of filtering election results based on demographics.
To be clear, custom fields have nothing to do with which positions display to voters the way voter groups and special interest groups do. Their sole purpose is to permit associating demographic data with each ballot so the results may be filtered to view voting activity from different demographic segments of an electorate.
Examples
Examples of the types of data that might populate a custom field include:
- Age
- Gender
- Education
- Location
Were all four of these examples in use on an election, an election administrator could conceivably determine how female voters, over the age of 40, with a Ph.D., living in Virginia voted and compare that to any other cross-section of the electorate to learn if different segments of voters are voting differently from other segments and what that might mean for the future of an organization. For example, in a voluntary membership association, if under 35 voters consistently vote differently from voters over 55, that might indicate the organization’s leadership needs to take a closer look at what’s driving that since the future of the association depends on continuing to be perceived as valuable to younger, incoming members.
How to Use
When uploading your voters into ElectionsOnline, you simply include whatever data you wish in the optional custom fields that are part of the voter roster template. (That assumes you’re conducting a fully-hosted election. When using an integrated election, you may optionally pass custom field data through the API.) For example, drawing from the example above, in the custom1 column, you would include the voter’s age. In the custom2 field, you provide either male or female, and so on. When using an integrated election model and not uploading voter data into the ElectionsOnline service, you would make sure to pass data into the API’s custom field parameters.
How the system handles custom fields
The system is smart and automatically detects when custom fields are in use and what type of data they store. This smart approach saves the administrator time and headache by not having to declare properties of custom fields manually in order to prepare them for use. It’s important though to understand how the system does this to appreciate why it’s necessary to make sure all data used on custom fields is clean before using them.
To determine when custom fields are used, the system looks at the custom field values of the first ballot cast in an election. From that, it makes conclusions about what type of custom field filters should be displayed on the results page. The system logic is as follows:
- Select the custom fields associated with the first ballot cast in an election.
- Is custom field 1 for that ballot empty? If so, abort further processing.
- Is custom field 1 a number? If yes, display a control on the results page for filtering numeric values.
- Is custom field 1 not a number, but a date? If yes, display a different style of filter on the results page, one better suited for date values.
- Is custom field 1 neither a number, nor a date, but just a plain text value? If yes, display a filter on the results page which permits selecting those text values.
- Repeat steps 2 and 5 for the remaining three custom fields from the first ballot in the system.
Understanding this behavior, it becomes clear that when using custom fields you must make certain to provide consistent data value types for each and every voter. If one voter has a numeric value in any custom field, all voters need to also have a numeric value in that same custom field. The same is true of text and date values for custom fields.
Conclusion
Do not include voter-identifying information in any custom field as that would destroy the secret ballot principle on which the system is built. In fact, for small organizations, it may be necessary to avoid the temptation to use a collection of custom fields that could narrow the results down to only a handful of individuals as that could permit determining how someone voted.
That said, there is a considerable amount of business intelligence to be gleaned from smartly using custom fields and your election results can tell you much more about your organization than just who won the election!
