Application ID Capturing in Page Name - How to Debug?

[PratheepArunRaj]

Dear Everyone, CaliseCheung​ , @Ivan Mironchuk ,

We have implemented Adobe Analytics in our Mobile Application using Adobe Launch SDK 5x.

The implementation was good and we didn't see any gaps but we are seeing Application ID capturing as the Page Name and it is equal to the overall Page Views in a day i.e. Guess it is firing every time the page is loading.

We tried to debug the image request and since because our Application Server blocks all the Proxies, we are unable to see the image request using Charles Debugger.

The Page Views we are receiving is nearly doubled and thus it is a red alert for us in terms of Server Calls.

Anyone faced this issue? Kindly guide on why and how to debug.

And, if we didn't have the setup to fire the Analytics Server Call within the Launch, then what's the advantage of it?

If i have the setup, at least we would have added a condition not to fire the Server Call for the Track State with Application ID or without any name.

Kindly suggest the best approach.

Thank You!

Arun

[Jen_Andrews]

Hi Arun,

When the AppID is populated at the the page name, it usually means that they 'value' being passed in the trackState method is null.

Are you potentially sending trackState method in your app code with 'no value'?  You may want to double check the implementation as well, are you potentially calling a Launch Rule with no value being set in a trackState call?

If you are unable to use Charles, then using logcat from Android Studio or our 'new' debugger tool Griffon have be able to help you diagnose your issue.  Project Griffon

Regards,
Jen

[PratheepArunRaj]

Dear Jennifer,

Thanks for the reply.

We are sure that we didn't call 'trackState' method in our Application Code.

Regarding Launch Rule, how do we set the 'trackState' call within the Launch Interface?

Based on my understanding 'trackState' implementation at Mobile Application will not request the Launch Rule to fire the Page View unlike Web Implementation right? Pretty not sure on the important of having 'trackState' at Launch, anyhow we wont have the control. Would you explain a bit?

Thank You!

Arun

[Jen_Andrews]

Hi Arun,

If you have no Launch Rules, then the only possible way that a 'pageview' is being populated in reporting is that a hit is being sent via a trackState. 

The sample app that we have does not contain any Launch Rules, but implements that trackState method. Overview 

In a mobile app this is sort of the equivalent to an s.t( ) call.  If this is Mobile.trackState( ) is not called then there should not be a hit being sent to Adobe.

In your Android App, if using Android Studio, do a search for trackState.

Regards,
Jen

[emdobrin]

Hi @PratheepArunRaj ,

Following up on this thread, was this issue resolved for you?

Thank you,

Emilia Dobrin

Computer Scientist

Adobe Experience Cloud

[PratheepArunRaj]

Dear Emilia, Yes, it did. Since we have used Adobe Launch, a trigger was firing from SDK and also from Launch. We have fixed the second Server Call through Launch and now it is fine. Thank You, Arun.

[PratheepArunRaj · Accepted solution]

Dear All,

Able to fix the gaps. Just sharing the fix details for everyone's reference.

Though Adobe Launch SDK 5x was used, still the Page View Server Call relies on TrackState. We thought that TrackState will send the response to Launch and Launch will fire the Server Call since it is an intermediate layer, but it fires the Server Call typically like our Mobile Service. If we need to use any additional Server Call based on the Track State Name and Context Variable, we can fire using Adobe Launch. So ideally, TrackState should be embedded to the SDK and it has nothing to do with Adobe Launch!

Thank You, Arun.