Mapping Default page(Page Name) dimension for trackAction Calls in apps

[aguseranalytics]

Hi Team,

We had a use case where pageView(custom event) and pageViews(by default metrics) numbers were not matching, because one of the probable reasons was, for few of the link click calls are going as trackState calls in apps therefore changed them to trackAction calls. Now, wanted to set the mapping of by default page variable in processing rules for apps for those trackAction calls via processing rules. Is this possible? Though Adobe itself stricks out the pagename value for link tracking or track Action calls is there any other way around. Please add in if there are any possible alternates.

Thanks in Advance!!

[SamuelPaulPeter]

No — you cannot map or force the default Page Name for trackAction (link) calls using processing rules. This is by design.

Why this happens

• In apps, trackState = page view → Page Name is valid

• trackAction = link event → Adobe intentionally strips Page Name

• Processing rules cannot override this behavior

So pageView (default metric) ≠ custom pageView events when actions are used.

What you can do instead

Use a custom dimension for “context page”

• Pass the current page/screen name in a custom eVar with trackAction

• Report on that eVar instead of Page Name for action-based flows

Convert key actions back to trackState

• If the interaction represents a screen/view change, it should be a trackState, not trackAction

Accept the model difference

• trackState = navigation

• trackAction = interaction
  Trying to make actions behave like page views will always cause mismatches

[aguseranalytics]

Thanks @SamuelPaulPeter  and @Sumit-Kumar for the inputs above.

However, I was simply trying just to research on it more if mapping the by- default page name variable irrespective of trackAction or trackState call, that means creating a separate processing rule altogether mapping a page name like below , whenever pagename value is present in the data layer it should map to page name : 

Any thoughts that it would give a separate outcome or again no page name value to be set with trackAction call specifically. Thanks Again!!.

[Sumit-Kumar]

If your ‘pagename’ contextData is also set on trackAction call then setting the default OOB ‘Page Name’ via processing rules will convert your trackAction into a page view hit. (meaning all your trackAction implementation will also be converted to trackState now)

so instead use a custom dimension for pagename eVar/prop for setting page name from a contextData. It will capture page name on trackAction calls without disrupting s.tl() or without inflating page views. so, default oob page name should not be set like your screenshot OR just add/ use a condition if “Page Name” is set then over write the “Page Name” with the contextdata(pagename)..

Basically the condition "if Page Name is set" will never be true for trackAction calls anyway.. meaning the rule would only fire on trackState calls (where default ‘Page Name’ is already being set) but will be overwritten by the contextData (pagename).

[aguseranalytics]

yes, this completely makes sense. And no change is observed, even by applying a separate rule which says if “Page Name” is set then over write the “Page Name” with the contextdata(pagename) , which is expected.
Thanks for the response @Sumit-Kumar , it helps.

[Sumit-Kumar]

Just to add to the above,

to match custom pageviews PV (eventX) with default PageViews PV metric fire your custom event(pageviews) only on trackState calls(if doing via processing rules then Set eventX(pageviews) only when pagename  is set ), not on trackAction. This keeps both numbers aligned.

PVs won't increment for trackAction. If you want your custom event(for pageviews) to match default PVs, trigger it only on trackState.