To edit or not to edit? That is the question.

Posted by: Gitahi Ng'ang'a on

Trust but verify. – Russian Proverb

Can enumerators modify their entries if they realize they’ve made a mistake? We hear this question a lot whenever we deploy mobile data collection for our clients. On the surface, it’s a straightforward question. A simple yes or no answer should do, right? Wrong.

In reality, the asker is usually pondering a lot more. Like, what if the record has already been submitted? Will editing it result in duplication or will the old record be overwritten? What if the enumerator is trying to cheat? Will I be able to know that the record was edited?

In order to answer this question meaningfully, we must consider the following:

  • Why would an enumerator want to edit a record?
  • Does the technology allow editing?
  • How can project officers detect malicious edits?

Why would an enumerator want to edit a record?

The first reason is that they simply made an honest mistake; a typo, for example. Often these are detected and fixed immediately, even before the record has been submitted. Sometimes, however, they may be detected much later after the data has already been uploaded.

The second reason is when a respondent changes their mind about a response they provided earlier. This may happen because they misunderstood a question. For instance, when stating how many children they have, a respondent might include adopted children, then later realize that only biological ones count – or vice versa. Again, this kind of anomaly may be detected either before or after submission, but usually before.

Hoji confirming that a user wants to edit an already submitted record.

The third reason is cheating. In my experience, this is rare, but it still happens. There’s almost always a significant time lag between when the enumerator completes a form and when it occurs to them to cheat. Often, this is the result of the enumerator judging that their original submission impacts them negatively in some way. For example, if they are supposed to interview a set number of males and females, they might decide to cheat to “balance out the numbers”.

Does the technology allow editing?

Any good mobile data collection app should allow enumerators to edit the records they submit when necessary. Some apps do not support this capability, while others require some sort of supervisor authorization in order to do so.

Our approach with Hoji is to allow enumerators to edit any data they enter by default – regardless of whether or not the record has already been submitted. Edited records simply overwrite new ones in the database in order to prevent duplication.

A record locked for editing after 24 hours.

However, projects can modify these default settings to either (a) completely disallow editing or (b) allow editing within a specific timeframe, say 24 hours. The rationale here is that any genuine errors will usually be detected within a short time.

How can project officers detect malicious edits?

Malicious edits are carried out with the explicit intention of misleading supervisors and data managers. This is precisely the reason that some mobile data collection apps require supervisor authorization for modification.

Our approach with Hoji is a bit different. In our experience, most enumerators are honest individuals looking to do good work. In any case, for the vast majority of projects, enumerators don’t even have any incentive to cheat in this way i.e. by editing an existing record.

For this reason, we do not require that enumerators seek supervisor approval before making edits. However, each individual edit is logged – including details on when it was performed and by whom. We also record and analyze how many times an enumerator has edited records.

A summary of the top 5 users who have edited their records the most.

This rich metadata allows project officers to monitor anomalies. For example, if the same user consistently keeps submitting their records more than once, that’s a clear red flag that should trigger an investigation. Another red flag is when the same record is submitted too many times. More than thrice, say.


We strongly believe in carefully hiring trustworthy enumerators and then empowering them with the tools they need to do their jobs well. It is important to allow them to gather and update field data as necessary. After all, they are there with the subject. But we also believe in having verification mechanisms to ensure that enumerators follow the rules and do not submit false data.

Let us know what you think in the comments section below.

Leave a Reply