Mobile implementation on iOS - Retrieving data | Community
Skip to main content
G
germanroncelli
New Participant
February 28, 2023
Solved

Mobile implementation on iOS - Retrieving data

  • February 28, 2023
  • 1 reply
  • 1628 views

Hi everyone. In my company I was requested to implement Adobe Analytics on mobile, using the correspondent SDK. So far, I have been able to connect it properly, but I am unaware on how is the process of sending data from the app to AA.

I have been using Launch for mobile settings, and I am aware that for mobile that is not the way, but I think I do not fully understand what to do next. 

When tagging events and sending them through the code in the app would be enough for Adobe to retrieve them? How do I map metrics and dimensions from these?

Or what needs to be done from the Adobe side to make it happen? Is it through a schema and a datastream?

 

In my web applications, I have a dataLayer with information about the app's name and team it belongs to. Something like:

 

dataLayer

     application: example

     team: example

 

I want to do the same for mobile (or retrieve the same data from that app). What is the best/simplest way of doing it?

 

Thank you!

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

Mobile Apps are a bit of a different breed... so starting with the basics, in web you have 2 calls (one for page views and one for actions), there are also 2 calls in mobile app:

 

  • trackState (mobile) = s.t() (web)
  • trackAction (mobile) = s.tl() (web)

 

Mobile Apps also have some "app only" actions and dimensions, such as Lifecycle Metrics (which need to be enabled manually, and paused / restarted as the app is sent to the background and brought forward, etc) and things like App IDs.

 

Now, just like on Web, you need to pass data on your calls, but unlike web, you don't set your eVars and Props directly... you actually have to create context variables that you pass data in, then you use Processing Rules to map these context variables to your dimensions.

 

This is where you have to plan out how you want this to work, how comfortable you feel with processing rules, how often tagging may change or require tweaks... and most importantly.. is you policy to force users to the latest version of the app? Or do you let them continue to use old versions... 

 

The reason I say this, is that IF there is an issue with developer set values, you have limited ways to manipulate the data... you can add values together, you cannot separate them...so if you have your devs set a value like "something|another-value|third-item" and there is a problem with one of those... you can't break it apart to fix the one value... but if you send as three separate values, and add them together in mapping and then you do have more control to fix the one value....

 

This is how I code my mobile apps.. breaking everything into separate context variables, then stitching them together as I want.

 

Then I also use logic to determine what events I want fired... if this, or that, or both these items, etc... then add these events.

 

You can break stuff into multiple rules too.. I have a general page views rule (if a.action is not set), a general events rule (if a.action is set), then I will have specific rules (sometimes one or more depending on the complexity) for different pages or actions to stitch in the specifics.

 

It should be noted, you cannot map s.products through.. these have to be set by your developers and passed directly in the trackState/trackAction calls. (&&products=xxxx)

 

Events can be mapped directly as well (&&events=xxxx) but I try to keep these limited to events tied specifically to products and use Processing Rules for everything else....

 

The last thing I will recommend right now.. make sure you install the AEP Assurance extension... this is the best way to test your mobile app implementations (it will show you the raw context variables as well as the post processed data - so you can test what your developers are sending you as well as your mapping rules)

1 reply

Jennifer_Dungan
Jennifer_DunganAccepted solution
New Participant
February 28, 2023

Mobile Apps are a bit of a different breed... so starting with the basics, in web you have 2 calls (one for page views and one for actions), there are also 2 calls in mobile app:

 

  • trackState (mobile) = s.t() (web)
  • trackAction (mobile) = s.tl() (web)

 

Mobile Apps also have some "app only" actions and dimensions, such as Lifecycle Metrics (which need to be enabled manually, and paused / restarted as the app is sent to the background and brought forward, etc) and things like App IDs.

 

Now, just like on Web, you need to pass data on your calls, but unlike web, you don't set your eVars and Props directly... you actually have to create context variables that you pass data in, then you use Processing Rules to map these context variables to your dimensions.

 

This is where you have to plan out how you want this to work, how comfortable you feel with processing rules, how often tagging may change or require tweaks... and most importantly.. is you policy to force users to the latest version of the app? Or do you let them continue to use old versions... 

 

The reason I say this, is that IF there is an issue with developer set values, you have limited ways to manipulate the data... you can add values together, you cannot separate them...so if you have your devs set a value like "something|another-value|third-item" and there is a problem with one of those... you can't break it apart to fix the one value... but if you send as three separate values, and add them together in mapping and then you do have more control to fix the one value....

 

This is how I code my mobile apps.. breaking everything into separate context variables, then stitching them together as I want.

 

Then I also use logic to determine what events I want fired... if this, or that, or both these items, etc... then add these events.

 

You can break stuff into multiple rules too.. I have a general page views rule (if a.action is not set), a general events rule (if a.action is set), then I will have specific rules (sometimes one or more depending on the complexity) for different pages or actions to stitch in the specifics.

 

It should be noted, you cannot map s.products through.. these have to be set by your developers and passed directly in the trackState/trackAction calls. (&&products=xxxx)

 

Events can be mapped directly as well (&&events=xxxx) but I try to keep these limited to events tied specifically to products and use Processing Rules for everything else....

 

The last thing I will recommend right now.. make sure you install the AEP Assurance extension... this is the best way to test your mobile app implementations (it will show you the raw context variables as well as the post processed data - so you can test what your developers are sending you as well as your mapping rules)

    Terms & ConditionsAccessibility statement

    Loading footer...