Adobe Analytics

aablank1 · 10/4/23

Our developers are looking at including wrapped web pages (with the Adobe Analytics JavaScript tags on them) in our mobile app. Is there documentation that shows how to make sure they are included in the mobile app tracking?

Jennifer_Dungan · 10/4/23

So this is an interesting, and unfortunately tied specifically to your custom implementation scenario; so there's no real documentation....

The thing is, mobile app tracking has metrics like App Version and Lifecycle metrics which cannot be a part of your web JS tracking... but I understand that logically you would want to track those pages within your own "App traffic" definitions....

First, I assume you are passing the ECID values from the app to the webview pages, and that your website is reading those parameters and making sure to identify the user as the same ID.

Now, there are different ways to do this, but it would still be customized...

There are different ways to identify this.. you could use a custom parameter passed on Webviews to indicate that your App was loaded within the app (this of course might end up getting shared as a link which would impact your ability to track reliably).

Here is what I use, but it's a bit more involved. I actually used a trick used by a lot of social media apps, I had our developers append a custom value to the User Agent within the app. Basically, all webviews through an app use your default browser to render the content (the content will be identified as that browser / OS)... appending to the end a value like "[my app]" doesn't change how Adobe / Google / etc identify the app, but you can actually create a rule to check for "[my app]" and code in special tracking for anything loaded in this scenario. If on your website you see this User Agent variation, you can set a dimension that you use in segmentation to identify web from app (however you are determining that)

aablank1 · 10/4/23

Thanks for that answer. I especially like the user agent alteration. We have a different report suite for web and mobile app. I'd like to change between them depending on user agent.

I'm not as familiar with web views. Would the tracking be the same if the web pages were "sliced" so that they don't have the navigation or footer? The screen template essentially frames in the main part of each page. I'm wondering if (conceptually) web views are that easy.

Jennifer_Dungan · 10/4/23

Trying to switch the tracking suite programatically can be done, but this can become a potential failure point... personally I wouldn't separate the tracking between web and apps... that is really just making your life harder when you need to pull overall stats (it's easier to segment data than to roll it up - Adobe's "rollup suites" don't work great, they were the solution many many years ago, they no longer recommend them for most implementations).

I use a Global Suite model (rolling 30+ sites, 3 apps, and many companion sites) into one suite, then use Virtual Suites to segment to "Core Web", "Mobile App", "AMP", etc for each site... allowing me to pull the subset of data that is needed, or all the data combined. But ultimately, the choice is yours in how you want to track and separate our your data.

If you do want to go the direction of separate suites, you will have to modify your web tracking in one of two ways....

Use Adobe Launch to detect the use of the "app webview" as above, and change the tracking accordingly to set the s_account value to the correct suite... or you can get your developers to detect it, and load a different Adobe Launch property onto the webpage that is set up to track to your mobile app suite (again, some core tracking elements like App Versions and Lifecycle metrics will not be included in any data collected this way)

As for your question

would the tracking be the same if the web pages were "sliced" so that they don't have the navigation or footer?

That is completely up to how your developers coded it... if you devs are hiding content such as the footer, then it sounds like they are already passing something to the page to tell it to load differently... you might be able to leverage that... or as above, as the developers to change the Launch property in that scenario.

Our webviews don't do anything special, no hiding of elements, no change it logic... they could if we wanted to... but since we have so few, most of our pages are built right into the app (at least in our more recent apps, older versions, may not have the pages and open as webview), so most webviews are of external sites; and my detection within our site allows me to record it appropriately.

aablank1 · 10/12/23

Thanks for the info on tips on detecting when the mobile app is using the website. I get the Global suite and subsequent Virtual suites. It makes sense. I guess I got a bad taste in my mouth for Globals when I had to use one before Virtual suites existed.

There are two reasons I'd attempt to switch the tracking suite programmatically:

- I'm more interested in observing the complete mobile app visit than seeing overall stats (again, no Global suite).

- I want to keep the sanctity of the user (we get a lot of questions about them).

When you mentioned passing the ECID, is that via a query parameter? Is that enough to keep the same visit integrity in the data?

Jennifer_Dungan · 10/12/23

Oh I hear you... the old rollup suites weren't all that good

And if you were doing globals a different way, then it really does come down to making sure there is a clear understanding of how the data fits together.

So if you are going to switch the suite programatically using Launch, I can help you with that... technically I do this... but only so that I can force tracking to go to QA in the "Prod Environment" when our internal staff is using preview mode.

Basically, we're a newspaper site, and our internal staff can actually preview articles through a specific function (but I don't want to track these articles as traffic, so I did make some programmatic changes to force the suite to QA instead of Prod, despite being a prod environment... I actually have my suites coded into a Custom Code Data Element, then I populate the Analytics extension using the Data Element... This does mean that I no longer see what each dimension is when in the Set Variables mode... I just see "eVar1" instead of "eVar1: Name of eVar"... it does make tagging a little harder (just warning you).

But again, if your developers are already running code that supports dropping the headers / footers / etc content on the page, you should be able to have them just use a completely separate Launch property, then you don't have to create a lot of code inside your one suite to handle variances....

When you mentioned passing the ECID, is that via a query parameter? Is that enough to keep the same visit integrity in the data?

It's supposed to... this is the Adobe solution for maintaining App to Web traffic. There is an app function that is supposed to modify the URLs opening the website to append ECID information - so that the tracking on the website can read it, overwrite the ECID identification in the web, and make sure that in the suite, that user is treated as one UV... This is also used for cross domain ID sharing.

I haven't personally used this, as we have so little traffic direct from App to Web, it's not been a priority.. but is something I eventually want to implement.

https://experienceleague.adobe.com/docs/experience-platform/edge/identity/id-sharing.html?lang=en

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

Let me know if I can help you any more with programmatically switching your traffic suite.