Mobile App Implementation | Community
Skip to main content
A
anil17
December 6, 2023
Solved

Mobile App Implementation

  • December 6, 2023
  • 1 reply
  • 1322 views

Hi,

 

We want to use one Launch property for three mobile apps. Reason - We have a similar setup for web where we have one report suits for 3 websites and we have an eVar to captures website's name. So to see data for one website in Analytics dashboard we just filter based on the website name eVar. We are looking to have a similar setup for App but for App I am not sure if we can have a similar eVar or conextData which will allow us to filter data for each app in dashboards, if it's an option please help with an example setup in processing rules. or suggest the best way to do it?

 

Thanks in advance,

AK

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

You absolutely can... we have 3 mobile apps, and 30 websites being tracked into a single report suite.

 

All the tracking on our apps is the same as the web (with the exception of app specific functionality, and web specific functionality where there is some divergence)

 

Though they use different names, trackState is the equivalent of s.t(), and trackAction is the equivalent of s.tl().

 

Now, App are moving towards deprecating standard context variables in favour of XDM Streams... I haven't yet switched our apps to this yet, but the process should be similar.. on each of the mobile app specific calls, you would send all the values (including values that will help you classify as an app) and map that to your props and eVars (to get the same final result that you would see from a website).

 

 

I have several such "Classification" eVars... I have one which I call our "Breakpoint" - this tracks "desktop", "mobile" or "tablet" on web, and "app|mobile" or "app|tablet" on our apps

 

And I use the server dimension to track the core domain.. so on SiteA and the corresponding App for Site A, both track the server as "sitea.com", similarly for web and app for Site B, I track "siteb.com"

I can use the two dimensions to either get all traffic to Site A, regardless of the platform/breakpoint or to traffic to all apps, or by combining the two, I can get traffic to Site A's app, or website only... 

1 reply

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
December 6, 2023

You absolutely can... we have 3 mobile apps, and 30 websites being tracked into a single report suite.

 

All the tracking on our apps is the same as the web (with the exception of app specific functionality, and web specific functionality where there is some divergence)

 

Though they use different names, trackState is the equivalent of s.t(), and trackAction is the equivalent of s.tl().

 

Now, App are moving towards deprecating standard context variables in favour of XDM Streams... I haven't yet switched our apps to this yet, but the process should be similar.. on each of the mobile app specific calls, you would send all the values (including values that will help you classify as an app) and map that to your props and eVars (to get the same final result that you would see from a website).

 

 

I have several such "Classification" eVars... I have one which I call our "Breakpoint" - this tracks "desktop", "mobile" or "tablet" on web, and "app|mobile" or "app|tablet" on our apps

 

And I use the server dimension to track the core domain.. so on SiteA and the corresponding App for Site A, both track the server as "sitea.com", similarly for web and app for Site B, I track "siteb.com"

I can use the two dimensions to either get all traffic to Site A, regardless of the platform/breakpoint or to traffic to all apps, or by combining the two, I can get traffic to Site A's app, or website only... 

    A
    anil17Author
    January 3, 2024

    Thank you, Jennifer. This is exactly what I was looking for!

      Terms & ConditionsAccessibility statement

      Loading footer...