SurveyCTO Coding Practices

Jump to: navigation, search

This article discuss solutions to common issues in the SurveyCTO programming language. For a general introduction to how to structure your approach to CAPI programming or best practices settings, see the Questionnaire Programming topic.

Read First All coding examples linked to in this section are stored in Google Drive. SurveyCTO also allows you to pull this code directly to your server, using the URL of the Google Sheet (alternatively, you can copy the code to Excel).


To speed up data import, all SurveyCTO surveys should have a language labelling column in both the questionnaire and the value labeling tab called "label:stata" which will be used to download and process the data. These labels should be in English, be no longer than 32 characters, and uses no special characters. The research assistant who will be responsible for data management can be of great assistance in preparing this. See the SurveyCTO documentation on "Translating a form into multiple languages" for more details.


In the field, the best practice when randomizing anything is to prepare the randomization before the field activities start, and preload the result of the randomization into the survey so that it is replicable. What follows are some examples of SurveyCTO forms that randomly select survey participants:

  • Random draw of beneficiaries from a large pool, without knowing if the potential beneficiaries are valid participants - this form randomly prioritizes participation over a group of IDs, which are then verified by the enumerator until a final group of 8 participants are registered.

Repeat Groups / Rosters

This sections lists code examples for special requirements in relation to rosters and repeat groups. These can be used to develop interesting functionality within forms, particularly interacting with the responses from a household, plot or crop roster. Here are some examples of this:

  • Setting Up Repeat Group Using Previous Choices - there are many cases when you want to repeat a set of questions over previously selected responses, such as a set of crops cultivated or activities performed. This example shows the 2 main ways of coding this.
  • Select Member in Roster Based on Criteria - in this example we have a roster over children and then we want the respondent to be asked to select the youngest child if the mother is present, if she is not present, we ask the respondent to select the second youngest child if the mother of the child is present, and so fourth.

Agriculture Survey Advice

There are many challenges encountered when coding agriculture sections of household surveys. There is a lot of data to capture at different and changing levels: per season, per plot, per crop, etc., and sometimes you might want to change the level of questions from crop within plot within season, to, for example, just the crop level. It's important that the respondents are able to recall harvest and sales information as accurately as possible, therefore we must structure surveys well to account for this. Here are some example forms that talk through the main issues and suggest designs to overcome these issues.

  • Dealing with 'Other' Crops Over Different Repeat Group Levels - in SurveyCTO it's very difficult to introduce new crops in different repeats and be able to recall them at other points in the survey. This example form talks about these difficulties and suggests a structure to refer back to them in other sections.


Use a lot of groups but do not over use them. In general, groups are used to fulfill one of the purposes below:

  • Frame all the questions on a module in group. Only do this at the highest level of the survey, i.e. do not use this for sub-levels of a module.

Choice Lists

Choice lists are the answer options an enumerator can choose from in a select_one or select_multiple question. They are listed in the choices tab in the SurveyCTO questionnaire. Open Data Kit, the programming language of SurveyCTO, has very few restrictions on how you can code your options. However, there are choice list best practices that matter for data quality.

  • Dynamically Populated Choice Lists - from repeated select_one - a specific example of dynamically populated choice list is when you populate a select_multiple question with answers from a select_one asked in a repeat group. For example, say that you list crops grown in a repeat group where each repeat is a crop, and later you want to be able to ask "which crop did you grow the most?" and only the crops already selected in the repeat group should display.

SurveyCTO Calculations

  • SurveyCTO has developed a great best practices guide for using calculations. Calculations help with the design of smarter surveys. For example, you can use calculations to find out how long it takes respondents to reach a certain point in your survey, you can monitor your respondents’ observance of suggested response times for skill assessments or you can use calculations to ensure that personally identifiable information (PII) doesn’t get captured in your data analysis. This guide provide 9 tips and examples for using calculations and can be found here.

SurveyCTO Audio Audits

  • SurveyCTO supports random audio audits as part of the meta-data of a survey. Audio audits are audio recordings that take place during a survey interview without an indication that the recording has been initiated. They are one of several tools that survey administrators can use to ensure that the highest possible quality of data is being collected. They are also a cost effective means for administrators to better understand how their surveys are actually being conducted in the field. You can learn more about best practices, logistical and ethical considerations of using audio audits in this SurveyCTO article.

SurveyCTO Sensor Data

  • With SurveyCTO, you can collect sensor meta-data using built-in Android device sensors. Android devices can come with a number of sensors beyond GPS including an accelerometer, gyroscope, light sensor, microphone, among others. The sensor data field types on SurveyCTO use these sensors to capture data during the survey that can provide users with an idea of:
    • The light conditions around the device.
    • How much the device moved.
    • How loud the sounds were around the device.
    • The pitch of the sounds around the device.
    • An estimate of whether a conversation was taking place around the device.

You can visit this SurveyCTO help article to learn more about sensor data.

Stata Commands for SurveyCTO Sensor Data

  • SurveyCTO has also built Stata commands to help users easily analyze large volumes of sensor data streams. Sensor streams can be time-consuming to work with because for every submission, a sensor stream records a stream of observations (potentially thousands) and stores it as an additional .csv file attached to the submission. You can learn about these commands in this article and you can access the scto package here.

Other Tips and Tricks

  • Question font formatting in HTML - SurveyCTO accepts HTML commands in the text of questions. This can be used to highlight and emphasize key information, among other uses.

Categories to add to this page:

  • Household rosters
    • General examples
    • Updating roasters from previous rounds on tablet during interview
  • ID and identification
    • Assigning IDs in the field - both when the sample is know before launch of survey and when respondents are sampled in the field

Additional Resources

Tips on coding complex agricultural surveys in SurveyCTO, from IFPRI: