Abobe SDK for mobile - screenview

[BertBru]

Hello,

Does anyone know the proper way to track screenviews in a mobile sdk implementation?

We are using edge, datastreams, and schemas. We need to track screenviews and clicks in adobe analytics.

I see the recommended event types for web clicks and web pageviews in the documentation, but nothing for mobile.

We successfully see our props and eVars in the report suite, but no "visits" or "pageviews"

- Should I follow the event type recommendations for web?

- Do I have to send an event, such as event1 to get a screenview?

[Jennifer_Dungan · Accepted solution]

In Adobe Analytics, they really don't distinguish "page view" from "screen view"... the verbiage is shared for web and apps.

Your App data should look just like your Web data, with a few differences.

For one, your mobile app should be setting an "App ID" (something that doesn't exist on your website).

In our implementation, I use dimensions to help give context to the traffic.. 

• Responsive Breakpoint - in this I track the breakpoint experience... so on web, I will track the "desktop", "tablet", "mobile" breakpoints, then I added "app|mobile" and "app|tablet" into our apps
• Site Type - for context, we have a lot of subdomains that support extended content... so I track values like "core", "obituaries", "classifieds", etc, for our apps, I use "app"

I make sure that ALL dimensions match the data (values / formatting / etc) between web and app, so that everything properly rolls up into the same row for reporting.

Using these, I can separate our web traffic from our mobile app (I could also use the existence of "App ID").

---

- Should I follow the event type recommendations for web?

---

Yes, I can literally take our web calls and app calls and look at them side by side, and they will match (aside from obvious data differences)

---

- Do I have to send an event, such as event1 to get a screenview?

---

Only IF you are using a custom event on web in addition to standard PV metric. As in, I would match your web as close as possible.

Now, I do realize that your app and web may have slightly different features or behaviours.... such as "swipe left and right" to get to additional content, or maybe changing dark mode, font size, etc.... these are the things that you will have to create "App Only" dimensions or actions to track..  but it shouldn't be too hard to figure out the similarities and differences and determine the best way to track those differences while joining the similarities for everything else.

[BertBru]

Thank you so much for your response! Here's more context

• This report suite will only have mobile data, so we don't need to differentiate. I just wanted to know how to properly send the mobile data. Good to know that we can follow the recommendations for web
• We are more than happy to stick to the _experience schema.
• I came across this (screenshot below and link here:https://experienceleague.adobe.com/en/docs/analytics/implementation/aep-edge/overview#:~:text=To%20p....) Where it seems like it's referencing something outside of the _experience schema
  • 
  • It looks like the above is referencing this field group outside of _experience
    • 
  • I see a similar one inside of experience
    • 
  • Also eventType is completely outside of the _experience tree, so I am completely confused about that.
  • Sorry for the layered questions, this shows my level of confusion.

[Jennifer_Dungan]

Yeah... I'm going to throw a little shade here... but I think Adobe really made the schema building and definitions way more complicated then they needed to be....

This is another reason we bypassed the schema altogether and used the Adobe Data model... obviously not something that would work if we were using CJA...

I am actually going to join you in that confusion... I don't understand why there are multiples of anything... the lack of definitions about the schema options, the additional complications of how to build a what should be a simple JSON object.... I wish I could give you more advice here... 

I think this might be why I've seen several people say "do your own custom model"... at least that way you know what is what.... I am not saying that is the way to go... I don't know your system, or what other schema you have, obviously consistency is better for managing multiple systems.... 

[BertBru]

lol! This helps understand why people create their own groupings. Alright, we will try a few things to see what works!

[BertBru]

Okay I am back with more question.

if i send a custom xdm structure from the map, can I map it to evars and props or are there rules to follow?

Asking because the map below in my datastream doesnt work (didnt show up in reporting)

programDetails.degreeLevel

=> 

_experience.analytics.customDimensions.props.prop33

but this worked (showed up in reporting)

_experience.analytics.customDimensions.props.prop35

=>

_experience.analytics.customDimensions.props.prop35

[Jennifer_Dungan]

Don't hold me to this, but from my understanding, yes, you should be able to map it... 

Interesting... I mean, I will be honest, I haven't don this myself..

I have some questions for you though:

1. Are you only using AA or do you also have, or plan to have CJA?

2. If the answer to question 1 is "just AA, no plans for CJA", are you just trying to get your mobile app to track to AA using the newest AEP SDK? And you are trying to find the easiest path to that end?

If you are just using AA, and are trying to get data into AA easily (also taking your comment from https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/how-to-map-json-from-mobi... as part of my understanding), then I may have some very good news / info for you, using the same model we're about to implement for AA in our mobile apps.... however, it's definitely not designed for CJA.....

[BertBru]

We are not using cja. This implementation is for AA only but we figured the edge route would be more future proof in case we want to expand.

With the edge route, we already have something that works but we wonder how flexible we can get with mapping. 

We're looking back a the route we didnt take and wonder if we missed an opportunity there.

Its not a must have but we were hoping to get the devs to implement a user friendly xdm structure that we can map to what ever evar or prop we want.

I would love to hear about your implementation!

[Jennifer_Dungan]

I will start by giving some context and history... our mobile app implementation uses contextually named variables, then I use processing rules to set and concatenate the values using processing rules.

This was done for multiple reasons:

1. It was easier for the developers, to just set values like "article title" or "asset id" etc, rather than having to worry about the formatting of how multiple values were stitched together
2. We don't force people to update our apps, so hard coding formatting into the app could cause issues if we had to adjust formatting or change the dimension, etc.

So, I have a lot of processing rules and logic to set the values...

I wasn't sure how flexible mapping XDM streams was, like was it only one to one? Could I actually build in logic and concatenate different values (if this, then concatenate these things in this order, or if that, then concatenate a different way - mostly for different page types that might not have all the same context variables)?

I didn't want to get the developers to re-write the entire implementation... 

So instead, we used the XDM Stream in the most basic way, and used the Data Object variable:

https://experienceleague.adobe.com/en/docs/analytics/implementation/aep-edge/data-var-mapping

So that we could continue sending our context variables as context and use our processing rules...  

For Products List and Events tied to developer logic, those can be set directly to the Adobe fields.

This way, I didn't even have to configure a schema (aside from a basic, empty, schema)

If we ever decide to look at CJA, we obviously have some work to do, but it at least limited the potential failure points at this time, but only switching to Edge Server and Data Stream without also changing most of the implementation logic....  it's a lower risk transition... 

[BertBru]

interesting. do you have an example of what the payload looked like? Also how did adobe analytics know what to map to props and evars?

[Jennifer_Dungan]

This data model was actually added by Adobe to make sending data to AA easier (i.e. not have to use the whole XDM Schema)

So everything in the data.__adobe.analytics model automatically uses the ADD naming.

So your pageName, pageURL, referrer, prop1-75, eVar1-250, events, etc go straight into the matching dimenson/metric; context variables, like in Adobe calls, are inside a sub-key called contextData, which can be seen and used to map based on Processing Rules.

"data": {
  "__adobe" : {
    "analytics": {
      "channel" : "sample channel",
      "eVar1" : "X",
      "eVar2" : "Y",
      "events" : "event1,event2,event3",
      "prop11" : "W",
      "prop2" : "Z",
      "pageName" : "sample page name",
      "pageURL" : "https://www.domain.com/",
      "referrer" : "https://www.google.com/",
      "contextData" : {
        "testContext1" : "some value",
        "testContext2" : "another value",
      }	
    }
  }
}

Basically it completely mirrors the traditional AA data model... 

[BertBru]

That's neat. Thank you for sharing. Where do the contextdata values go? Are you able to map those into props and evars?

[Jennifer_Dungan]

Context variables, whether sent using AppMeasurement, WebSDK, the old ACP SDK or the new AEP SDK (with Data Streams), etc. context variables have to be mapped using processing rules.

In the old ACP SDK, we relied on Context Variables for most of our implementation. Aside from standard values like the Page Name or Action Name, Products (which can't be mapped in Processing Rules) and the Events related to Products, everything else was sent via context and mapped using Processing Rules.

The way we did it, it made the implementation more complex for me, but gave me much more freedom to change how the data was formed / mapped... like if I needed to change something from a prop to an eVar, I could make the change without needing a new app deployment... 

Like everything, there are pros and cons to each decision on how to approach a solution. You try to make the call that is best for you, and your situation.

[BertBru]

@Jennifer_Dungan  in case notifications don't work. I responded to your comment with more context!

[FarazHusain]

Apart from what @Jennifer_Dungan mentioned, you can check out this particular documentation - https://experienceleague.adobe.com/en/docs/platform-learn/implement-mobile-sdk/initial-configuration... 

Basically you have to setup a custom field group as defined above and then https://experienceleague.adobe.com/en/docs/platform-learn/implement-mobile-sdk/app-implementation/ev... and add something like below:

This is a good documentation for tracking screen views for Mobile SDK implementation using Edge, but this one is for iOS; a similar setup would be for Android. I have tried and tested this one, and it works.

[Jennifer_Dungan]

Lol, I should have mentioned that we are using the data.__adobe.analytics model rather than the full XDM Schema!

Since we are not likely to have CJA anytime soon, we decided to not redesign everything and stick with our context variables and processing rules.... 

So there is no separate model in that... I don't know if using the Analytics Bridge (so that you can continue using trackState and trackAction) would also result in not having the separate app schema....  

[FarazHusain]

Yes, if we use Analytics Bridge/Edge Bridge, one can continue to send the data via trackState and trackAction APIs, and in the case of Edge Bridge, the schema setup is optional. 

[Jennifer_Dungan]

Haha that's Adobe for you... a million and eight ways to do anything, and they are all valid. lol.

[BertBru]

Thank you for your help!

Since I am new to this, I just want to confirm. This is "a" way to do this, right? If so we want to stick to the web schema instead

[Jennifer_Dungan]

I think the most important thing is... "is it right for you"?

With the ability to map schema fields, following someone else's model may cause confusion?

I don't think there is a problem with choosing to use the web schema... but I also am not using the schema at all, aside from very basic items.

We do have some data in the "application" group, things like the app id... But I think the SDK is handling most of those themselves, and I didn't have to declare any of it in the schema, which I basically left empty...