Data Element for Page Name Not Sent With Every Hit | Community
Skip to main content
J
joshuab42862197
Level 2
August 20, 2019
Solved

Data Element for Page Name Not Sent With Every Hit

  • August 20, 2019
  • 5 replies
  • 5264 views

I have a Data Element set on every hit to generate Page Name. However, there are thousands of hits where it comes through as unspecified, and I don't understand why. Are data elements asynchronous, or is there something else going on?

This is what I have set up:

  • Processing rule that copies Page Name to eVar61
    • 12% of hits are coming through as unspecified, with no pattern
  • All hits set Page Name using a Data Element
  • Data Element pageName is set as: return _satellite.getVar('pageDomain') + ',' + _satellite.getVar('siteCountry') + ',' + _satellite.getVar('siteSection');
    • Data Element pageDomain is set as: Javascript variable name window.location.hostname
    • Data Element siteCountry is set as: Javascript Variable name digitalData.page.pageInfo.countryCode
    • Data Element siteSection is a very long function, that I believe is at the root of the problem. Is it not getting enough time to complete?

This thread makes me think a solution could be setting Page Name as a condition to the pageview hit.

    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 Andrey_Osadchuk

    Hi Joshua,

    If I understand your case correctly, the unspecified value appears not in the Page dimension, but in the eVar61 dimension. If that's accurate, I guess this is because not all the server calls are processed with the original pageName value — s.tl() calls may be processed the way that despite you can see the pageName value sent from the page, it may not exist when the processing rules start working.

    To verify this hypothesis consider creating a report in analysis workspace where the freeform table contains eVar61 as a dimension, and the following metrics in the columns:

    • Page Views
    • Download links instances
    • Exit links instances
    • Other links instances

    If you see that "unspecified" equals 0 Page Views and N instances, then it would prove the hypothesis.

    Please share the result.

    5 replies

    Andrey_Osadchuk
    Andrey_OsadchukAccepted solution
    Level 10
    August 21, 2019

    Hi Joshua,

    If I understand your case correctly, the unspecified value appears not in the Page dimension, but in the eVar61 dimension. If that's accurate, I guess this is because not all the server calls are processed with the original pageName value — s.tl() calls may be processed the way that despite you can see the pageName value sent from the page, it may not exist when the processing rules start working.

    To verify this hypothesis consider creating a report in analysis workspace where the freeform table contains eVar61 as a dimension, and the following metrics in the columns:

    • Page Views
    • Download links instances
    • Exit links instances
    • Other links instances

    If you see that "unspecified" equals 0 Page Views and N instances, then it would prove the hypothesis.

    Please share the result.

      J
      joshuab42862197Author
      Level 2
      August 21, 2019

      I really appreciate your response Andrey. That is a strange and unexpected behavior, but it makes sense.

      I created the report you suggested and found your hypothesis to hold water:

      What is confusing, is that this is occurring on hits that are set to use s.t() as well. I attach a "Hit Type" dimension to all hits, and Pageview hits are always sent using s.t():

      Regardless, I'm going to test setting eVar61 directly to see if that resolves the issue. Do you have any insight on why pageName would be removed before reaching processing rules?

      Andrey_Osadchuk
      Andrey_Osadchuk
      Level 10
      August 21, 2019

      Thank you for the quick response!

      I think this behaviour of Processing Rules could be driven by the architecture of how s.t and s.tl calls are being processed. The latter should not take into account the page at all and that's why the pageName value gets ignored immediately (or deleted from the beacon/ payload by design) in the data workflow of s.tl calls.

      Just in case, do not try to populate the pageName with the dynamic variable syntax as the result will be the same as with the processing rules. The eVar61 should be set with the actual value.

        J
        joshuab42862197Author
        Level 2
        August 21, 2019

        That makes sense, thanks again. I made this change, and it appears to be working. eVar61 is now always set with the value of pageName.

        However, I do still have instances where there are more Visits than Page Views which makes me concerned that the pageName isn't being set on every s.t() call, but I don't know how that is possible. This is what I have configured:

        Have you had instances where data elements are not populated before the beacon is fired?

        T
        thomas_amsler
        Level 6
        August 29, 2019

        Just to be sure, you don't set the value to the eVar within custom code? If you do, don't forget to also add it to s.linkTrackVars, else s.tl() calls won't track it.

        Terms & ConditionsAccessibility statement

        Loading footer...