Change Details

At this time our calculations of number of unique users for iOS and Android are an underestimate. We use tokens to identify app installs and it is only opting in that users send that data. The number of users sending data is very small in iOS so it is likely that our number is far off from the true number of users for the app. If we were to use a more privacy conscious method to calculate uniques we would not require an opt in and thus our estimate of uniques will be a lot more precise. A proposal: Rather than using appinstallids to calculate uniques, let's use a variation of the last access method (https://blog.wikimedia.org/2016/03/30/unique-devices-dataset/). This would require changes in the application code for both android and iOS but changes should be small and probably the payoff of more precise metrics will actually quite make up for those. How would this work: 1. When we install the app we store in the device storage the date in which the install happens in a table -or similar- that just has one field: APP_LAST_ACCESS the value of this field is 2018-10-01. No event gets sent (I assume we track installs in a different way, thus no event is needed). 2. Time passes and user comes to app for the 2nd time after install. User has not used app for couple of days so it is now October 5th. 3. When user engages with app the 1st thing app does is to check whether current date is equal to date stored in APP_LAST_ACCESS field, in this case the date is different thus app sents an event with the following fields (note there is no appInstallId or token of any sort). - user_agent - timestamp, current time 2018-10-05 - time the app was last used, in this case 2018-10-01 4. App updates the APP_LAST_ACCESS to 2018-10-05 5. User continues using the app until app goes to sleep When user engages with the app again 3 and 4 are repeated. Note that this is a simplistic set of steps, it could be that depending on the platform events that signal that the session has started or that application is going to the background the check-sent-and-update-date-sequence might happen in a different way that it is have outlined above. On the server side every record for the day with a date different to current date signals a user that engaged with the app that day. Server side counting is trivial. The harder engineering problem is to make sure the check-sent-and-update-date-sequence is happening properly .

At this time our calculations of number of unique users for iOS and Android are an underestimate. We use tokens to identify app installs and it is only opting in that users send that data. The number of users sending data is very small in iOS so it is likely that our number is far off from the true number of users for the app. If we were to use a more privacy conscious method to calculate uniques we would not require an opt in and thus our estimate of uniques will be a lot more precise. A proposal: Rather than using appinstallids to calculate uniques, let's use a variation of the last access method (https://blog.wikimedia.org/2016/03/30/unique-devices-dataset/). This would require changes in the application code for both android and iOS but changes should be small and probably the payoff of more precise metrics will actually quite make up for those. How would this work: 1. When we install the app we store in the device storage the date in which the install happens in a table -or similar- that just has one field: APP_LAST_ACCESS the value of this field is 2018-10-01. No event gets sent (I assume we track installs in a different way, thus no event is needed). 2. Time passes and user comes to app for the 2nd time after install. User has not used app for couple of days so it is now October 5th. 3. When user engages with app the 1st thing app does is to check whether current date is equal to date stored in APP_LAST_ACCESS field, in this case the date is different thus app sents an event with the following fields (note there is no appInstallId or token of any sort). - user_agent - timestamp, current time 2018-10-05 - time the app was last used, in this case 2018-10-01 4. App updates the APP_LAST_ACCESS to 2018-10-05 5. User continues using the app until app goes to sleep When user engages with the app again 3 and 4 are repeated. Note that this is a simplistic set of steps, it could be that depending on the platform events that signal that the session has started or that application is going to the background make the check-sent-and-update-date-sequence might happen in a different way that it is have outlined above. On the server side every record for the day with a date different to current date signals a user that engaged with the app that day. The harder engineering problem is to make sure the check-sent-and-update-date-sequence is happening properly .

At this time our calculations of number of unique users for iOS and Android are an underestimate. We use tokens to identify app installs and it is only opting in that users send that data. The number of users sending data is very small in iOS so it is likely that our number is far off from the true number of users for the app. If we were to use a more privacy conscious method to calculate uniques we would not require an opt in and thus our estimate of uniques will be a lot more precise. A proposal: Rather than using appinstallids to calculate uniques, let's use a variation of the last access method (https://blog.wikimedia.org/2016/03/30/unique-devices-dataset/). This would require changes in the application code for both android and iOS but changes should be small and probably the payoff of more precise metrics will actually quite make up for those. How would this work: 1. When we install the app we store in the device storage the date in which the install happens in a table -or similar- that just has one field: APP_LAST_ACCESS the value of this field is 2018-10-01. No event gets sent (I assume we track installs in a different way, thus no event is needed). 2. Time passes and user comes to app for the 2nd time after install. User has not used app for couple of days so it is now October 5th. 3. When user engages with app the 1st thing app does is to check whether current date is equal to date stored in APP_LAST_ACCESS field, in this case the date is different thus app sents an event with the following fields (note there is no appInstallId or token of any sort). - user_agent - timestamp, current time 2018-10-05 - time the app was last used, in this case 2018-10-01 4. App updates the APP_LAST_ACCESS to 2018-10-05 5. User continues using the app until app goes to sleep When user engages with the app again 3 and 4 are repeated. Note that this is a simplistic set of steps, it could be that depending on the platform events that signal that the session has started or that application is going to the background make the check-sent-and-update-date-sequence might happen in a different way that it is have outlined above. On the server side every record for the day with a date different to current date signals a user that engaged with the app that day. Server side counting is trivial. The harder engineering problem is to make sure the check-sent-and-update-date-sequence is happening properly .