Use case: The paradata currently includes all events related to answers being provided (e.g., initially set, changed, deleted, etc.) but includes only the last event related to answer being valid/invalid. In other words, the paradata describe whether the last answer given is valid/invalid, but not whether previous answers given were valid/invalid.
One potential use of paradata might be to investigate whether interviewers change answers in response to validation errors, and whether those changes suggest correcting an accidental error (e.g., changing 5000, which contains an extra 0, to 500) or editing data so that it fulfills a validation condition (e.g., entering 5000, seeing an error, changing to 4000, seeing an error, … , and changing to a final answer that satisfies the validation condition but may be inaccurate data).
But current paradata do not allow this to be done easily. While the analyst could, in principle, reconstruct from the paradata whether each answer change result in a valid/invalid answer, the task would be substantially easier if the valid/invalid state for each answer change were part of paradata.
- Record these answer valid/invalid events in the data sent from the tablet to the server. This could result in large data files that might be difficult to send over poor networks.
- Reconstruct the answer valid/invalid events on the server based on data received. This would be a computationally costly exercise that may not be a good use of system resources.