I'm also having trouble getting this to work correctly. Following Adobe's guidelines, 'exp' should be set as POSIX time (seconds since the Epoch).That can be implemented in Javascript like this: const thirtyMinutesFromNowInSeconds = (Date.now() / 1000) + 30 * 60; However, changing the seconds affects the access token response very little. It seems that no matter what I enter, I get expires_in: 86399995 as the response.Building on this, I think the 'expires_in' parameter returned in the access to...

Building on this, I think the 'expires_in' parameter returned in the access token response can be interpreted as milliseconds. At least I hope. Will be testing this.

You got it. I didn't realize it would disable the classification if it had been used in another rule set.Thank you for the help. After looking through, I found which rule set was using the variable and added my rule there.

Due to clearVars()... I didn't think that through. Very strange... The change you made using s.tl(this...) is going to apply a delay to tracking the link. Your original configuration of s.tl(true...) was best.Where are you setting docLength? If this isn't working, it seems like there must be other code causing the bug.Try this:var s=s_gi('mfs-distribution-intranets');s.linkTrackVars='prop1,prop46,prop50';for (var i = 0; i < myDocs.length; i++) { s.prop1=articleIDs[i]; // stores compliance number...

What happens if you define s and s.linkTrackVars outside of the for loop?Setting props to '' shouldn't be necessary as clearVars() will set them as undefined. And null isn't necessary as the fourth argument in s.tl(). These shouldn't affect anything, but simplifying your code could make it easier to find bugs.Are you positive the id you're setting in s_gi() is the name of your report suite?

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?

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 remo...