Data Element for Page Name Not Sent With Every Hit

[#1]

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.

[#2 · Accepted solution]

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.

[#3]

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.

[#4]

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.

[#5]

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?

[#6]

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?