Creating funnel flow for mobile native app with web views | Community
Skip to main content
NorData
NorData
Level 2
June 6, 2024
Question

Creating funnel flow for mobile native app with web views

  • June 6, 2024
  • 1 reply
  • 1888 views

Hi Community,

 

Context:

We have built an hybrid app in which some of the flows are using web views. For example: once user clicks on "buy now" on product details page, the web view flow starts and it ends once user lands on "purchase confirmation" screen.  All the previous screens until product details screen are all developed in native.

 

Queries:

  • We would like to create a funnel flow in workspace for the web view screens (from buy now until the purchase confirmation screen), so that we can find out where users are dropping off. 
    • Wondering how we can achieve this? Since we are technically hitting the mobile responsive pages of website, can we just use the page name values from the website(which we are already tracking) to create a funnel? If yes, how do we segment out the mobile NATIVE app traffic on web views? I think the category "mobile phone" from "device type" dimension on workspace only shows the numbers from mobile responsive pages but not native app, if im not wrong.

 

    • Also, does having an additional digitalData object on every page view event on website helps to segment out mobile native app traffic in this case? (something like "mobileTraffic : true/false" to tell if the page was loaded via mobile app or no?). 
    • Our goal is to create two funnels to analyze drop offs 1) for website (users who buys from our website) which is already done. 2) for mobile native app (users who buys from mobile native app).

 

  • Also, can we use all the standard metrics like page views, visits, entries, bounce, exists etc.., for mobile app dashboards as well ? or are we limited to just using "app users", "Launches", "crashes" etc.., ?
  • One challenge we have with our app is that , all the native screens are reporting to different report suite and webview screens are reporting to different screens. Can you please suggest if this is a red flag specially if we are trying to create funnels like i mentioned above?

Appreciate any leads!

 

Thanks,

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 7, 2024

Hi,

 

There's a lot to unpack here, so if I miss something please let me know and I will follow up.

 

If you are trying to do flows that cover both your native app and the webviews within the app, you will first need to ensure that you are passing the user identification properly from the app to the webview so that the different contexts are both registering as the same user and visit. There is a function for this in your mobile app code, I believe this is the appendIdentityToUrl function (but you should make sure that everything has been implemented correctly and this is actually working.

 

Now, as for your comment about "Device Type":

I think the category "mobile phone" from "device type" dimension on workspace only shows the numbers from mobile responsive pages but not native app, if im not wrong

That is not correct, a device type is a device type, regardless of whether the traffic is coming from your website, your mobile app or even AMP. So you cannot rely on this to segment out your app from your website traffic.

 

In my implementation I actually track two separate "lookup" dimensions for helping to facilitate my segments.... one is my Breakpoint Experience which will track things like "desktop", "tablet", "mobile", "app|mobile", "app|tablet", etc (this is based on the responsive breakpoints that users are experiencing regardless of the device they are on, and in the case of our apps, ours don't allow for rotation, and have different layouts depending on the screen real estate of a phone vs a tablet. On top of this, I also have a Site Type which tracks if the site is "core" (meaning our main www site), "app" (our mobile apps), "amp" (our amp experience), and a designation for each of our extended content sub domains, which are still websites and have similar web breakpoints, but they are sites for loading specific related content (we are a news org, so we have things like announcements and obituaries and games, etc). Between these two dimensions I can identify much about the usage and where the pages are being accessed.

 

Now, while we don't have a lot of webview traffic, we do have some... so I also asked our developers to make a slight modification to the User Agent String being used by the webview (this is something a lot of social media apps do, so we did the same)... basically we appended a value to the end of the User Agent to identify the web traffic as being loaded via our app.

 

For example, here is a FB Messenger User Agent example:

Mozilla/5.0 (iPad; CPU OS 10_1_1 like Mac OS X) AppleWebKit/602.2.14 (KHTML, like Gecko) Mobile/14B100 [FBAN/MessengerForiOS;FBAV/122.0.0.40.69;FBBV/61279955;FBDV/iPad4,1;FBMD/iPad;FBSN/iOS;FBSV/10.1.1;FBSS/2;FBCR/;FBID/tablet;FBLC/vi_VN;FBOP/5;FBRV/0]

Notice the content at the end between the [ and ] characters... this allows your tracking to continue to read and identify the proper browser being used, but the additional [custom id] can allow you to identify this and other app webviews. I actually did a session on this a few years ago that you can watch here:

https://experienceleague.adobe.com/en/docs/events/the-skill-exchange-recordings/analytics/sept2021/analytics-rockstars
The tip starts around 23:00

 

With this added to the mix, I now have three dimensions that I can use to build out more complex segments of usage.

 

Once you have created your own dimensions to classify your traffic, you should be able to leverage those to split out your flows as needed.

 

 

can we use all the standard metrics like page views, visits, entries, bounce, exists etc.., for mobile app dashboards as well ? or are we limited to just using "app users", "Launches", "crashes" etc..,

Absolutely, while you have some mobile app specific metrics like Launches and Crashes, all the standard metrics are definitely available within your mobile app, and I encourage you to use them to their full potential... just be aware though, Adobe's default "Bounce Rate" is based on a single server call within a visit... and since there are usually 2 server calls on an app visit (the lifecycle metrics, and the first page) this won't actually work for you...  In my own organization, we don't like that definition of a bounce (not even for web)... we prefer the "Single Page per Visit" definition, and so we created our our calculated metric using "Single Page Visits" divided by Entries or Visits (you might consider doing the same).

 

 

Now, all of my above information is actually based on having your apps and websites tracked in the same suite. While ultimately the decision is up to you, I always prefer consolidation of my data... but this can be a lot of work, since you need to be diligent in ensuring that both your website and app are using the exact same dimensions and events, and are triggering tracking in as similar a way as possible.  There will be some differences... features that are only available in one or the other, but it nice to have them all in one suite because it's easier to pull consolidate reports... Traffic to Page X regardless of the platform, or Total Conversions, etc... you can always create Virtual Report Suites to have just web and just app traffic... and if you have a lot of cross-over app/webview data, you can ensure that ALL of that traffic is available in one place to see a full start to finish flow.

    NorData
    NorDataAuthor
    Level 2
    June 7, 2024

    @jennifer_dungan 

     

    Thank you Jennifer for your detailed reply! Really appreciate it!

     

    We are yet to implement changes to handle the web views for which we will follow the instructions mentioned in below documentations.

     

    https://experienceleague.adobe.com/en/docs/platform-learn/implement-mobile-sdk/app-implementation/web-views

    https://github.com/Adobe-Marketing-Cloud/mobile-services/blob/master/docs/android/reference/hybrid-app.md?lang=en

     

    I've watched your session video around identifying the web views by using user agents. It was very helpful and will implement the same for our app as well.

     

    Now, I also have few follow up questions on some of the things you have mentioned in your reply.

     

    1. Would you be able to please share more details around how you have created the "lookup" dimensions "Breakpoint Experience" and "Site Type" ? I'm assuming you are tracking "Site Type" as an eVar within the main site's (www) page view event?
    2. In regards to the standard metrics for example page views, i'm wondering how adobe tracks page views on native app's (every time a native screen was loaded in an app)? As per my understanding, this metric counts all the page view tracking calls (s.t()) in the report suite, and we have configured it in a "Page Load" rule to fire a page view event with an action "s.t()" on all pages for our website (www). However, with native app we aren't actually firing any (t()) calls and i'm wondering how it is still capturing? May be i'm missing something here?

     

    Thanks again for your help!

      Jennifer_Dungan
      Community Advisor and Adobe Champion
      Jennifer_DunganCommunity Advisor and Adobe Champion
      Community Advisor and Adobe Champion
      June 8, 2024

      Hi @nordata,

       

      You are very welcome.

       

      1. Yes, I just use a standard Hit expiry eVar (or a prop, since it's hit data and doesn't need a lot of characters, 100 is sufficient for this).

       

      For my breakpoint dimension, I use some JS to detect the inner screen width:

      I made sure to match the widths to our website's responsive breakpoints... if we had more major items (like maybe tablet landscape / portrait, or super high res screens maximized for more width, I would add those options as well).

      Then, on my mobile apps, I have the developers pass back "app|mobile" or "app|tablet" based on what version is running.

       

      For "Site Type", I have different Launch properties for each code base, so I basically just hard code a value for each site variant, and again, on the app, we just hard code "app" into that dimension. If you are using a single Launch property that drives different variations, you could either work with your developers to provide a site type value in your data layer, or write a custom code Data Element to identify the variation and send that value through.

       

       

      2. Mobile apps don't use s.t() and s.tl(); you're right, but they have the equivalent... trackState is the equivalent of s.t / page view; and trackAction is the equivalent of s.tl / click / action. Both the trackState and trackAction allow for context variables to be passed. We are still using the older ACP version of the SDK, but the newer AEP SDK that uses XDM Streams would be similar... each of these actions allows a payload to be connected to it (whether it's a set of context variables, or XDM data).

       

      There is a lot of misunderstanding when it comes to mobile apps... I've seen a lot of people think that the extra data can only be sent on the trackAction, but this is not correct, and will result in bad tracking (along with unnecessary inflated server calls).. it would be the equivalent of calling s.t with no dimensions / metrics then immediately calling an s.tl with all your page data.... Your mobile app tracking should try to mirror what you would do on a website, all the info you need on the page view should be part of the trackState, and when you need to track a click, or a triggered action (like a successful conversion or a successful form submission, etc) all the data that you would track on such a call on the website should be include as part of the trackAction.

       

      TrackState will count as a page view in your analytics, and trackAction will appear as Custom Link. Note, this one drives a lot of us crazy, but for some reason all trackActions append "AMACTION:" to the start of the Custom Link name... there is no way to remove that....  Also, you can set the pageName and pageURL values within your app, but be careful, particularly if you are setting these with processing rules.... if either of these are set on a trackAction, the call will count as both a Custom Link and a Page View (which you don't want)... it is best practice to use an eVar to track a duplication of your pageName and URL anyway, so just set those values there on your actions.

      Terms & ConditionsAccessibility statement

      Loading footer...