An enumerator visits the same household in March, July and November — three tablets, three uploads, three rows. Offline collection is not really a connectivity problem. Signal comes back; the answer to "is this the same family?" does not, unless someone assigned an identifier before the first visit.
This chapter resolves check 02 One record of the eight checks.
An enumerator visits the same household in March, July and November. Three tablets, three uploads, three rows — and because nobody assigned that household an identifier on the first visit, someone in the office now matches them by the spelling of a name written on a paper form. That reconciliation is not a data-cleaning task. It is the moment the programme loses the ability to say whether anything changed for that family, and no amount of analysis afterwards recovers it.
You assign the identifier before the first visit, not after the last one. Everything else about offline collection — queuing responses with no signal, syncing when the bars return, validating on the device — is solved by most field tools. What is almost never solved is identity: whether the person you met in March is recognisably the same person in November, across a different tablet, a different enumerator, and eight months of gap. Get that wrong and you have three separate surveys of strangers.
Field conditions attack identity from four directions at once. An identifier that survives one and fails another is no better than no identifier, because a partially matched cohort is more dangerous than an obviously unmatched one — it looks analysable.
That last one is the most commonly violated, and the failure is worth describing precisely because it looks so reasonable on paper.
The scheme is appealing because it preserves anonymity: ask each person to build a code from things only they know — first two letters of their mother's name, their state abbreviation, the day of their birthday. No names stored, and the same person can regenerate the code next year.
Except they cannot. A patient association with more than eleven thousand members ran exactly this design across several surveys. People forgot the identifier they had invented, entered something different at the next wave, and the records could not be matched. The anonymity was preserved perfectly and the longitudinal analysis was lost entirely — which is the worst possible trade, because the whole reason for the ID was to enable the follow-up.
The lesson is not that anonymity and continuity conflict. It is that the burden of remembering has to sit with the system. A system-generated identifier issued at first contact and carried in the invitation link asks nothing of the respondent, and it can still be de-identified in analysis.
The fallback, when no identifier exists, is to match on name plus something — village, age, phone number. In the field this degrades faster than teams expect:
The last failure is the reason to care. An unmatched record announces itself — you can count the orphans. A wrongly matched record does not, and it enters your outcome figures as signal.
The method is not proprietary, and it is worth building by hand once so you know what the software is doing for you.
KAM-014, KAM-015. If you cannot enumerate the population in advance, generate a block of unused codes and assign them at first contact.Run that and you have solved check 02 for one cohort with a spreadsheet and some printed cards. It genuinely works.
It breaks on repetition, and always in the same three places. The roster spreadsheet drifts from the form as questions change between waves, so the code column ends up in a different position and someone pastes the wrong column. The person who designed the scheme leaves, and their successor does not know that KAM means Kamuli district or that codes beginning X were test entries. And a second site starts collecting with its own numbering, so two participants share the code 014 and the merge across sites is now a manual reconciliation of exactly the kind the scheme existed to prevent.
This is where a system earns its place, and the claim is narrow: Sopact Sense issues the identifier at first contact and carries it in the invitation itself, so every later response joins to that record regardless of device, enumerator, sync order, or elapsed time — and nothing is asked of the respondent. Validation runs on the device offline, so what syncs is already clean and already attached to a person. Multiple sites draw from one identifier space, so a second site cannot mint a colliding code. Your team still decides who is on the roster, what the form asks, and who may see the mapping.
Use: One participant recorded three times across two waves, on two different devices, by two different fieldworkers, with one of the uploads deliberately synced last. Add one respondent who declines consent to be re-contacted.
Pass: All three responses land on one record without anyone matching by name. The out-of-order sync makes no difference. The declining respondent is not linked on return.
Fail: Any step requires a human to decide whether two rows are the same person.
Do this on a live cycle. A demo dataset has no transliteration variance, no eight-month gap and no staff turnover, which are the only three things this check is actually about.
Yes — forms render and accept answers on the device, and responses queue locally until connectivity returns. That part is well solved across the field-tool market. Identity across visits is the part that is not, and it is decided before the first visit rather than at sync.
Yes, and more reliably than with a self-generated code. A system identifier lets you de-identify the analysis while retaining the ability to follow up, because the code-to-person mapping lives in one access-controlled place rather than in each respondent's memory.
Generate a block of unassigned codes and issue them at first contact. The requirement is that the code exists before the response does — not that you knew who would receive it.
The identifier is what makes this recoverable: the record persists even when the address does not, so a re-contact at a new location joins the same history. Matching on address or phone number is precisely what fails here.
The identifier has to be able to break the link as deliberately as it makes it. A consent withdrawal should prevent re-linking on return, which is only possible if consent status travels with the record rather than sitting in a separate log.
XLSForm imports directly, preserving skip logic and validation. The change is not the form — it is attaching that form to an identifier issued in advance instead of to a row in an export.
Because you can count missing records and disclose them. A wrong match produces a participant whose before-and-after belongs to two different people, and it enters the outcome figure as evidence with nothing marking it as suspect.
The unglamorous conclusion is that offline data collection is not really a connectivity problem. Signal comes back; the queue uploads; that part is engineering that other people have already finished. What does not come back is the answer to is this the same family? — and that question is settled months earlier, by whether someone wrote a code on a card before knocking on the door the first time.
ChatGPT, Claude, and Gemini are fine for a quick test — but not for an answer you'll put in front of a funder or board. When it has to hold up, run it in Sopact Sense.
Try it in Sopact →
