Clarification on mobileappid Persistence in Adobe Analytics | Community
Skip to main content
N
nitesh__anwani
Level 3
May 19, 2025
Solved

Clarification on mobileappid Persistence in Adobe Analytics

  • May 19, 2025
  • 1 reply
  • 544 views

Hi Folks,

 

I have Adobe Analytics implemented on both the mobile app and the website. In some cases, we render webviews within the mobile app to display specific content types.

 

We use the appendVisitorInfoForUrl approach to synchronize the visitor ID between the native app and the webview.

 

For dashboarding purposes, I rely on the data feed from Adobe Analytics. I’ve observed that once the mobileappid is tracked within a visit, it is then persisted across all subsequent hits—including those coming from the webview—even though there is no explicit implementation of mobileappid on the webview side.

 

This behavior makes sense for native app hits, as the mobile SDK automatically tracks the mobileappid. However, I’m still unclear why it persists for webview hits as well.

I searched for documentation to confirm whether mobileappid is persisted at the visit level, but I couldn't find anything definitive.

 

I tried to find the documentation that can clarify whether the mobileappid is persisted at the visit level or not, but couldn't find any document.

 

Any insights or official documentation regarding this behavior would be greatly appreciated.

 

Thanks,

Nitesh

    Best answer by pradnya_balvir

    Hi @nitesh__anwani ,

     

    Although mobileappid is not a persisted variable by design, Adobe Analytics’ processing layer may carry forward certain context data across hits within a visit when the Experience Cloud Visitor ID (ECID) is shared — as is the case with appendVisitorInfoForUrl().

     

    In practice:

    When the initial hit from the native app includes mobileappid, Adobe Analytics associates that value with the ECID for the duration of the visit.

    If subsequent hits (from webviews) share the same ECID and tracking server, Adobe may attribute the previously seen mobileappid to later hits—even if those hits don’t explicitly send that value.

    This results in the behavior you're seeing: the mobileappid appears to persist across all hits within the visit due to ECID-level data attribution within Adobe’s backend.

     

    Below are some documents

    1. Adobe Experience Platform Mobile SDK Documentation
      https://experienceleague.adobe.com/docs/mobile.html
      (Mentions mobileappid is auto-collected, but not about persistence.)
    2. appendVisitorInfoForURL documentation
      https://experienceleague.adobe.com/docs/mobile-sdk/ios/analytics/analytics-appendvisitorinfoforurl.html
      Describes how ECID is passed to webview but doesn’t elaborate on how mobileappid behaves.

     

    Best Practices:

    • If you want to separate native vs webview hits, consider capturing a custom dimension (e.g. eVar) explicitly on the webview side to distinguish source types.
    • You could set a flag like eVarX = "webview" on the webview pages and eVarX = "native" on native app pages.
    • For dashboards, avoid assuming mobileappid strictly identifies native app hits — filter hits more precisely using user agent, referrer, or explicit custom flags.

    1 reply

    pradnya_balvir
    Community Advisor
    pradnya_balvirCommunity AdvisorAccepted solution
    Community Advisor
    May 19, 2025

    Hi @nitesh__anwani ,

     

    Although mobileappid is not a persisted variable by design, Adobe Analytics’ processing layer may carry forward certain context data across hits within a visit when the Experience Cloud Visitor ID (ECID) is shared — as is the case with appendVisitorInfoForUrl().

     

    In practice:

    When the initial hit from the native app includes mobileappid, Adobe Analytics associates that value with the ECID for the duration of the visit.

    If subsequent hits (from webviews) share the same ECID and tracking server, Adobe may attribute the previously seen mobileappid to later hits—even if those hits don’t explicitly send that value.

    This results in the behavior you're seeing: the mobileappid appears to persist across all hits within the visit due to ECID-level data attribution within Adobe’s backend.

     

    Below are some documents

    1. Adobe Experience Platform Mobile SDK Documentation
      https://experienceleague.adobe.com/docs/mobile.html
      (Mentions mobileappid is auto-collected, but not about persistence.)
    2. appendVisitorInfoForURL documentation
      https://experienceleague.adobe.com/docs/mobile-sdk/ios/analytics/analytics-appendvisitorinfoforurl.html
      Describes how ECID is passed to webview but doesn’t elaborate on how mobileappid behaves.

     

    Best Practices:

    • If you want to separate native vs webview hits, consider capturing a custom dimension (e.g. eVar) explicitly on the webview side to distinguish source types.
    • You could set a flag like eVarX = "webview" on the webview pages and eVarX = "native" on native app pages.
    • For dashboards, avoid assuming mobileappid strictly identifies native app hits — filter hits more precisely using user agent, referrer, or explicit custom flags.
      N
      nitesh__anwaniAuthor
      Level 3
      May 21, 2025

      Hi @pradnya_balvir ,

       

      Thank you very much for your response.

      Yes, tracking a new variable to indicate the source of hits will sufficiently meet the requirement.

      I had concerns regarding the persistence behaviour of the mobileappid, as it was not clearly defined in any of the available documentation. I now understand that Adobe’s processing layer includes logic to persist certain context variables at the ECID level during a visit, particularly when a shared ECID is used.

      Would you happen to know which other variables exhibit similar behavior? This is especially important as the same approach used for app-to-WebView communication—appending the Visitor ID to the URL—is also commonly used in cross-domain tracking. I am trying to understand the potential impact of this method more broadly.

       

      Additionally, could you please advise on the best way to request official documentation from Adobe on this topic? I believe it would be very helpful for others who may encounter similar scenarios.

       

      Thanks,

      Nitesh

        Terms & ConditionsAccessibility statement

        Loading footer...