Computer Aided Personal Interview

The Reality of Deploying CAPI Field Teams

Most organizations treat CAPI like a software problem. It isn't. It's a logistics problem with a screen attached. I've shipped three CAPI deployments across Sub-Saharan Africa and Southeast Asia in the last five years. The software part takes about two weeks. The part that actually works depends entirely on whether your enumerators can charge devices at 6 PM, whether the sync server doesn't crash during evening uploads, and whether your skip logic doesn't send a respondent to page 47 when they answer "no" to question 3. I use ODK Collect for most field work, combined with a custom backend built on Python and PostgreSQL. For larger operations I've moved to SurveyCTO because their server management takes pressure off my team. Both run on Android tablets, both handle GPS timestamps, both support branching logic. The differences are in the operational details that don't show up on any comparison chart.

Setting Up a Computer Aided Personal Interview Form That Actually Survives the Field

Start by building your form in XML. Don't skip this step to jump into the UI builder. The XML gives you version control. When you need to change a question mid-fieldwork because the translation was wrong or the skip logic was broken, you push an updated XML, the devices pull it, and you're not calling every enumerator to explain what changed. I've seen teams lose three days of data because they edited a form inside ODK and the version numbers didn't match across 40 tablets. Your form needs mandatory metadata fields: enumerator ID, start time, end time, GPS coordinates at the household location, and device serial number. Without these, cleanup later is someone else's problem. A respondent who says their interview started at 9 AM but the GPS shows the device was 14 kilometers away at 9 AM is a data quality problem you'll spend hours investigating. The GPS metadata alone prevents maybe half of those issues if you check it during cleaning. Here's the edge case nobody warns you about: battery drain from continuous GPS logging. If you set your form to record GPS every 5 seconds during an interview, a tablet going through a 90-minute survey will consume roughly 18-22% of a typical 7000mAh battery just from GPS. That's not a small number when you're doing multiple interviews per day in hot weather, which degrades battery capacity anyway. The workaround I use is setting GPS recording to interval-on-change rather than time-based, and only activating GPS for the first and last position fix of each interview. You still get the household location with enough accuracy for geocoding, and you preserve battery for the actual data entry screen time.

Skip logic needs to be tested on actual devices, not just in the preview mode. Preview doesn't simulate the exact same path as field execution because of how Android handles memory when forms get large. I had a form with 340 questions where the preview worked perfectly, but on a low-end $60 tablet running Android 8, navigating back after a skip would sometimes freeze the UI for six to eight seconds. The respondents noticed. Some just stopped cooperating. Moving to a mid-range tablet and upgrading to Android 11 fixed it entirely. Device specifications matter more than you'd expect. For multilingual forms, store all labels and texts as external CSV files rather than embedding them in the XML. When you catch a translation error, you update the CSV and push it alongside the form. Embedding translations directly in the XML means republishing the entire form definition every time you fix a typo in the Swahili version. That sounds minor until you're doing it twelve times in a week.

Deployment Strategy and Operational Discipline

Training enumerators on CAPI is different from training them on paper. The biggest failure mode I see is enumerators treating the tablet like a teleprompter. They read questions aloud without looking at the screen, which means they miss visual cues, skip validation prompts, and don't notice when the form highlights a response that falls outside the expected range. I make every enumerator do at least five practice interviews where they have to look at the screen for each question. It slows them down initially by about 30%, but the data quality improvement is immediate and permanent. Sync discipline is where most projects fail. You need a fixed sync schedule. Morning before fieldwork starts, and evening after the last interview. Not ad hoc. I've had situations where an enumerator went four days without syncing because their battery was dead and they were waiting to charge at a colleague's house. Those four days of data existed on only one device. A power outage killed the tablet. Four days of work gone. This is why redundant backups matter. Export daily to a cloud folder even when the main sync server is working fine. Redundancy isn't expensive paranoia when the alternative is losing two weeks of fieldwork. Real-time monitoring of incoming data catches patterns fast. If your dashboard shows that one enumerator is completing interviews in under eight minutes on average while the group average is twenty-two, something is wrong. Either they're not reading questions or they're selecting default answers without engagement. The first enumerator I flagged this for turned out to be filling out forms for households they hadn't visited. The GPS data showed they were sitting at a tea shop for three hours while completing twelve "interviews" across different locations. CAPI catches this because the GPS timestamp and location data are objectively recorded. Paper surveys don't give you that leverage.

Device management is its own full-time job on larger deployments. I assign one person whose only responsibility is charging, syncing, troubleshooting, and rotating devices. They track which tablet is with which enumerator, which devices need replacement batteries, and which units are showing screen degradation from sun exposure. Solar-powered charging stations at central locations work in areas without reliable electricity, but they require daily rotation schedules and waterproof storage. I budget for one replacement tablet per twenty deployed because screens crack, water gets in, and Android updates occasionally brick devices that were working fine the day before.

Common Pitfalls That Have Nothing to Do With Technology

Respondent comfort with tablets varies enormously by context. In urban areas with high smartphone penetration, people expect to interact with a screen. In rural communities where the interviewer's first with technology might be seeing a tablet for the first time, hesitation is real and it affects response patterns. I've seen respondents give socially desirable answers more frequently when they know the data goes directly to a server rather than staying in a paper notebook. The perceived permanence of digital data changes behavior. There's no clean fix for this other than acknowledging it and building it into your analysis assumptions. Internet dependency is the classic CAPI limitation. Offline-first design means your software handles offline data storage and syncs when connectivity returns. But "when connectivity returns" is the vague part. In some regions, 3G coverage exists but is unusably slow during certain hours. I've watched syncs take forty-five minutes for forms that contained maybe thirty megabytes of data because the connection kept dropping mid-transfer. Setting auto-retry with exponential backoff helps. So does compressing audio recordings before sync if your survey collects them. Cost analysis deserves honest attention. A fully equipped CAPI deployment costs significantly more upfront than paper. Tablets range from $60 to $400 depending on whether you buy enterprise-grade or consumer-grade hardware. Enterprise devices cost more but handle drops, heat, and extended daily use better. Per-unit costs add up fast when you need forty devices. But the savings come later: no data entry clerks, no transcription errors, no lost paper forms, faster cleaning cycles. The break-even point for my projects has consistently landed around thirty to forty-five days of fieldwork depending on sample size and geography.

When CAPI genuinely fails is when your questionnaire requires complex visual stimuli that don't render well on small screens. Showing photographs for food frequency questions, displaying color-coded maps for location questions, or using video vignettes for attitude measurement all create compatibility headaches. I worked on a nutrition survey where enumerators had to show participants photos of portion sizes. The tablet screens were too small and low-resolution for the images to be useful. We switched to printed card sets for that section while keeping CAPI for the rest of the interview. Hybrid approaches are often the practical answer rather than forcing everything into a single digital workflow.

Choosing the Right Platform for Your Scale

For small teams under ten enumerators working short deployments, ODK is sufficient and free. The setup complexity is low and the community support is extensive. For medium deployments with concurrent data review needs and multiple languages, SurveyCTO's hosted option removes server maintenance from your plate entirely. For large-scale government or NGO operations requiring custom dashboards, role-based access control, and integration with existing databases, building on top of CommCare or a custom PostgreSQL backend with a React frontend gives you the flexibility to go further. No platform handles everything. Each has tradeoffs in cost, customization, and support depth. The right choice depends on your team's technical capacity, your budget timeline, and whether you need to hand the system to local staff who will maintain it after your team leaves. If the answer to that last question is no, you're building a temporary system and you should plan for that explicitly rather than designing something that looks permanent and isn't.