trackAction call generates pageView | Community
Skip to main content
marishg69668790
marishg69668790
Level 2
January 24, 2020
Solved

trackAction call generates pageView

  • January 24, 2020
  • 8 replies
  • 6434 views

We are working on Adobe Analytics implementation on our mobile app. It is observed that a simple trackAction call is generating pageViews in Adobe. Any help here is appreciated.

Looks like Adobe SDK sets pageName and therefore pageviews are incremented.

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by vinodtanwar

    Hello,

    I think you have posted your query in incorrect forum and might want to post your query here Adobe Analytics Forum .
    AEM Mobile is a totally different product used to build content-rich hybrid apps and stands separate from AEM.
    Thanks,

    Vinod

    8 replies

    V
    Adobe Employee
    vinodtanwarAdobe EmployeeAccepted solution
    Adobe Employee
    May 21, 2020

    Hello,

    I think you have posted your query in incorrect forum and might want to post your query here Adobe Analytics Forum .
    AEM Mobile is a totally different product used to build content-rich hybrid apps and stands separate from AEM.
    Thanks,

    Vinod

      dswest_sv
      dswest_sv
      Level 2
      September 11, 2020

      This looks to be related to the same bug in s code that I reported a couple of years ago. I'm betting that if you trace this you will see the same behavior noted when only two args are passed to s.tl(). Check the docs on the sdk and see if there is not a third argument for the link which expects a string (generally you would send the link address as the third argument. Since the code base is different in the sdk it might be something else--for the same use case in s code and a much more in depth discussion, see: https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/pageviews-incrment-in-s-tl-call/qaq-p/178616/comment-id/1606#M1606

      fredrambert
      fredrambert
      Level 2
      January 20, 2021
      Hi @marishg69668790. did you find fix for this? we are experiencing same issue
      dswest_sv
      dswest_sv
      Level 2
      January 21, 2021
      @fredrambert is your third argument an empty string? See the link in my answer from a couple of years ago...i have not verified the sdk issues, but it's remarkably similar in behavior--it's logical that the same fix would work.
      fredrambert
      fredrambert
      Level 2
      January 22, 2021
      Hi @dswest_sv. Thanks for your response. I did see your response from the past. I looked into that, but I don't appear to find any reference to that third argument in the sdk code documentation.
      dswest_sv
      dswest_sv
      Level 2
      January 22, 2021
      @fredrambert have you looked trackAction method to see what it actually does? If it is what i think it is, you won't find it in the docs, only in the code. If trackAction() is simply passing arguments to another method as I suspect, then look to see if that other function handles pageview as well. I would bet that the code smell from s code t() and tl() was carried over to the mobile SDK.
      fredrambert
      fredrambert
      Level 2
      January 25, 2021
      Hi, seems it was due to a processing rule that was populating the Page Name report, which subsequently increments a page view.
      marishg69668790
      marishg69668790Author
      Level 2
      January 26, 2021

      Hi @fredrambert 

      Hope you found the resolution based on your last comment. 

      We had processing rules to concatenate certain context variables and build a string that sets the page name.

      When these context vars are set in the trackAction() call, it completes the rule for a pageName and the pageName gets assigned. The solution is to remove the building blocks that sets pageName if there are  OR  make adjustments in processing rule such that pageName is not set for a trackAction call.

       

      I shall  go back and check my notes on the exact changes we did if you still would like to know.

      Best,

      Terms & ConditionsAccessibility statement

      Loading footer...