Mobile Tracking for Low Touch Apps: Frameworks and Tips

Imagine that one morning, you open Teams or Slack and see a message from one of the stakeholders saying: “Our competitor is proud of XX million installs due to his last report; how many do we have?”. If you have ever tried to answer that question meaningfully, you already understand how tricky it can be. Do they just mean the number of installations due to Store statistics? Users or app instances? It’s all installations minus every uninstallation since the Big Bang? Do XX installations mean that XX people use that application? Functioning devices with already installed but still not uninstalled instances of the app? It’s easy to avoid those questions when speaking about high-frequency user needs (as they naturally use the application often). We only measure users’ activity without any awareness of mobile tracking technical specifics. It becomes harder if our application is purposed to solve user problems that happen less frequently (e.g., insurance or hospital apps). In this article, I will provide several frameworks that can bring clearance and transparency to quantified discussions about such apps. Key objects It’s necessary to distinguish the difference between three types of objects: Users Mobile devices – you can’t measure anything useful about the device itself since you are not a Google \ Apple \ or other device vendor. Installation – the instance of your mobile app installed on the mobile device. Some product and martech managers don’t distinguish between installations, ignoring the physical nature of the device and installations. Often, it leads to messing things up – like thinking about a new installation as a new customer. As soon as your current customers can reinstall your app, such assumptions will lead to the wrong data and, what matters most – wrong dynamics. It’s impactful – people change their devices every 43 months (worldwide average), so every year ~28% of your customers will update their phone. Thus, scoring that “new installs” as growth is just wrong. For the low-touch apps of insurance companies, hospitals or even niche e-commerce apps, a new kind of problem arises. You have invested a lot of effort in user acquisition and converting users to authorization, and now dashboards say that you have XX percent of customers with installed apps. You send them app pushes but observe unexpectedly low conversion. Moreover, that conversion degrades over time. Two years later, at least half of the "so-called users with an app" don't have an app (or they do have it, but they don't authorize on it anymore). You are still sending the communication on their old devices without noticing they are already gone. Your product analytics and marketing communication teams spend endless hours trying to understand why the numbers from their dashboards don’t match. That problem is quite common. It can be solved in four simple steps: Distinguish objects (we are here now) Add 7 attributes to your tracking system Implement one prediction model Put things together in the right data structure How to track a new installation and what attributes to add to telemetry There is no direct way to know if someone installed your application. There is no direct way to see if someone deleted your app. There is no direct way to understand if someone drowns their phone or resets it to factory defaults. However, there is a way to interpret available data and answer most questions. In this section, we won’t discuss tracking or attribution of application installations. Instead, we’ll focus on the direct and indirect tracking of events that happen after the application is installed. One more remark here: there is no way to directly catch your application installed BEFORE the user launches it. However, it's pretty simple to track everything at the "DARK GREEN" zone – when your application is in the foreground; it can execute your code and can send some events like "I'm launched", "user clicked", "I'm on the screen 30 seconds without any user activity", etc. It's where you should work with managing the Installation_ID (it's like user_ID but for every unique installation): At the launch, your application checks (locally) if it had initialised Installation_ID before; If not, it should generate a new Installation_ID. Then, it should store Installation_ID locally and send the “First_application_launch” event to your tracking system; Raise an "Application is an on-screen" event with the Installation_ID attribute; **Note that it's useful to add the Installation_ID attribute to any other event you want to measure against installations. In the real world, you also have to handle the network availability issues, so the scheme becomes slightly complex, but still, it's a relatively small piece of code to add to your app and tracking environment. These 6 attributes are most commonly collected on Apple devices (and they are very similar on other platforms): Installation_ID – issued by you as a vendor, and it is the main identifier for the installation. It existed from the first launch till the deletion. The version upgrade didn't make any changes to them. IDFA – ID for Advertisement - issued by Apple and used to identify client devices. Your app can't access that attribute without direct technical consent from the client. IDFV – ID for Vendors. The value of this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. Current application version Notification permission authorisations – enumerate specific access your customer grants to applications for sending local and remote notifications (badges, alerts, sounds). Device Token for the Apple notification services (APNS) The ID of the logged user How to track that my application was deleted and why to build a prediction model Once again, there is no direct way to know if someone installed your application, deleted it or reset it to factory defaults. However, there is a way to interpret available data and answer most of the questions. There is no specific signal from your application, Apple or Google, that you can use to mark the installation as removed. But you can use the absence of activity from installation to predict that the installation is deleted, the device is reset, or even no longer exists. The dependence between the chance of receiving the next event from the installation and the number of days, that passed since the last installation activity usually looks like this reverse exponential curve: You can collect two types of activity to train your simple prediction model: initiated by the user (like app opens or some actions in the app) or notification-related (APNS, local notifications, etc). There is a great article about notifications at Apple and StackOverflow for tracking development details. It's important to understand that you should put some threshold on the graph and decide that "if the chance to have any activity from installation in the next 1 year is less than XX%, then you mark that installation as uninstalled". It is equivalent to saying that your installation is alive if it has had any activity for the last N days. Adding some additional logic like reinstallation detection through IDFA is also useful – this way you can mark previous installation on the same IDFA as uninstalled without waiting for XX days. Example of the data structure After collecting data the way I described above, you will have enough information to answer most common installation-related questions in a clear and transparent way. Here is an example of a typical data structure for the analytical cube/pivot table: Snapshot date – the basis for historical analyses First launch date – the basis for any kind of cohort analysis Last on-screen date Last activity date Aliveness metrics: Alive due to day180 criteria (last activity less than 180 days ago + no signals of reinstallation; chance of capture activity in the next 365 days less than 5%) - if something is not alive due to this measure – then it’s definitely uninstalled Alive due to day90 criteria (last activity less than 90 days ago + no signals of reinstallation; chance of capture activity in the next 365 days less than 10%) Alive due to day30 criteria Alive due to day7 criteria Alive due to day1 criteria Been launched at least once no matter when Technical consents for the notifications Is the user logged on the installation or not As a final note, maintaining the lifecycle of installations can concrete the foundation for the analytical and martech systems. It’s pretty simple and still useful for many product and marketing decisions. Feel free to share your experience and tips in the comments section. Imagine that one morning, you open Teams or Slack and see a message from one of the stakeholders saying: “Our competitor is proud of XX million installs due to his last report; how many do we have?”. If you have ever tried to answer that question meaningfully, you already understand how tricky it can be. Do they just mean the number of installations due to Store statistics? Users or app instances? It’s all installations minus every uninstallation since the Big Bang? Do XX installations mean that XX people use that application? Functioning devices with already installed but still not uninstalled instances of the app? It’s easy to avoid those questions when speaking about high-frequency user needs (as they naturally use the application often). We only measure users’ activity without any awareness of mobile tracking technical specifics. It becomes harder if our application is purposed to solve user problems that happen less frequently (e.g., insurance or hospital apps). In this article, I will provide several frameworks that can bring clearance and transparency to quantified discussions about such apps. Key objects It’s necessary to distinguish the difference between three types of objects: It’s necessary to distinguish the difference between three types of objects: Users Mobile devices – you can’t measure anything useful about the device itself since you are not a Google \ Apple \ or other device vendor. Installation – the instance of your mobile app installed on the mobile device. Users Users Mobile devices – you can’t measure anything useful about the device itself since you are not a Google \ Apple \ or other device vendor. Mobile devices – you can’t measure anything useful about the device itself since you are not a Google \ Apple \ or other device vendor. Installation – the instance of your mobile app installed on the mobile device. Installation – the instance of your mobile app installed on the mobile device. Some product and martech managers don’t distinguish between installations, ignoring the physical nature of the device and installations. Often, it leads to messing things up – like thinking about a new installation as a new customer. As soon as your current customers can reinstall your app, such assumptions will lead to the wrong data and, what matters most – wrong dynamics. It’s impactful – people change their devices every 43 months ( worldwide average ), so every year ~28% of your customers will update their phone. Thus, scoring that “new installs” as growth is just wrong. worldwide average worldwide average For the low-touch apps of insurance companies, hospitals or even niche e-commerce apps, a new kind of problem arises. You have invested a lot of effort in user acquisition and converting users to authorization, and now dashboards say that you have XX percent of customers with installed apps. You send them app pushes but observe unexpectedly low conversion. Moreover, that conversion degrades over time. Two years later, at least half of the "so-called users with an app" don't have an app (or they do have it, but they don't authorize on it anymore). You are still sending the communication on their old devices without noticing they are already gone. Your product analytics and marketing communication teams spend endless hours trying to understand why the numbers from their dashboards don’t match. That problem is quite common. It can be solved in four simple steps: That problem is quite common. It can be solved in four simple steps: Distinguish objects (we are here now) Add 7 attributes to your tracking system Implement one prediction model Put things together in the right data structure Distinguish objects (we are here now) Distinguish objects (we are here now) Add 7 attributes to your tracking system Add 7 attributes to your tracking system Implement one prediction model Implement one prediction model Put things together in the right data structure Put things together in the right data structure How to track a new installation and what attributes to add to telemetry There is no direct way to know if someone installed your application. There is no direct way to see if someone deleted your app. There is no direct way to understand if someone drowns their phone or resets it to factory defaults. However, there is a way to interpret available data and answer most questions. There is no direct way to know if someone installed your application. In this section, we won’t discuss tracking or attribution of application installations. Instead, we’ll focus on the direct and indirect tracking of events that happen after the application is installed. One more remark here: there is no way to directly catch your application installed BEFORE the user launches it. However, it's pretty simple to track everything at the "DARK GREEN" zone – when your application is in the foreground; it can execute your code and can send some events like "I'm launched", "user clicked", "I'm on the screen 30 seconds without any user activity", etc. It's where you should work with managing the Installation_ID (it's like user_ID but for every unique installation): At the launch, your application checks (locally) if it had initialised Installation_ID before; If not, it should generate a new Installation_ID. Then, it should store Installation_ID locally and send the “First_application_launch” event to your tracking system; Raise an "Application is an on-screen" event with the Installation_ID attribute; **Note that it's useful to add the Installation_ID attribute to any other event you want to measure against installations. At the launch, your application checks (locally) if it had initialised Installation_ID before; If not, it should generate a new Installation_ID. Then, it should store Installation_ID locally and send the “First_application_launch” event to your tracking system; Raise an "Application is an on-screen" event with the Installation_ID attribute; **Note that it's useful to add the Installation_ID attribute to any other event you want to measure against installations. In the real world, you also have to handle the network availability issues, so the scheme becomes slightly complex, but still, it's a relatively small piece of code to add to your app and tracking environment. These 6 attributes are most commonly collected on Apple devices (and they are very similar on other platforms): These 6 attributes are most commonly collected on Apple devices (and they are very similar on other platforms): Installation_ID – issued by you as a vendor, and it is the main identifier for the installation. It existed from the first launch till the deletion. The version upgrade didn't make any changes to them. IDFA – ID for Advertisement - issued by Apple and used to identify client devices. Your app can't access that attribute without direct technical consent from the client. IDFV – ID for Vendors. The value of this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. Current application version Notification permission authorisations – enumerate specific access your customer grants to applications for sending local and remote notifications (badges, alerts, sounds). Device Token for the Apple notification services (APNS) The ID of the logged user Installation_ID – issued by you as a vendor, and it is the main identifier for the installation. It existed from the first launch till the deletion. The version upgrade didn't make any changes to them. Installation_ID – issued by you as a vendor, and it is the main identifier for the installation. It existed from the first launch till the deletion. The version upgrade didn't make any changes to them. IDFA – ID for Advertisement - issued by Apple and used to identify client devices. Your app can't access that attribute without direct technical consent from the client. IDFA – ID for Advertisement - issued by Apple and used to identify client devices. Your app can't access that attribute without direct technical consent from the client. ID for Advertisement ID for Advertisement IDFV – ID for Vendors. The value of this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. IDFV – ID for Vendors . The value of this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. ID for Vendors ID for Vendors Current application version Current application version Notification permission authorisations – enumerate specific access your customer grants to applications for sending local and remote notifications (badges, alerts, sounds). Notification permission authorisations – enumerate specific access your customer grants to applications for sending local and remote notifications (badges, alerts, sounds). Notification permission authorisations Notification permission authorisations Device Token for the Apple notification services (APNS) Device Token for the Apple notification services (APNS) The ID of the logged user The ID of the logged user How to track that my application was deleted and why to build a prediction model Once again, there is no direct way to know if someone installed your application, deleted it or reset it to factory defaults. However, there is a way to interpret available data and answer most of the questions. There is no specific signal from your application, Apple or Google, that you can use to mark the installation as removed. But you can use the absence of activity from installation to predict that the installation is deleted, the device is reset, or even no longer exists. The dependence between the chance of receiving the next event from the installation and the number of days, that passed since the last installation activity usually looks like this reverse exponential curve: You can collect two types of activity to train your simple prediction model: initiated by the user (like app opens or some actions in the app) or notification-related (APNS, local notifications, etc). There is a great article about notifications at Apple and StackOverflow for tracking development details . article about notifications at Apple article about notifications at Apple StackOverflow for tracking development details StackOverflow for tracking development details It's important to understand that you should put some threshold on the graph and decide that "if the chance to have any activity from installation in the next 1 year is less than XX%, then you mark that installation as uninstalled". It is equivalent to saying that your installation is alive if it has had any activity for the last N days. Adding some additional logic like reinstallation detection through IDFA is also useful – this way you can mark previous installation on the same IDFA as uninstalled without waiting for XX days. Example of the data structure After collecting data the way I described above, you will have enough information to answer most common installation-related questions in a clear and transparent way. Here is an example of a typical data structure for the analytical cube/pivot table: Here is an example of a typical data structure for the analytical cube/pivot table: Snapshot date – the basis for historical analyses First launch date – the basis for any kind of cohort analysis Last on-screen date Last activity date Aliveness metrics: Alive due to day180 criteria (last activity less than 180 days ago + no signals of reinstallation; chance of capture activity in the next 365 days less than 5%) - if something is not alive due to this measure – then it’s definitely uninstalled Alive due to day90 criteria (last activity less than 90 days ago + no signals of reinstallation; chance of capture activity in the next 365 days less than 10%) Alive due to day30 criteria Alive due to day7 criteria Alive due to day1 criteria Been launched at least once no matter when Technical consents for the notifications Is the user logged on the installation or not Snapshot date – the basis for historical analyses First launch date – the basis for any kind of cohort analysis Last on-screen date Last activity date Aliveness metrics: Alive due to day180 criteria (last activity less than 180 days ago + no signals of reinstallation; chance of capture activity in the next 365 days less than 5%) - if something is not alive due to this measure – then it’s definitely uninstalled Alive due to day90 criteria (last activity less than 90 days ago + no signals of reinstallation; chance of capture activity in the next 365 days less than 10%) Alive due to day30 criteria Alive due to day7 criteria Alive due to day1 criteria Been launched at least once no matter when Technical consents for the notifications Is the user logged on the installation or not As a final note, maintaining the lifecycle of installations can concrete the foundation for the analytical and martech systems. It’s pretty simple and still useful for many product and marketing decisions. Feel free to share your experience and tips in the comments section.