Very excited to know that we can use quotas now thanks to entities

Hello all,

I haven't been using ODK for some months and now I am back for a new project. Just learned about entities and my first thought was how can I use this feature for quota management live.

I did some reading and some tests and it's working, no external apps or nothing.

For those not familiar with quotas, we use them in our projects to keep the sample under control, like we need 2 males 25-34, 2 females 45-54 etc.

It's very easy to do this now just by creating and updating entities on form submit.

Please reply if you need help or guidance. I am very happy to give something back to the community.

Thanks,
Elvi

6 Likes

Thanks for sharing your experience! I would love to learn more about how you've chosen to approach your need. Are you populating a participants list and then doing your counting and filtering in your forms? This would be similar to what I described in this post.

Do you have multiple data collectors in your case? If so, how are you managing the possibility of some of them going offline? Do you ask them to make sure they refresh right before each new form filling session? Are your quotas strict or is it not a big deal if you go over by a couple of participants because a data collector didn't get the latest entity list version?

Would you mind to share a simple XLSForm here showing your approach, please?

Hi @LN , I think we are approaching this in a very similar way.
My method is by having 2 forms. the Quota Management Form and the QNR form. In the Quota Management form I create the quotas (for testing, need to use API because of the high number) with a Quota status variable = 1 (available). Then on the QNR form, I retrieve these quotas and at the end of the interview I change the Quota status variable to 2 (done) so it will not show again.

Do you have multiple data collectors in your case?
I have multiple data collectors but I use the cascade selection method to "drive" the collector to the specific zone. only one collector is working on one zone.

How are you managing the possibility of some of them going offline?
Collectors need to have their tablets connected through mobile hotspots (their phones) so they can get GPS coordinates as in most areas satellites will not give you accurate positions.

Do you ask them to make sure they refresh right before each new form filling session?
Yes, I haven't done a real project yet as I am just testing things out but that's the plan. refresh before starting the interview.

Are your quotas strict or is it not a big deal if you go over by a couple of participants because a data collector didn't get the latest entity list version?
The enumerator will select the quota from a prepopulated list. There will be 1000 quotas available for 1000 interviews. Each quota is removed after the interview is done. The quota we use refers mostly to gender and age group combination.

I am sharing a sample of Excel form with @wroos . I am looking for any suggestions on how I can optimize the process

Thanks.

4 Likes

Hello @wroos . Here's a very simple test. it should give you the idea.
the Quota Management creates the quota (age and gender) for each city (the final will be for each zone). Then the QRN form pulls these quotas and shows a specific quota for each city. after the interview is done, that quota is discarded and it will not show next time.

QuotaManagement.xlsx (18.9 KB)

QNR.xlsx (19.0 KB)

4 Likes

wonderful! thank you @Elvi_Web ! I replicate it correctly, are you using ODK Collect or public access links? I experience that in ODK collect need to update before entering a new form, and also sometimes it is better to wait a few minutes because it doesnt update, with public links it is right away, what is your experience?

1 Like

This is great, @Elvi_Web, thanks so much for taking the time to share a worked example!

Essentially, your quota list is a pre-populated participant list but all you know about your participants initially is their age range and gender. When a data collector completes an assigned participant, they "check them off" by changing their status. That "participant" (or quota as you called it) is then filtered out of the selection list. This is a great approach!

It's a little different from what I had in mind. I was thinking of creating participant entities when a successful interview is submitted. The interview form would both do that entity creation and have the entity list attached to it. It would use existing entities to count how many participants of each age range have been interviewed so far to create a summary of which participant types are still needed.

The disadvantage of my strategy is that the form ends up needing a lot of logic. This could lead to performance issues if there are many participants and could easily contain subtle bugs.

I really like that your strategy is easy to validate: you can scroll through the 1000 quotas and verify that they look like what you expect. The only slight downside is that you have to generate that list up front.

Are there any problems that lead you to want to optimize? Is it difficult to generate the quota lists? I can share a sample form for what I have in mind if you think that would be helpful.

It should be the same! Currently both Collect and Enketo have to re-request the full list of entities from Central every time there's a change. It should take Central only a few seconds to generate entity updates but sometimes it could be a bit longer so if you refresh immediately after submitting, you might not get the new data.

We're actively working on making entities available offline in Collect. That would mean that the quota update would be instant after finalizing a form. As soon as you open another form that uses the quota list, it will see the update without having to be online.

1 Like