Solved

Unintended extra pageviews using WebSDK

Forum|Forum|4 years ago
December 3, 2021
4 replies
12084 views

Hello gang... We've been running with the WebSDK for a bit now and all has seemed just fine. We've been impressed with the performance as well as the relative ease of implementation. Note that we use the NPM module directly, incorporated into our front-end build process.

Throughout testing as well as live data in Analytics nothing has seemed amiss. However in looking at our raw Data Feeds out of Analytics, there are extra "phantom" hits that are being treated as pageviews. There are few if any actual variables set in the Data Feed for those rows, except for some default Adobe ones like page URL, hit time, etc.

And when looking at just raw pageviews in Workspace with no reporting dimensions or segments applied, they can be seen. Our pre-implementation testing and evaluation never included just looking at data this way.

Unfortunately it looks as though these phantom pageviews correlate almost perfectly with the extra calls we make to just retrieve personalizations from Target. It seems that even though I don't set xdm.web.webPageDetails.pageViews.value, the hit is still being treated as such.

Is this in fact the case? And if so, is there some way to stop this from happening. It is absolutely undesirable. A pageview should ONLY be registered in Analytics if it is explicitly stated as such in the XDM.

Best answer by jgrubbs

@jgrubbs Thanks a lot! Insightful!

Here is the recommended short term solution, intended to be used as part of the alloy onBeforeEventSend callback. I've just implemented something based on this and it has alleviated the extra pageviews for now, throwing the "phantom" hits into the Custom Links report

https://gist.github.com/jfkhoury/b390688267854c75d75245ed0c12253b

yuhuisg

Community Advisor

This definitely sounds like a bug with Web SDK. You should bring this up with Adobe Client Care. They can then get the Web SDK product team to look into it with their Analytics colleagues to fix it.

pradeep_nextrow

@jgrubbs I faced a similar issue. AA was counting a page view even when I had not set "web.webPageDetails.pageViews.value" as '1'. I think this is because AA fires a page view event if pageName is present. I am going to try and remove the page name value in those "phantom" calls and give it a try. Let me know if you could get rid of that in the Target call and whether it makes a difference.

jgrubbsAuthor

Hi there... Yeah I did confirm it was the Target calls generating the extra pageviews.

I tried setting tinkering with the pagename, both by ensuring that xdm.web.webPageDetails.name was undefined and even setting up a processing rule to delete Pagename, neither of which was successful unfortunately.

I tried setting xdm.web.webPageDetails.pageViews.value to 0 and even -1, both of which failed as well.

I've been in contact with Adobe and our CSM, and have been informed that a fix is in the works. There is a short term solution available as of this morning which involves transforming these hits into webInteractions. That of course will not stop us from using up our contractual server calls, but it does at least prevent the accumulation of these unwanted pageviews.

pradeep_nextrow

@jgrubbs Thanks a lot! Insightful!

B

b_koth

Hey guys, this seems to have been unresolved for a long time and a workaround is not a fix.

Has anyone received any update from Adobe on this since I am, more than a year later, having exactly the same problems and can imagine that pretty much everyone else has who is using Target mboxes in conjunction with Analytics.

BR

Björn

jgrubbsAuthor

Hi Bjorn,

Unfortunately it isn't fixed. Interestingly shortly after I identified this issue, Adobe did release a "fix" which stopped the unwanted pageviews from accruing while fetching personalizations from Target some time in early 2022, and I was ecstatic! But by March 2022, that change was rolled back because there were apparently 2 customers (I'm exaggerating out of frustration, apologies) that complained because they were relying on that (undesirable) behavior. I suppose they couldn't be bothered by altering their implementation by effectively one line of code in their XDM, but who am I to judge? 🙄

Adobe were also unwilling to offer a switchable functionality, as in, a checkbox or radio button or some other configuration option in the Datastream setup that would allow a customer to track pageviews and fetch personalizations the correct way or continue to use the default undesirable way.

The current situation is that Adobe stopped forwarding the "rendered" events to Analytics, so that at least stopped some of the bleeding.

Adobe did offer the option of writing a custom Vista rule to funnel the unwanted traffic into a null report suite, but I don't know if that is still a viable solution. And apparently writing Vista rules is an old-school way to do things, and I get the impression the resources on staff to do it are scarce. It's probably much like trying to find a COBOL developer to fix some tax calculation software that's been in use since the Carter administration

I want to say that the engineers I spoke with on the WebSDK and Edge teams are utterly brilliant and super friendly. The world needs more engineers like those guys. Sadly, they are at the whim of perhaps misinformed Product Planners/Managers or just the ebb and flow of a massive software company like Adobe.

B

b_koth

Oh my, they could at least point this out somewhere in the WebSDK setup's configuration and provide a standard piece of code like prehiding snippet for Target / Personalization. Just something that indicates that actions need to be taken.

Anyway, thanks for the update!

BR

M

MA1985v1

Level 3

Is this issue resolved from Adobe end? as, right now we have patches to take care of it from our end.

bjoern__koth

Community Advisor and Adobe Champion

@frederikwerner , @jennifer_dungan, @yuhuisg by any chance, do you know anything about this issue's status quo?

@jgrubbs there is a new tutorial on how to integrate WebSDK + Target which also mentions A4T, in which the need for a workaround is not (no longer?) stated.
In a best case scenario, the workaround could be removed, but I am really hesitant to do so 😄

Cheers from Switzerland!

Asad-Kapadia

We've just implemented the webSDK and are also coming across this issue. However I'm not certain if the extra call we are seeing is the Personalisation request. While it contains Personalisation attributes, it does not have the 'propositionFetch' eventType.

Also, our WebSDK extension (v2.27.0) does not appear to have the 'Request personalisation' option shown in your screenshot.

Any thoughts on how we fix this? (cc. @dwright-adobe)

Hello Darrin,

Would you want to debug this on a quick call? Can help you resolve this quicker. Thanks!

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded