Expand my Community achievements bar.

Join us at Adobe Summit 2024 for the Coffee Break Q&A Live series, a unique opportunity to network with and learn from expert users, the Adobe product team, and Adobe partners in a small group, 30 minute AMA conversations.
SOLVED

pageviews incrment in s.tl() call

Avatar

Level 2

Hi Everyone,

I have set a direct call rule and written some JS code in the sequential javascript there. I have opted 'disbaled' in the tracking section of the rule and am using s.tl() at the end of javascript code instead. Below is the specific code line:

    s.tl(this, 'o', 'Success Search');

Now during my testing when I check the beacon for this call happening I see the PageName also being sent in the call and the pageviews also gets incremented accordingly in the Page report.

AFAIK pageviews should not be incrementing in s.tl() call. Any input why this is happening?

1 Accepted Solution

Avatar

Correct answer by
Level 2

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.

Cheers,

Daniel

View solution in original post

5 Replies

Avatar

Level 5

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.

Regards,

Saurabh Kumar.

Avatar

Correct answer by
Level 2

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.

Cheers,

Daniel

Avatar

Community Advisor

This type of issue is handled very efficiently in DTM

You can set up a direct call rule. Then define if it is to be a s.t/s.tl event then within the rule itself define whether or not it is to increment a pageview...Screen Shot 2018-03-13 at 11.35.47.png

Avatar

Employee

Daniel

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”?

Brandon

Avatar

Level 2

Brandon

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

Daniel