Details
On PLH Teens TZ, there are a couple of users whose app launch count reduced (which should not be possible). The hypothesis is that they cleared their app cache/data, potentially by uninstalling and reinstalling the app. There is no way to verify this assumption in the postgres data at the moment:
We do have a CreatedAt timestamp in the postgres data, but this is unchanged for these users so cannot be used to verify the hypothesis. This is expected, since it is the timestamp in which the user ID was first created in the postgres table.
We do have an app_events_summary key visible on the web app, which contains a first_app_launch timestamp, but this variable doesn't seem to make its way to postgres.
I think this key is legacy (one of its properties is app_day which was something specific to one deployment that was discarded a long time ago) and can be removed.
I could already store a first_app_launch contact field through the templates, but since this could be useful for debugging any app it might make sense to put it in as a protected variable _first_app_launch (or maybe _app_launch_first to be consistent with the existing variables _app_version and _server_sync_latest)
esmeetewinkel
commented
4 months ago
Details On PLH Teens TZ, there are a couple of users whose app launch count reduced (which should not be possible). The hypothesis is that they cleared their app cache/data, potentially by uninstalling and reinstalling the app. There is no way to verify this assumption in the postgres data at the moment:
CreatedAttimestamp in the postgres data, but this is unchanged for these users so cannot be used to verify the hypothesis. This is expected, since it is the timestamp in which the user ID was first created in the postgres table.app_events_summarykey visible on the web app, which contains afirst_app_launchtimestamp, but this variable doesn't seem to make its way to postgres.app_daywhich was something specific to one deployment that was discarded a long time ago) and can be removed.I could already store a
first_app_launchcontact field through the templates, but since this could be useful for debugging any app it might make sense to put it in as a protected variable_first_app_launch(or maybe_app_launch_firstto be consistent with the existing variables_app_versionand_server_sync_latest)