@fredrambert have you looked trackAction method to see what it actually does? If it is what i think it is, you won't find it in the docs, only in the code. If trackAction() is simply passing arguments to another method as I suspect, then look to see if that other function handles pageview as well. I would bet that the code smell from s code t() and tl() was carried over to the mobile SDK.

@fredrambert is your third argument an empty string? See the link in my answer from a couple of years ago...i have not verified the sdk issues, but it's remarkably similar in behavior--it's logical that the same fix would work.

This looks to be related to the same bug in s code that I reported a couple of years ago. I'm betting that if you trace this you will see the same behavior noted when only two args are passed to s.tl(). Check the docs on the sdk and see if there is not a third argument for the link which expects a string (generally you would send the link address as the third argument. Since the code base is different in the sdk it might be something else--for the same use case in s code and a much more in depth...

Brandonthree ways, 1) pageview report shows incrementing on a call to s.tl; 2) pe/pev2 not sent in request; 3) raw dataYou can follow progress and get more details at AN-158955Daniel

Hi @ParthaS,Not an issue of billing, but at this writing, s.tl() can increase the page view counter under the right conditions...there is a bug in the s.tl function in which, if a value for arguments two or three is an empty string (or missing), then the subsequent request created by s.track() will not include the pev2 and pe params...the result will be a page view recorded just as if you had called s.t (s.t also calls s.track()).This is particularly bad since certain adobe docs show s.tl being ...