Expand my Community achievements bar.

SOLVED

iOS Native app sdk. Using swift implementation. No Pagenames

Avatar

Community Advisor

Hi we are having some odd behaviors in terms of getting pagename to populate.

We have later 4.x sdk installed and we are able to get TrackActions working well.

Our issue is we cannot get pagname to populate.

We enabled all mobile tracking in report suites.

We use correct tracking server.

ADBMobileconfig looks good.

Any ideas how to troubleshoot?

I use charles and data output looks ok.

Any ideas appreciated.

Thanks

1 Accepted Solution

Avatar

Correct answer by
Level 3

Within the SDK, state (page) views are tracked when trackState call is made.  You can specify the state (page) name with the first argument:

SDK Code

Android

  1. Analytics.trackState("Page Name Here", null); 

iOS

  1. [ADBMobile trackState:@"Page Name Here" data:nil]; 

Mobile Services Config

Currently there is no way to set the page name from the Mobile Services App Config interface. Variables configured within the Mobile Services interface ultimately generate regular Processing Rules (PRs).  If you go to the PR config page in Adobe Analytics, you can see the rules (read only) set by them.  However, the mobile services interface does not give you access to the full capabilities of creating your own PR in the regular PR interface, because.. reasons?

Processing Rule

You can set/override the page name within the Processing Rule (PR) interface. Login to the Adobe Analytics (AA) interface, and navigate to Admin > Report Suites. Select your mobile app Report Suite Id (rsid) from the list. Then navigate to Edit Settings > General > Processing Rules.  I'm not sure what your conditions or source of value is for page name, but to set the page name value, select "Page Name" from the relevant dropdown.

A couple of warnings about this method:

Warning #1: Your implementation may make trackAction calls or other non-page(state) view calls for various reasons. Usually the previous trackState page name is included in these requests, but the Adobe collection server strips it before moving to processing rules in the processing flow. This allows for the action to be associated with the underlying page(state), but not be recorded as a separate page(state) view.   If you assign a value to Page Name, where it was previously stripped from pre-processing, downstream Adobe will record it as a full page view. Therefore, at a minimum, make a condition on your PR to only set (override) the Page Name value if it already exists.

Example:

PR_Set_Page_Name - Copy.png

Warning #2: Overriding the Page Name value via PR may cause funkiness in reports, particularly when breaking down Page Name by other dimensions or visa versa.  As mentioned above, trackAction calls include the previous trackState call's page name, and Adobe strips it so that it won't count as a page view, but it still keeps it in a separate post-process var (not exposed to PR) to associate the trackAction data to the last trackState call. So if you override the Page Name value for the trackState call in a PR, then that new Page Name will be reported. Meanwhile upstream in the actual SDK code, the next trackAction call will still have that old Page Name value, so data will be associated with that Page Name value, not your PR-set value.  There is nothing you can do about this within the PR. Therefore the recommended solution is to set it with the SDK code, and only use this solution (understanding the implications) if changing SDK code is not an option.

View solution in original post

1 Reply

Avatar

Correct answer by
Level 3

Within the SDK, state (page) views are tracked when trackState call is made.  You can specify the state (page) name with the first argument:

SDK Code

Android

  1. Analytics.trackState("Page Name Here", null); 

iOS

  1. [ADBMobile trackState:@"Page Name Here" data:nil]; 

Mobile Services Config

Currently there is no way to set the page name from the Mobile Services App Config interface. Variables configured within the Mobile Services interface ultimately generate regular Processing Rules (PRs).  If you go to the PR config page in Adobe Analytics, you can see the rules (read only) set by them.  However, the mobile services interface does not give you access to the full capabilities of creating your own PR in the regular PR interface, because.. reasons?

Processing Rule

You can set/override the page name within the Processing Rule (PR) interface. Login to the Adobe Analytics (AA) interface, and navigate to Admin > Report Suites. Select your mobile app Report Suite Id (rsid) from the list. Then navigate to Edit Settings > General > Processing Rules.  I'm not sure what your conditions or source of value is for page name, but to set the page name value, select "Page Name" from the relevant dropdown.

A couple of warnings about this method:

Warning #1: Your implementation may make trackAction calls or other non-page(state) view calls for various reasons. Usually the previous trackState page name is included in these requests, but the Adobe collection server strips it before moving to processing rules in the processing flow. This allows for the action to be associated with the underlying page(state), but not be recorded as a separate page(state) view.   If you assign a value to Page Name, where it was previously stripped from pre-processing, downstream Adobe will record it as a full page view. Therefore, at a minimum, make a condition on your PR to only set (override) the Page Name value if it already exists.

Example:

PR_Set_Page_Name - Copy.png

Warning #2: Overriding the Page Name value via PR may cause funkiness in reports, particularly when breaking down Page Name by other dimensions or visa versa.  As mentioned above, trackAction calls include the previous trackState call's page name, and Adobe strips it so that it won't count as a page view, but it still keeps it in a separate post-process var (not exposed to PR) to associate the trackAction data to the last trackState call. So if you override the Page Name value for the trackState call in a PR, then that new Page Name will be reported. Meanwhile upstream in the actual SDK code, the next trackAction call will still have that old Page Name value, so data will be associated with that Page Name value, not your PR-set value.  There is nothing you can do about this within the PR. Therefore the recommended solution is to set it with the SDK code, and only use this solution (understanding the implications) if changing SDK code is not an option.