Adobe Analytics

jaishal · 11/26/24

Hi Everyone,

We have Adobe Mobile SDK integrated into our mobile apps. I am just trying to understand in general how Mobile apps are different from web?

1. What is the correct terminology that is used for each page in Mobile app. Is it a "view", is it a "page"? What is the standard way of defining it?

2. Are there URL's in mobile apps? If so how do they work?

3. Is it recommended to track URLs / URIs in mobile apps in regards to performance tracking and marketing analytics?

Jennifer_Dungan · 11/26/24

Mostly it's the technology that is the big difference... using an SDK installed in the app, with greater reliance on the developers... while yes this can be connected to Launch, you can't run JS or do a lot of manipulation of the data, there is no DOM to read, etc...

For your specific questions:

1. What is the correct terminology that is used for each page in Mobile app. Is it a "view", is it a "page"? What is the standard way of defining it?

Meh, some systems call it a "Screen View"... but really, we just continue with the "Page View" terminology... especially since in Adobe, you will use the page view metric. We roll all our apps into the same global suite as our websites... we pass the same "page names", "channels", "URLs" (even though it's a native app, each page or screen of the app has an equivalent web URL, so we pass that), all the same dimensions and metrics, etc...

We have a few "lookup" type dimensions, such as our "breakpoint" which on web tracks desktop, tablet or mobile depending on the responsive breakpoint, and on our apps we send app|mobile or app|tablet depending on if it's the phone or tablet version. We also have another dimension which is used to help distinguish all our variations, "core site", "obituaries", "classifieds", "app", etc (basically this allows us to segment by the the site or app we control, or our third-party subdomains, etc).

There are a few app specific features that have tracking that doesn't exist on our web, and we just note that in the description of the dimensions and metrics used for them.

2. Are there URL's in mobile apps? If so how do they work?

I touched on this briefly... if you have a Native App, then technically no... if you are using an app wrapper and webviews (definitely yes, but you also have to make sure you aren't double counting your app and web on the same view). However, as I mentioned, we know exactly what pages belong to what URLs, this is also part of the Universal Linking (i.e. if someone opens a link on their phone, and they have the app installed; the app will open to that page and not open in a browser). I am sure you have seen this behaviour in other apps. So while the page itself is not really loaded via a URL, your developers should know the equivalent URL that they can pass for tracking purposes.

3. Is it recommended to track URLs / URIs in mobile apps in regards to performance tracking and marketing analytics?

I would say absolutely yes... this also falls in line with our Universal Linking... for us, when a user opens a newsletter or marketing email link for instance, there are campaigns... I track the URL (with those campaigns), which also will get picked up by my Marketing Channel rules, but I also make sure my developers get all my campaign data so I can pass it to the standard Tracking Code dimension (1 week attribution), as well as all my custom campaign tracking solutions (which are all set to Visit level attribution).

And while I have a lot of URLs, so that the low traffic bucket applies, for popular pages, I can segment or pull data based on URL across my network (web and app together) because I am tracking the URL.

jaishal · 11/30/24

Thank you so much for detailed explanation.

Regarding Mobile Apps, have few questions like is there a metric that measures following KPI's:

1. Load time – how much time it takes for an app to load from the initial tap to being ready to use

2. Crashes/exceptions

3. Uninstall

4. Churn Rate

5. API Latency

Jennifer_Dungan · 11/30/24

You're welcome.

So:

1. Load time – how much time it takes for an app to load from the initial tap to being ready to use

No, there is nothing out of the box... however, you might be able to work with your developers to create some custom tracking. It may not catch the entire load time; but if the developers can prioritize tracking time as soon as the app starts to load until it's ready to use, they can send that data to you for tracking purposes.

Now, the web plugin that used to do this is deprecated (due to modern browsers no longer supporting the PerformanceTiming interface, but you can take some inspiration from how it used to work to determine how to send the information to yourself. Basically, the old plugin recommended sending the information in a dimension (keep in mind that dimensions are stored as text, so that you could see the individual load values, as well as they sent the information to a numeric event (i.e. an event that can pass a specific numerical value like "event1=645" - so that the metric was incremented by 645 - you will have to choose what scale you want to collect the data in... milliseconds, seconds, minutes, etc). The event data will roll up, but you can use it to calculate average (like "initial load time" / visits...)

Play around with how the information will make sense to you, and you should be able to get something.

2. Crashes/exceptions

Yes-ish... so Adobe does have "Crashes" as part of the lifecycle metrics... basically, if the app closes unexpectedly, the next time it is opened, it will send a "crashEvent" along with the "launchEvent". If the user never opens the app again after a crash, this obviously won't send.

You also need to make sure that your developers are handling Lifecycle Metrics properly... When the app is stated, Lifecycle metrics need to be initialized / turned on... when the app is sent to the background, the Lifecycle Metrics need to be paused, and when the app is brought back from the background, the Lifecycle Metrics need to be unpaused.

This is because if someone sends your app to the background, and then "swipes it off" to close it... if the Lifecycle Metrics haven't been paused, this will be treated like a crash, so obviously not the ideal situation.

3. Uninstall

No, unfortunately, since uninstalls are done outside of the app itself, there is no way to properly track this to my knowledge.... I also think a lot of devices have disabled a lot of "background pushes" that might have allowed you to create a custom tracking solution for this....