Unintended extra pageviews using WebSDK

[jgrubbs]

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.

[yuhuisg]

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.

[jgrubbs]

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!

[jgrubbs · Accepted solution]

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

[asadk74975933]

Hi, where do we set this page view event in? which code? I have multiple page load rules and custom link rules?

[yuhuisg]

ignore this

[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

[jgrubbs]

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_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

[pradeep_nextrow]

This issue is happening to many new migrations as well and consultants inside Adobe are grappling with this. I have redirected them to this useful thread and at the same time asked them to highlight this in internal meetings, so that it gets some visibility across the product managers.

[b_koth]

But how can this not be treated as a road block since it is obviously also resulting in massive additional server calls to AA which then will also increase the cost on client side? 
I am really struggling to understand why this has gone so long under the radar and if it has been fixed once, then rolled back because clients have started working their way around it??

One question I have now is: are there other event types which cause the same behavior or is it "just" Target?

Any ideas?

BR

Björn

[jgrubbs]

The only event type that isn't automatically forwarded to Analytics is "decisioning.propositionDisplay" if I recall. This is the event that the WebSDK sends once the Target offer(s) are rendered. This was the "UNfix" Adobe applied in late March.

If you don't specify an event type and have not defined the web.webInteraction object in the XDM, then it is automatically treated as a pageview, as though Konductor just plugs web.webPageDetails.pageViews.value = 1 in there for you

[shayo28675173]

I would like to provide some more detail on the current situation and upcoming changes. Currently events sent to Experience Edge are forwarded to all services that are enabled for a data stream. As noted in this thread, that means that events that are sent to Target are also sent to Analytics. There is currently special processing in place for calls with eventType = "decisioning.propositionDisplay",  to minimize the impact on A4T reporting. Besides this special case, in order to avoid sending additional calls to Adobe you need to combine the Target and Analytics calls.

We realize that in many cases it's not practical to combine the Target and Analytics calls. Often the Target call must be sent quickly to ensure a smooth personalization experience (aka "top of the page") while the Analytics call must wait to ensure all relevant data is ready (aka "bottom of the page"). We are building a solution that will support this scenario and hope to have it available in the first half of this year. The solution will provide a way to make calls that are only sent to Target and not other services. Any A4T responses from Target will be returned to the client so that it can then be included on the subsequent Analytics call.

I do want to acknowledge that the current limitations present a difficult choice for you - unify Target and Analytics calls or send additional calls to Analytics. We believe the upcoming solution address this and provide more freedom with Web SDK implementations. We hope to have updates on the specific timing of that solution shortly. Until then please feel free to contact me directly or respond to this thread if you have any additional questions or concerns.

[b_koth]

Hi @shayo28675173 

thank you for the detailed answer. It really helps to understand the problem a lot better resp. confirms the knowledge and assumptions contained in this thread from an official Adobe perspective.

As mentioned earlier, if this is a known issue, I think it would help many developers to add some kind of hint in the WebSDK extension's configuration itself and/or add it into the official Adobe documentation until this is fixed, raising awareness and providing the workaround code snippet there, maybe giving it an ofiicial Adobe code review

BR and thanks again for the information

Bjoern

[shayo28675173]

Thanks @b_koth. Yes, the documentation should be more explicit about this. I will work to get some updates published in the coming weeks.

[isaakskinner]

Experiencing the same issues as outlined above, is there any update on expected timelines for this fix? Sounds like intially it was the 'first half of this year' and as we approach that, wondering if that is still the expected timeline. Cheers

[bjoern__koth]

Unfortunately not that I am aware of  

[pintosahu]

Hi @shayo

When will the above issue get fixed?

Regards,

pinto

[jgrubbs]

Oh my. This issue I reported 2 years ago is still ongoing? I feel for you all and really hope that Adobe are able to offer some kind of resolution or workaround. My company ended up leaving Adobe about a year ago, so I have not been in the loop regarding how this story has evolved