Mobile App Dashboard Template

[pauldambra]

We want to add a mobile app dashboard template

What should go on it?

(cc @marandaneto @andyvan-ph)

[marandaneto]

There are a bunch of dashboard templates that would make sense. Eg

• DAU
• MAU
• Stickiness ratio based on DAU/MAU
• App version adoption (90% of my users are in the 6.0 version and 10% in the 5.0 version) based on $app_version and $app_build
• Install/Updated vs Uninstall conversion (We don't have an uninstall event, so we'd need to consider it as uninstalled when a user does not send events for a few weeks?) based on Application Installed and Application Updated, so you can calculate The cost per install (CPI), Retention rate, Churn rate
• Average session duration based on Application Opened and Application Backgrounded events or somehow via $session_id
• Most common deep links via Deep Link Opened event
• Most common screens via $screen event, you can calculate the Exit rate
• User adoption per Country/Region and/or Language based on $locale, I guess Country is inferred by the server?
• Most common devices/OS versions based on $device_manufacturer, $device_model, $os_name, $os_version, etc...
• Most common screen sizes based on $screen_height, $screen_width
• Most common connection type based on $network_wifi, $network_bluetooth, $network_cellular
• More ideas https://developer.apple.com/app-store/measuring-app-performance/

Those are just ideas, some of them are important, and some of them are not so much.

[pauldambra]

Quick first run in the manoel testing project https://us.posthog.com/dashboard/120138

[marandaneto]

Quick first run in the manoel testing project us.posthog.com/dashboard/120138

Nice, I've fixed a few of them to not depend only on the $screen events but rather all events.

A few notes:

App build adoption is pretty much the same as the App version Adoption, I guess we can kill it in favor of App version Adoption only since its the human-readable version.

Most common devices I'd not use the $os_name and $os_version here otherwise its too fragmented, I'd rather have another dashboard template for OS version breakdown.

User stickiness is actually a calculation on top of the MAU/DAU, See here.

Application Opened's Session duration average depends on the Application opened event, but since we have $session_id now, should it be for all events instead?

[pauldambra]

App build adoption is pretty much the same as the App version Adoption, I guess we can kill it in favor of App version Adoption only since its the human-readable version.

👍

Most common devices I'd not use the $os_name and $os_version here otherwise its too fragmented, I'd rather have another dashboard template for OS version breakdown.

👍

User stickiness is actually a calculation on top of the MAU/DAU, See [here (https://support.google.com/analytics/answer/12993725?hl=en).

👁️

Application Opened's Session duration average depends on the Application opened event, but since we have $session_id now, should it be for all events instead?

So, it takes all sessions with an application openend event in them. Then for each session finds the duration between the first and last event in that session. Then averages those values (or applies whatever calculation you put). Could be all events

[pauldambra]

User stickiness is actually a calculation on top of the MAU/DAU, See [here (https://support.google.com/analytics/answer/12993725?hl=en).

OK, so we group per insight not per series, which means I can't put DAU and MAU on the same chart and then get a ratio.

But, the built in stickiness chart gives a similar reading by showing how many days out of the last X days a user did an action. So for screen events.

So, in this test project we had

• 4 users who did a screen event only on any 1 day of the last 8
• 1 user who did a screen event on any 2 days of the last 8
• and 1 user who did a screen event on any 3 days of the last 8

Which is close enough for rock & roll in comparison 🙈

[marandaneto]

User stickiness is a calculation on top of the MAU/DAU, See [here (https://support.google.com/analytics/answer/12993725?hl=en).

OK, so we group per insight not per series, which means I can't put DAU and MAU on the same chart and then get a ratio.

But, the built-in stickiness chart gives a similar reading by showing how many days out of the last X days a user did an action. So for screen events.

So, in this test project we had

• 4 users who did a screen event only on any 1 day of the last 8
• 1 user who did a screen event on any 2 days of the last 8
• and 1 user who did a screen event on any 3 days of the last 8

Which is close enough for rock & roll in comparison 🙈

Yep, I still wouldn't use it only for $screen events, the stickiness ratio is actually to tell if the users are using the app or not (engagement), $screen is just a feature, so it should be for all events, the same for MAU/DAU.

If users wanna calculate the stickiness ratio of a specific feature/event, they can use this one as a template and modify the events, but it should not be one of our "default" templates.

Although the current one already gives you some insight, the User stickiness is a standard metric for Mobile apps and people understand it well, diverging from that is something I'd not like to do, the goal is to make PH more mobile friendly, and having Mobile dashboard templates that people already understand would be ideal unless of course it's not possible somehow.

[pauldambra]

User stickiness is a calculation on top of the MAU/DAU, See [here (https://support.google.com/analytics/answer/12993725?hl=en).

I wonder if it's something @robbie-c or @PostHog/team-product-analytics have thought about adding...

[robbie-c]

Hey, so I haven't thought about this specifically, but DAU divided by MAU, or DAU divided by WAU are pretty standard depending on the usage patterns users would expect with the app (maybe even WAU/MAU if it's an app that would only be used weekly, like idk a weekly shopping app or something).

I do have lots of thoughts about what should be on the mobile dashboard, before PostHog I was a founder of a B2C mobile app startup so I can share what was on our dashboards. It was a freemium app so that'll skew some of my thoughts. Some of these would be impossible to include without e.g. billing data from Stripe/Revenuecat/etc but I'll add them anyway in case we refer back to this issue after data warehouse. In our case these were split across multiple tools.

• Usage retention, up to 28 days, both n-day and unbounded are interesting but n-day is more important (split by paid users, free users, all users)
• Stickiness (DAU/MAU) (same split) ideally excluding users' first session / day from the calculation
• Revenue retention
• Usage conversion funnel of main app journey, any order (app specific, but might be something like open app -> create account -> view some content -> invite a friend)
• Payment conversion funnel of main app journey, any order (open app -> create account -> view subscription screen -> start trial -> complete trial -> renew subscription)
• Conversion rate of the subscription page (breakdown by source, e.g. onboarding flow, deep link url, in-app banner name), some other app-specific conversion funnels too
• Churn survey reason (multiple choice, email sent on trail cancellation or billing churn for paid, or uninstall event for free) over time
• NPS survey over time (email sent on end of trial)
• MAU/DAU over time
• MRR over time

Ideally these would have breakdowns, the important ones are:

• user acquisition channel (e.g. google ads, referral, etc)
• app platform
• probably others that I'm forgetting right now

Mobile apps can often get a lot of downloads that just open the app and leave immediately, especially if your ad campaigns are badly set up, so it's good to filter most of the graphs to only users who have done a particular event, e.g. logged in, viewed a certain screen, generally something quite early so as not to exclude real users. The one exception is the conversion funnel, where you do want to start at app open.

P.S. I've definitely missed some things 😅

[pauldambra]

OK, so for our test project we now have this screenshotted dashboard... I don't think the other things can be done without some proper effort. But that ties in with our Q1 goals assuming we get goal 1 and 2 under control

[pauldambra]

interesting lifecycle worked in the browser but not in the export 🙈

[pauldambra]

Ah @marandaneto I realised the drawback with "All events" here... if you have also web events then you don't want "all events" you want "all mobile events"??

[pauldambra]

So I guess "All events where device type is mobile"

[marandaneto]

So I guess "All events where device type is mobile"

Yep, but some SDKs need fixing eg https://github.com/PostHog/posthog-js-lite/issues/135

[marandaneto]

Ah @marandaneto I realised the drawback with "All events" here... if you have also web events then you don't want "all events" you want "all mobile events"??

If it's common that people mix up different SDKs under the very same project, yeah, we'd need to filter per $device_type or something like that eg $lib.

[marandaneto]

https://posthog.com/changelog/2024/mobile-analytics-template-added