Expand my Community achievements bar.

SOLVED

Inconsistent Data Collection

Avatar

Level 2

Although we frequently test (successfully) our websites to be sure the adobe analytics beacon fires for each page view, it is becoming apparent that all page views are not included in our analytics data.  For example, the number of order confirmation page views in adobe analytics is only a fraction (less than 50%) of the actual number of orders submitted via the website, according to our ERP (where the orders are actually processed)

Although there have been minor discrepancies in previous years, this gap appears to be increasing.

Is this what we should expect in the future?

Need recommendations for testing and resolving, or alternatives to an expensive analytics package that appears to no longer provide accurate analytics.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Bah.. the Post-Processing not returning bug is back..

 

 

That is very strange then... if the beacon is sending, you verified that the data is correct... then you should have the data in your system... 

 

Just to be overly cautious... you can confirm on those tracking calls that the suite name is correct? That there isn't a possibility that the data is sending to the wrong suite?

 

 

I asked to confirm the beacon actually sent because there could (in theory) be a JS error in some browsers that could be causing a cascading failure and preventing your tracking from firing... or some "privacy" mode is enabled for site/browser combination that could prevent the call from going through or processing. It never hurts to double check.

 

It can be hard to help this way, we can't see your code, or what you are doing... we can't even be sure of your experience level... so some questions may seem basic but I'm just trying to cover all the bases. 

 

That issue with the Debugger Tool isn't helping matters....not being able to confirm the post-processed values isn't good... I mean, in theory, it shouldn't make a difference if you have no Processing Rules... unless there is some VISTA Rule doing something.... 

View solution in original post

5 Replies

Avatar

Community Advisor

Hi Steve so this seems to be a QA issue and understanding if some of teh following are happening:
- Any edge case where page views are missed due to some sort of bug

- users able to make a purchase via a flow where tagging is not in place

- users making a purchase via a non web interface so ERP registers it but Adobe wont see it.

- payment pages done via 3rd party domains where tagging is tripped up via a redirect

Any info on website is it a SPA type of site (single page app) like angular based?

 

When it comes to QA have you tagged transaction ID as well as purchase event? The reason I ask is it can be a useful metric to then compare ERP to Adobe data and then allow you to see any customer trends for those who are not seen.

 

I then would look at QAing purchase flows via network tab, checking adobe beacon and all parameters sent to adobe.

start with things like device types(mobile vs destop), then mac users vs PC. See if perhaps any browser is a predominant issue. 

 

GLTU

Avatar

Level 2

Our best example of this disparity is the order confirmation page analytics versus the actual number of orders submitted, but this is happening everywhere.

On 1/17/2024 I used the latest version of Chrome, Edge, & Firefox on 4 of our websites with specific URLs (makes them easy to find in Analytics)

Only MKS.com Analytics captured all 3 Tests.  At different times, the rest results will be different, but still incomplete.

stevenb77962023_0-1705589741251.pngstevenb77962023_1-1705589758947.pngstevenb77962023_2-1705589780739.png

stevenb77962023_3-1705589803616.png

 

 

Avatar

Community Advisor

From the sounds of it, you did these test runs yourself, on your browsers?

 

Are you using WebSDK or still on client side tracking?

 

If you are on client side, did you check on all the pages that you had the "b/ss" beacon send and populated correctly?

Did you use the Adobe Experience Platform Debugger (and did you have "Post-Processing Rules" enabled to see the final result of testing)?

Did you use any third party testing plugins like Omnibug?

 

Basically, did you check that the beacons were sending and with the correct information, and that there are not processing rules breaking things after the data was sent?

 

 

 

If you are on WebSDK, things are a little trickier.. but you can still use the Network panel in your browser to check what data is being sent to the XDM stream. The Platform Debugger will also show you some info about what is being sent... I don't know if you can see the post-processed values.. I don't have WebSDK yet, but hopefully there is something that can help pinpoint accurate data mapping....

 

This is the first step anyway, to make sure that your rules are firing and that data is being sent to Adobe... if it's being sent, then you need to make sure its properly mapped.

Avatar

Level 2

Ran these tests myself, with my browsers, using default settings.

We are still on Client Side tracking

I checked that all the pages had a "b/ss" beacon send and populated correctly

I'm using the Experience Platform Debugger, with "post-processing rules" enabled, but even after 15 minutes, those columns remain completely empty (I have checked each report suite and there are no processing rules in any of them)

In all my tests over the last few years, I rarely get to a page that does not send a "b/ss" beacon populated the way I expect it to be (perhaps not everyone else has the same results??)

Avatar

Correct answer by
Community Advisor

Bah.. the Post-Processing not returning bug is back..

 

 

That is very strange then... if the beacon is sending, you verified that the data is correct... then you should have the data in your system... 

 

Just to be overly cautious... you can confirm on those tracking calls that the suite name is correct? That there isn't a possibility that the data is sending to the wrong suite?

 

 

I asked to confirm the beacon actually sent because there could (in theory) be a JS error in some browsers that could be causing a cascading failure and preventing your tracking from firing... or some "privacy" mode is enabled for site/browser combination that could prevent the call from going through or processing. It never hurts to double check.

 

It can be hard to help this way, we can't see your code, or what you are doing... we can't even be sure of your experience level... so some questions may seem basic but I'm just trying to cover all the bases. 

 

That issue with the Debugger Tool isn't helping matters....not being able to confirm the post-processed values isn't good... I mean, in theory, it shouldn't make a difference if you have no Processing Rules... unless there is some VISTA Rule doing something....