Although pageName parameter value may be seen in debugger during onclick tracking call s.tl() but the corresponding page view count does not increment in pages report. I believe page view count that you are noticing in the Pages report is coming from the page load tracking call s.t() that you might have implemented for various pages on your site. s.tl() does not increment page views metrics.
Do let me know if it helps.
2 people found this helpful
In places, Adobe uses all caps to say s.tl will not increment a page view; client care will also tell you that it does not. In the original answer to this thread, Saurabh Kumar, an Adobe engineer, uses bold to say, "s.tl() does not increment page views metrics."
It turns out that s.tl() can and does increment page view metrics under certain conditions. I generally call 'unexpected behavior' like this a bug since it is clearly documented that s.tl() does NOT increment page view--client care will generally insist that you must be calling t() from somewhere and just don't know it. The way the bug manifests depends on your version of s code. The basic gist of the issue is that s.tl() takes up to five arguments--fewer than 3 can net a page view despite example code in the adobe docs which show only two being passed (e,g, s.tl(this, 'o') which will cause a page view)--also, an empty string in position 3 doesn't count as having passed an argument. Though certain docs indicate that the third argument is optional ("if it is set..."), leaving it unset, or as an empty string can end up with what manifests as looking an s.t() call when s.track creates the image request. The same is true for the second argument in some versions of s code. In testing i was not able to find a variant on the object/bool expected as the first arg that triggered the bug and I have not dug deeper, but that does not mean that there is not some variation (or was with the version of s code the OP was using).
The first (1) arg is expected to be either an object with a href, or, a boolean true (I know, right?), passing a null should be valid since an object could come back as a null, and in testing, that did not trigger the bug.
The second (2) arg is for link type. It is expected to be a string with a length. Expected values are 'e', 'd', or 'o'. An empty string will trigger the bug in some versions of s code and increment the pageview as if t() were called. We also tested tl calling with a non-expected value with a length of 1 ('f'); that did not trigger the bug and the pageview counter was not incremented.
The third (3) arg is for link name. It is expected to be any arbitrary string value. An empty string will trigger the bug in some versions of s code and increment the pageview as if t() were called.
the fourth (4) arg truly is optional; it's an arbitrary string.
Digging deeper into s code, you will see that both s.t and s.tl call the same function, s.track(). s.track constructs the image request which is sent to the server. The fix for Adobe could easily go down either of two paths: 1) make the call safe so that tl() always sets the differentiating variables in the called function, or 2) call something other than track from tl that always safely sets the variables.
You can test this in the console pretty easily. With three required args, there are not many permutations so it's not that bad to try different values.
In your scenario what are you using to validate your “page call”. where you seeing the number increment in this testing where the s.tl() is fires and a page view is “recorded”?
three ways, 1) pageview report shows incrementing on a call to s.tl; 2) pe/pev2 not sent in request; 3) raw data
You can follow progress and get more details at AN-158955