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.

[bkoth99]

HI @shayo28675173 

it has been another year. Has this been resolved in the mean time?

Meaning, can we get rid of the patches in our implementation?

[MA1985v1]

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

[bjoern__koth]

@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  

[asadk74975933]

The page view issue is resolved? Can you please let us know what issues are you facing at moment.

[bjoern__koth]

Hi @asadk74975933 

the question is, "is it resolved?".
I don't dare taking away the patches I implemented, risking confused and angry clients to be honest.
So, some kind of official Adobe statement on this topic would be hugely appreciated.

Looking at the Adobe blog here, it is still listed as "Banana Peel #5: 'Send Events' just for Adobe Target".
I wrote in the comments of that blog, asking whether the author can give feedback in this thread.

Cheers

[jgrubbs]

Wow, three years after I created this post and this is still an issue? I'm not sure if I mentioned it earlier, but my company moved on from Adobe Analytics. I'm kind of shocked that Adobe customers are still having to wrestle with this.

[bjoern__koth]

Haha yeah we're not sure whether it is still since no one wants to try out removing the bandaids on a productive environment

[dwright-adobe]

Hi,
Was the source of the additional page calls an additional call used at the top of the page, primarily used by Adobe Target? If so, I think this might be the approach you are looking for, described in these two documents:

• https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/use-cases/top-bottom-page-eve...
• https://experienceleague.adobe.com/en/docs/platform-learn/implement-web-sdk/applications-setup/setup...

This implementation approach allows you to make a "personalization" request at the top of the page (for Target) and an "analytics" request at the bottom of the page (for Analytics, CJA, etc).

The "personalization" call uses an eventType "propositionFetch" which Analytics knows to ignore. The "analytics" call waits for the "personalization" call response so it can include all of the activity details needed for A4T and you won't see the propositionDisplay calls like you would have previously.

[bjoern__koth]

Hi @dwright-adobe ,

that's actually exactly what this thread was all about.

Now, years later, this seems finally fixed. Thank you much for sharing this!

Event though the screenshot in the documentation is slightly different from my extension which shows still "Beta", I think this will finally help us solve this issue.

Thank you, thank you, thank you!

@jgrubbs not sure whether you can still change the right answer, but @dwright-adobe 's is surely the right solution!