Hi community!
I have a question regarding ANDROID/DESKTOP data collection done: if there any possibility to get how the enrollments/events have been entered/recorded into DHIS2.
I just want to know how many users entered data by using ANDROID or DESKTOP app, and analyse the data entry errors rate and provide respective trainings.
Would be happy to get any suggestions, even it is not possible to get by the standard DHIS tools.
Thank you
Regards,
Ulanbek
Hello @Ulanbek . My first thought is to analyse by user, if you have created different users for Android and Desktop you could extract that information directly from the DB. Maybe you can make a SQL query to access that information from the interface (although not sure about that as I would probably target directly the DB). If the user is shared (the same user entering data via two methods) you could extract this information from the web server logs.
Those are my suggestions, maybe someone else might have a better answer so I will monitor to learn from this post 
Thank you for your answer. Unfortunately tomcat logs are not available for longer period, as the provider delete them daily. And all my users use both: mobile app and desktop.
Therefore would be great somehow to record source of users app into audit file.
So let’s wait if anyone else has other ideas
Thank you
@Ulanbek I’ve noticed but never made use of the differences of detail between mobile and browser based capture, namely on dueDate. For us (2.37.9.1 and previous, so far as I know) mobile entered events will have Time specification on the dueDate, i.e. dueDate=“2023-01-05T09:30:24.578” whereas browser based entry will not, i.e. dueDate=“2023-09-18T00:00:00.000”
If this is consistent for you, I can imagine this would at least get you something to work with?
Hi @Ulanbek
Thank you for the post! This is an interesting feature request because I don’t think there’s an out of the box solution to be able to differentiate between android users and web browser users. I think this information would be interesting if added to the Data Statistics in the Data Administration app:
Would you like to create a feature request in Projects - Jira with your account and add the CoP label? Please post the link here so other community members would vote/watch/comment if this interests them as well.
Thanks!
@vgarciabnz , maybe you can add here something in terms of datetime filled in the App? I am not sure why such a difference in between both, and maybe @Markus can confirm that this behavior is not really intentional?
Morning @Matthew_Boddie
I have checked all my programs and their events’ dueDates. Unfortunately I couldn’t find any link to the dueDate field for Adnroid/Desktop app used. Currently I am using 2.36.12.1 and when I downloaded all records for the countries where Apps are not used and those where the App partially in use I could find all dueDate field are filled with values. So it is not clear.
I have create a feature request ticket [DHIS2-15861] - Jira as suggested @Gassim. I believe it would be great to have not only number of Android/Desktop user, but also active users for the last month/half year/year.
Thank you
Regards,
Ulanbek
Sorry for sending you down a wrong direction @Ulanbek ! I’ll have another look on my side just to see why I have that on my side—given what you’ve found, it must be on the side of a custom app we use for data entry. cc @jaime.bosque @vgarciabnz @Markus as I don’t want to send you down rabbit holes either!
Hi all! The suggestion by Matthew makes sense to me, although I have never tested it myself. The Android app includes a timestamp in both eventDate (ocurredAt in newer versions) and dueDate (scheduledAt in newer versions). So you should find something like 2023-01-07T00:00:00.000 for web users and 2023-01-07T11:45:12.456 for Android users.
That said, there was a bug that could make it not work in older versions ([DHIS2-14836] - Jira). In short, evenDates were correctly stored in the database including timestamp, but they were exposed in the API without timestamp. The issue was backported down to 2.38, which means that for versions < 2.38
Other parameters worth checking are createdAtClient and lastUpdatedAtClient. The Android app fills in these parameters, so if they have an actual value we could assume they come from an Android client. This properties apply to trackedEntity, enrollment and event. But there was an issue that could make it not work in some cases, this issue was fixed in 2.8.0 (Android SDK for DHIS2 - Issues - Jira).
Please let us know about your findings in any approach
Dear @vgarciabnz
Thank you for your detailed answer.
I will check it and revert back to you
Regards,
Dear @vgarciabnz
Thank you for your detailed explanation. I have checked on my DHIS2.36 instance and couldn’t find any connections between the dates and actual data entered by the Android app. Most probably version 2.36 doesn’t support it and works differently.
Thank you again
Regards,
Ulanbek
