Guide to timestamps and timing questions

For more SurveyCTO features that can promote high-quality data, check out our documentation Collecting high-quality data

There are times where you would like to know how much time was spent completing a field or group of fields. For example, what if you would like to see if some enumerators are completing important parts of your form faster than others?? What if you would like to see if a particular section of the form is taking a particularly long time to complete, so you can know if it should be revised for future surveys? Timestamps and timing fields are an excellent way to determine how much time was spent on a field or a section of fields.

Timestamps and timing fields

There are two main ways to time fields: using expressions, and using text audits. Look over both methods, and determine which one will work best for your form (you can also use both methods if you'd like).

Timestamp expressions Text audits
✓ Can use value in other expressions in form. ✗ Can only be accessed after form is submitted.
✓ No extra files to manage (i.e. exported form data and timestamps in one data file). ✗ Generates a CSV file for each submission with all field times, so uses more storage.
✗ Can only track the first time the enumerator was in that section of the form, not the time spent when they returned later. ✓ Can track total time spent on each field, even if the enumerator returns later.
✗ Only works if the form is completed linearly without skipping ahead using the Go To Prompt menu. ✓ Works even if the enumerator jumps around the form.
✗ Must be set up for each section you would like to track. ✓ Tracks all field times automatically by adding a single field, so requires less time to apply.
Text audit fields have other great features, including an audit log of app actions that can track when a form is opened, closed, re-opened, finalized, and updated with a new form definition. See the documentation for more details.

Method 1: Expressions

This section is accompanied by this sample form. For assistance deploying the sample form to your server, check out our support article Deploying form definitions and server datasets.

One method to track time spent on fields is to use calculate_here fields. Take a look at the sample form linked above: before and after the field "question" on row 12, there are two calculate_here fields, each with the same calculation:


Those fields calculate timestamps, or the time it took in seconds to reach those points in the form. Here is a breakdown of each part:

  • calculate_here field type: This is used instead of a regular calculate field. That way, it does not calculate the duration until you reach that part in the form.
  • once() function: This ensures the field does not recalculate if the enumerator returns to that point in the form. For example, if the enumerator leaves that section of the form at 60 seconds, and then returns to that point in the form at 300 seconds (after they have already completed other fields in the form), the field value stays at 60 seconds, and it does not recalculate to 300 seconds.
  • duration() function: The key to this expression. This calculates how much time the form has been open so far.
Compare this to the field "duration" on row 10 of the sample form. That is a regular calculate field without the once() function. Because of that, it is always recalculating as needed, so it calculates the total time spent with the form open. That value is great for data analysis, but if you also need to know the timestamps of certain points in the form, you can use the method discussed above. You can also learn more in our support article Difference between duration() and end-start.

To calculate time spent on a field or section of fields, simply use a calculate field to get the difference between two timestamps. For example, if the timestamp field before the section is called "stamp_1", and the timestamp field after the section is called "stamp_2", add a calculate (not calculate_here) field with this calculation:

${stamp_2} - ${stamp_1}

That field will store the time in seconds it took to complete that section. In the sample form, this is demonstrated in the field "difference".


This method returns time in seconds. To get the time in minutes, simply divide the value by 60 using the "div" operator, like this:

${difference} div 60


This method only works if the enumerator completes the form linearly. For example:

  1. If the enumerator skips the first calculate_here field using the Go To Prompt menu, then there will be no start time to subtract from the end time.
  2. If the enumerator skips the second calculate_here field, then there will be no end time to subtract the start time from.
  3. If the enumerator skips ahead to the second calculate_here field, and then returns to the first one, then the time will appear to be negative.
  4. If the enumerator returns to the section after already passing by both calculate_here fields, the form will not track the additional time spent on the section. For example, if the enumerator initially spends 60 seconds on a section, then after reaching the end, they return to that section for 15 seconds to edit some fields, the form will only track those initial 60 seconds, and not the additional 15 seconds.

For these reasons, if you are using this method, it is a good idea to disable the Go To Prompt menu and Skip to Next from the Admin Settings.

You can use quick setup to make sure collection devices have the correct settings applied as soon as they sign in. For example, you can have the Go To Prompt menu and Skip to Next automatically disabled when users sign in, so you don't have to disable it manually on each individual device.

To learn more, check out our documentation Managing device settings, especially the section Default device configurations and quick setup, as well as our support article Best practices for configuring and securing enumerator devices.

Method 2: Text audits

Another method to track time spent on fields is to add a field with the type text audit. A text audit will track how many seconds were spent on each field. Then, when you go to export your data via SurveyCTO Desktop, it will also export a CSV file for each submission, which will show how much time was spent on each field. If you would like to determine how much time was spent on a section of fields, you can use the data in the text audit to add up the time spent on each individual field in that section (though you will have to do this after the data has been exported).


Example of a text audit opened in Excel.

If an enumerator leaves a field and then returns later, that time spent returned to the field will be included (unlike method 1 above). For example, let's say there is a field called "age": if an enumerator spends 60 seconds on the field "age", leaves, and returns to the field "age" for an additional 15 seconds, then the text audit will report that the enumerator spent 75 seconds on that field.

This method is a lot easier to set up, uses fewer fields, and it is less resource-intensive on devices. However, it will also create a large number of CSV files, and you cannot determine section length until after data has been exported. If you are familiar with data analysis tools such as Stata or Python, you can set up a tool that synthesizes and congregates the data for you.

To learn more, check out our documentation on the text audit field type.

The team at Innovations for Poverty Action (IPA) maintains Stata tools for managing the quality of survey data, which includes commands for generating statistics from text audit data. Stata users who are interested in text audits should check out the ipacheck Stata package.

Checking for linear completion

Text audits can also be used to see if the enumerator used the Go To Prompt menu to skip around the form. Take a look at this example text audit.

Field name Total duration (seconds) First appeared (seconds into survey)
field1 10 0
field2 35 10
field3 15 25
field4 10 40

If you were just to look at the 'First appeared' column, you would presume that the enumerator spent 15 seconds on "field2", since there is a 15-second difference between the time spent on the fields "field2" (10 seconds) and "field3" (25 seconds). However, the 'Total duration' for that field is 35 seconds. This is because the enumerator spent 15 seconds on that field initially, and then they used Go To Prompt to return to that field later, spending an additional 20 seconds there. The enumerator then skipped to the end of the form and marked it as finalized.

Here is another example:

Field name Total duration (seconds) First appeared (seconds into survey)
field5 15 50
field6 40 150
field7 15 65
field8 10 80

This one might appear odd since the 'First appeared' value for "field6" (150) is after the 'First appeared' value of "field7" (65). What must have happened is that when the enumerator reached the field "field5", they used the Go To Prompt menu to skip to "field7". Then, when the enumerator reached the end, they went back to the field "field6" (likely because they were prompted to return to that field because it is marked as required).

Using field plug-ins

You can also use field plug-ins to time certain actions. For ready-made field plug-ins you can use to time actions, check out our field plug-in catalog.

Do you have thoughts on this support article? We'd love to hear them! Feel free to fill out this feedback form.


Article is closed for comments.