Skip to content

Commit 05f9cde

Browse files
committed
Add household survey tutorial
1 parent 05af785 commit 05f9cde

1 file changed

Lines changed: 130 additions & 0 deletions

File tree

docs/tutorial-household-survey.rst

Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
Entities tutorial: household survey
2+
===================================
3+
4+
Household-based surveys are one of the most common patterns in field data collection, spanning population studies, public health, agriculture, education, and humanitarian response. Across these domains, the same core structure is found: there's a household or other parent unit, the people or items linked to it, and the operational forms and supporting data needed to carry out the work.
5+
6+
This tutorial shows how to leverage Entities to support a household survey at scale.
7+
8+
In this workflow, households have already been identified, sampled, and assigned to enumerators. We focus on enumerators visiting each of their assigned households to capture baseline data and build member rosters. They will then need to follow up both with the households and selected individuals over time:
9+
10+
.. mermaid::
11+
:align: center
12+
13+
flowchart LR
14+
A@{ shape: notch-rect, label: "Register\nhouseholds" }
15+
B[Assign enumerators outside ODK]
16+
C@{ shape: notch-rect, label: "Build roster\nand baseline" }
17+
D@{ shape: notch-rect, label: "Household\nfollow-up" }
18+
E@{ shape: notch-rect, label: "Member\nfollow-up" }
19+
20+
A --> B --> C --> D
21+
C --> E
22+
23+
style C stroke-width:3px
24+
25+
Prerequisites
26+
-------------
27+
28+
This tutorial requires Central v2025.4.4 and Collect v2026.1 or later. It assumes familiarity with :doc:`XLSForm <xlsform>` and :doc:`ODK Entities <entities-intro>`.
29+
30+
You will need administrator access to an ODK Central project. We recommend using a new project just for this tutorial. You can also use a project with other test forms, but be aware that you may end up with conflicts with existing form or Entity List names.
31+
32+
If needed, you can add a prefix or suffix to the names used in this tutorial. If you do so, be sure to apply it consistently everywhere needed, including in expressions to read from Entity Lists.
33+
34+
Designing the Entity model
35+
--------------------------
36+
37+
Because this workflow involves repeat encounters with the same households over time, it's helpful to represent those households as Entities so that their current status can be accessed and updated by forms. This enables enumerators to immediately see their progress as they visit households and automatically access data they previously captured in follow-up forms, even while offline. The ``households`` Entity List stores this household data. You can think of it as a data table, where each row is a single ``household`` Entity.
38+
39+
A key part of workflows that divide work across data collectors is making sure the full work gets done while avoiding duplicate effort. In this example, that is done with an ``enumerators`` Entity List. Each Entity in the list represents one person responsible for a set of households. The assignments are represented by a link from each ``household`` Entity to the ``enumerator`` it is assigned to. A single ``enumerator`` is generally assigned to multiple ``households``.
40+
41+
In our workflow, enumerators will also need to follow up with individual members, so it is helpful to represent those members separately in a ``members`` Entity List with a property linking them to the ``household`` they belong to.
42+
43+
When deciding what to store in Entity Lists, focus on what needs to be available during ongoing fieldwork. Form submissions capture raw data and are typically used later for analysis, while Entities store the current state of real-world things that need to be accessed and updated over time.
44+
45+
If you only needed follow-up from households and not individual members, you might choose to keep member data only in submissions and access it at analysis time. Similarly, if you only needed members' names, you could join them with a character like ``|`` and store them in a single property in the ``households`` Entity List for quick reference.
46+
47+
However, if you need multiple pieces of information about members to be available and updated during follow-up, it is better to represent them in a separate ``members`` Entity List.
48+
49+
Here are the Entity Lists and relationships we will use to support our workflow:
50+
51+
.. mermaid::
52+
:align: center
53+
54+
flowchart LR
55+
subgraph Data[Entity Lists]
56+
direction LR
57+
E[(enumerators)]
58+
H[(households)]
59+
M[(members)]
60+
end
61+
62+
E -.- |1 → many| H
63+
H -.- |1 → many | M
64+
65+
Setting up the enumerators and households lists
66+
------------------------------------------------
67+
68+
In workflows where only a sampled subset of households need to be visited, it's generally beneficial to carry out initial household discovery as a separate step. This could be done as part of a different project such as a local census or it could be carried out using an ODK form that does not automatically create Entities. Then, submission data can be cleaned as needed and used as a basis for sampling and assigning to enumerators.
69+
70+
For this tutorial, we have prepared two files with sample data. Start by downloading these:
71+
72+
* `enumerators.csv <https://docs.google.com/spreadsheets/d/1Liz9nzDDIoH3d901KTl-0uskeYYJ1reFo1xbvuQpfyM/export?format=csv>`_
73+
* `households.csv <https://docs.google.com/spreadsheets/d/13wK6LN_lu7lAXb_oojsDL0r8bkCCtKBFjZo16U2ioR8/export?format=csv>`_
74+
75+
.. note::
76+
77+
The names, places, and phone numbers in these files may look somewhat like real ones in Tanzania but they are entirely made up. Even the administrative areas are not completely correct.
78+
79+
In ODK Central, open your project and go to the :guilabel:`Entity Lists` tab to create and configure the Entity Lists so you can populate them with the data from the CSVs.
80+
81+
Create the ``enumerators`` Entity List
82+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
83+
84+
* Click :guilabel:`New Entity List`.
85+
* Enter ``enumerators`` as the name.
86+
* The declared properties must match columns from the CSV. Add the following properties:
87+
88+
* ``code`` (unique code for each enumerator)
89+
* Upload the ``enumerators.csv`` file.
90+
91+
Each row in the file becomes an Entity in the ``enumerators`` list. Note that Central does not validate or guarantee uniqueness or property values so you are responsible for choosing naming conventions that ensure uniqueness.
92+
93+
For the sample data we have generated, we used the following structure for enumerator codes: ``region code - first 4 letters of first name - first letter of last name``. For our 5 sample enumerators, this produces unique codes. When building your own household workflow, use a convention appropriate for your context or pre-existing values like employee ids.
94+
95+
Create the ``households`` Entity List
96+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
97+
98+
* Click :guilabel:`New Entity List`.
99+
* Enter ``households`` as the name.
100+
* The declared properties must match columns from the CSV. Add the following properties:
101+
102+
* ``hhid`` (unique code)
103+
* ``geometry`` (geopoint representing the household location)
104+
* ``enumerator`` (code of the assigned enumerator)
105+
* ``admin1`` (region)
106+
* ``admin2`` (district)
107+
* ``admin3`` (ward)
108+
* ``hh_head_name`` (full name of household head)
109+
* ``hh_head_phone`` (phone number of household head)
110+
* Upload the ``households.csv`` file.
111+
112+
Each row in the file becomes an Entity in the ``households`` list.
113+
114+
Notice that the ``enumerator`` property stores the code of the assigned enumerator, linking each Entity in the ``households`` list to an Entity in the ``enumerators`` list. Because the relationship between enumerators and households is established outside of ODK, we use our own identifiers for linking (enumerators' ``code``) instead of Central's system-assigned IDs, which are not available when preparing the data.
115+
116+
In the next section, we will create a form to get basic information about all members of the household as well as some baseline data.
117+
118+
Building the baseline form
119+
--------------------------
120+
121+
The baseline form needs to:
122+
123+
* get the enumerator's identity
124+
* show the enumerator the households they're responsible for
125+
* help the enumerator navigate to the next household to visit
126+
* ask the household head for consent and end if consent is not given
127+
* ask baseline household questions
128+
* get listing of household members and ask them baseline questions
129+
130+
See `the final form <https://docs.google.com/spreadsheets/d/1Qs9UCRshSxkEAp7EPDxXsFXFlmH0YAo-P-iKxItzPYs>`_

0 commit comments

Comments
 (0)