Tracking wrapped web pages in mobile apps | Community
Skip to main content
A
aablank1
Level 4
October 4, 2023
Question

Tracking wrapped web pages in mobile apps

  • October 4, 2023
  • 1 reply
  • 2683 views

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?

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
October 4, 2023

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)

    A
    aablank1Author
    Level 4
    October 4, 2023

    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.

     

     

    A
    aablank1Author
    Level 4
    August 8, 2024

    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-views.html?lang=en

     

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


    So we're not using Data Collection for tagging.  Instead we're using a third party tag manager.  We'll switch when we eventually go to Web SDK tagging.  For now, it's essentially manual.


    I've got the passing of the ECID to the wrapped web pages.  But how do we overwrite the new one in the wrapped page appmeasurement tagging?  Is it as simple as setting a certain ECID variable?  (I'd love to use appendIdentityToUrl, but we don't use Web SDK.)

    Terms & ConditionsAccessibility statement

    Loading footer...