ADBINTERNAL:Lifecycle Custom Link Causing Phantom Pagename?

[blasta86794993]

We recently launched Adobe Analytics tracking on an Android app. We set context data variables within the app, and are using processing rules in Adobe Admin to map them to the relevant variables. We're using the context data variables modularly, like puzzle pieces and doing a lot of concatenated values delimited by an underscore. For example pagename for category pages is:

<<site>>_<<page_type>>_<<section>>

We saw some funny values in the pagename report during QA, but I chalked it up to something weird in the dev build. When we launched the production build, we found something unexpected: a phantom page that is a significant percent of traffic and almost all entries!

When you break that "_" down by any other variable, the breakdowns always show "None." Clearly that "_" is showing up like that because somewhere there is a server call with no context data variables but the processing rule is still executing. When you see that the phantom "_" page is 99.3% of entries, it's clear that it is most likely related to the launch lifecycle event. To try to correct, we added another condition to our pagename processing rule specifying that <<page_type>> had to be set before setting s.pagename.

Well the good news is after adjusting that condition, "_" is gone from the pages report. The bad news is that it was simply replaced by "Other."

I have been debugging and QA'ing using the Charles debugger, and I never see an initial trackState server call that would explain this phantom page. That ADBINTERNAL:Lifecycle Launch Event trackAction is the only thing that fires before that home page.

I also looked into when Adobe populates the "Other" value, and according to this Knowledgebase article (None, Unspecified, Unknown, and Other in reporting), "Other" happens when "Pages fire outside your internal URL filters". Not sure how URL filters work in an app, but for what it's worth there is one wildcard URL filter set up on this report suite for "."

Any ideas on why this might be happening and how we can get this gremlin out of our reports?

[PratheepArunRaj]

Dear Blasta,

Cannot give you an exact answer without debugging the scenario, but i suspect that there is a problem with Processing Rule Setup.

If you have process rule setup say,

Copy Context Data "Mobile_PageName" to "Page Name", then for the life cycle server calls, the Page Name will be empty and it may bucket everything under Other.

So change the rule to Copy Context Data "Mobile_PageName" to "Page Name" if "Mobile_PageName" is set. This should eliminate these gaps. If you are already using this coniditon, sorry, i need to debug the scenario to give the answer.

You can ignore Internal Filters, because these will not affect Page Name.

Thank You!

Arun

[blasta86794993]

Hi PratheepArunRaj​, thanks for your response! We already did try something similar, which was to add a condition to the pagename processing rule to only run if "content type" was set. That only resulted in turning our "_" pages into "Other."

What is the best way to share the company/report suite info with you privately so you can debug? Can I just send a private message here in the forums, or do I need to open a Customer Care ticket and ask them to have you assigned to it?

[PratheepArunRaj]

Dear Blasta,

Yes, please contact clientcare@adobe.com

If you are supported user, Adobe Team will acknowledge and help you to fix

Thank You!

Arun

[blasta86794993 · Accepted solution]

Following up to share the resolution and mark this resolved: we inadvertently had a processing rule setting page_url. (This was not intentional.) We learned from Client Care that "When manipulating pagename and page_url via processing rules it causes the custom link to be counted as a pageview."

The Lifecycle Launch event is normally a custom link, but because the processing rule was trying to give it a URL it forced it to fire a pageview, which then caused a value of "Other" to appear in the pages report.

Once we removed that processing rule, the "Other" page dropped off: