Inconsistent Data Collection | Community
Skip to main content
Level 2
January 18, 2024
Solved

Inconsistent Data Collection

  • January 18, 2024
  • 1 reply
  • 1328 views

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jennifer_Dungan

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??)


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

1 reply

Pablo_Childe
Community Advisor
Community Advisor
January 18, 2024

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

Level 2
January 18, 2024

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.

 

 

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
January 18, 2024

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??)


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